Умный дом (архитектура)

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

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

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

Modbus 

Как мы уже говорили, выбрали для проводной части протокол Modbus RTU. Для простоты, в качестве транспорта, используется интерфейс RS-485. Факторов в пользу такого выбора было много, но определяющим стало то, что это древний промышленный протокол, который поддерживает большое количество различных устройств. 

По своей сути это очень простое взаимодействие. Есть линия передачи данных по двум проводам (A и B), на одном конце которой находится опрашивающее (Master) устройство. На другом конце линии стоит терминатор (обычно резистор на 120 Ом). Между двумя концами этой шины данных, как лампочки на гирлянде, последовательно подключены опрашиваемые (Slave) устройства. 


Master устройство отправляет запрос одному из slave устройств и получает ответ. Недостаток такого взаимодействия очевиден - для получения информации от каждого устройства, их придётся поочередно опросить. Это означает, что при ограниченной скорости передачи данных (а она всегда конечна), можно опросить только определённое количество устройств. Следствие из этого - чем больше количество устройств на "гирлянде", тем больше времени требуется на опрос их состояний. 

Примитивный RS-485 мы использовали ещё и потому, что были собственные Java наработки в этой области. Не обязательно повторять наш путь, но если всё-же смотрите в сторону Modbus, то обратите внимание на Modbus TCP. Те же опрашивающий и опрашиваемые, но поверх Ethernet. 

Более современные протоколы, такие как KNX, лишены подобного недостатка (опрашивания оконченных устройств). На шине они равноправны и обмениваются между собой сообщениями. Напомним, что одно из наших требований было про низкий бюджет базового решения, с возможностью развития. Поэтому мы строили такой умный дом, к которому, при желании, можно будет подключить не только Modbus RTU или KNX линию, но и вообще любые беспроводные устройства (WiFi, Zigbe, и т.д.).    

Открытая архитектура

Как выглядит умный дом с открытой архитектурой, изобразим на схеме. Причём, обратите внимание, может использоваться любой контроллер (даже не один). Главное условие, что-бы он поддерживал интеграцию через MQTT. Фактически, использование данного транспорта в качестве центральной шины данных, стало промышленным стандартом при построении открытых архитектур в системах автоматизации.    


Суть MQTT шины - обмен сообщениями. Все потоки сообщений делятся на каналы (топики). Можно подключиться к MQTT шине и подписаться на все сообщения одного или нескольких каналов. Как только отправитель пошлёт сообщение в какой-либо канал, все подписавшиеся на этот канал получат его. При отправлении, помимо самого сообщения можно указать режим доставки. Сами сообщения, как правило, представляют собой кусочки текста. Например так:
/devices/wb-msw-v3_189/controls/Current Motion 9
/devices/wb-msw-v3_23/controls/Illuminance 50.14
/devices/wb-msw-v3_182/controls/Max Motion 12
/devices/wb-map3et_13/controls/Total AP energy 5152.15632
/devices/wb-msw-v3_23/controls/Air Quality (VOC) 893
zigbee2mqtt/0x00158d00028aaed5 {"battery":100,"last_seen":16810706495,"linkquality":65,"occupancy":true}

Цветом выделен MQTT топик. Последнее сообщение из примера содержит информацию об уровне заряда батареи, времени регистрации движения, качестве связи с Zigbee координатором и самой главное - признак присутствия. Конечно, названия состав атрибутов и тип данных у каждого устройства и исполнительного механизма будет свой. В такой концепции всех отправителей и получателей объединяет одно - умение отправлять и получать сообщения (команды или статусы). 

Аналогично, датчик температуры и давления периодически (или при изменении показателей) отправит в MQTT шину нечто такое: 
{"battery":100,"humidity":29.62,"last_seen":1681065263715,"linkquality":80,"pressure":1021.8,"temperature":23.63,"voltage":3015}
Другой пример. Умное реле читает свой MQTT топик "/devices/wb-mr6c_27/controls". Получив команду "K1 1" замкнёт (1) или разомкнёт (0) соответствующий канал.  
/devices/wb-mr6c_27/controls/K1 1
Таким образом происходит управление устройствами и обмен информацией между датчиками, выключателями, контроллером и всеми остальными компонентами в системе умного дома. 

