"С" обозначает номер ревизии.

Wiki: Revision C was issued in a document dated August 1969. Revision D was issued in 1986. The current revision is TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, issued in 1997.

Мне лень было проверять
Но не важно, суть в другом названии.

Про UART вам тоже лень было проверять... Нет никакого UART в TIA-232-F, ни сном ни духом. Более того, прямым текстом стазано, что последовательные данные могут быть и синхронные, и асинхронные.
Зато скорость ограничена, не более 20 кбит/сек. И разъемы только 25- или 26- контактные.

То есть, ссылка на RS-232 на самом деле практически ничего не значит. Стандарт оговаривает одно, а реальный писюковый интерфейс просто кое в чем похож на него и отчасти совместим.

А я такое не утверждал. Я только на слово defunct-у поверил, что RS-232C объединён сразу с UARTом.
Причём ясно написал, что по 232-ому можно и SPI передавать. Какие проблемы?


Чтобы не быть голословным - приведите определение или укажите на неточности "описания" определениями других терминов.

А вот SPI как раз не получится законным образом, поскольку назначение всех линий оговорено стандартом, а клока там нет.



Уже приводилось:

Интерфе́йс — совокупность средств и методов взаимодействия между элементами системы.

Это противоречит тому что приводил defunct?


То есть там оговорены линии RXD и TXD, но не оговорен формат посылки/фрейма, который по ним можно передавать?
Если это так на самом деле, то тогда при передаче SPI по RS232 можно говорить, что это SPI по электрически совместимому интерфейсу RS232.

Да, противоречит. Потому что в определении нет той отсебятины про "обязательное наличие протоколов", которую он несет.

Замечу, что англоязычные вообще не испытывают никакого пиетета перед стандартами, определениями, формальной точностью и пр. Эти заморочки более характерны для говорящих на немецком и русском. Поэтому английская википедия вообще не утруждает себя давать формальное определение. Они довольствуются неформальным иллюстративным описанием.



Формат не оговорен - это полбеды. Cигнала клока нет. А без клока не бывает SPI.

Отсебятина у вас. Речь шла об интерфейсе передачи данных (в частности между девайсами). И это не тот в широком смысле интерфейс. И определение должно оперировать более специализированными терминами, касающихся передачи данных по проводным/радио каналам.

В магазине спросить:
- Дайте мне чернила для восьмого класса! (с)

Бритва Оккама: нельзя вводить лишних сущностей без нужды. Рекомендую к использованию.

Мимо кассы.
Есть много типов интерфейсов. И они вполне продуманно отличаются. В частности интерфейс пользователя имеет мало общего с интерфейсом передачи данных (по каналам связи). Кроме того каждый тип интерфейса имеет свои особенности.
http://ru.wikipedia.org/wiki/%D0%98%D0%BD%...%B5%D0%B9%D1%81

В этой ветке подразумевался и весь спор идёт только вокруг интерфейса передачи данных. Моё имхо (искать где-то определения мне лень) что интерфейсом можно обозвать как исключительно электрические уровни сигналов RS-232 (хоть RS-485 и др.), так и более сложную связку например электрические характеристики, временные, механические разъёмы, кол-во линий связи и функциональное их назначение. Вплоть до подробного описания протокола обмена, если он жёстко заложен в какой-то девайс. И это вполне честно будет интерфес этого девайса. Но протокол как и разъёмы и прочее (вобщем все составляющие) не являются обязательными в описании конкретного интерфейса.

На всякий случай повторю цитату http://ckp.made-it.com/rs232.html:

The description of RS232 is an EIA/TIA norm and is identical to CCITT V.24/V.28, X.20bis/X.21bis and ISO IS2110.
X.20 DTE-DCE интерфейс старт-стопной передачи данных по сетям общего пользования


На той же страничке Wiki абзацем выше:

Details of character format and transmission bit rate are controlled by the serial port hardware, often a single integrated circuit called a UART that converts data from parallel to asynchronous start-stop serial form. Details of voltage levels, slew rate, and short-circuit behavior are typically controlled by a line-driver that converts from the UART's logic levels to RS-232 compatible signal levels, and a receiver that converts from RS-232 compatible signal levels to the UART's logic levels.

