Умный дом. Как соединить разные технологии? Реальный опыт

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

Так я размышлял, когда обдумывал варианты реализации своего умного дом. А началось все с одного банального вопроса: «А как лучше сделать проходные выключатели?». Далее я описываю итоги моих размышлений.

В качестве предисловия. Я более 20 лет работаю в области телекоммуникаций и IT (преимущественно разработка). На данный момент, большую часть времени трачу на разработки в области IoT и M2M вместе с командой единомышленников. В 2024 году с подачи моего коллеги и хорошего товарища начал преподавать. В статьях планирую излагать обобщенный опыт и свое видение на различные вопросы в обозначенных ранее областях.

Итак, к теме статьи…

Какие требования я предъявляю к умному дому и что по моему мнению делает его умным?

1. Умный дом не должен зависеть от облачных решений! Вы не должны потерять базовую функциональность вашего дома при проблемах со связью или при блокировках каких-либо ресурсов. Есть ли в моем требовании исключения? Да есть! Если облачное решение закрывает вопрос, который не является критичным в вашей жизни. Например, сюда я отношу голосовое управление. Другой вариант, когда это может быть оправдано: облачное решение используется при наличии резервного локального решения.

2. Умный дом обязательно должен иметь автоматические сценарии, которые уменьшат количество рутинных действий со стороны пользователя. Идеальным умным домом я считаю тот, который вообще не заметен в обычной жизни. В противном случае, умный дом станет для вас одноразовой игрушкой! Все закончится на том, что вы похвастаетесь перед родственниками и друзьями, нажмете красивые кнопочки в своем смартфоне, посмотрите диаграмки, а затем при первой же возникшей проблеме выключите и забудете о нём.

3. Голосовое управление в умном доме должно быть! Это действительно удобно.

4. Базовая функциональность умного дома должна строиться вокруг проводных решений! Возможно это профессиональная деформация, но я не могу себе представить, что информацию от датчика протечки будет передавать в радиоэфир устройство, питающееся от батареи. А если от датчика утечки газа? Или датчика угарного газа? Я вовсе не являюсь противником беспроводных технологий, напротив, активно использую их в своем умном доме, и более того, предполагал их использование с самого начала. Просто нужно понимать, что дом это не предприятие, где для критичных сценариев есть резервные механизмы, регламенты обслуживания устройств и замены батарей и т.п.

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

Минусы проводных решений очевидны:

• Нужно заложить кабель, а это возможно только на этапе строительства или капительного ремонта.

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

Что же вошло в базовый функционал? Не аксиома, может отличаться в каждом конкретном случае.

1. Управление освещением (внутренним и наружным) + проходные выключатели.

2. Мастер выключатель (отключаемая и не отключаемая зона).

3. Управление вытяжной вентиляцией.

4. Обнаружение протечек со сценарием отключения подачи холодной воды (перекрытие подачи + отключение скважинного насоса).

5. Обнаружение утечки газа.

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

7. Управление газовым котлом, включая погодозависимую автоматику (ПЗА).

Состав оборудования, которое вошло в конечное решение

Привожу сразу весь список оборудования, используемого в настоящий момент. Покупалось не все сразу, что-то докупалось позже.

1. Программируемое реле Owen ПР200-24.5.1.0 [М01] — 1 шт.

2. Модуль расширения дискретного ввода/вывода Owen ПРМ-24.1 — 2 шт.

3. Блок питания Owen БП60Б-Д4-24 — 1 шт.

4. Микрокомпьютер RPi 3 Model B — 1 шт. (был в наличии)

5. SD-карта на 64 Гб для микрокомпьютера — 1 шт.

6. USB-стик Zigbee EleLabs — 1 шт.

7. Конвертер MODBUS RTU в MODBUS TCP (Full-isolation Serial Device Server ZLAN5143D) — 2 шт.

8. Комнатный датчик температуры и влажности с двумя выходами 4-20 мА — 1шт.

9. Датчики протечки Gidrоlock WSP 2 — 5 шт.

