Введение и карта платформы

Урок · Основы умного дома · 30 мин · theory

Архитектура современного умного дома

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

> 📋 Ключевые понятия:

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

Современная система автоматизации строится по многоуровневой архитектуре, напоминающей сетевую модель OSI. Это позволяет сделать систему гибкой, масштабируемой и легко обслуживаемой.

| Уровень | Описание | Компоненты на нашей платформе |

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

| Физический уровень (Hardware) | Непосредственное оборудование, которое взаимодействует с реальным миром: датчики, реле, приводы, светильники. Это "глаза, уши и руки" системы. | Контроллер, модули реле, диммеры, датчики протечки, температуры, влажности, кнопки. |

| Коммуникационный уровень (Protocols) | Протоколы и шины, которые связывают физические устройства между собой и с центральным контроллером. Это "нервная система" объекта. | Проводные: RS-485 (Modbus), CAN, DALI. Беспроводные: LoRaWAN, Zigbee. Логический транспорт: MQTT. |

| Логический уровень (Automation) | "Мозг" системы. Здесь принимаются решения на основе данных с физического уровня. Сценарии, расписания, сложные алгоритмы — всё это живет здесь. | Node-RED (визуальное программирование), функции ПЛК на контроллере для критичных задач. |

| Уровень визуализации (Interfaces) | Пользовательские интерфейсы, через которые человек взаимодействует с системой: мобильные приложения, настенные панели, голосовые ассистенты. | iRidium (профессиональная визуализация), веб-интерфейс контроллера. |

В рамках наших курсов мы сфокусируемся на эталонном стеке технологий, который доказал свою надежность и гибкость на тысячах объектов:

Аппаратный шлюз (Контроллер): Наша основная рабочая лошадка на базе Linux. Он служит мостом между физическим и логическим мирами.

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

Движок автоматизации: Node-RED. Мощный и наглядный инструмент визуального программирования, идеальный для создания сценариев любой сложности.

Визуализация и управление: iRidium. Профессиональная платформа для создания кастомизированных пользовательских интерфейсов.

Понимание роли и взаимодействия этих четырех столпов — ключ к успешному внедрению любой современной системы автоматизации.

---

Физический уровень: Контроллер и Modbus

На физическом уровне мы имеем дело с настоящим "железом". Центральным элементом здесь выступает наш контроллер, который выполняет роль Программируемого Логического Контроллера (ПЛК). Он не просто запускает скрипты; он является надежным шлюзом, объединяющим десятки и сотни периферийных устройств, подключенных по разным шинам.

Одной из самых распространенных и надежных шин для профессиональных инсталляций является RS-485. Как мы знаем из предыдущих занятий, её главные преимущества — высокая помехоустойчивость и возможность прокладки на большие расстояния (до 1200 метров), что критически важно на реальных объектах.

Поверх физической шины RS-485 работает протокол Modbus RTU. Это промышленный стандарт де-факто для связи между электронными устройствами. Его ключевая модель — "мастер-слейв" (Master/Slave), где наш контроллер выступает мастером, а все периферийные устройства (модули реле, диммеры, счетчики) — слейвами.

> 💡 Подсказка: При работе с Modbus помните, что адреса устройств на одной шине RS-485 должны быть уникальны. Дублирование адресов приведет к коллизиям и полной неработоспособности сегмента сети.

Основная концепция Modbus — это работа с регистрами. Представьте, что каждое слейв-устройство — это шкаф с пронумерованными ячейками. Мастер (контроллер) может либо читать данные из этих ячеек, либо записывать новые данные в них.

Основные типы регистров в Modbus:

Coils (Койлы): Однобитные регистры на чтение/запись. Идеально подходят для управления реле (включить/выключить).
Discrete Inputs (Дискретные входы): Однобитные регистры только на чтение. Используются для опроса состояния "сухих контактов", кнопок, датчиков открытия.
Input Registers (Входные регистры): 16-битные регистры только на чтение. Типичное применение — чтение показаний с датчиков (температура, влажность, напряжение).
Holding Registers (Регистры хранения): 16-битные регистры на чтение/запись. Используются для хранения настроек устройства (например, уставки термостата) или управления аналоговыми выходами.

Как контроллер работает с Modbus-устройствами?

На нашем контроллере за преобразование данных из Modbus в более удобный формат отвечает специальная служба — `wb-mqtt-serial`. Этот сервис выполняет следующую работу:

Чтение конфигурации: Он обращается к файлам конфигурации, где описаны все подключенные к портам RS-485 Modbus-устройства, их адреса и карты регистров.

Периодический опрос: Служба в бесконечном цикле опрашивает каждое устройство согласно настройкам: отправляет Modbus-команду "прочитать регистр X" на адрес Y.

Публикация в MQTT: Получив ответ от устройства, `wb-mqtt-serial` немедленно публикует это значение в соответствующий MQTT-топик.

Таким образом, для остальной системы (для Node-RED, для iRidium) сложность протокола Modbus полностью скрыта. Они работают не с Modbus-адресами и регистрами, а с простыми и понятными MQTT-сообщениями. Например, вместо того чтобы отправлять сложную Modbus-посылку для чтения температуры, мы просто подписываемся на топик `/devices/dts_outside/controls/temperature` и получаем готовое значение. Аналогично для управления: чтобы включить реле, мы отправляем `1` в топик `/devices/wb-mr6c_15/controls/K1/on`, а `wb-mqtt-serial` сам преобразует это в нужную Modbus-команду.

---

Транспортный уровень: MQTT как "нервная система" платформы

Представьте систему, где каждый компонент должен знать о каждом другом компоненте. Датчик протечки должен знать IP-адрес модуля реле, чтобы отправить ему команду. Панель управления должна знать адреса всех диммеров. Это так называемая сильно связанная (tightly-coupled) архитектура. Она хрупкая, сложная в настройке и немасштабируемая. Добавление нового устройства превращается в кошмар, так как нужно перенастраивать все остальные.

Решение этой проблемы — слабо связанная (loosely-coupled) архитектура, основанная на модели Publish/Subscribe (Публикация/Подписка). Идеальным инструментом для ее реализации является протокол MQTT (Message Queuing Telemetry Transport).

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

> 📋 Ключевые понятия:

> * Брокер (Broker): Центральный сервер, который принимает сообщения от одних клиентов и пересылает их другим. Наш контроллер уже имеет встроенный и настроенный MQTT-брокер.

> * Клиент (Client): Любое устройство или программа, подключенная к брокеру. Датчик, реле, Node-RED, приложение на смартфоне — все они являются MQTT-клиентами.

> * Публикация (Publish): Процесс отправки сообщения брокеру. Клиент, отправляющий сообщение, называется издателем (publisher).

> * Подписка (Subscribe): Процесс информирования брокера о том, что клиент хочет получать сообщения на определенную тему. Такой клиент называется подписчиком (subscriber).

> * Топик (Topic): Строковый идентификатор, похожий на путь к файлу (например, `/office/floor1/room101/light/status`), который категоризирует сообщения. Издатели отправляют сообщения в топики, а подписчики подписываются на интересующие их топики.

> * Сообщение (Payload): Непосредственно передаваемые данные. Это может быть что угодно: строка "ON", число 23.5, или, что чаще всего используется, структурированный JSON-объект.

Наш контроллер использует стандартизированную структуру топиков, что делает систему предсказуемой и легкой для интеграции:

`/devices/{имя_устройства}/controls/{имя_канала}`

`/devices/`: Статический префикс.
`{имя_устройства}`: Уникальное имя устройства, например `wb-mr6c_25` или `dht22_humidity_sensor`.
`/controls/`: Статический разделитель.
`{имя_канала}`: Конкретный канал управления или датчик на устройстве, например `K1` (для реле 1), `temperature`, `voltage`.

Для управления устройством используется дополнительный суффикс `/on`.

Чтение состояния: Подписаться на `/devices/wb-mr6c_25/controls/K1`. Брокер будет присылать сообщения `0` или `1`.
Запись/команда: Опубликовать значение `1` в топик `/devices/wb-mr6c_25/controls/K1/on`, чтобы включить реле.

> ⚠️ Внимание: Используйте 'retained' флаг для MQTT-сообщений с осторожностью. Он полезен для сохранения последнего состояния сенсоров, но может вызывать нежелательные срабатывания логики при перезагрузке Node-RED или других клиентов, если используется для команд или событий.

Незаменимым инструментом для работы с MQTT является утилита MQTT Explorer. Она подключается к брокеру как клиент, подписывается на все топики (`#`) и строит наглядное дерево всех сообщений в системе в реальном времени. Это позволяет отслеживать данные с датчиков, видеть команды управления и быстро диагностировать проблемы, когда "что-то не работает".