Может всё таки вернутся к началу.

1. Есть дом
2. В нем N -слейвов со своими задачами.
Вопрос 1.
Нужны ли данные ( например мне ) от всех слейвов. Задача охраны дома , естественно не рассматривается только - комфорт.
Скорее всего нет. Значмт останется N-m.
Вопрос 2.
Насколько мне важны данные от оставшихся ? Т.е отпадает ещё группа слейвов , данные от которых нужны , для примера , один раз в неделю-месяй-год.


Вот и останется да группа, данные от которых нужны постоянно, но сколько их в итоге?
Нужен ли будет этой группе мастер?
И исходя из данной группы , помоему и нужно выбирать интерфейс , протокол. Может всё в UART уложится ( грубо).

А статус исправен/неисправен интересен? Если да - то при запросе статуса, можно и данные получить.. т.е. задача получить данные от слейва, будет фоновой для мастера. И зачастую она одинаковая для всех слейвов, независимо от их типа.

На этом сайте много других косяков такой же разнузданности. Например, про RS-485 сказано, что "выходное сопротивление передатчика 100 Ом", а минимальное входное приемника якобы равно 4 кОм, а не 12 кОм, как на самом деле. Тоже прикажете этому бреду верить?

Данные нужны тому, кому они нужны. Если настенный выключатель только включает/выключает лампочку посредством релейного модуля, то никому, кроме этого модуля, данные от выключателя не нужны.


Сегодня вам задача представляется в одном виде, через год-другой захочется что-то изменить, прежде всего - добавить. И тогда можете упереться в ограничения, заданные исходя из сегодняшних ваших представлений.

Скорее это риторический вопрос . Хорошо , блок вышел из строя. Причина неисправности может быть определена только когда сам блок у Вас в руках или Вы можете его протестировать.
Но предположим , что на блок просто не подается внешнее питание. Считать это неисправностью.? Если в первом случае я смогу , удаленно протестировать блок , но именно сам блок , то во втором ,я ничем не смогу помочь .

Я на досуге экспереметировал со светом в ванной комнате ( датчик присутствия ) и с наливанием воды в бачок ( датчик давления с частотным выходом и электрический клапан от той же стиралки) Mega48.
Сгорит лампочка , воду отключат - хорошо я дополню код тестом для проверки целостности лапочки , клапана , датчика. Но необходимости в получении в сети этих данных я не вижу. При выходе их из строя - требуется моё личное присутствие.


Согласен , такой вариант исключать нельзя. Я конечно думал по этому поводу, но до конца .. пока туманно. Так что я отложу ответ на короткое время , но обязательно его дам

+1
У всех грузовиков и автобусов сейчас только CAN. До 2006 г. выпуска ещё J1708 встречалось, а сейчас вообще ничего, кроме CAN нет. У легковых тоже доля CAN-а стремительно приближается к 100%. Автомобильные интерфейсы на базе UART (типа K-Line) и со своим протоколом (типа J1850 - кстати, урезанный CAN напоминает) последние дни доживают - только в старых ЭБУ, которые ради экономии ставят на новые машины, и встречаются. Сейчас уже фактически стандарт, что все устройства (двигатель, АБС, КПП, кондиционер и т.д.) в одной сети живут. А скоро и юридически это закрепят. Тогда только CAN и останется. Ну м.б., конечно, что-нибудь получше CAN-а придумают, но на сегодняшний день я ничего такого не видел.
Это я к тому, что стали те старые интерфейсы тормозом. Из-за них кучу лишнего железа автодиагностам держать приходится. А в своё время, когда эти интерфейсы внедряли, наверное, тоже об экономии думали. А уж в новых разработках модбас, который уж 10 лет назад похоронить нужно было, использовать - это просто смешно.

Сам факт что блок ответил и есть признак исправности.


Естессно, потому что если это выключатель, то он не сможет ничего ни выключить, ни включить, когда нет питания.


А к чему этот +1? CAN уже было сказано автомобильный интерфейс, а то что требуется для автомобиля в доме не нужно. Нет в доме, таких температур, вибраций, влажности, риска для жизни как в автомобиле на дороге..