10. Кран с приводом Neptun Bugatti Pro 220В ¾» — 1 шт.

11. Датчик температуры ДТС314-РТ1000.В2.50/2 — 2 шт.

12. Двухполюсный контактор Schnider Electric iCT 40A — 2 шт.

13. Набор промежуточных реле 220В — 24 шт.

14. Шкаф встраиваемый ABB UK648E3 на 48 (+8) модулей с винтовыми клеммами 2CPX077843R9999 — 2 шт.

15. Шкаф мультимедиа АВВ UK620MVB — 1 шт.

16. Адаптер цифровой шины Navien ectoControl, модель: ES-BRNV-01 — 1 шт.

17. Беспроводной датчик температуры Вега ТД-11 — 1 шт.

Идея использовать программируемое реле или ПЛК в качестве базы сама по себе не нова. Я видел в своей практике проекты жилых домов с сотнями точек I/O на базе ПЛК промышленного уровня, которым под силу управлять небольшим предприятием, не то что умным домом. В данном случае речь идет о том, как соединить различные проводные и беспроводные технологии и как сделать так, чтобы управление происходило не из интерфейса SCADA, типичного для промышленной автоматизации, а из привычного смартфона.

Реализация

Основное электротехническое оборудование группы безопасности было размещено в одном из встраиваемых шкафов ABB, второй шкаф был предназначен для ввода слаботочных кабелей, размещения программируемого реле, модулей расширения дискретного ввода-вывода, размещения промежуточных реле, контакторов и конвертеров MODBUS RTU в MODBUS TCP. Третий мультимедийный шкаф был предназначен для ввода интернет-кабеля и размещения домашнего маршрутизатора и коммутатора (на практике оказался несколько мал).

Скрытый текст

До всех клавишных выключателей (импульсных), а так же до всех проводных датчиков был проложен слаботочный кабель. Все силовые кабеля приходят в шкафы напрямую.

Параллельно с монтажом кабеля и электротехнического оборудования, разрабатывалась программа для программируемого реле. Разрабатывал сам, параллельно изучая язык функциональных блочных диаграмм (FBD). Как оказалось, паттерны, заложенные длительным опытом разработки на классических высокоуровневых языках программирования, играют здесь злую шутку, но через некоторое время пошло как по маслу. Программа была разработана с учетом того, что можно удаленно изменить состояние любого дискретного выхода (читай включить/выключить нагрузку) по протоколу MODBUS TCP. Вот миниатюра FBD диаграммы (слева входы, справа выходы):

Как только все было скоммутировано, а программа загружена в программируемое реле (это было еще на этапе отделки), базовый функционал заработал. Еще не стояло никаких выключателей, а светом уже можно было управлять с панели реле. Базовые сценарии безопасности (протечка воды, утечка газ) тоже заработали.

Управление со смартфона

На следующем этапе нужно было получить управление со смартфона, голосовое управление и возможность создавать пользовательские сценарии. Рассматривал Home Assistant (HA) и OpenHUB. Оба решения понравились, но выбор пал на HA, т.к. он написан на Python, а я его знаю на достаточно хорошем уровне, что кстати в дальнейшем пригодилось при добавлении функции ПЗА к моему газовому котлу.

Далее установка HA на RPi. Тут все просто: Docker или HASS.io. Я выбрал Docker, так как на RPi стоят еще брокеры AMQP и MQTT.

Чтобы HA мог опрашивать реле по протоколу MODBUS TCP, используется конвертер MODBUS RTU/TCP. С одной стороны он подключен к интерфейсу RS485 реле, с другой стороны в локальную Ethernet сеть, в которую подключен и HA. HA — Master, реле — Slave. Я мог бы подключить HA напрямую к реле через USB-dongle RS485, но тогда бы не получил возможность отладки MODBUS c ПК, через использование функции конвертера под названием Multi-Master.

Некоторые реле уже имеют RJ45 на борту и не приходится докупать подобный конвертер для работы с ним через MODBUS TCP.