---

Логический уровень: Node-RED для автоматизации

Если MQTT — это нервная система, то Node-RED — это мозг. Это среда визуального потокового программирования, которая позволяет создавать сценарии автоматизации путем соединения готовых функциональных блоков — узлов (nodes) — на рабочем поле. Это устраняет необходимость писать сложный код для большинства задач автоматизации и делает логику работы системы наглядной.

Основные элементы интерфейса Node-RED:

Палитра узлов (слева): Библиотека всех доступных узлов, сгруппированных по категориям (ввод, вывод, функции, MQTT, и т.д.).
Рабочее поле (в центре): Бесконечный холст, на котором вы строите свои потоки (flows), соединяя узлы.
Боковая панель (справа): Содержит вкладки "Информация" (документация по выбранному узлу), "Помощь" и, самое главное, "Отладка" (Debug), куда выводятся сообщения от отладочных узлов.

Концепция объекта `msg`

Ключ к пониманию Node-RED — это концепция объекта `msg`. Данные в Node-RED не передаются сами по себе; они "путешествуют" внутри стандартного JavaScript-объекта, который по умолчанию называется `msg`. Когда один узел завершает свою работу, он передает этот объект `msg` следующему узлу по соединению.

Каждый узел может читать данные из `msg`, изменять их или добавлять новые. Самое важное свойство этого объекта — `msg.payload`.

> `msg.payload` — это свойство, которое по соглашению используется для хранения основных передаваемых данных.

Например, узел `mqtt in` при получении сообщения из топика формирует объект `msg`, где `msg.payload` будет содержать значение из MQTT-сообщения, а `msg.topic` — имя топика.

Практический пример: кнопка управляет светом

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

Задача: Кнопка подключена к входу `K1` модуля `wb-mwac_10` (адрес Modbus 10). Лампочка подключена к реле `K2` модуля `wb-mr6c_25` (адрес Modbus 25). Логика:

Подписаться на MQTT-топик состояния кнопки.

При получении сообщения со значением `1` (кнопка нажата)...

...отправить команду `1` в MQTT-топик управления реле.

Построение потока в Node-RED:

Вход: Из палитры перетащите на поле узел `mqtt in`. Дважды кликните по нему и настройте:

* Сервер: Выберите преднастроенный брокер (обычно `localhost:1883`).

* Топик: `/devices/wb-mwac_10/controls/K1`

* Вывод: `a parsed JSON object` (если ожидается JSON) или `a string` (для простых значений). В нашем случае — строка.

Логика (Фильтр): Перетащите узел `switch`. Он будет фильтровать сообщения. Настройте его так, чтобы он пропускал сообщение дальше, только если `msg.payload` `==` (строка) `1`.

Действие (Формирование команды): Перетащите узел `change`. Он изменит `msg.payload` перед отправкой. Добавьте правило: `Set` `msg.payload` `to` `1` (число). Это нужно, так как многие устройства ожидают именно число `1` или `0` в команде, а не строку.

Выход: Перетащите узел `mqtt out`. Настройте его:

* Сервер: Тот же брокер.

* Топик: `/devices/wb-mr6c_25/controls/K2/on`

Соединение: Соедините узлы в цепочку: `mqtt in` -> `switch` -> `change` -> `mqtt out`.

Развертывание: Нажмите красную кнопку `Deploy` в правом верхнем углу. Ваш сценарий активен!

Визуальная схема потока (ASCII):

                           ┌──────────┐      ┌──────────┐
(кнопка нажата) --► | mqtt in  | --► |  switch  | --► (если payload=='1')
(value: "1")       | /dev/... |      | payload? |
                   └──────────┘      └──────────┘
                                          |
                                          ▼
                   ┌──────────┐      ┌──────────┐
(команда "вкл") ◄-- | mqtt out | ◄-- |  change  |
(value: 1)         | /dev/... |      | set_pl:1 |
                   └──────────┘      └──────────┘

Контракт сообщения на входе (от узла `mqtt in`):

{
    "payload": "1",
    "topic": "/devices/wb-mwac_10/controls/K1",
    "qos": 0,
    "retain": false,
    "_msgid": "..."
}

Контракт сообщения на выходе (перед узлом `mqtt out`):

