(Модераторам - а тег "умный дом" не добавить ли?)
Попробую более-менее кратко описать, какой объём конфигурирования и поддержания знаний требуется для среднего размера системы умного дома. Мне кажется, коллеги проблему недооценивают.
Кратко о системе: Московская квартира 100м2, стойка 19" в потолок, модули в помещениях, полное централизованное управление светом (ручное, групповое, сценарное, по датчикам движения и открытия дверей), климатом (тёплый пол и управляемые радиаторы, под два десятка датчиков) и много по мелочи (уличные датчики, датчики звука, CO2, взаимодействие с теликами, снятие данных с NAS и т.п.). Ещё столько же в планах, но времени нет, и, главное - я вижу как растёт сложность системы.
Попытаюсь пройтись по тому, как документирована конфигурация всего этого.
Конфигурация роутера
Отдельная большая проблема. Есть карта всех IP (вне роутера!), она же прописана в роутер, там же фиксация MAC/IP для DHCP, и нет, туда нельзя положить дополнительные конфигурационные параметры - даже в довольно продвинутом mikrotik DNS сервер рудиментарный. И да, по возможности всем устройствам IP-адреса прописаны жёстко. То есть реально пара мак-ip живёт в трёх местах - документ, роутер, устройство.
Кросс-журнал
В сумме в стойку приходит около ста витых пар, примерно половина - локалка, половина - слаботочка умного дома. В основном - +24 вольта, RS485, датчики pt1000, 1wire и прямые линии управления, например - клапанами радиаторов. Много мелочей - например, импульсы расхода воды или аплинк от автономного контроллера протечки.
Силовых линий вряд ли меньше - во всяком случае, светильники и выключатели разведены на три кросса, 50+50+20 точек. Отдельно все люстры, бра, тёплые полы, блоки розеток и кое-где отдельные розетки (впрочем, управляемых розеток в итоге вообще нет, так что половина силовых просто разведена на гребёнки и автоматы).
Кросс-журнал - номера проводов, распайки по цветам жил, соединения проводов, подключение каждого конца каждого провода куда-либо. По факту - там есть ошибки. Иногда нахожу и исправляю. По факту - шесть проводо из оговоренного объёма в итоге непригодны для эксплуатации. Три тупо потеряны или рваные, три с короткими замыканиями.
Кросс-журнал сделан в виде нескольких вкладок в гугл-таблицах, информация продублирована. Отдельно есть таблица проводов (и сказано, к какому устройству он подключен), отдельно - таблица устройств (и сказано, какой провод на какую клемму приходит) - это позволяет проще искать ошибки.
Пример из кросс-журнала по плинтам: номер плинта, номер пары, номер провода, цвет, что на том конце, что на этом.
3
0
76
зел-бел,зел
пт1000 детская 1 (у двери, ближний)
МВА1.1
3
1
76
кор-бел,кор
1wire+клапан батареи
plc 30 do2, mmnet2 1w2
Слаботочка: локалка разведена на стандартную патч-панель, специальная - на плинты. Местами есть кроссировка и между ними. Журнала для локалки нет, а, наверное, скоро будет нужен - буду вводить сегменты сети, отдельный на умный дом без роутинга в Интернет и отдельный на IP-камеру в подъезде с роутингом только в одну точку.
Пример из журнала распаек (по одному типу кабеля):
управл батареями + датчики темп
1
оранжевый-бел
земля
НОМЕРА КОНТАКТОВ РАЗЪЕМА
2
оранжевый
+24
СДЕЛАНО
3
зеленый-бел
pt1000
6
зеленый
pt1000
4
синий
rs485 +
5
синий-бел
rs485 -
7
коричневый-бел
минус термопривода
термопривод крана батареи
между +24 (2, оранж) и кор-бел (7) - NB! - предохранитель на вых. контроллера!
8
коричневый
1wire термометр
DS18B20
Журнал питания
В стойке стоит блок предохранителей, чтобы КЗ по питанию не выжгло провод в стене. Расписано, какой канал блока что питает (вне стойки). Кабель, напряжение, устройство. Как правило, везде идёт +24 и локально стабилизируется ШИМ-ом в +12 или +5. Снижаем ток в проводах, привносим стандарт.
Журнал 1-wire
А куда деваться? Они прописаны в конфигурации контроллера, но если контроллер умрёт - откуда их доставать и как их вспоминать? Это вот - одна из главных причин иметь централизованное конфигурирование.
Датчики температуры 1Wire
В контроллере
MAC
контроллер
Шина
Индекс
расположение
28:8D:4E:AB:02:00:00:87
mmnet вытяжка
-
0
Внутри вытяжки на контроллере
28:E3:37:AB:02:00:00:C9
mmnet вытяжка
-
1
Снаружи вытяжки вверху (короткий провод)
28:44:36:AB:02:00:00:DD
mmnet вытяжка
-
2
Снаружи вытяжки внизу (длинный провод)
Журнал каналов умного дома
Каналом считается вход или выход основной системы, которая стоит в шкафу. Тут нет входов-выходов модулей, которые стоят по квартире.
Устройство
Порт
Канал
Выключатель
Лампа
Фидбек
Объект
Комментарий
МДВВ0
1
0
A28-29
B32-31
да
Столовая люстра Лев
канал modbus порт 502
2
1
A28-29
B30-31
да
Столовая люстра Прав
3
2
B12-11
B12-11
да
Столовая бра Лев
4
3
B10-11
B10-11
да
Столовая бра Прав
5
4
A8-7
B42-43
да
Детская люстра Лев
6
5
A8-7 OR A9
B44-43
да
Детская люстра Прав
7
6
-
-
нет
Прихожая светодиоды
8
7
A8-7
B44-43
Детская ночник
через реле включает два ночника в обоих люстрах
Обратите внимание на комментарий про ночники. Рисовать полную схему - убиться. Вместо этого все существенные вещи прописаны вот так в комментариях.
Так расписаны все железки в шкафу. Где уместно - указаны специфические настройки входов (опять конфигурация).
Разводка и конфигурация выносных модулей
Специфична для каждого типа. Вот пример для собственных контроллеров atmega128 + ethernet. Кстати, именно им я раздаю MAC-адреса из 1-wire DS2401, и именно им я хотел бы вместо этого выдавать конфигурацию из центрального конфигуратора. Потому как если оно сдохнет - его придётся перенастраивать руками.
Port B
Kitchen Vent -
http://mmnet1.
Rack -
http://mmnet2.
Bath -
http://mmnet3.
192.168.88.129
192.168.88.130
192.168.88.131
0 - output, SS for ?
-
-
-
1-3 - SPI SCK/MOSI/MISO
-
-
-
4 - DHT11
y
y
y
5 - data flash SS
-
-
-
6,7 - uart tx enable / LED
Port D
0,1 - I2C SCL/SDA
-
bmp180
-
2,3 - UART1 (debug)
n
n
n
4-7 - DI/DO/PWM
PD6 - Di Light, PD7 - Di motor
n
клапаны воды контакты Di
2-7 - Multibus 1wire
n
y, chan 6 - температура в стойке
n
Журнал шин и адресов
Тут - все IP-адреса всех устройств, все шины 485 и 1wire, номера modbus юнитов, номера портов на TCP/serial конверторах и настройки скорости/формата последовательных портов. И, конечно, указано, что к чему подключено (например, на какой 485-й порт какого контроллера приходит шина или куда уходит порт tcp/serial конвертора)
Журнал настроек
Здесь фиксируются разные настройки, которые или вручную выставлены в устройствах, или прошиваются в них из контроллеров/софта на старте.
Как нетрудно видеть, поддерживать это сложно. Кроме того, всё это - просто документы, никак не связанные. Контроля целостности между документами нет, в кросс-журнале и распайке могут быть написаны разные применения для жил кабеля. Нет и контроля совпадения между документом и прошивкой.
И ещё есть куча вещей, которые вообще хардкод, а хотелось бы иметь возможность конфигурировать. И это ещё я вообще не коснулся OpenHAB-а и его скриптинга, и его связи с контроллерами (а только тут есть ТРИ метода связи), и его связи с наколенными скриптами и драйверами разного железа. Для примера - есть драйвер, который ходит через конвертор интерфейса и специальный протокол поверх модбаса в CCU825, а полученное запихивает в OpenHAB. И в нём есть отображение Item-ов OpenHAB на входы CCU, и это тупо забито в код. И где это искать - через год ты уже не помнишь. И всё это прописывать в доки уже нет никакой мочи.
В итоге в не самой сложной системе бегают с десяток разных протоколов и информация размазана по полусотне мест.
И всё это тряхозвоние я хочу заменить на
- один глобальный канал обмена данных все на всех (MQTT/UDP)
- одну глобальную методику конфигурирования
Довольно понятно, что и то и другое не удастся на 100%, но если я структурирую за следующий год хотя бы треть этого зоопарка, я буду счастлив.