Теперь, когда роль MQTT шины понятна, не сложно представить универсальную открытую архитектуру для построения автоматизации на любой платформе и с любыми протоколами.


Вся архитектура строится на центральной MQTT шине, через которую передаются сообщения или состояния и команды

На рисунке в правом верхнем углу условно изображена лампа, подключенная к "умному" релейному модулю. Вся его "умность" заключается в умении читать из определённого MQTT топика. Если кто-то в этот топик отправит 1 - контакт замкнётся,  0 - контакт разомкнётся. Фактически, управление исполнительными механизмами производится путём отправки в определённые MQTT топики определённых сообщений в понимаемом механизмом формате. 

Ниже лампы на схеме изображено аналоговое устройство подключенное к "умному" читателю. Он преобразует аналоговое значение в кусок текста определённого формата и отправляет его в определённый MQTT топик.    

Существуют такие цифровые датчики и устройства, которые сами умеют отправлять своё состояние в MQTT топик без промежуточных "умных" посредников. Просто, всё необходимое для отправки у такой железяки есть "на борту". 

Далее, имея центральную MQTT шину, мы можем снабдить нашу систему автоматизации умного дома любыми сервисами. Например, захотим на WEB страничке отображать текущее состояние всего дома (с открытыми дверьми, включённым светом, температурой и т.д.). Подключаем для этого службу, которая читает из MQTT состояния разных устройств и показывает их на страничке. Захотим написать правила для сценариев автоматизации. Подключаем службу, которая читает из MQTT топиков состояния, сравнивает условия наступления того или иного события и, по сценарию управляет различными устройствами и выключателями. Управление сводится к простой отправке в нужный топик сообщения определённого формата. По такому принципу к своему умному дому, который умеет MQTT, можно подключить внешний модуль управления типа Node-RED и в графическом виде создавать свои собственные сложные сценарии. Допустим, если родной контроллер не умеет отправлять сообщение в WatsApp, но умеет взаимодействовать с внешним миром через MQTT, то отправку можно сделать в другой службе (Node-RED).

Аналогичным образом можно добавлять к своему умному дому датчики и исполнительные механизмы, работающие по другим протоколам. Например, у нас базовый контроллер от Wirenboard не умеет работать с Zigbee устройствами. Зато существует USB свисток на базе CC2531, который подключен через свободно распространяемую zigbee2mqtt. Все события от Zigbee железок записываются в соответствующие MQTT топики (пример см. выше). Управление ими так-же сводится к простой отправке определённого сообщения в нужный топик. 

Боле сложная и нужная функциональность, такая как: управление климатом, запоминание последовательности событий и команд, выделение кандидатов в сценарии автоматизации, запись телеметрии с датчиков в Prometheus для последующего отображения в Grafana и многое другое. Именно то, что не умеет ни одна из существующих систем умного дома и то, что необходимо заказчику, может быть реализовано в виде специализированной службы. Внешне эта служба не сильно отличается от остальных. Она читает из MQTT сообщения, обрабатывает и отправляет в ответ управляющие команды. Напомним, не обязательно быть программистом, что-бы создавать такие службы. В большинстве случаев, вам будет достаточно уже упомянутого Node-RED.      

Итоги

Как вы уже поняли, уважаемые читатели, не обязательно иметь KNX или Modbus решение в сердце своего умного дома. Достаточно построить открытую архитектуру на базе MQTT шины. Тогда вы вообще не будете ограничены протоколами или производителями контроллеров. Главное иметь компоненты в вашей системе, которые умеют читать и писать в MQTT топики. 

Полезные ссылки