Интеграция MODBUS в HA не самая дружелюбная в плане настройки, WebUI на данный момент отсутствует. Самое главное тут внимательно прочитать документацию. В yaml-файл были прописаны все регистры, отвечающие за управление + сенсоры.

modbus:   - name: "PR200"     type: tcp     host: 192.168.1.56     port: 502     timeout: 2     delay: 1     sensors:       - name: "temperature"         unit_of_measurement: "°C"         slave: 1         unique_id: 521         address: 521         scan_interval: 15         input_type: holding         data_type: float32         precision: 2         device_class: temperature       - name: "humidity"         unit_of_measurement: "%"         slave: 1         unique_id: 525         address: 525         scan_interval: 60         input_type: holding         data_type: float32         precision: 2         device_class: humidity       - name: "floor_temp_su1"         unit_of_measurement: "°C"         slave: 1         unique_id: 556         address: 556         scan_interval: 15         input_type: holding         data_type: float32         precision: 1         device_class: temperature       - name: "floor_temp_su2"         unit_of_measurement: "°C"         slave: 1         unique_id: 558         address: 558         scan_interval: 15         input_type: holding         data_type: float32         precision: 1         device_class: temperature     switches:       - name: "close_water"         slave: 1         unique_id: 553         address: 553         write_type: holding         command_on: 0         command_off: 1         verify:       - name: "switch_pump_and_septic"         slave: 1         unique_id: 554         address: 554         write_type: holding         command_on: 0         command_off: 1         verify:       - name: "switch_master"         slave: 1         unique_id: 515         address: 515         write_type: holding         verify:     fans:       - name: "fan_su1"         slave: 1         unique_id: 519         address: 519         write_type: holding         verify:       - name: "fan_su2"         slave: 1         unique_id: 547         address: 547         write_type: holding         verify:     lights:       - name: "light_tambur"         slave: 1         unique_id: 512         address: 512         write_type: holding         verify:       - name: "light_klilco"         slave: 1         unique_id: 513         address: 513         write_type: holding         verify:       - name: "light_ulic_1"         slave: 1         unique_id: 514         address: 514         write_type: holding         verify:       - name: "light_koridor"         slave: 1         unique_id: 516         address: 516         write_type: holding         verify:       - name: "light_garderob"         slave: 1         unique_id: 517         address: 517         write_type: holding         verify:       - name: "light_su1"         slave: 1         unique_id: 518         address: 518         write_type: holding         verify:       - name: "light_kom1_1et"         slave: 1         unique_id: 537         address: 537         write_type: holding         verify:       - name: "light_podsobka"         slave: 1         unique_id: 538         address: 538         write_type: holding         verify:       - name: "light_gostinaya"         slave: 1         unique_id: 539         address: 539         write_type: holding         verify:       - name: "light_kuhnya"         slave: 1         unique_id: 540         address: 540         write_type: holding         verify:       - name: "light_kuhnya_stol"         slave: 1         unique_id: 541         address: 541         write_type: holding         verify:       - name: "light_patio"         slave: 1         unique_id: 542         address: 542         write_type: holding         verify:       - name: "light_ulic_2"         slave: 1         unique_id: 543         address: 543         write_type: holding         verify:       - name: "light_lestnica"         slave: 1         unique_id: 544         address: 544         write_type: holding         verify:       - name: "light_koridor2"         slave: 1         unique_id: 545         address: 545         write_type: holding         verify:       - name: "light_su2"         slave: 1         unique_id: 546         address: 546         write_type: holding         verify:       - name: "light_kom1_2et"         slave: 1         unique_id: 548         address: 548         write_type: holding         verify:       - name: "light_kom2_2et"         slave: 1         unique_id: 549         address: 549         write_type: holding         verify:       - name: "light_kom3_2et"         slave: 1         unique_id: 550         address: 550         write_type: holding         verify:     binary_sensors:       - name: "temp_min_alarm"         slave: 1         unique_id: 528         address: 528         scan_interval: 15         input_type: holding         device_class: cold       - name: "temp_max_alarm"         slave: 1         unique_id: 529         address: 529         scan_interval: 15         input_type: holding         device_class: heat       - name: "humi_min_alarm"         slave: 1         unique_id: 530         address: 530         scan_interval: 15         input_type: holding         device_class: problem       - name: "humi_max_alarm"         slave: 1         unique_id: 531         address: 531         scan_interval: 15         input_type: holding         device_class: problem       - name: "moisture_su1_alarm"         slave: 1         unique_id: 532         address: 532         scan_interval: 15         input_type: holding         device_class: moisture       - name: "moisture_su2_alarm"         slave: 1         unique_id: 533         address: 533         scan_interval: 15         input_type: holding         device_class: moisture       - name: "moisture_podsobka_alarm"         slave: 1         unique_id: 534         address: 534         scan_interval: 15         input_type: holding         device_class: moisture       - name: "moisture_kuhnya_alarm"         slave: 1         unique_id: 535         address: 535         scan_interval: 15         input_type: holding         device_class: moisture       - name: "gas_alarm"         slave: 1         unique_id: 536         address: 536         scan_interval: 15         input_type: holding         device_class: gas   - name: "NAVIEN"     type: tcp     host: 192.168.1.65     port: 502     timeout: 2     delay: 1     sensors:       - name: "adapter_status"         slave: 1         unique_id: 0x0010         address: 0x0010         scan_interval: 10         input_type: holding         data_type: uint16       - name: "adapter_version"         slave: 1         unique_id: 0x0011         address: 0x0011         scan_interval: 10         input_type: holding         data_type: uint16       - name: "adapter_uptime"         unit_of_measurement: "s"         slave: 1         unique_id: 0x0012         address: 0x0012         scan_interval: 10         input_type: holding         data_type: uint32       - name: "coolant_temp"         unit_of_measurement: "°C"         slave: 1         unique_id: 0x0018         address: 0x0018         scan_interval: 15         input_type: holding         data_type: int16         device_class: temperature         scale: 0.1       - name: "dhw_temp"         unit_of_measurement: "°C"         slave: 1         unique_id: 0x0019         address: 0x0019         scan_interval: 15         input_type: holding         data_type: uint16         device_class: temperature         scale: 0.1       - name: "burner_status"         slave: 1         unique_id: 0x001D         address: 0x001D         scan_interval: 5         input_type: holding         data_type: uint16

