Интерфейсы и протоколы взаимодействия в экосистеме HI
COURSE-16-M03-L01 — Интерфейсы и протоколы взаимодействия в экосистеме HI
Введение
В предыдущих уроках мы рассмотрели базовые компоненты IoT-системы. Этот урок переводит теоретические знания в практическую плоскость, фокусируясь на том, как устройства в экосистеме контроллера HI обмениваются данными между собой и с внешним миром. Понимание интерфейсов и протоколов — это ключевой навык инженера, позволяющий строить надежные и масштабируемые решения, от простого управления освещением до комплексной автоматизации зданий.
Мы разберем четыре уровня взаимодействия, от физического подключения проводов до логики в Node-RED, используя исключительно стек технологий платформы HI.
Уровень 1: Физические интерфейсы контроллера
Физический интерфейс — это точка, где цифровой мир контроллера встречается с реальным оборудованием: датчиками, кнопками, реле и исполнительными механизмами. Ошибки на этом уровне являются причиной до 80% всех проблем на объекте.
Наш контроллер оснащен следующими основными физическими интерфейсами:
- Универсальные входы (UI 1-22): Позволяют подключать широкий спектр устройств:
* Датчики 1-Wire: Цифровые датчики температуры (DS18B20), влажности и др.
* Аналоговые датчики: Датчики с выходом 0-10В или 4-20мА (давление, уровень CO2).
- Релейные выходы (RELAY 1-22): Используются для коммутации нагрузки до 230В/16А. Позволяют управлять освещением, розетками, клапанами отопления, двигателями штор.
- Последовательные шины:
* CAN: Высокоскоростная шина, применяемая в автомобильной и промышленной автоматизации для критически важных коммуникаций.
* DALI: Стандарт для управления профессиональным осветительным оборудованием.
💡 Совет: Всегда используйте стандарт `WIRING-XXX-YYY` для документирования подключений. Это критически важно для последующей диагностики и обслуживания.
Практический пример: Подключение настенного выключателя
Задача: Подключить стандартный кнопочный выключатель для управления светом. Схема подключения: `WIRING-INPUT-001`//========= WIRING-INPUT-001: Wall Switch to Universal Input =========
(SW-01: Wall Switch) [CTRL:HI-Core]
Клемма 1 --------- UI-05 (GND)
Клемма 2 --------- UI-06
- Логика: При нажатии на кнопку контакты замыкаются, и на входе `UI-06` контроллер фиксирует изменение состояния. В Node-RED это событие будет обработано узлом `rpi gpio in`.
Уровень 2: Протоколы канального уровня
После физического подключения необходимо установить "правила общения" по шине данных. Для промышленных и полупромышленных объектов основным протоколом является Modbus RTU.
- Modbus RTU (по шине RS-485): Это протокол типа "Master-Slave" (Ведущий-Ведомый).
* Slave (Ведомый): Оконечные устройства (счетчики, датчики) с уникальными адресами (1-247) на шине. Они только отвечают на запросы Master'а.
⚠️ Предупреждение: Ключ к успешной работе Modbus — точное совпадение настроек порта (скорость, четность, стоп-биты) на контроллере и всех устройствах на шине, а также уникальность адресов.
Практический пример: Чтение данных со счетчика электроэнергии
Задача: Считывать текущее потребление мощности со счетчика с Modbus-адресом `5`. Мощность хранится в Holding Register `40101` (адрес `100`). Логика в Node-RED:[Inject: 15s] -> [Modbus-Getter: Read Power] -> [Function: Validate & Format] -> [Debug]
| (on error)
v
[Catch] -> [Function: Log Error] -> [MySQL: audit_log]
Уровень 3: Протоколы прикладного уровня
Эти протоколы определяют, как данные передаются по сетям TCP/IP и как приложения взаимодействуют друг с другом. Для экосистемы HI ключевыми являются MQTT и HTTP API.
MQTT (Message Queuing Telemetry Transport)
MQTT — это легковесный протокол для IoT, работающий по модели "Издатель-Подписчик" (Publisher-Subscriber) через центральный сервер — брокер.
- Брокер (Broker): Сервер, принимающий и пересылающий сообщения. Может быть запущен как на самом контроллере HI, так и в облаке.
- Издатель (Publisher): Устройство или сценарий, отправляющий данные (сообщение) в определенную тему (topic). Например, датчик температуры публикует значение в тему `hi/office/room101/temperature`.
- Подписчик (Subscriber): Устройство или приложение, которое подписалось на тему и получает все сообщения, отправленные в нее. Например, мобильное приложение, подписанное на `hi/office/room101/temperature`, будет отображать актуальную температуру.
{
"value": 23.5,
"source": "temp-sensor-office-101",
"ts": 1678886400000,
"unit": "°C",
"meta": {
"room": "Office 101",
"floor": 1
}
}
Практический пример: Публикация данных с датчика в MQTT
Задача: Данные с датчика 1-Wire (DS18B20) после чтения необходимо отформатировать и опубликовать в MQTT. ASCII-схема потока: `FLOW-SENS-TEMP-001`[Inject: 30s] -> [1-Wire In] -> [Function: Format to Contract] -> [MQTT Out: telemetry/temp]
// Входящее msg.payload от узла 1-Wire: "24.125" (строка)
let temp = parseFloat(msg.payload);
// 1. Валидация
if (isNaN(temp) || temp < -55 || temp > 125) {
node.status({fill:"red", shape:"dot", text:"Invalid reading"});
node.error("Некорректное значение температуры: " + msg.payload, msg);
return null; // Останавливаем поток
}
// 2. Формирование сообщения по контракту
msg.payload = {
value: temp,
source: "28-01234567abcd", // Уникальный ID датчика 1-Wire
ts: Date.now(),
unit: "°C"
};
// 3. Установка топика для MQTT
msg.topic = "hi/telemetry/office/room101/temperature";
node.status({fill:"green", shape:"dot", text:"OK: " + temp + " °C"});
return msg;
HTTP API (RESTful)
Контроллер HI может предоставлять внешний HTTP API для интеграции со сторонними системами, которые не поддерживают MQTT. Это реализуется с помощью узлов `http in` и `http out` в Node-RED.
Пример: Создать API-endpoint для включения света в кабинете 101.- URL: `http://
:1880/api/light/room101` - Метод: `POST`
- Тело запроса: `{"command": "ON"}`
[HTTP In: POST /api/light/room101] -> [JSON] -> [Switch: msg.payload.command] -> [Function: Set Relay ON] -> [GPIO Out] -> [HTTP Response: 200 OK]
Уровень 4: Пользовательские интерфейсы (UI)
Пользовательский интерфейс — это способ, которым конечный пользователь взаимодействует с системой.
- Физические UI: Кнопки и выключатели, подключенные к входам контроллера. Это самый надежный и привычный способ управления.
- Цифровые UI:
* Веб-интерфейсы: Могут работать как по MQTT (через WebSocket), так и по HTTP API.
* Node-RED Dashboard: Встроенный в Node-RED инструмент для быстрого создания простых панелей управления. Идеально подходит для пусконаладки, тестирования и создания интерфейсов для технического персонала.
Сквозной пример: Сценарий `SCN-LIGHT-023` — Автоматическое управление светом
Объединим все уровни в одном практическом сценарии.
Задача: Свет в коридоре включается по датчику движения. Его также можно включить/выключить принудительно через мобильное приложение. Состояние света всегда отображается в приложении.* Датчик движения (выход "сухой контакт") подключен к `UI-07`.
* Светильник подключен к `RELAY-03`.
* Схема: `WIRING-LIGHT-023`.
* Входы:
* Событие от датчика движения (узел `rpi gpio in`).
* Команда из мобильного приложения (узел `mqtt in` на теме `hi/commands/corridor/light`).
* Логика (Паттерн "Конечный автомат" - FSM):
* Состояние системы (`AUTO`, `MANUAL_ON`, `MANUAL_OFF`) хранится в переменной `flow.context`.
* Если пришло движение и режим `AUTO`, включается свет и запускается таймер на выключение.
* Если пришла команда `ON` из MQTT, система переходит в `MANUAL_ON`, свет включается.
* Состояние реле (`true`/`false`) и режим (`AUTO`/`MANUAL`) публикуются в `mqtt out` в тему `hi/status/corridor/light`.
* Выходы:
* Управление реле `RELAY-03` (узел `rpi gpio out`).
* Отправка статуса в мобильное приложение (узел `mqtt out`).
* Пользователь видит в приложении актуальный статус света и кнопки для ручного управления.
* Система автоматически реагирует на движение.
---
Лабораторные работы
COURSE-16-M03-LAB01: Чтение данных с датчика и публикация в MQTT
- Цель: Научиться считывать данные с физического входа, преобразовывать их в стандартный контракт сообщения и публиковать в MQTT.
- Оборудование: Контроллер HI, датчик температуры DS18B20, подключенный к универсальному входу.
- Задачи:
2. Добавить узел `Function` для валидации данных (температура должна быть в диапазоне от -10 до +40 °C).
3. В том же узле `Function` преобразовать данные в JSON-формат согласно контракту сообщения Академии.
4. Опубликовать полученный JSON в MQTT-топик `hi/lab/ваша_фамилия/temperature`.
5. Использовать узел `Status` для отображения последней успешной температуры или ошибки.
- Критерии оценки:
* Формат сообщения в MQTT точно соответствует контракту.
* Поток корректно обрабатывает невалидные значения (не публикует их, выводит ошибку).
* Узлы имеют осмысленные имена, поток снабжен комментариями.
COURSE-16-M03-LAB02: Создание HTTP API для управления реле
- Цель: Научиться создавать простой RESTful API на контроллере для управления исполнительными устройствами.
- Оборудование: Контроллер HI.
- Задачи:
2. Поток должен принимать JSON-тело вида `{"state": true}` или `{"state": false}`.
3. В зависимости от полученного значения, поток должен управлять реле №5 на контроллере.
4. После выполнения команды поток должен возвращать HTTP-ответ с кодом `200 OK` и телом `{"status": "success", "newState": true/false}`.
5. Добавить обработку некорректных запросов (неверный JSON, отсутствующее поле `state`), возвращая код `400 Bad Request`.
- Критерии оценки:
* Отправка `curl ... '{"state": false}'` выключает реле.
* В обоих случаях возвращается корректный JSON-ответ.
* Отправка некорректного запроса (`'{"command": "ON"}'`) возвращает ошибку 400.
---
Тест для самопроверки (COURSE-16-M03-QUIZ)
* а) Датчик температуры
* б) Счетчик электроэнергии
* в) Контроллер HI
* г) Любое устройство
* а) Физический способ подключения проводов.
* б) Стандартизированный JSON-формат для `msg.payload`.
* в) Договор на техническое обслуживание.
* г) IP-адрес MQTT-брокера.
* а) Хранит исторические данные за год.
* б) Напрямую управляет реле.
* в) Принимает сообщения от издателей и пересылает их подписчикам.
* г) Шифрует трафик на физическом уровне.
* а) Для запуска потока по расписанию.
* б) Для перехвата и обработки ошибок от других узлов (например, сбой связи по Modbus).
* в) Для визуального отображения статуса.
* г) Для отправки HTTP-запросов.
* а) `mqtt in`
* б) `modbus-read`
* в) `rpi gpio in`
* г) `http in`
* а) 40016
* б) 16
* в) 15
* г) 40015
* а) Подключение к интернету.
* б) Питание датчиков.
* в) Объединение промышленных устройств (счетчиков, модулей) по протоколу Modbus RTU.
* г) Управление освещением по протоколу DALI.
* а) Они будут работать по очереди.
* б) Возникнет конфликт адресов, и связь на шине станет нестабильной или невозможной.
* в) Контроллер автоматически назначит им новые адреса.
* г) Ничего, это нормальная ситуация.
* а) База данных MySQL.
* б) Написание собственного веб-сервера на Python.
* в) Палитра Node-RED Dashboard.
* г) Мобильное приложение от стороннего разработчика.
* а) `value`, `unit`, `color`
* б) `value`, `source`, `ts`
* в) `data`, `ip_address`, `port`
* г) `payload`, `topic`, `qos`
---
Мини-runbook «Если что-то не работает»
📋 Симптом: Modbus-устройство не отвечает (ошибки Timeout в Node-RED).
📋 Симптом: Команда по MQTT не доходит до контроллера или статус не обновляется в приложении.
📋 Симптом: Датчик "сухого контакта" (кнопка, геркон) не срабатывает.