Кому это нужно? Мне например не нужно его хоронить, пусть живет.
И ppp пусть и slip и hdlc и ipv4 / ipv6 и i2c, и Кан в автомобилях .. Оно одно другому не мешает.


если разработчик не смог построить систему с применением модбас - это не значит что модбас чем-то плох, это значит что разработчик - дебил некомпетентен в вопросах построения распределенных систем, и CAN ему не поможет. Не выйдет построить более сложную систему (с CAN'ом система будет сложнее) когда более простую ниасилил.

К тому, что нужно о расширении думать. А с CAN-ом в автомобилях - это всего лишь пример. Ну не хотели его сразу использовать, по причине дороговизны или ещё по каким, на таки потом всё равно пришлось. И затрат в итоге больше. Так и тут - не стоит из-за сегодняшней копеечной экономии лишать систему расширяемости.

Согласен, но только в том случае, если систему в принципе возможно построить на модбасе. Т.е. нерасширяемой. А если понадобится ещё один мастер, и чтобы мастера в одной сети работали и друг-другу не мешали. Или не один мастер, а несколько?
По аналогии с автомобилем - систему кондиционирования в прицепе добавили, или систему контроля давления в шинах, или ещё один двигатель. Сейчас просто блоки управления на общую шину вешаются и всё. А если бы там модбас был? Ещё несколько витых пар параллельно тащить?

Почему не расширяемой?! На уровене где используется модбас система прекрасно расширяема, по мере необходимости можно добавлять больше и больше дешевых выключателей в одну сеть, ИК устройсройств и т.д.!
Но полная система не заканчивается одним Модбасом. Если хотим универсальности, в итоге все равно получится много уровней - нечто такое:



21-й век, без управления через интернет система мало кому будет нужна.
Модбас это всего лишь нижнее звено, как и CAN. Неограниченные возможности масштабирования сейчас дает Интернет (ipv4/ipv6), просто нужно предусмотреть выход в него... Когда система представлена одним мастером как в модбас - достаточно высунуть наружу в интернет только его... В случае с кан придется делать отдельное устройство сопряжения, по сложности как мастер RS485-й сети - ну и какой смысл от Кана в таком свете? Заменить одно сложное устройство плюс много простых (Modbus сеть с мастером-конвертером в Ethernet), на все сложные и одно очень сложное (CAN сеть с конвертером в Ethernet)?


Собсно и предложил делать большое начав с малого:
1 мастер с ethernet и RS485-м интерфесом. Много RS485-х слейвов и управление с компа по ethernet.

Ранее обсуждалось, что система должна реагировать на пользовательские воздействия за ограниченное время, в районе 100-300 мс. Если с момента нажатия на кнопку до включения/выключения лампочки проходит больше времени, порядка 0.5 сек и более, это начинает раздражать. В сущности, требование ограниченного времени реакции делает систему управления домом системой реального времени.

Возможность "логического" расширения системы есть малый аспект проблемы. В процессе расширения система обязана оставаться системой реального времени. Это накладывает дополнительнуе требования. Тупая система "мастер-слэйв", в которой мастер регулярно опрашивает узлы на предмет наличия новой информации, с ростом количества узлов начинает дико тормозить. Ведь помимо того, что мастер тратит больше времени на опрос, он еще тратит больше времени на рассылку собранной информации. В какой момент такая система станет настолько тормозной, что пользоваться ею станет неудобно, можно прикинуть заранее.

Что же касается интернета и т.п., то он никак не может работать в качестве системы реального времени. Поэтому глупо ссылаться на него, как на средство улучшения масштабируемости системы реального времени.

Все ли согласны, что слейв должен быть простым устройством?
А не будет ли самым верным решением сделать, скажем, "контроллер комнаты"?
В контроллер сходятся все провода от всех выключателей и лампочек одной комнаты (порядка 16 входов и 16 выходов; если больше, то можно в комнату поставить несколько контроллеров).
Контроллер берет на себя все функции управления электрооборудованием только этой комнаты. Если что-то надо передать в другие "комнаты" или получить из других "комнат" - использует общую сеть.
При таком подходе комнаты локально-живучи, сеть не нагружена неактуальным трафиком, все устройства одинаковые по сложности (просто - одинаковые).

Я бы предложил следующие критерии:
- число "комнатных" контроллеров и места их расположения выбирать с позиций оптимизации кабельных трасс и удобству эксплуатации. Пусть вся проводка комнаты сходится в один щиток (коробку), в котором установлен контроллер, защитные цепи (автоматы, УЗО), резервные цепи (перевод Умного Дома на ручное управление).
- в сеть должны передаваться только те сообщения, которые точно будут использоваться другим контроллером/и. При этом надежность передачи высокая не нужна - подумаешь, не выключил свет в ванной из спальни. Попробуй второй раз, в конце концов сходи ножками и выключи. К сети можно подключить "комнатный" контроллер с функцией Ethernet (имея реализацию Ethernet и CAN, скрещивание производится в считанные часы).

Риторический вопрос: уважаемый All менял ли когда разбитую лампочку в люстре, управляемой Умным Домом? Нельзя быть уверенным, что ток сейчас не появится. Отрубать автоматы - остаешься без света. Дилемма еще та)