После настройки я получил возможность управлять и видеть показания на своем смартфоне через приложение HomeAssistant:

Скрытый текст

Расширение функционала за счет беспроводной сети

Далее путем включения USB-стика Zigbee от EleLabs в RPi, последний был превращен в ZigBee-хаб. В HA для этого используется интеграция под названием ZHA. На ZigBee были возложены некоторые второстепенные задачи, которые просто повышают удобство:

• Дублирующие выключатели света и вентиляции в некоторых помещениях. На практике оказалась очень полезная опция. По-хорошему, нужно было закладывать кабель еще на этапе проектирования, но как я писал ранее, очень сложно предугадать эту потребность.

• Термостатирование и управление теплым полом c помощью ZigBee реле стоимостью 500 р. В сравнении с умным термостатом, экономия сотни процентов.

• Термостатирование для газового котла с помощью релейного выхода. Данный способ сейчас не использую, т.к. перешел на ПЗА, но оставил как резервный. Механизм очень простой, реализуется через запрет включения котла, если температура в помещении уже превысила целевую, однако он обеспечивает только минимальный уровень комфорта.

Голосовое управление

Тут оказалось все совсем просто. Для HA есть интеграция Yandex Smart Home, которая доступна в HACS. Интеграция позволяет вывести любые объекты HA в УДЯ и они сразу подхватываются Алисой. Есть возможность настроить какие именно объекты HA будут проброшены в УДЯ. Теперь я уже мог сказать «Алиса, включи свет на кухне» или «Алиса, что с температурой в доме?».

