Практика: Выбор архитектуры для кейса

Введение и постановка задачи

Цели и структура урока

Добро пожаловать на практический урок, в котором мы объединим все теоретические знания, полученные в этом модуле. Сегодня мы не будем изучать новые концепции. Вместо этого мы применим ранее рассмотренные архитектурные шаблоны для решения реальной инженерной задачи. Наша цель — пройти весь путь от первоначальных требований заказчика до готовой архитектурной схемы и примера реализации базового сценария.

Структура урока построена по логике реального проекта:

Постановка задачи: знакомимся с объектом, оборудованием и пожеланиями клиента.

Анализ и выбор: декомпозируем требования и обоснованно выбираем архитектурный шаблон.

Проектирование: определяем роль каждого компонента и создаем структуру "цифровой нервной системы" — пространства имен MQTT-топиков.

Реализация: на примере сценария "Ушел из дома" посмотрим, как теория превращается в работающий код в Node-RED.

Итоги: формируем финальную архитектурную схему и обсуждаем перспективы масштабирования.

Описание практического кейса: умная квартира 70м²

Наш сегодняшний объект — типовая двухкомнатная квартира площадью 70 квадратных метров. В ней проживает семья с одним ребенком. Выполнен дизайнерский ремонт, и на этапе проектирования были заложены основы для системы автоматизации.

Исходные данные:

• Объект: Квартира (гостиная, спальня, детская, кухня, санузел, коридор).
• Силовой щит: Собран с учетом автоматизации, все группы освещения и розеток заведены в щит отдельными линиями.
• Заказчик: Технически подкован, но не является программистом. Ценит надежность и удобство, хочет иметь возможность удаленного контроля.

Формулирование требований заказчика

В ходе обсуждения проекта были сформулированы следующие функциональные требования:

Освещение:

* Управление всеми основными группами света с настенных выключателей и из приложения.

* Диммирование света в гостиной и спальне.

* Декоративная подсветка (кухонный гарнитур, шторы), управляемая отдельно.

Климат:

* Управление электрическими теплыми полами в санузле и на кухне по расписанию и температуре.

* Управление радиаторами отопления (установлены термоголовки с приводами).

Шторы:

* Управление электрокарнизами в гостиной и спальне (открыть/закрыть/стоп).

Сценарии:

* "Я ушел": по нажатию одной кнопки у выхода выключается весь свет и некритичные розетки (кроме холодильника, роутера и т.д.).

* "Кино": в гостиной плавно гаснет основной свет, включается декоративная подсветка, закрываются шторы.

* "Ночь": во всей квартире выключается свет, кроме ночника в детской, теплые полы переходят в экономичный режим.

Безопасность и мониторинг:

* Датчики движения в коридоре и гостиной для ночной подсветки и охранных функций.

* Датчики протечки воды на кухне и в санузле с автоматическим перекрытием вводных кранов.

* Удаленный доступ к системе через смартфон для контроля и управления.

Определение исходного стека оборудования

На объекте уже частично установлено или выбрано заказчиком следующее оборудование, которое нам необходимо интегрировать:

• Центральный контроллер: Наш стандартный контроллер HI-Core (Debian, Node-RED, 4 ядра/4 ГБ RAM) с его набором входов/выходов. Он будет сердцем системы.
• Выключатели: Дизайнер настоял на использовании выключателей стандарта KNX. Они уже установлены на стенах. Для их интеграции потребуется KNX/IP шлюз.
• Беспроводные датчики: Для датчиков движения и протечки выбран стандарт Zigbee из-за их доступности, компактности и отсутствия проводов. Мы будем использовать популярные модели от Aqara (Lumi).
• Исполнительные устройства: Управление освещением, розетками и кранами будет осуществляться через релейные модули, подключенные к контроллеру HI-Core по шине RS-485 (Modbus).

Таким образом, перед нами стоит задача интеграции трех разных технологий (прямое управление с контроллера, KNX, Zigbee) в единую, целостную систему.

---

Анализ требований и выбор архитектурного шаблона

> 🔗 Связанный материал: Подробный разбор каждого шаблона и критериев выбора мы рассматривали в уроках COURSE-01-M06-L01-L04. Сейчас мы применим эти знания на практике.

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

Декомпозиция требований по подсистемам

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

| Подсистема | Требования | Потенциальные устройства и технологии | Критичность (Offline-First) |

| :--- | :--- | :--- | :--- |