Для этого в выходном устройтве (т.е. в релейном или диммерном модуле) ставятся выключатели "override" на каждый вых. канал.


Проводов будет много. И ставить его в комнате негде.

Самым верным решением будет "контроллер светильника", к которому по радиоканалу может "достучаться" любой выключатель в комнате. Никаких "мастеров" не нyжно, это лишний хлам.

"Проводов будет много. И ставить его в комнате негде.")



Проводов будет как в обычной квартире. (может больше, но порядок тот же)



Жить в микроволновке? Радиомодулям тоже нужно питание (выключатели, например). Радио саботировать легче.

Override кнопки должны стоять на модуле управления. Для примера, модуль 12-канального реле:
Нажмите для просмотра прикрепленного файла


Мобильник таскаете в кармане - не напрягаетесь? А ведь он все время "разговаривает" с базовой станцией, причем, мощность излучает недетскую, порядка ватта. А тут вдруг забоялись RF-линка, который в момент нажатия на кнопкy коротко пискнет с мощностью не более 10 мВт, а все остальное время помалкивает, чтобы батарейку не расходовать.

Питание радиомодуля - литиевая батарейка. Срок службы батарейки 10 лет.

Про "саботирование" - напомнили анекдот:
- Вон скачет неyловимый Джо.
- Что, действительно никто поймать не может?
- Да просто он нафиг никому не нужен.

Все уже сделано до нас.
PROFIBUS/DP.
Время реакции системы на любое изменение на удаленных модулях 10 мс.
В большинстве случаев это "тупая система мастер-слейв" RS485.
Реже - это мультимастер с "токеном", бегающим по кругу.
Скорость в канале 12 МБод.
Интересно, а способен ли CAN на такие скорости.

Для PROFIBUS-DP требуется дорогой кабель, высококачественная экранированная витая пара. При 12 Мбит/сек суммарная длина кабеля 100 м, число узлов 32 в сегменте, а кабель должен обходить узлы последовательно, произвольная топология не допускается. Значит, к каждому выключателю придется тянуть два кабеля, плюс питание.

PROFIBUS-DP - это интерфейс второго уровня иерархии, на уровне датчиков и исполнительных механизмов используются дрyгие интерфейсы.

А теперь сравните это с C-bus, который специально заточен для "умного дома"
- для питания маломощных узлов специального кабеля не надо, сигнал и питание идут по одной паре
- расстояние - до 1 км в сегменте, число узлов >100 в сегменте, а с репитерами число узлов практически неограничено
- кабель - любая витая пара, топология разводки - любая

В чем секрет? C-bus использует малyю скорость обмена, всего 5 кбит/сек. За счет CSMA/CA обеспечивается комфортное для человека время реакции на нажатие кнопок, при этом количество кнопок и исполнительных устройств роли практически не играет - замедление случается только при совместных событиях, которых практически никогда не бывает, даже если большое здание или стадион обвязать единой сеткой. В таких условиях PROFIBUS-DP смог бы работать только при иерархическом разбиении системы на уровни, иначе - захлебнется и мегабиты не помогут.

Да, это идеальное решение. И его не нужно изобретать, - уже продается - ~40 грн - 3 розетки (1/1.5кВт) и пульт в комплекте на 5 радио каналов / 5 устройств на канал.

