Node-RED + RealIoT

Node-RED не опрашивает устройства сам по себе. Источник правды — иконки и виджеты, которые вы установили на рабочее поле.

• Реальные датчики и исполнительные устройства — WiFi, Zigbee, Matter, LoRaWAN, Modbus. Их телеметрия приходит по MQTT, отображается на рабочем поле и доступна алгоритмам Node-RED.
• Виртуальные датчики и виджеты — VirtualNumber, VirtualToggle, VirtualSelect, Virtual Schedule, Virtual Formula, Virtual Integrator, VirtualThermostat и другие. Пользователь меняет значение на поле, а Node-RED читает его как обычный параметр устройства.

Простые правила удобнее делать в сценариях If-Else. Когда нужна сложная логика, расчёт, история или интеграция, алгоритм собирают в Node-RED. Обмен с рабочим полем идёт двумя независимыми путями. Смешивать их «на всякий случай» нельзя: каждый узел использует один конкретный канал.

Локальный брокер Mosquitto принимает телеметрию устройств и команды. Сервер RealIoT подписан на топики, обновляет рабочее поле и пишет историю. Узлы Node-RED из палитры realiot используют тот же брокер.

• В Node-RED. Узлы mqtt input и state trigger подписаны на топик realiot/data/json. Сообщение приходит сразу, как только изменилось состояние устройства.
• Из Node-RED на устройство. Узлы actuator и multi actuator публикуют команду в топик протокола устройства: WiFi realiot/command/<deviceSN>, Zigbee zigbee2mqtt/<friendlyName>/set, Matter matter/<deviceId>/set и другие.
• Виртуальные значения обратно на поле. Узлы virtual sensor, virtual switch, virtual number, thermostat и db-writer публикуют телеметрию в realiot/data/json с топиком устройства realiot/virtual/<deviceSN>. Рабочее поле получает обновление сразу.

Рабочее поле хранится в MongoDB: состав иконок, Device SN, текущие payloadData. История параметров пишется в отдельную коллекцию телеметрии. Узлы Node-RED читают и пишут эти документы напрямую.

• Текущее состояние. device state и get multi загружают устройство из рабочего поля и отдают актуальные значения параметров. Так можно стартовать поток по таймеру и узнать, что сейчас на поле, даже если MQTT-события давно не было.
• Расписание с поля. schedule link читает виджет Virtual Schedule из документа рабочего поля.
• История. get history и history stats запрашивают архив параметра из коллекции телеметрии. История должна быть включена в свойствах устройства.
• Запись на поле. db-writer записывает вычисленные поля в документ виртуального устройства в MongoDB и затем публикует MQTT, чтобы интерфейс обновился сразу.

Практические потоки и список узлов — на странице Node-RED.

В Node-RED все сообщения между узлами имеют стандартную структуру объекта msg. Это соглашение документации Node-RED, а не особенность RealIoT.

msg = {
  payload: <любые данные>,  // основные данные сообщения
  _msgid: "уникальный-ID"    // идентификатор, Node-RED ставит сам
}

msg = {
  payload: ...,
  topic: "тема/маршрут",      // MQTT, switch и другие узлы
  req: {...},                 // HTTP request
  res: {...},                 // HTTP response
  error: {...},               // информация об ошибке
  statusCode: 200,            // HTTP-статус
  headers: {...},             // HTTP-заголовки
  cookies: {...},             // HTTP cookies
  filename: "file.txt",       // имя файла для file node
  parts: {...}                // split / join
}

Возвращаемый объект не обязан быть тем же самым, что пришёл на вход. Function-узел может собрать новый объект и вернуть его:

const newMsg = { payload: msg.payload.length };
return newMsg;

Подробнее о function-узле: Writing Functions. Документация Node-RED: nodered.org/docs.

Каждый узел документирует свой формат входа и выхода. Жёсткого стандарта для содержимого payload нет: его задаёт узел-источник.

1. Выделите узел на холсте.
2. В правой панели нажмите значок книги — откроется описание узла.
3. Читайте разделы Inputs и Outputs.

Тот же текст доступен из окна настройки: дважды кликните узел и откройте вкладку Info.

1. Подключите debug к выходу интересующего узла.
2. Нажмите Deploy и отправьте тестовое сообщение.
3. В правой панели смотрите фактическую структуру msg.

В редакторе есть стандартные узлы Node-RED: inject, switch, change, function, delay, debug и другие.

Узлы, написанные специально для RealIoT, находятся в разделе realiot в левой палитре. Они знают рабочие поля, Device SN, MQTT-топики устройств и документы MongoDB. Полный список и типовые потоки — на странице Node-RED.

Для отладки потока используйте узлы debug. Они выводят значения в правую панель, которая открывается кликом по значку жучка.

• По умолчанию debug показывает msg.payload.
• В настройках узла можно выбрать complete message object — тогда видна вся структура msg.
• После изменения потока нажимайте Deploy, иначе debug покажет старое поведение.

1. Подключите debug к выходу узла.
2. Отправьте тестовое сообщение через inject.
3. Изучите структуру в правой панели (значок жучка).
4. Прочитайте документацию узла (значок книги / вкладка Info).
5. Проверьте тип payload: string, object, array?
6. Добавьте проверки в function-узлах, если тип или поля могут отличаться.

JSONata — язык запросов к JSON. В Node-RED он доступен в узлах change и switch, когда выражение задано как JSONata.

• msg — всегда объект. msg.payload — основное поле с данными.
• Структура payload зависит от узла-источника. Жёсткого стандарта, что должно быть внутри, нет.
• Есть соглашения: HTTP-узлы кладут объект с body и headers; MQTT даёт payload и topic; файловые узлы — содержимое или путь; узлы базы данных — результат запроса.
• Узлы RealIoT в палитре realiot общаются с рабочим полем через MQTT (события и команды) и через MongoDB (состояние, история, запись результата).
• Реальную структуру всегда проверяйте узлом debug.