| Освещение | Вкл/Выкл, Диммирование | Релейные модули (Modbus), Диммеры (Modbus/0-10V), KNX-выключатели, Контроллер HI | Высокая |

| Климат | Теплые полы, Радиаторы | Реле для полов (Modbus), Приводы для радиаторов (Zigbee/Modbus), Датчики температуры (1-Wire) | Средняя |

| Шторы | Открыть/Закрыть/Стоп | Релейные модули с поддержкой реверсивного режима (Modbus), Контроллер HI | Низкая |

| Сценарии | "Ушел", "Кино", "Ночь" | Логика в Node-RED, KNX-выключатели (триггеры), Приложение | Высокая |

| Безопасность| Протечки, Движение | Zigbee-датчики, Электрокраны (управляются реле), Контроллер HI | Критическая |

Оценка нефункциональных требований

• Надежность: Ключевое требование — offline-first. Все базовые функции (управление светом с выключателей, защита от протечек) должны работать даже при полном отсутствии интернета. Сценарии также должны исполняться локально. Удаленный доступ является вторичной функцией.
• Масштабируемость: Система должна позволять в будущем легко добавлять новые устройства, например, Zigbee-розетки, датчики CO₂, или интегрировать голосового ассистента.
• Бюджет: Выбор Zigbee-датчиков и управления нагрузками через контроллер HI вместо полной системы на KNX уже является мерой оптимизации бюджета. Архитектура должна поддерживать эту гетерогенную (разнородную) среду.

Сравнительный анализ применимости шаблонов

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

Шаблон "Standalone" (Автономный контроллер):

Применимость:* Этот шаблон предполагает, что все устройства подключены напрямую к одному контроллеру. В нашем случае это не так. У нас есть KNX и Zigbee устройства, которые требуют внешних шлюзов и протоколов для взаимодействия. Чистый Standalone-подход не сработает, так как он не описывает, как контроллер будет "общаться" с KNX-шиной и Zigbee-сетью.

Вердикт:* Не подходит.

Шаблон "Multi-controller" (Иерархия):

Применимость:* Этот шаблон используется на крупных объектах (офисы, гостиницы), где несколько контроллеров управляют своими зонами (этаж, крыло) и координируются центральным сервером.

Вердикт:* Избыточен. Для квартиры площадью 70м² одного контроллера HI-Core более чем достаточно для управления всей логикой и нагрузками. Устанавливать несколько контроллеров было бы неоправданно дорого и сложно.

Шаблон "Edge + MQTT Broker":

Применимость:* Этот шаблон описывает систему, где есть центральный MQTT-брокер (цифровой посредник), а различные устройства и сервисы ("говорящие" на разных языках) общаются через него.

* Контроллер HI-Core выступает в роли Edge-устройства: он напрямую управляет своими входами/выходами (реле, диммеры, датчики 1-Wire) и публикует их состояния в MQTT. Он же подписывается на команды из MQTT для исполнения.

* KNX/IP шлюз действует как "мост", транслируя события из шины KNX (нажатия кнопок) в сообщения MQTT и обратно.

* Zigbee-адаптер с программным обеспечением Zigbee2MQTT также является "мостом", который превращает радиосигналы от датчиков в сообщения MQTT.

* Вся логика сценариев реализуется в Node-RED, который подписывается на нужные MQTT-события (нажата кнопка, сработал датчик) и публикует команды для исполнительных устройств.

Вердикт:* Оптимальный выбор.

Обоснование выбора шаблона "Edge + MQTT Broker"

Этот шаблон идеально решает нашу главную задачу: интеграцию разнородных систем. Он позволяет создать единое информационное пространство на базе протокола MQTT, где каждое устройство, будь то реле на шине Modbus, дорогая KNX-кнопка или дешевый Zigbee-датчик, становится равноправным участником системы. Вся система может работать полностью локально на контроллере HI-Core, который будет одновременно выполнять роль Edge-контроллера, хоста для MQTT-брокера и среды исполнения Node-RED. Это обеспечивает максимальную надежность (offline-first) при сохранении гибкости и масштабируемости.

---

Проектирование решения: Компоненты и MQTT-топики

> 💡 Подсказка: Стандартизированная и осмысленная структура MQTT-топиков — это 80% успеха при дальнейшей отладке и масштабировании системы. Рекомендуем формат `проект/локация/группа/устройство/действие`, например: `home/living_room/light/main/set` и `home/living_room/light/main/state`.