{
    "payload": 1,
    "topic": "/devices/wb-mwac_10/controls/K1",
    "qos": 0,
    "retain": false,
    "_msgid": "..."
}

Обратите внимание, как узел `change` изменил `msg.payload` со строки `"1"` на число `1`, а узел `mqtt out` отправит это значение в совершенно другой топик. Это и есть суть автоматизации на Node-RED.

---

Уровень визуализации и управления: iRidium

Последний, но не по значимости, уровень — это уровень визуализации. Конечный пользователь системы — житель дома, сотрудник офиса, гость отеля — не должен иметь дела с MQTT-топиками или Node-RED. Ему нужен простой, красивый и интуитивно понятный интерфейс на смартфоне или настенной панели. Для решения этой задачи мы используем платформу iRidium.

iRidium — это профессиональный инструмент для создания полностью кастомизированных интерфейсов управления.

Архитектура iRidium:

iRidium Studio: Мощная среда разработки (IDE) для Windows, в которой интегратор "рисует" интерфейс, размещает кнопки, слайдеры, иконки и привязывает их к командам и каналам обратной связи.
iRidium Server: Серверная часть проекта, которая может быть запущена на отдельном ПК, Raspberry Pi или даже на нашем контроллере. Сервер постоянно подключен к MQTT-брокеру и содержит всю логику взаимодействия с оборудованием.
iRidium App: Клиентское приложение для iOS, Android, Windows, C, которое устанавливается на устройствах пользователя (смартфоны, планшеты). Приложение подключается к iRidium Server для получения состояний и отправки команд.

iRidium как MQTT-клиент

По своей сути, iRidium Server является еще одним продвинутым MQTT-клиентом.

Для отображения состояний (обратная связь): В iRidium Studio вы создаете, например, иконку лампочки. В ее свойствах вы указываете, что ее состояние "включено" зависит от значения в MQTT-топике `/devices/wb-mr6c_25/controls/K2`. iRidium Server подписывается на этот топик. Как только в нем появляется значение `1`, сервер сообщает об этом приложению, и иконка меняет свой вид. Это обеспечивает обратную связь — пользователь всегда видит актуальное состояние системы.
Для отправки команд: Для кнопки "Включить свет" вы настраиваете действие: "при нажатии опубликовать значение `1` в топик `/devices/wb-mr6c_25/controls/K2/on`".

Полный цикл команды от пользователя:

Давайте проследим весь путь сигнала от нажатия кнопки в приложении до изменения статуса этой кнопки.

Пользователь нажимает кнопку "Свет в гостиной" в приложении iRidium App.

iRidium App отправляет команду на iRidium Server.

iRidium Server, согласно настройкам проекта, публикует сообщение со значением `1` в MQTT-топик `/devices/livingroom_light/controls/K1/on`.

MQTT-брокер на контроллере немедленно доставляет это сообщение всем подписчикам, включая сервис `wb-mqtt-serial`.

`wb-mqtt-serial` преобразует MQTT-команду в Modbus-команду "записать 1 в Coil X" и отправляет ее на шину RS-485 нужному модулю реле.

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

Обратная связь: В следующем цикле опроса `wb-mqtt-serial` читает новое состояние реле (теперь оно `1`).

`wb-mqtt-serial` публикует новое состояние в "статусный" MQTT-топик: `/devices/livingroom_light/controls/K1` со значением `1`.

MQTT-брокер доставляет это сообщение всем подписчикам, включая iRidium Server.

iRidium Server видит, что статус изменился, и отправляет обновление в iRidium App.

iRidium App получает обновление и отрисовывает кнопку в состоянии "включено".

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

> 🔗 Связанный материал: Подробное изучение iRidium, включая создание кастомных интерфейсов и написание скриптов на JS, будет рассмотрено в курсе COURSE-05: "Профессиональная Визуализация и Управление".

Что дальше

В этом уроке мы рассмотрели высокоуровневую архитектуру платформы, от физических устройств до пользовательского интерфейса. Мы увидели, как Modbus, MQTT, Node-RED и iRidium работают вместе, создавая мощную и гибкую систему. В следующем уроке, COURSE-01-M01-L02: Первое подключение к контроллеру и настройка сети, мы перейдем от теории к практике: впервые подключимся к нашему контроллеру, настроим его сетевые параметры и убедимся, что все базовые сервисы запущены и готовы к работе.