Использование ноды Status для мониторинга состояния
Введение в ноду Status: что это и зачем она нужна?
В экосистеме Node-RED, ориентированной на обработку потоков данных, критически важно иметь инструменты не только для выполнения логики, но и для наблюдения за состоянием самой системы. Если нода `Catch`, которую мы изучили ранее, является реактивным инструментом для перехвата уже случившихся ошибок выполнения, то нода `Status` — это проактивный инструмент для мониторинга состояний.
> 📋 Ключевые понятия:
> * Нода Status: Специальная нода в Node-RED, которая не обрабатывает основной поток данных, а генерирует сообщение каждый раз, когда отслеживаемая нода изменяет свой внутренний статус.
> * Состояние ноды: Это не результат ее работы, а ее внутреннее состояние. Например: "подключен к серверу", "ожидание данных", "ошибка аутентификации", "буфер заполнен".
Основное назначение ноды `Status` — предоставить инженеру автоматизации возможность "подслушать" внутреннюю жизнь других нод и отреагировать на изменения их состояния. Это позволяет создавать более надежные и интеллектуальные системы, которые могут самостоятельно диагностировать проблемы.
Ключевое отличие от ноды Catch
Крайне важно понимать фундаментальную разницу между `Status` и `Catch`, так как они решают разные, хотя и связанные, задачи.
| Критерий | Нода `Status` | Нода `Catch` |
| -------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Триггер | Изменение состояния ноды (например, `connected` -> `disconnected`). | Возникновение ошибки выполнения внутри ноды (например, `node.error()` или исключение JavaScript). |
| Пример сценария | Нода `mqtt in` теряет связь с MQTT-брокером из-за сбоя сети. Статус меняется на "disconnected". | Нода `modbus-read` отправляет запрос, но устройство возвращает код ошибки Modbus (Exception). |
| Тип информации | Предоставляет информацию о текущем состоянии, часто с визуальными атрибутами (цвет, форма иконки). | Предоставляет детальную информацию об ошибке: текст ошибки, стек вызовов и оригинальное сообщение. |
| Основная цель | Проактивный мониторинг работоспособности компонентов и соединений. | Реактивная обработка сбоев в логике и взаимодействии для предотвращения остановки потока. |
Типы отслеживаемых состояний
Нода `Status` универсальна, но наиболее эффективна при мониторинге нод, взаимодействующих с внешним миром. Именно эти ноды имеют наиболее выраженные и важные состояния:
- Статус подключения: Ноды `mqtt in/out`, `modbus-client`, `knx-in/out`, `tcp in/out`. Их статусы могут быть "connecting...", "connected", "disconnected", "error". Это самая частая точка применения.
- Статус исполнительных механизмов: Некоторые ноды управления, например, для шаговых двигателей, могут сообщать о своем состоянии: "running", "stopped", "stalled".
- Заполнение буфера: Ноды, работающие с потоками данных (например, `file in`), могут сообщать о процессе чтения или заполнении внутреннего буфера.
- Специфичные статусы: Разработчики сторонних нод могут определять любые кастомные статусы. Например, нода для работы с Zigbee-шлюзом может иметь статусы "pairing mode on" или "network scan active".
Структура объекта `msg.status`
Когда отслеживаемая нода меняет свое состояние, нода `Status` генерирует новое сообщение. Вся информация о событии помещается в объект `msg.status`. Полная структура `msg` может варьироваться, но `msg.status` является ключевым.
{
"status": {
"fill": "red",
"shape": "ring",
"text": "disconnected",
"source": {
"id": "c7a8b6f2.123456",
"type": "mqtt-broker",
"name": "HI Main Broker"
}
},
"_msgid": "d8b9c7a6.654321"
}
Ключевые поля в `msg.status`:
- `text`: Самое важное поле. Содержит текстовое описание статуса, которое и используется для построения логики. Например: `"connected"`, `"timeout"`, `"CRC error"`.
- `fill`: Цвет иконки статуса (`"green"`, `"yellow"`, `"red"`, `"blue"`).
- `shape`: Форма иконки (`"dot"` или `"ring"`).
- `source`: Объект, содержащий информацию о ноде-источнике события:
* `type`: Тип ноды (например, `"mqtt in"`, `"modbus-client"`).
* `name`: Имя, которое вы задали ноде в редакторе.
Понимание этой структуры — ключ к эффективному использованию ноды `Status` в ваших проектах автоматизации.
---
Конфигурация ноды Status: таргетинг и анализ сообщения
Правильная настройка ноды `Status` позволяет сфокусировать мониторинг на критически важных частях системы, избегая информационного шума от второстепенных компонентов. Процесс конфигурации состоит из двух шагов: размещение и настройка области действия, а затем анализ выходного сообщения для построения логики.
Размещение и базовая настройка
Ноду `Status` можно найти в палитре "common". Перетащите ее на рабочую область. В отличие от большинства нод, у нее нет входа, только один выход. Это подчеркивает ее роль наблюдателя, а не участника основного потока.
Двойной клик по ноде открывает окно ее настроек.
Ключевой параметр здесь — "Scope" (Область действия). Он определяет, за какими именно нодами будет следить данный экземпляр ноды `Status`.
Концепция 'Scope': таргетинг нод
Параметр "Scope" имеет три варианта:
> 💡 Подсказка: Для отладки всегда подключайте ноду `Debug` к выходу ноды `Status` и настраивайте её на вывод всего объекта `msg`. Это самый быстрый способ увидеть, какую именно информацию о состоянии отправляет целевая нода.
Детальный разбор выходного сообщения
Рассмотрим практический пример. У нас есть нода `mqtt in`, подписанная на топик. Мы хотим отслеживать состояние ее подключения к MQTT-брокеру.
Когда Node-RED развертывается, нода `mqtt in` пытается подключиться к брокеру. Если подключение успешно, `Status` немедленно генерирует сообщение.
{
"status": {
"fill": "green",
"shape": "dot",
"text": "connected",
"source": {
"id": "e3f4a5b6.123abc",
"type": "mqtt in",
"name": "Датчик протечки"
}
},
"payload": "",
"topic": "",
"_msgid": "f1e2d3c4.987xyz"
}
Теперь, если мы физически остановим MQTT-брокер или оборвем сетевое соединение, нода `mqtt in` перейдет в состояние переподключения, а затем в "disconnected". Нода `Status` зафиксирует эти изменения и сгенерирует соответствующие сообщения:
Сообщение при потере связи:// msg.status.text будет "connecting" или "disconnected"
// msg.status.fill будет "yellow" или "red"
{
"status": {
"fill": "red",
"shape": "ring",
"text": "disconnected",
"source": {
"id": "e3f4a5b6.123abc",
"type": "mqtt in",
"name": "Датчик протечки"
}
},
// ...
}
Обратите внимание на объект `msg.status.source`. Он позволяет точно идентифицировать, какая именно нода сменила статус. Это критически важно, если одна нода `Status` отслеживает несколько источников. Поле `source.name` (`"Датчик протечки"`) делает логгирование и отладку гораздо более наглядными.
Таким образом, анализируя поле `msg.status.text`, мы можем построить любую логику: отправить уведомление администратору, записать событие в базу данных MySQL или, что самое важное для нашего курса, запустить сценарий перевода системы в безопасное состояние (Safe-State).
---
Пример: Мониторинг Modbus-устройств и переход в Safe-State
Рассмотрим реалистичный сценарий для промышленного объекта или умного дома: управление климатической установкой (фанкойлом) через Modbus RTU. Потеря связи с Modbus-шлюзом означает, что контроллер больше не может управлять фанкойлом, что может привести к перегреву, переохлаждению или работе впустую. Наша задача — отследить потерю связи и перевести систему в безопасное состояние (например, выключить фанкойл).
Компоненты потока:- `modbus-client` (нода конфигурации): Настраивает параметры подключения к COM-порту (RS-485) контроллера.
- `modbus-read` / `modbus-getter`: Узлы, которые используют `modbus-client` для выполнения опроса устройств.
- `Status`: Отслеживает состояние именно ноды конфигурации `modbus-client`.
- `Switch`: Анализирует текстовое описание статуса.
- `Subflow: Safe-State`: Переиспользуемый субпоток, реализующий логику безопасного состояния (как было рассмотрено в уроке `COURSE-05-M05-L03`).
> ⚠️ Внимание: Не все сторонние (community) ноды корректно и своевременно обновляют свой статус. Перед внедрением в продакшн всегда тестируйте поведение ноды, имитируя сбои: отключайте кабель RS-485, перезагружайте сетевое оборудование, останавливайте MQTT-брокер.
Построение потока
* Добавьте ноду `Status`.
* В настройках "Scope" выберите "Selected Nodes".
* Нажмите "Pick target nodes" и выберите вашу ноду конфигурации "Шина RS485-1 (Климат)".
* Подключите выход `Status` ко входу `Switch`.
* В настройках `Switch` в поле "Property" укажите `msg.status.text`.
* Добавьте правила для анализа текста статуса. Нода `node-red-contrib-modbus` использует следующие статусы:
* `connected`
* `connecting`
* `disconnected`
* `error`
* `timeout`
* Создайте правило: `contains` `"disconnected"` -> выход 1.
* Добавьте правило: `contains` `"error"` -> выход 1 (объединяем с первым).
* Добавьте правило: `contains` `"timeout"` -> выход 1.
* Добавьте правило: `==` `"connected"` -> выход 2.
* Остальные статусы (например, "connecting") можно проигнорировать, направив их на последний выход "otherwise".
* Подключите первый выход `Switch` (ошибки связи) к вашему субпотоку "Safe-State: Climate". Этот субпоток должен, например, отправить команду на выключение всех реле, управляющих фанкойлом.
* Подключите второй выход `Switch` (успешное подключение) к ноде, которая может записать в лог, что связь восстановлена, или отправить уведомление.
Пример JSON-конфигурации потока:Вы можете импортировать этот JSON-код в Node-RED (`Import -> Clipboard`), чтобы увидеть готовую структуру потока.
[
{
"id": "a1b2c3d4.123456",
"type": "tab",
"label": "Modbus Monitoring",
"disabled": false,
"info": ""
},
{
"id": "b2c3d4e5.234567",
"type": "status",
"z": "a1b2c3d4.123456",
"name": "Monitor Modbus Client",
"scope": [
"c3d4e5f6.345678"
],
"x": 230,
"y": 140,
"wires": [
[
"d4e5f6a1.456789"
]
]
},
{
"id": "d4e5f6a1.456789",
"type": "switch",
"z": "a1b2c3d4.123456",
"name": "Check Connection Status",
"property": "status.text",
"propertyType": "msg",
"rules": [
{
"t": "stric",
"v": "disconnected,error,timeout",
"vt": "str"
},
{
"t": "eq",
"v": "connected",
"vt": "str"
}
],
"checkall": "true",
"repair": false,
"outputs": 2,
"x": 480,
"y": 140,
"wires": [
[
"e5f6a1b2.56789a"
],
[
"f6a1b2c3.6789a1"
]
]
},
{
"id": "e5f6a1b2.56789a",
"type": "debug",
"z": "a1b2c3d4.123456",
"name": "Trigger Safe-State!",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "{ \"action\": \"SAFE_STATE\", \"reason\": msg.status.text, \"source\": msg.status.source.name }",
"targetType": "jsonata",
"x": 750,
"y": 100,
"wires": []
},
{
"id": "f6a1b2c3.6789a1",
"type": "debug",
"z": "a1b2c3d4.123456",
"name": "Connection OK",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "{ \"status\": \"OK\", \"source\": msg.status.source.name }",
"targetType": "jsonata",
"x": 730,
"y": 180,
"wires": []
},
{
"id": "c3d4e5f6.345678",
"type": "modbus-client",
"name": "Шина RS485-1 (Климат)",
"clienttype": "serial",
"bufferCommands": true,
"stateLogEnabled": true,
"queueLogEnabled": false,
"tcpHost": "127.0.0.1",
"tcpPort": "502",
"tcpType": "DEFAULT",
"serialPort": "/dev/ttyUSB0",
"serialType": "RTU-BUFFERD",
"serialBaudrate": "9600",
"serialDatabits": "8",
"serialStopbits": "1",
"serialParity": "none",
"serialConnectionDelay": "100",
"unit_id": "1",
"commandDelay": "1",
"clientTimeout": "1000",
"reconnectOnTimeout": true,
"reconnectTimeout": "2000"
}
]
Этот практический пример демонстрирует, как `Status` становится ключевым элементом в создании самодиагностирующейся и отказоустойчивой системы автоматизации.
---
Синергия: Комбинация Status и Catch для максимальной отказоустойчивости
Использование только ноды `Status` или только ноды `Catch` по отдельности создает пробелы в системе безопасности. `Status` может не заметить ошибку исполнения, а `Catch` не узнает об обрыве связи, если не было попытки отправки данных. Истинная отказоустойчивость достигается только при их синергетическом, совместном использовании.
Разграничение зон ответственности
Представим систему как многоуровневую структуру. `Status` и `Catch` работают на разных уровнях:
- `Status` (Уровень соединения): Отвечает за физический или транспортный уровень. Есть ли сетевое соединение с MQTT-брокером? Открыт ли COM-порт для Modbus? Есть ли связь с KNX-шлюзом? Это "нижний" уровень мониторинга.
- `Catch` (Уровень приложения): Отвечает за логический или прикладной уровень. Корректен ли формат отправленных данных? Не вернуло ли устройство ошибку в ответ на валидный запрос? Не превышен ли таймаут ожидания ответа на конкретную команду? Это "верхний" уровень.
🔗 Связанный материал: Для углубленного понимания работы `Catch`, обратитесь к уроку `COURSE-05-M05-L02`, где мы подробно разбирали механику перехвата ошибок.
Сценарий, требующий обе ноды
Рассмотрим наш пример с Modbus-устройством.
Только благодаря `Catch` мы узнаем о проблеме на прикладном уровне, даже когда на уровне соединения все выглядит хорошо.
Архитектурный паттерн: Центральный обработчик ошибок
Для сложных проектов лучшей практикой является создание выделенного потока (отдельной вкладки в Node-RED), который можно назвать "Monitoring & Safety".
Структура этого потока:* Нормализация: Приводит сообщения от `Catch` и `Status` к единому формату.
* Логирование: Записывает стандартизированное сообщение об ошибке в базу данных MySQL на контроллере или в системный лог.
* Принятие решений: На основе тяжести и источника ошибки, запускает соответствующие сценарии:
* Отправка уведомления администратору.
* Попытка автоматического восстановления (например, перезапуск соединения).
* Активация сценария Safe-State для затронутой подсистемы.
Такая архитектура делает систему прозрачной, легко отлаживаемой и предсказуемо реагирующей на любые сбои.
---
Итоги и лучшие практики
Нода `Status` — это не просто еще один инструмент в палитре Node-RED, а фундаментальный компонент для построения профессиональных, отказоустойчивых систем автоматизации на контроллерах HI. Она смещает парадигму инженера от "реагирования на пожар" (когда что-то уже сломалось и было поймано `Catch`) к "установке дымовых датчиков" — проактивному мониторингу здоровья системы.
Изучив ее функционал, можно сформулировать несколько ключевых правил, которые должны стать стандартом для любого инсталлятора, работающего с платформой HI.
Лучшая практика №1: Всегда отслеживайте внешние интерфейсы
Точки интеграции с внешним миром — самые хрупкие и непредсказуемые части любой системы. Сетевые кабели могут быть повреждены, Wi-Fi сигнал может пропасть, стороннее оборудование может "зависнуть".
- Обязательно устанавливайте ноды `Status` для мониторинга каждой ноды конфигурации, отвечающей за внешние коммуникации:
* `modbus-client` (как для RTU, так и для TCP)
* `knx-gateway`
* `tcp request` (если используется для API-интеграций)
* Специфичные ноды для Zigbee, Z-Wave, LoRaWAN и других беспроводных протоколов.
Это ваш первый и самый важный рубеж обороны. Потеря связи с любым из этих компонентов должна немедленно вызывать тревогу.
Лучшая практика №2: Используйте узкий таргетинг
Соблазн использовать одну глобальную ноду `Status` (`Scope: All Nodes`) велик, но это плохая практика для производственных систем. Глобальный мониторинг генерирует огромное количество "белого шума" от нод, чьи статусы некритичны (например, нода `Inject` меняет статус при срабатывании).
- Предпочитайте режим `Scope: Selected Nodes`. Создавайте отдельные, четко названные ноды `Status` для каждой важной точки мониторинга (`Status: MQTT`, `Status: Modbus Climate`).
- Такой подход позволяет создавать более чистую, читаемую и точную логику реагирования. Вы точно знаете, какая именно подсистема вышла из строя, и можете запустить соответствующий сценарий Safe-State, не затрагивая исправные части системы.
Лучшая практика №3: Полноценный Safe-State — это триада
Для создания действительно надежного механизма Safe-State недостаточно только `Status` и `Catch`. Необходимо добавить третий компонент для обработки "зависших" состояний, когда ошибки нет, но и данные не поступают.
> ℹ️ Информация: Полноценный механизм отказоустойчивости на контроллерах HI строится на связке трех нод:
> 1. `Status`: Отслеживает состояние подключения.
> 2. `Catch`: Перехватывает ошибки исполнения команд.
> 3. `Trigger` / `Watchdog`: Контролирует таймауты поступления данных. Если от датчика не было данных в течение N минут, `Trigger` отправляет сигнал тревоги, даже если `Status` показывает "connected" и `Catch` молчит.
Комбинируя эти три инструмента, вы можете покрыть практически все возможные сценарии сбоев, от обрыва кабеля до программного "зависания" конечного устройства, и гарантировать, что ваша система автоматизации всегда останется предсказуемой и безопасной.
Что дальше?
В следующем уроке мы объединим все полученные знания и на практике создадим комплексный сценарий управления приводом с интерлоками, таймаутами и полным циклом обработки ошибок с использованием связки `Status`, `Catch` и `Trigger` для реализации финального, наиболее надежного варианта Safe-State.