Мы выбрали архитектуру. Теперь спроектируем ее компоненты и, что самое важное, язык их общения — пространство имен MQTT.

Роль компонентов

| Компонент | Программное обеспечение | Роль в системе |

| :--- | :--- | :--- |

| Контроллер HI-Core | Debian Linux, HI Drivers | Физический интерфейс с оборудованием (реле, входы), хост-система. |

| MQTT-брокер | Mosquitto (установлен на HI-Core) | Центральная нервная система. Принимает и пересылает все сообщения. |

| Движок автоматизации | Node-RED (установлен на HI-Core) | Мозг системы. Реализует всю логику сценариев, обработки данных. |

| Zigbee мост | USB-стик + Zigbee2MQTT | "Переводчик" с языка Zigbee на MQTT. Публикует данные с датчиков. |

| KNX мост | KNX/IP шлюз + адаптер в Node-RED | "Переводчик" с языка KNX на MQTT. Публикует нажатия кнопок. |

| Интерфейс пользователя| Мобильное приложение / Веб-интерфейс | Визуализация и управление. Напрямую общается с MQTT-брокером. |

Схема взаимодействия

Обмен данными происходит следующим образом:

Событие: Пользователь нажимает KNX-кнопку.

Мост KNX->MQTT: KNX/IP шлюз ловит событие в шине и публикует сообщение в MQTT-топик, например, `home/hall/switch/exit_button/state` с payload `{"click": "single"}`.

Логика: Node-RED подписан на этот топик. Получив сообщение, он запускает сценарий "Ушел из дома".

Команды: Node-RED публикует серию команд в другие MQTT-топики:

* `home/living_room/light/main/set` с payload `OFF`

* `home/kitchen/sockets/group1/set` с payload `OFF`

* и т.д.

Исполнение:

* Драйвер контроллера HI-Core подписан на эти топики, получает команды и размыкает соответствующие реле.

* После успешного переключения он публикует новое состояние в "статусный" топик, например, `home/living_room/light/main/state` с payload `OFF`.

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

Таким образом мы получаем систему с полной статусной обратной связью, работающую через единый центр — MQTT-брокер.

Проектирование пространства имен MQTT-топиков

Создадим четкую иерархическую структуру.

Формат: `home/<локация>/<тип_устройства>/<имя_устройства>/[state|set|command]`

| Устройство / Сущность | Топик для управления (set/command) | Топик для статуса (state) | Пример Payload |

| :--- | :--- | :--- | :--- |

| Реле освещения в гостиной | `home/living_room/light/main/set` | `home/living_room/light/main/state` | `"ON"`, `"OFF"` |

| Реле розеток на кухне | `home/kitchen/socket/worktop/set` | `home/kitchen/socket/worktop/state` | `"ON"`, `"OFF"` |

| Штора в спальне | `home/bedroom/blind/main/command` | `home/bedroom/blind/main/state` | `"OPEN"`, `"CLOSE"`, `"STOP"` |

| Zigbee датчик движения `lumi.sensor_motion.aq2` | - (только чтение) | `zigbee2mqtt/motion_sensor_hall` | `{ "occupancy": true, "battery": 95, ... }` |

| KNX кнопка "Ушел из дома" | - (только чтение) | `knx/0/1/2/state` (зависит от настроек шлюза) | `1` (нажато) |

| Сценарий "Кино" | `home/scenes/movie/command` | `home/scenes/movie/state` | `"START"` |

# Пример структуры для релейного модуля, подключенного к контроллеру HI
# Управление первым реле (свет в коридоре)
> mosquitto_pub -t "home/hall/light/main/set" -m "ON"
# Статус этого же реле, публикуемый драйвером контроллера
> mosquitto_sub -t "home/hall/light/main/state"
OFF
ON

# Пример данных от Zigbee датчика движения
> mosquitto_sub -t "zigbee2mqtt/motion_sensor_living_room"
{"battery":100,"illuminance":347,"illuminance_lux":347,"linkquality":92,"occupancy":true,"voltage":3025}

Такая структура позволяет легко подписываться на все события в одной комнате (`home/living_room/#`) или на состояние всех светильников в доме (`home/+/light/+/state`).

---

Практика в Node-RED: Сценарий 'Ушел из дома'

> ⚠️ Внимание: Для критически важной логики, например, защиты от протечек, рекомендуется дублировать автоматизацию на уровне встроенной функции ПЛК контроллера HI. Node-RED гибок и мощен, но логика ПЛК работает на более низком уровне, не зависит от состояния движка Node.js и гарантирует детерминированное время исполнения.