Высоко-приоритетное событие, такое как нажатие на кнопку, никто не мешает по особому обрабатывать во всех узлах сети. При появлении такого события, ставить его в высоко-приоритетную очередь в каждом гейтвее, тем самым сократив Latency до Network Transit Delay между двумя устройствами. Если в системе будет присутствовать модбас мастер, то получив сверху высокоприоритетную команду, он немедленно прерывает поточный опрос, формирует и отправляет команду исполнительному устройству.

Допустим опрос одного устройства мастером в модбас сети занимает 10мс. Допустим в некой модбас сети1 есть один пульт с кнопками (хотя пульт лучше ставить в скоростной CSMA сети), тогда мастер этой сети каждый второй опрос посылает пульту. Итого latency от момента нажатия на кнопку до момента регистрации этого события первым мастером == 20ms, мастер немедленно по ethernet отсылает событие на сервер. Сервер транслирует событие в другую модбас сеть2, пусть трансляция от мастера1 до мастера2 по ethernet через сервер займет еще 20ms. Мастер2 получив высокоприоритетную команду, завершает текущий опрос и немедленно переходит к исполнению команды, что так же займет максимум 20ms. Итого 60ms latency (по максимуму) между пультом в одной модбас сети и исполнительным устройством в другой модбас сети, с транзитом через ethernet. В обратную сторону, подтверждение на пульт займет столько же. Итого 60ms с момента нажатия на кнопку до реакции, 120ms до подтверждения на пульте. Прекрасно укладываемся в требования - 100-300мс.

C пультом в Ethernet сети, и исполнительными устройствами в модбас сети, latency будет вдвое меньше.
C пультом в той же модбас сети где и исполнительные устройства - втрое меньше.

Игрушка для энтузиастов. Люстру такой не включишь, пульт на стенку вместо выключателя не пристроишь - и угробище, и трудно разобраться, на что надо нажать, чтобы зажглось именно то, что хочется.

А я вообще не понимаю, зачем он нужен, "умный дом"? Неужели так трудно встать с дивана и включить люстру? И так уже у всех поголовно дистрофия, аритмия, гиподинамия, лишний вес и прочие "прелести" тех. прогресса.

Нет, конечно, если дом трехэтажный и по десять комнат на этаже, подземный гараж, рядом с домом баня и приусадебный участок в 2 га, то да, оправдано.. А в обычной трешке всё это бесполезная "Игрушка для энтузиастов"..
Также как и Интерфейс для этой игрушки.

Если говорить о жилом доме, то:
- Уходя из дома, можно весь свет в доме выключить одной кнопкой.
- Если где-то в потолок встроено много галогенок, то можно настроить несколько вариантов освещения. Например, у меня в гостиной 7 галогенных лампочек, разведенных на тройной выключатель. Однако жестко настроенных проводкой вариантов не хватает, иногда хочется настроить по-другому. А лазить менять проводку че-то совсем неохота.
- Когда уезжаешь в отпуск, можно заставить "умный дом" включать/выключать свет в комнатах так, чтобы с улицы казалось, будто в доме есть люди. Меньше вероятность, что вломятся в пустую квартиру.
... и т.п.

В общем-то Вы оказались в большинстве!

Идея умного дома для всех давно в кризисе, нет квалифицированных людей, чтобы все смонтировать все и настроить и потом обслуживать. Поэтому это делают или одиночки для себя, или небольшие фирмы в качестве разводилова для очень богатых людей.
Я строил дом и делал электрику и отопление сам, и сделал это без наворотов.
Мои приоритеты - розы в саду, они живые, в отличие проводов.

А интерфейс лучше всего - Ethernet. Вот на днях был у нас TI и отжалел платку с Люминари. Разъем с трансформатором и ARM. Расширяемость, гибкость, скорость, гальваноразвязка. Стойку в подвал, провода за гипсокартон, опять таки есть готовое решение с WLAN. Вот и звук, вот и видео...

А если целью умного дома ставится отпугивание воров морганием, подобным телевизору, то это профанация идеи.

Целью создания УД могут выступать:
- экономия энергоресурсов;
- "понты".
Богатые дядьки любят второе, совсем не парясь о первом. Штаты и Европа наоборот.

