Протоколы связи в экосистеме HI
COURSE-16-M02-L02 — Протоколы связи в экосистеме HI
Введение в протоколы связи
Любая система автоматизации — это, в первую очередь, система коммуникаций. Устройства должны обмениваться данными: датчики передают измерения, контроллеры отправляют команды, а системы верхнего уровня собирают телеметрию. Протоколы связи — это формализованные языки и правила, которые позволяют этим устройствам «договариваться» друг с другом.
В экосистеме HI выбор протокола диктуется задачей, типом оборудования и требованиями к надежности. Наш контроллер является универсальным шлюзом, поддерживающим ключевые промышленные и IoT-протоколы. Ваша задача как инженера — не просто знать названия протоколов, а понимать, какой из них выбрать для конкретной задачи и как его правильно сконфигурировать для обеспечения стабильной и отказоустойчивой работы объекта.
В этом уроке мы разберем основные протоколы, доступные на контроллере HI, и научимся применять их на практике с помощью Node-RED.
MQTT (Message Queuing Telemetry Transport) — Язык для IoT
MQTT — это легковесный протокол обмена сообщениями, работающий по модели «издатель-подписчик» (publish/subscribe). Он является стандартом де-факто для большинства IoT-проектов благодаря своей эффективности и низким требованиям к ресурсам.
Принцип работы:Вместо прямой связи между устройствами, все сообщения отправляются центральному серверу — брокеру. Устройства-издатели (publishers), например, датчики температуры, отправляют сообщения в определенные топики (topics) — именованные каналы, например `hi/office/room101/temperature`. Устройства-подписчики (subscribers), например, панель визуализации или логический сценарий, подписываются на эти топики и получают все сообщения, которые в них поступают.
Применение на платформе HI:- Основной протокол для обмена данными между контроллерами HI, мобильными приложениями, облачными платформами и системами верхнего уровня (SCADA).
- Передача телеметрии с датчиков.
- Отправка команд управления на исполнительные устройства.
- Организация взаимодействия между различными подсистемами (например, климат и безопасность).
💡 Совет: На контроллере HI уже может быть предустановлен MQTT-брокер (например, Mosquitto). Это позволяет создавать полностью автономные системы без зависимости от внешних облачных сервисов.
Пример потока в Node-RED: Публикация данных с датчика Задача: Каждые 10 секунд отправлять показания виртуального датчика температуры в MQTT-топик. ASCII-схема потока (ID: `FLOW-FOUND-MQTT-001`): +--------------------+ +---------------------------+ +------------------+
[Inject] -> | Function: | -> | mqtt out: | -> | Status |
| "Generate Temp" | | "To Local Broker" | +------------------+
+--------------------+ +---------------------------+
Код для узла `Function: "Generate Temp"`:
// Генерируем случайное значение температуры для примера
let temp = (22.5 + Math.random() * 2).toFixed(1);
// 1. Формируем сообщение строго по контракту
msg.payload = {
value: parseFloat(temp),
source: "virtual-temp-sensor-01",
ts: Date.now(),
unit: "°C"
};
// 2. Устанавливаем топик для публикации
msg.topic = "hi/telemetry/lab/room1/temperature";
// 3. Обновляем визуальный статус узла для быстрой диагностики
node.status({fill:"green", shape:"dot", text:"Sent: " + temp + " °C"});
return msg;
Контракт сообщения (в `msg.payload`):
{
"value": 23.1,
"source": "virtual-temp-sensor-01",
"ts": 1678886400000,
"unit": "°C"
}
Modbus (RTU и TCP) — Язык промышленности
Modbus — это проверенный временем протокол, широко используемый в промышленной автоматизации для связи с релейными модулями, счетчиками электроэнергии, частотными преобразователями и климатическим оборудованием.
Принцип работы:Протокол работает по модели «ведущий-ведомый» (master-slave) или «клиент-сервер». Master (контроллер HI) отправляет запросы на чтение или запись данных в определенные регистры (ячейки памяти) Slave-устройства (например, счетчика).
- Modbus RTU: Использует последовательный интерфейс RS-485. Устройства соединяются двухпроводной шиной. Каждому устройству на шине присваивается уникальный адрес (ID от 1 до 247).
- Modbus TCP: Использует сеть Ethernet (TCP/IP). Каждому устройству присваивается IP-адрес.
- Интеграция с профессиональным инженерным оборудованием: счетчиками, ИБП, вентиляционными установками, дизель-генераторами.
- Управление модулями реле и диммерами по шине RS-485.
- Сбор данных с промышленных датчиков.
⚠️ Предупреждение: Наиболее частые проблемы с Modbus RTU связаны с физическим уровнем: неправильная полярность (перепутаны провода A/B), отсутствие согласующих резисторов (терминаторов 120 Ом) на концах шины или неверные настройки скорости порта.
Пример потока в Node-RED: Опрос счетчика электроэнергии Задача: Каждую минуту считывать текущее значение потребляемой мощности из Holding-регистра `40101` (адрес `100`) Modbus-устройства с ID `5`. ASCII-схема потока (ID: `FLOW-FOUND-MODBUS-001`): +----------+ +-------------------+ +----------------------+ +------------------+
[Inject] -> | modbus- | -> | Function: | -> | mqtt out: | -> | Status |
| Getter | | "Parse & Format" | | "Power Telemetry" | +------------------+
+----------+ +----------------------+ +------------------+
| (on error)
v
+----------------+
| Catch | -> [To Error Logger]
+----------------+
Код для узла `Function: "Parse & Format"`:
// Входящие данные от узла modbus-getter: msg.payload.data = [1578] (массив)
let rawValue = msg.payload.data[0];
// 1. Валидация данных
if (rawValue < 0 || rawValue > 50000) { // Примерный диапазон мощности в Ваттах
node.error("Invalid power value from Modbus: " + rawValue, msg);
node.status({fill:"red", shape:"dot", text:"Invalid value: " + rawValue});
return null; // Останавливаем поток
}
// 2. Формирование сообщения по контракту
msg.payload = {
value: rawValue,
source: "powermeter-main-01",
ts: Date.now(),
unit: "W"
};
// 3. Установка топика
msg.topic = "hi/telemetry/electrical/main/power";
node.status({fill:"green", shape:"dot", text:"OK: " + rawValue + " W"});
return msg;
Контракт сообщения (в `msg.payload`):
{
"value": 1578,
"source": "powermeter-main-01",
"ts": 1678887000000,
"unit": "W"
}
HTTP/HTTPS — Язык Веба
HTTP — это протокол, лежащий в основе всего веба. Он работает по модели «запрос-ответ». Хотя он более "тяжеловесный" по сравнению с MQTT, он незаменим для интеграции с внешними веб-сервисами.
Применение на платформе HI:- Получение данных от внешних API (например, прогноз погоды, курсы валют).
- Отправка данных в облачные системы аналитики, не поддерживающие MQTT.
- Создание простых панелей управления (Dashboard) или API для взаимодействия с контроллером через веб-браузер.
💡 Совет: Используйте узел `http request` для запросов к внешним сервисам и узлы `http in` / `http response` для создания собственного API на контроллере. Всегда обрабатывайте ошибки сети и коды ответа сервера (404, 500 и т.д.).
Другие важные протоколы
| Протокол | Принцип работы | Применение на платформе HI |
| :--- | :--- | :--- |
| DALI | Цифровой протокол управления освещением. Позволяет адресно управлять каждым светильником, диммировать и запрашивать его состояние по двухпроводной шине. | Управление профессиональными системами освещения в офисах, гостиницах. Требует аппаратного шлюза DALI, подключенного к контроллеру (например, по RS-485 или Ethernet). |
| CAN | Надежная шина, используемая в автомобильной промышленности и промышленной автоматизации. Обеспечивает высокую скорость и помехоустойчивость. | Интеграция со специфическим оборудованием (промышленные станки, автомобильные системы, некоторые виды климатической техники). Используется встроенный CAN-порт контроллера. |
| Zigbee | Беспроводной протокол для создания ячеистых сетей (mesh) с низким энергопотреблением. Идеален для беспроводных датчиков и выключателей. | Подключение широкого спектра беспроводных устройств (датчики движения, открытия, кнопки, лампочки). Требует внешнего USB-стика (Zigbee-координатора) и ПО (например, Zigbee2MQTT). |
| Bluetooth LE | Беспроводной протокол для связи на коротких расстояниях с очень низким энергопотреблением. | Подключение носимых устройств, фитнес-трекеров, Bluetooth-меток для определения присутствия. Требует встроенного или внешнего Bluetooth-адаптера. |
Сравнительная таблица ключевых протоколов
| Критерий | MQTT | Modbus (RTU/TCP) | HTTP |
| :--- | :--- | :--- | :--- |
| Модель | Издатель/Подписчик | Ведущий/Ведомый | Клиент/Сервер |
| Транспорт | TCP/IP | RS-485 / TCP/IP | TCP/IP |
| Накладные расходы | Очень низкие | Низкие | Высокие |
| Типовая задача | Телеметрия, команды IoT | Опрос пром. оборудования | Интеграция с веб-сервисами |
| Применение на HI | Основной для логики и облака | Основной для полевого уровня | Для внешних API и дашбордов |
---
Лабораторная работа №1: Публикация данных в MQTT
ID: `COURSE-16-M02-LAB01` Цель: Создать поток Node-RED, который имитирует работу датчика открытия двери и публикует его состояние в MQTT-брокере. Задачи:// Ветка отправки
[Inject: "Open"] ---+
+--> [Function: "Format Door State"] --> [mqtt out: "Door State"]
[Inject: "Close"] --+
// Ветка проверки
[mqtt in: "Door State"] --> [Debug]
Код для узла `Function`:
// msg.payload от узла Inject будет true или false
let state = msg.payload;
msg.payload = {
value: state,
source: "door-sensor-main",
ts: Date.now()
};
msg.topic = "hi/home/main_door/state";
return msg;
Рубрика оценивания (5 баллов):
- (1 балл) Поток создан и содержит все необходимые узлы.
- (1 балл) Узлы `Inject` корректно передают `true` и `false`.
- (1 балл) Узел `Function` правильно формирует `msg.payload` в соответствии с контрактом.
- (1 балл) Сообщения успешно публикуются в указанный MQTT-топик.
- (1 балл) Узел `mqtt in` успешно принимает и отображает сообщения в панели `Debug`.
Лабораторная работа №2: Управление реле по Modbus TCP
ID: `COURSE-16-M02-LAB02` Цель: Создать поток для управления виртуальным реле через Modbus TCP по команде из MQTT. Задачи:// Ветка управления
[mqtt in] --> [Switch: "ON/OFF"] --+-- (ON) --> [Change: set true] --+--> [Modbus-Write]
| |
+-- (OFF)--> [Change: set false]-+
// Ветка имитации устройства (на отдельной вкладке или в стороне)
[Modbus-Server] --> [Debug: "Modbus State"]
Настройки узлов:
- `mqtt in`: Топик `hi/home/living_room/light/set`.
- `Switch`: Проверяет `msg.payload` на строки `"ON"` и `"OFF"`.
- `Change`: Устанавливает `msg.payload` в булево `true` или `false`.
- `Modbus-Write`:
* Address: `0`
* Server: Настроенный Modbus TCP клиент, указывающий на `127.0.0.1` и порт, заданный в `Modbus-Server`.
- `Modbus-Server`: Настройте его на любой свободный порт (например, `5020`) и наблюдайте за его состоянием в `Debug`.
- (1 балл) Поток управления и поток имитации устройства созданы.
- (1 балл) MQTT-команды `"ON"`/`"OFF"` корректно обрабатываются узлом `Switch`.
- (1 балл) Узел `Modbus-Write` правильно сконфигурирован и отправляет команду.
- (1 балл) Узел `Modbus-Server` получает команду и изменяет свое внутреннее состояние (видно в `Debug`).
- (1 балл) Весь сценарий работает end-to-end: отправка MQTT-сообщения приводит к изменению состояния виртуального Modbus-устройства.
---
Тест для самопроверки
ID: `COURSE-16-M02-QUIZ`a) HTTP
b) MQTT
c) Modbus RTU
d) DALI
a) MQTT
b) Modbus RTU
c) Modbus TCP
d) CAN
a) Издатель (Publisher)
b) Подписчик (Subscriber)
c) Брокер (Broker)
d) Клиент (Client)
a) Усилитель сигнала
b) Терминирующий резистор 120 Ом
c) Дополнительный источник питания
d) Фильтр помех
a) Опрос датчика температуры по шине
b) Получение прогноза погоды с внешнего веб-сайта
c) Управление реле в реальном времени
d) Обмен данными между двумя контроллерами в локальной сети
a) Лицензионное соглашение на использование узла
b) Стандартизированный формат JSON-объекта в `msg.payload`
c) Настройки безопасности для MQTT-соединения
d) Физическая схема подключения
a) Неправильный Slave ID
b) Перепутаны провода A и B на шине RS-485
c) Слишком длинный MQTT-топик
d) Несовпадение скорости порта (Baud Rate)
a) `Status`
b) `Debug`
c) `Catch`
d) `Switch`
a) Ничего, поддержка встроенная
b) Специальный DALI-шлюз
c) Внешний USB-координатор (стик)
d) Прямое подключение к Wi-Fi
a) Более надежная передача данных
b) Значительно меньшие накладные расходы и трафик
c) Возможность работать без интернета
d) Более высокая скорость передачи больших файлов
---
Мини-runbook «Если что-то не работает»
📋 Чек-лист быстрой диагностики:
Проблема: Сообщения не доходят до MQTT-брокера* Проверьте полярность: клеммы A -> A, B -> B. Попробуйте поменять их местами.
* Проверьте наличие питания на устройстве.
* Убедитесь, что на концах шины есть терминаторы 120 Ом.
* Проверьте IP-адрес и порт устройства.
* Убедитесь, что контроллер и устройство находятся в одной подсети.
* Выполните `ping