Рассмотрим, как будет выглядеть поток (flow) в Node-RED для реализации сценария "Ушел из дома".

Описание логики сценария

• Триггер: Нажатие на одноклавишный KNX-выключатель у входной двери. Шлюз публикует сообщение в топик `knx/0/1/5/state`.
• Условия: В данном простом сценарии нет сложных условий. Мы просто реагируем на факт нажатия.
• Действия:

1. Выключить все группы света во всех комнатах.

2. Выключить "некритичные" группы розеток (например, розетки для торшеров, телевизора, аудиосистемы).

3. Отправить PUSH-уведомление на телефон владельца: "Активирован сценарий 'Я ушел'".

Настройка ноды `mqtt in`

Это стартовая точка нашего потока. Мы создаем ноду `mqtt in` и настраиваем ее:

• Server: Выбираем наш локальный MQTT-брокер (обычно `localhost:1883`).
• Topic: `knx/0/1/5/state` (или тот топик, что настроен в вашем KNX/IP шлюзе для этой кнопки).
• QoS: `0`.
• Output: `a parsed JSON object` (если шлюз отправляет JSON) или `a string` (если он отправляет просто "1" или "ON").

Пример кода JSON для экспорта потока Node-RED

Ниже приведен пример JSON-представления нашего потока. Вы можете скопировать этот код и импортировать его в свой Node-RED (`Меню -> Импорт`), чтобы увидеть структуру.

[
    {
        "id": "a1b2c3d4.e5f6a7",
        "type": "mqtt in",
        "z": "f0e1d2c3.b4a5f6",
        "name": "KNX Кнопка 'Я ушел'",
        "topic": "knx/0/1/5/state",
        "qos": "0",
        "datatype": "auto",
        "broker": "local-mqtt-broker-id",
        "x": 150,
        "y": 200,
        "wires": [
            [
                "b1c2d3e4.f5a6b7",
                "c1d2e3f4.a5b6c7",
                "d1e2f3a4.b5c6d7",
                "e1f2a3b4.c5d6e7"
            ]
        ]
    },
    {
        "id": "b1c2d3e4.f5a6b7",
        "type": "mqtt out",
        "z": "f0e1d2c3.b4a5f6",
        "name": "Выкл. свет гостиная",
        "topic": "home/living_room/light/main/set",
        "qos": "",
        "retain": "",
        "broker": "local-mqtt-broker-id",
        "x": 450,
        "y": 120,
        "wires": []
    },
    {
        "id": "c1d2e3f4.a5b6c7",
        "type": "mqtt out",
        "z": "f0e1d2c3.b4a5f6",
        "name": "Выкл. свет спальня",
        "topic": "home/bedroom/light/main/set",
        "qos": "",
        "retain": "",
        "broker": "local-mqtt-broker-id",
        "x": 450,
        "y": 180,
        "wires": []
    },
    {
        "id": "d1e2f3a4.b5c6d7",
        "type": "mqtt out",
        "z": "f0e1d2c3.b4a5f6",
        "name": "Выкл. розетки ТВ",
        "topic": "home/living_room/socket/media/set",
        "qos": "",
        "retain": "",
        "broker": "local-mqtt-broker-id",
        "x": 450,
        "y": 240,
        "wires": []
    },
    {
        "id": "e1f2a3b4.c5d6e7",
        "type": "function",
        "z": "f0e1d2c3.b4a5f6",
        "name": "Формирование сообщения",
        "func": "// Мы не меняем msg.payload, так как он нам не нужен.\n// Просто устанавливаем новый payload для следующей ноды.\nmsg.payload = \"OFF\";\nreturn msg;",
        "outputs": 1,
        "noerr": 0,
        "x": 280,
        "y": 300,
        "wires": [
            [
                "b1c2d3e4.f5a6b7",
                "c1d2e3f4.a5b6c7",
                "d1e2f3a4.b5c6d7"
            ]
        ]
    }
]

Примечание: в реальном потоке вместо дублирования `mqtt out` нод можно использовать `function` ноду, которая в цикле отправит несколько сообщений.

Разбор потока

`mqtt in` (ID: `a1b2c3d4.e5f6a7`): Это наш триггер. Когда приходит сообщение, оно передается дальше по "проводам" (`wires`).