Есть 2 способа как УДЯ будет общаться с вашим HA:

1. Напрямую, но для этого нужен публичный IP на домашнем роутере и валидный TLS-сертификат. У меня реализован этот способ.

2. Посредством Yaha Cloud, который предоставляется интеграцией. Данный вариант по субъективным ощущением реагирует медленней, хотя тоже исправно работает.

Датчики за пределами дома

Так как реализация ПЗА для газового котла была на уровне идеи с самого начала, то я озаботился тем, чтобы иметь возможность получать информацию и с уличных датчиков. Можно было попробовать использовать ZigBee для этих целей, но по моему убеждению ZigBee это все таки LPLAN, а все, что находится снаружи, должно использовать LPWAN технологии.

В качестве LPWAN была выбрана сеть LoRaWAN. Выбор неслучайный. Во-первых, в моём городе сеть уже развернута, а доступ для персонального использования бесплатный с ограничением в 10 базовых станций и 50 устройств. Во-вторых, я имею доступ к инфраструктуре, так как непосредственно участвую в разработке ПО для IoT/M2M и в частности для LoRaWAN. Сенсоры при этом могут находиться на значительном удалении от дома.

Первый датчик, который мне потребовался, это датчик уличной температуры (это основной датчик для ПЗА). Для этого я использовал Вега ТД-11 совместно с экраном Стивенсона.

Данные из сетевого сервера LoRaWAN направил в HA по протоколу MQTT, предварительно конвертировал их в JSON (функционал сетевого сервера это позволяет). В HA есть соответствующая интеграция для MQTT. На выходе внутри HA получил сенсор с уличной температурой и остатком заряда батареи.

Что в итоге?

В итоге объекты умного дома могут управляться следующими способами:

• С панели программируемого реле

• Сценариями жестко запрограммированными в реле

• В ручном режиме импульсными выключателями

• Беспроводными выключателями

• Сценариями HomeAssistant

• Из мобильного приложения HomeAssistant

• Голосом через колонку с Алисой (или другие устройства с Алисой)

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

Отдельно хочу отметить скорость включения системы. Из-за того, что базовый функционал реализован на программируемом реле, его включение происходит примерно через 3 секунды после подачи питания. Все остальное придется подождать около 3-5 минут, так как RPi с HA грузится не моментально.

Умный дом имеет в своем составе:

• Проводные датчики и исполнительные механизмы.

• Беспроводные датчики и исполнительные механизмы ZigBee.

• Беспроводные датчики LoRaWAN.

Сценарии, которые реализуются на данный момент:

• Обработка аварии по протечке воды. Перекрывает подачу воды и выключает скважинный насос.

• Включение/выключение наружного освещения по расписанию на основе восхода/захода солнца.

• Сценарий ПЗА для газового котла.

• Термостатирование электрического теплого пола.

• Автоматическое выключение вытяжки в санузлах.

• Уведомление об утечке газа. Напрашивается автоматическое отключение, но с газом все несколько сложнее, так как требует согласований. В процессе изучения данного вопроса.

• Уведомление о пороговых значениях температуры и влажности.

• Уведомление о низком заряде батарей для устройств с батарейным питанием (одна из проблем беспроводных технологий это логистика замены батарей).

В планах:

• Зональное отопление с помощью радиаторных термоголовок.

• Зональное управление с помощью термоголовок для водяного теплого пола.

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

• Сценарии на основе датчиков присутствия.

• Добавить в умный дом LPWAN датчики на основе NBIoT/IP и NBIoT/NIDD (в качестве эксперимента).

• На базе интеграции MODBUS, разработать для HA отдельную интеграцию для поддержки адаптеров цифровых шин от ectoControl.

P.S. В следующий раз попробую более подробно рассказать про ПЗА на базе адаптеров цифровой шины от ectoControl + HA с интеграцией WDA Sensor (очень простая интеграция, разработал специально для задачи ПЗА).