ТНК, раз уж у нас тут теперь форум
позволю себе порассуждать на эту тему. Не столько в ответ на ваш вопрос, сколько высказать свое видение проблемы, чтобы люди, попадающие в эту тему смогли понять о чем идет речь.
Логически любой модуль управления освещением можно разделить на две крупные части:
1. Исполнительная (входы, выходы)
2. Интерфейсная
Что касается исполнительной части, все просто. Если это чистый исполнитель, то реле или электронный ключ (тиристор/симистор), который, к слову, лично мне нравится больше по причине своей бесшумности, но есть некоторые ограничения по подключаемой нагрузке. Удобнее, как мы уже определились, делать (как минимум) сдвоенные модули типа Вход-Выход. Когда вход (выключатель) в определенных условиях, в рамках заложенного алгоритма может управлять выходом (лампочкой) напрямую без участия контроллера, компьютера и т.д. Лично у меня контроллер (он же сервер, ПК) включен всегда, ибо на нем такое количество задач, что на P4 uptime не опускается ниже 1.5-2.0 (грубо говоря, это 30-40% от максимальной комфортной нагрузки на систему), поэтому в таком модуле я бы хотел предусмотреть режим, когда при срабатывании выключателя модуль сначала спрашивает сервер что делать, а если не получает ответ или ответ типа destination host unreachable, то действует по-умолчанию, например как простой коммутатор нагрузки. Но это все детали, тут каждый сам решает как ему удобнее.
А вот с интерфейсной частью сложнее. В отличие от исполнительной части, интерфейсная, как это ни странно, определяется:
а) задачей
б) существующей инфраструктурой (проводка, отделка)
в) стоимостью дальнейшего развития, зависимостью от производителя
г) возможностью интеграции в другие системы (наличием шлюзов, открытых протоколов и т.д.)
Вариантов, о которых вы говорите, далеко не два. У нас есть управляемый выключатель с микросхемой (которая, помимо нужного нам интерфейса, реализует некоторую логику по умолчанию). Как этим выключателем можно управлять (проверять доступность, состояние, отправлять команды и т.д.).
1. Шины (1-wire, RS485+Modbus, CAN, Profibus, LONwork, EIB) и т.д.
2. Силовая проводка (X10/S10, Xanura, INSTEON, PLC*) и т.д.
3. Радио (ZigBee, Z-Wave, X10 RF, 433Mhz*, GSM) и т.д.
4. Ethernet
Шина. Любая шина (если это не радиореализация) требует провода (как минимум 2-х: данные и земля). Часто по кабелю передается питание, а значит нужно еще 2 проводника. Шина должна быть неразрывной и проходить через все модули с минимальными ответвлениями. В качестве кабеля удобнее использовать "витую пару". Если мы разрываем шину, у нас "отваливается" кусок сети со всеми модулями. Шина удобна когда модули расположены последовательно на длинном расстоянии (в условиях производства, например) или когда по всему дому у нас множество распределительных щитков. Тогда нам нужно просто проложить один кабель через все щитки. Большинство шин (хотя и не все и не всегда) строятся по типу мастер-слейв. Мастер спрашивает, контроллер отвечает. Без мастера модуль может работать только "сам в себе".
Силовая проводка. Никакой кабель не нужен вовсе. Питание также берется из электрической сети. Ничего прокладывать не нужно. Модули могут монтироваться либо в щитки, либо прямо у электроприборов. Но в 3-х фазной сети нам нужно предусмотреть репитеры, иначе команды между фазами проходить не будут, на входе поставить защиту от управления извне. Модулей отправляющих команды в сеть может быть несколько, но нужно смотреть ситуации с разрешением коллизий. Скорости обычно не высоки. Надежность работы сети высокая, но не 100%. При отключении электричества сеть не работает.
Радио. За редким исключением (ZigBee, Z-Wave), когда мы говорим именно о сети, а не о связке 1 контроллер - 1 модуль, тоже самое, что и все остальные технологии, только по радио. Плюс в том, что не нужны провода. Минусов тоже хватает: питание по радио не передается, а значит нужно решать вопрос питания модуля локально; помехозащищенность ниже чем у проводов; защищенность от взлома и управления извне гораздо ниже, чем у проводов; в ряде случаев и скорость ниже, хотя бывают и исключения.
Ethernet. Топология звезда. К каждому модулю идет свой кабель (витая пара). Необходимо устанавливать сетевые коммутаторы. Это минус, жирный. Все остальное плюсы.
- Скорость до 1Гб/с а в перспективе и 10Гб по обычному кабелю Cat 5/Cat 6
- Модули могут "разговаривать" друг с другом без компьютера/мастера/контроллера
- Отменная помехозащищенность, низкоуровневая фактически аппаратная реализация разрешения коллизий, наличие коммутатора, который не "смешивает" траффик
- Полностью изученные, разработанные, надежные, совместимые, удобные в использовании протоколы начиная от NetBIOS и IPX, заканчивая TCP/IP
- Фактически не требуется никакого аппаратной или программной совместимости. Если все модули "говорят" на одном языке (TCP/IP), соединили в сеть и работаем.
Выбор интерфейса - вопрос сложный. Необходимо взвесить все за и против. Все, что я перечислил выше можно собрать своими руками. Есть микросхемы для реализации CAN, RS485, X10, Ethernet, есть готовые модули для ZigBee, Z-Wave.
Теперь касательно Вашей темы. Не совсем понимаю зачем эмулировать работу 1-wire чипа, когда можно к выходу и входу AVR присоединить нормальный 1-wire чип. AVR будет сам принимать решение о включении/выключении, сообщать через выход о состоянии ключа и управлять через вход командами 1-wire сети. Если только из экономии или по причине недоступности компонентов. Но экономия получится копеечная, а любая софтверная реализация, полагаю, будет сильно уступать тому, что заложено в чип. Все-таки 1-wire достаточно сложная технология.
А что касается IP Power, так это просто конкретная железка. Да, у нее есть недостатки, но мысль заключалась не в этом.
К примеру у нас есть модуль, к которому подключен датчик протечки, скажем, на 2-м этаже в ванной. Есть модуль, "висящий" на управляемом аварийном кране в одной части подвала и такой же модуль в другой части подвала. А у меня в частности в доме два входа воды. А также модуль или несколько в щитке, которые управляют электрикой в ванной. Сработал датчик протечки. Модуль, к которому подключен датчик спрашивает у компьютера что делать. Но вот беда, у компьютера вышел из строя блок питания! Тогда модуль "знает", что ему надо отправить команду 1 и 2 аварийным кранам, чтобы те закрылись и еще модулю, который бы обесточил ванную для предотвращения КЗ. Учитывая, что модули находятся в разных частях дома, реализовать задачу в одном устройстве невозможно или крайне затруднительно. Шина с мастер-слейвом в данной ситуации будут "курить", а через пару часов в доме уже будет десяток-другой кубов воды. Ситуация с протечкой не выдуманная. За два с половиной года я сталкивался с протечкой уже два раза. Причем последний раз пару дней назад, когда случайно обнаружил, ложась спать, что у меня вырубилось уличное освещение. А когда пошел в подвал, где у меня расположена котельная и серверная, обнаружил весьма чудную картину. Если бы это происходило до утра, то у меня накрылось бы все оборудование. В лучшем случае. В описанном подходе есть только один минус. А что если одновременно выйдет из строя коммутатор? И здесь есть решение. В ПО модулей необходимо будет реализовать проверку сети. Если сеть недоступна более, чем на 30-60 минут, срабатывает аварийный сценарий.
Что касается элементной базы, то сейчас я тестирую собранное на макетке устройство на AVR + Ethernet и напишу об этом статью отдельно.