Промежуточная логика (не показана в простом примере): Здесь могла бы быть нода `switch` для проверки времени суток или нода `function` для более сложной логики. В нашем случае для простоты используется одна `function`-нода `e1f2a3b4.c5d6e7`, которая просто устанавливает `msg.payload` в `OFF`.

`mqtt out` (ID: `b1c2d3e4.f5a6b7` и другие): Каждая из этих нод отвечает за отправку команды на выключение конкретного устройства. Они все получают на вход сообщение с `payload: "OFF"` и публикуют его в свой, уникальный `topic`.

Этот пример демонстрирует мощь и простоту архитектуры "Edge + MQTT": одна нода-триггер (`mqtt in`) может запустить целый каскад действий, управляя десятками устройств, даже если они принадлежат к разным технологическим стекам. Главное, чтобы все они "говорили" на одном языке — MQTT.

---

Итоги и финальная архитектурная схема

Мы прошли путь от размытых требований до конкретной реализации. Давайте подведем итоги и закрепим полученный результат в виде финальной схемы.

Резюме принятых архитектурных решений

• Архитектурный шаблон: Выбран "Edge + MQTT Broker" как наиболее гибкий, надежный и масштабируемый для задачи интеграции разнородных систем (HI-Core I/O, KNX, Zigbee) на локальном объекте.
• Центр системы: Контроллер HI-Core выполняет роль и вычислительного узла (Edge), и хоста для MQTT-брокера, и среды для логики Node-RED. Это обеспечивает полную автономность.
• "Язык общения": Протокол MQTT используется как универсальная шина данных, объединяющая все подсистемы.
• Структура топиков: Разработано иерархическое пространство имен (`home/location/device/...`), обеспечивающее порядок и простоту отладки.
• Логика: Основная логика сценариев реализуется в Node-RED, что дает гибкость, а критически важные функции (защита от протечек) дублируются на уровне ПЛК контроллера для максимальной надежности.

Визуальная блок-схема итоговой архитектуры

+---------------------------------------------------------------------------------+
|                                  Уровень Приложения                             |
|    [Мобильное приложение] <-----> [Веб-интерфейс] <-----> [Голосовой ассистент]  |
+------------------------------------^--------------------------------------------+
                                     | (MQTT over WebSocket/TLS)
                                     |
+------------------------------------V--------------------------------------------+
|                            ЛОГИЧЕСКИЙ УРОВЕНЬ (на HI-Core)                        |
|                                                                                 |
|   +-------------------+ <-----> +-------------------+ <-----> +---------------+   |
|   |    Node-RED       |         |   MQTT-брокер     |         |    База данных|   |
|   | (Логика сценариев)|         |   (Mosquitto)     |         |    (MySQL)    |   |
|   +-------------------+         +-------------------+         +---------------+   |
|                                          ^                                      |
+------------------------------------------|--------------------------------------+
                 (Локальные MQTT-сообщения)|
+------------------------------------------V--------------------------------------+
|                           УРОВЕНЬ ДРАЙВЕРОВ И МОСТОВ                            |
|                                                                                 |
| [HI-Core Drivers] <-----> [Zigbee2MQTT] <-----> [KNX/IP Gateway Driver] <-----> [..] |
|                                                                                 |
+------------------------------------------^--------------------------------------+
                                           |
+------------------------------------------V--------------------------------------+
|                              ФИЗИЧЕСКИЙ УРОВЕНЬ                                 |
|                                                                                 |
| [Реле, Датчики 1-Wire]   [Zigbee-датчики]   [KNX-кнопки]   [Modbus-устройства]   |
| (Подключены к HI-Core)   (Радиоканал)       (Шина KNX)     (Шина RS-485)         |
|                                                                                 |
+---------------------------------------------------------------------------------+

Ключевые выводы урока

Анализ требований — самый важный этап. Правильный выбор архитектуры на старте экономит огромное количество времени и денег на этапах внедрения и поддержки.

MQTT — это "универсальный клей" для современного умного дома, позволяющий элегантно объединять несовместимые на физическом уровне системы.

Хорошо спроектированная структура топиков превращает хаос сообщений в стройную и понятную систему, которую легко диагностировать с помощью утилит вроде `mqtt-cli`.

Современный контроллер, такой как HI-Core, — это не просто набор реле. Это мощная Edge-платформа, способная локально запустить всю необходимую инфраструктуру, обеспечив истинную надежность, независимую от облаков.

Что дальше?

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