Управление лампочками в УД, конечно же удобно, но только ради этого систему строить никто не станет.
Можно автоматизировать дом по системам (объемник в коридоре, защита от протечек и т.п.) независимо - для этого не надо ничего придумывать. А вот чтобы все было в единой системе...

Для себя во главе ставлю задачу безопасности, а уже на второй план удобства, которые в обычном доме не создать.
Для удаленного мониторинга нужна связь через Интернет, управление по GSM.

+ Да, и расходы экономить по максимуму (в идеале, чтоб у системы появилась окупаемость)

Вообще-то целью "умного дома" является гибкость конфигурирования и интеграция подсистем (свет, HVAC, развлечения, безопасность, и пр.). Это реально востребовано для производственных помещений и "сложных" домов. Я однажды в пентхаузе, занимающем верхний этаж дома, видел систему в действии, там она была вполне к месту.

Да я не против идеи, я просто в курсе, что не так все просто с ее реализацией, причем давно.
Лет 5-6 назад проводил сертификацию приборчика с LonWorks. Фирма, специально созданная под монтаж умных домов была вынуждена переквалифицироваться на сертификацию электроники для абсолютно другой отрасли. И это в Европе, кстати.

Что касается экономии ресурсов, то ее можно обеспечить локально (например, в отоплении - в контроллере котла), или ручками. Невелик труд задницу оторвать и подойти к выключателю, да и полезно для здоровья. У меня дома теплые полы регулируются руками и не парюсь.

Сложность реализации это одно, более остро стоит вопрос обслуживания системы. Как правило, разработчик сложной системы "живет" на объекте годами (
Общался с ведущим разработчиком подобных систем. В неформальной переписке поинтересовался, есть ли у него самого УД. Ответ шокировал: "Ни за что!" и какой-то текст про задницу... (причем задница как и в плане работоспособности, так и в плане "мне не трудно ее оторвать от дивана").

Бегать и крутить ручки отопления, как меня уверяют, никто не будет. Если заказчик заплатил кучу денег, он считает, что все должно крутится само - причем запросы такие, что система должна обладать не то что интеллектом, а скорее разумом с двумя высшими. И я уже предлагал на 10% суммы за систему накупить "ручек", а на оставшиеся нанять китайца, который эти ручки крутить будет. Реально интеллектуальная система получается)

Как вообщем-то и любая идея , так и идея "умного дома" впервую очередь должна приносить экономическую выгоду
Если "разобрать" дом по частям и выделеить в нем те элементы на которых можно сэкономить, то естественно в первую очередь и делается система позволяющая без Вашего вмешательства экономить Ваши деньги.
Это касается и света и отопления и охраны ( не очень приятно приходить в обворованую квартиру -из личного опыта) и расхода воды.
Вторая задача - прибамбасы - создание более комфортных условий , себе любимому. Обычно на эту фишку и "ведутся" те кто не понимает основную задачу.
Эти задачи ,как не покажется странным , взаимосвязаны т.к. в независимости от того , что Вы "не накрутили" выполняя вторую задачу , первая должна оставаться экономически выгодной. Т.е достичь консенсуса, который так долго искал один из наших руководителей, но не шмог.


Я всё больше , склоняюсь к варианту - слейв инициирует себя в системе сам. Пересылая свой адрес и функции. Если мастер знает такое устройство , то общение начинается "сразу", нет - мастеру подгружают драйвер этого устройства. При этом слейв пока работает в автономно

На фиг вообще нужен мастер? Какая от него польза? При нажатии кнопки сигнал об этом событии надо послать исполнительному устройству - диммеру или реле. Мастер в этом участвовать не должен. Вообще.

Вот как работают C-Bus и EIB:

- Каждое устр-во имеет уникальный физический адрес. Он используется только и исключительно для конфигурирования системы: РС посылает настройки в каждое устр-во, используя физический адрес.

- В системе существует n-ное количество групповых адресов (ГА). Это виртуальный адрес, который не принадлежит никакому устройству. Иногда этот адрес называют "адрес провода", поскольку он адресует некий виртуальный провод, который связывает выключатели с лампочками. На один провод можно навесить сколько угодно кнопок и сколько угодно реле или диммеров.

