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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Блок питания Овен БП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 диаграммы (слева входы, справа выходы):

Кусок программы на FBD для программируемого реле

Управление с панели реле

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

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

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

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

Конвертер MODBUS RTU <-> MODBUS TCP

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

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

Настройка конвертера ZLAN для работы с программируемым реле.

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

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

Моя YAML конфигурация интеграции MODBUS в HA:

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:

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

Полный список используемых в HA интеграций

Главная панель

Термостат электрического теплого пола на базе сценариев HA

Параметры котла

Управление котлом + параметры ПЗА

План первого этажа

План второго этажа

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

Далее путем включения 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 + экран Стивенсона

Первый датчик, который мне потребовался, это датчик уличной температуры (это основной датчик для ПЗА). Для этого я использовал Вега ТД-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 (очень простая интеграция, разработал специально для задачи ПЗА).

UPD: Обозначил, что используемый тип выключателей: "кнопка" или "импульсный выключатель". За уточнение спасибо @akod67.

UPD: Исправил название производителя Owen -> Овен. Спасибо @joseph-cansas.