MajorDoMo

Всем привет.

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

Бэкграунд:
строю дом, летом-осенью дойду до этапа проводки.
Хочу разные сценарии, в первую очередь:
- управление котлом/котлами; хочу электрический и газовый котлы, и, в первую очередь, нужно будет балансировать, какой используется, в зависимости от времени суток и объёма потреблённых ресурсов;
- датчики протечек/газа и т.п.;
- централизованное управление светом, а также свет в некоторых зонах по датчикам;
- в будущем, управление поливом.
Ресурсы:
Я по образованию и опыту программист, микроконтроллеры программировать – не мой профиль, я больше по прикладному ПО. На PC (windows, linux) могу писать практически на всём, а вот нюансы программирования для микроконтроллеров пока знакомы только условно, и не хочется слишком уж досконально прыгать в технологию на уровне «кодировать новый протокол». Максимум, что я сделал – купил ардуино, несколько attiny, датчики температуры для 1-wire и dht22; Я, например, хотел для пруф-оф-концепта сделать программный слейв для 1-wire на attiny+dht22, хотел сделать модуль, который каким-то образом отдаёт значения влажности, но пока сфейлил это, ни один код из инета сходу не работает, и дальше надо глубоко дебажить, подозреваю, нюансы с таймингами – лень.
По железу – умею базово припаять провод к ноге/дырке, паять платы (пока) не умею...
Ограничения:
- Время. Мне интересно покопаться, но во многом мной движет лень. Хочется автоматизировать и забыть.
- Деньги. Решения на базе KNX и т.д. выглядят необоснованно дорогими, особенно, если обращаться к интеграторам. Может быть, мнение изменю, если с самопальным будет необоснованный геморрой, но... Пока выглядит так, что такие решения – это премиум-класс; решения для среднего класса почему-то не вижу.
- Не хочу на этом этапе, пока нет проводов, беспроводное решение для базы, но система в будущем должна быть расширяема, чтоб можно было добавить беспроводные датчики/модули управления (всего я не учту).
- система не должна требовать чрезмерного внимания – я хочу настраивать тогда, когда я хочу, а не потому, что что-то отвалилось и для обеспечения нормального жизнеобеспечения нужно срочно что-то дебажить.
Видение системы:
Центральный модуль (железо TBD, пока видится что-то на интел атом с линуксом или что-то армное) – через Ethernet несколько «универсальных узлов автоматики» по терминологии с этого сайта, по узлу на одну-две комнаты, только мне видится не роутер с опенврт, а скорее дешевые одноплатники с GPIO, типа raspberry pi или odroid c1, - дальше подключенные по проводам датчики и исполнительные устройства.

Внимание, центральный вопрос, который меня беспокоит: на какой протокол или протоколы смотреть в первую очередь для подключения датчиков и исполнительных устройств? Или какие датчики можете порекомендовать, которые уже поддерживают какие-то протоколы?
Что беспокоит – дальность от узла автоматики будет по дому до пары десятков метров, я не уверен, что хочу делать топологию «звезда» (если не придётся?), скорее общую шину; кроме того, некоторые устройства вынесены на несколько десятков метров, например, датчики в приямке скважины.
Сложилось такое мнение:
1) 1-wire. Преимущества – довольно много людей в комьюнити использует, довольно значительная возможная длина сети.
Недостатки: полузакрытый протокол, в том плане, что писать 1-wire-слейвы легально нельзя. Думал для «частного» применения сделать слейв на attiny, к нему подключить интересуемый dht22, но пока «обломалось».
2) I2С/SPI. Судя по спецификации, нативно поддерживается купленными мной для тестов avr-овскими чипами; недостатки - годится только на короткие расстояния, в первую очередь, из-за отсутствия поддержки механизмов идентификации ошибок, типа CRC.
3) Rs485 (с Modbus или на другом протоколе уровня данных). Вроде как предназначен для нужных расстояний, но не совсем понимаю, что мне понадобится для реализации такого сценария с majordomo. Например, я хочу собирать показания с dht22 на удалении 50 метров, какие мои действия? Я делаю какую-то схему с dht22, attiny85, чем-то типа max1487, дальше что? Что-то получится в этом направлении, как думаете?
4) CAN – как-то мало информации, не ресёчил, но шина-то автомобильная, есть ли смысл туда копать?
Какие ещё варианты? И куда таки лучше копать?

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

Или на данном этапе планировать тянуть отдельную витую пару со щитка, условно говоря, в каждую розетку (а не общую шину)?

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

Про 1-wire - впервые слышу, чтобы нельзя было легально сделать слейв. Откуда такие сведения? Впрочем, 1-wire как протокол домашней автоматизации в любом случае настолько малопригоден, что всерьез его рассматривть не стоит. Температурный датчик поключить - это пожалуйста, а на большее он не тянет.

RS-485 с Modbus RTU - намного более подходящий вариант. Правда, староват Modbus, но еще жив.

Если CAN широко применяют в автомобилях, это отнюдь не значит, что он "автомобильный". В промышленности его тоже во-всю применяют.

Я выбрал CAN. Для этого есть веские технические основания. Домашнюю проводку очень трудно сделать "правильной", чтобы она хорошо работала на высоких скоростях, поскольку для этого надо выдерживать топологию: прокладывать один кабель, который по очереди обходит все узлы сети, не делать длинных отводов от кабеля, терминировать кабель на концах сопротивлением, равным волновому сопротивлению линии. Домашняя проводка скорее всего будет иметь произвольную топологию. А с такой проводкой можно получить скорость от силы 100 kbps, а более реалистично рассчитывать на меньшее, на 10...50 kbps. На таких скоростях Модбас будет тормозом. Дело в том, что Модбас использует старинный способ организации сети, "мастер-слэйв". В сети один мастер, он все время должен по очереди опрашивать слэйвов "у тебя что-то изменилось?". Получив ответ, мастер должен обработать его и передать команду на исполнение другому слэйву. То есть, если управлять светом, вы нажмете кнопку, а свет включится с изрядной задержкой, причем, чем больше вы будете добавлять узлов в сеть Модбас, тем больше будет задержка.

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

Стоит отметить, что "фирменные" интерфейсы для автоматизации домов и зданий (EIB, C-bus) работают на малых бодовых скоростях и тоже по принципу "производитель-потребитель".

Тоже сошлюсь на ту-же соседнюю тему, я там отписался. Добавлять сказанному там, что эта схема наиболее удобна при прокладке новой проводки. Проводные решения априори стабильнее и защищеннее беспроводных. Если есть свободные средства и не хочется паять - можно приобрести готовые модули езернет там-же, где эту концепцию "исповедуют" - на ab-log.ru (не реклама! Проект открытый!) правда там в базе нет питания по лану, но это мелочи. Есть неплохие темы на том форуме как раз на тему стройки/кап ремонта.