- Выключатели имеют несколько кнопок. Каждой кнопке может быть назначен индивидуальный ГА. Например, если в устройстве 4 кнопки, то ему можно назначить 4 ГА, по одному на каждую кнопку. Аналогично, каждому вых. каналу реле или диммера тоже можно назначить индивидуальный ГА.

- Конфигурирование, собственно, и заключается в назначении ГА и настройке параметров.

Мастер , может не совсем правильное определение для задач этого устройства. Наверное надо просто сменить терминологию.
Давайте назовём его "дворецкий"
Вот у него задачи связанные с глобальном управлением ресурсами дома ( квартиры) , кнопками он вообще никогда не управляет и возможно даже и не предполагает их существование.
В его подчинении электропитание ( самый главный рубильник) , бойлерная ( если она есть) ,запасной генератор, связь с Вами и окружающем миром, связь с милицией , если он же выполняет задачи системы охраны.
Его взаимодействие с остальными устройствами минимально, до поры до времени.
"Умный дом" -это не только дом напичканый всевозможными контроллерами , но и куча чисто технических решений . Так например в нем нельзя включать батареи отопления последовательно , а только параллельно .
Иначе управление , в отдельно взятой комнате , климатом не возможно.
В каждом блоке дома ( комната , кухня и. д) свой "бугор" который отвечает за все события происходящие в его блоке , дворецкий ему по большей части и не нужен. И в большей степени, это ему подключаются дополнительные устройства. Дворецкий может ему "сказать" - всё хватит комфорта, переходим в режим экономии. Например это произойдёт , уходя из дома , Вы включили сигнализацию.
При этом , дворецкий может обесточить не нужные в режиме экономии устройства , да и "бугра" тоже.
К тому же в задачи "умного дома" входят и задачи по спасению или причинению минимального вреда имущества хозяина. Я не беру случаи пожара , охраны. Чисто бытовые.
Уходя из дома вы вроде бы закрыли окно, датчик отработал , но заблокировать забыли. Порыв ветра , окно нараспашку, а доводчика на окне нет. Или "добрые люди" разбили окно. Температура -20С. И в этот ситуации самый главный тот "бугор" у которого произошло ЧП. Это уже он должен упрравлять ресурсами дома , а дворецкий только "слушать" и сообщить Вам. Про всех остальных и речь не идёт , они просто молчат в тряпочку.Итог этой борьбы " за выживание" ясен, Вы в крайнем случае теряете батарею . А если происходят глобальные форс-мажорные обстоятельства , отключили свет , газ и воду, то уже дворецкий спасает весь дом , сбрасывая систему отопления в канализацию , сливая воду из всех накопителей и по возможности продувая системы т.е круг задач по спасению имущества всего дома.
Так , что " умный дом " это , если можно сказать , "сплав" технических и управленческих решений. И что бы включить доп. устройство в систему надо всё опять внимательно "взвесить" .

И вот только теперь выбор сети. Вообще может выяснится , что для "умного дома" нужна своя , ни начто не похожая сеть. Это если мы говорим о "УД" как о целостной системе , а автоматический освежитель воздуха в туалете - это не умный дом , хоть управляется он по инету.

P/S Интересно , какую сетку приминили в том автономнике , в котором "пацаны" полетели на Марс

Зачотное объяснение! "Чисто конкретно" согласен на все 100.

Интересно, должна ли эта система стоить дорого? Окупаемость возможна? Будет ли доступна подобная система широкому кругу потребителей?

Ага, точно, "умный дом" есть суть сего вопроса Если так, хочу спросить, а почему никто ничего не сказал про CAN? Или я невнимательно читал топик? Помехозащищенный, есть дешевые контроллеры с поддержкой CAN на борту. В сеть удобно соединять обычной дешевой четырёхжильной витухой. Две жилы сигнал, две - питание. А мультимастер получается автоматически. Всё-таки у подобной сети есть один огромный плюс: если одно любое устройство сдохнет (кроме общего БП, который поменять недолго ), все остальные модули благополучно продолжают работать.

Попробуйте весь топик почитать. Про CAN еще на первой странице упоминали.

Посыпаю голову пеплом (( И посылаю вопрос в личку.