Нода `Status`: мониторинг состояния других нод

Введение в ноду Status: мониторинг состояния вместо данных

> 💡 Подсказка: Нода Status — это ваш "пульсометр" для потока. Если `Debug` и `Catch` — это стетоскоп для прослушивания сообщений и ошибок, то `Status` следит за жизненными показателями самих исполнителей — нод.

В предыдущих уроках мы рассмотрели два ключевых инструмента отладки: ноду `Debug` для инспекции содержимого сообщений (`msg`) и ноду `Catch`, которая централизованно перехватывает ошибки, возникающие в потоке. Однако, в реальных системах автоматизации нас интересует не только поток данных, но и состояние самих компонентов системы. Подключен ли контроллер к MQTT-брокеру? Отвечает ли Modbus-устройство на шине RS-485? Завершился ли длительный процесс вычисления?

Именно для ответа на эти вопросы предназначена нода `Status`. Ее принципиальное отличие от `Debug` и `Catch` заключается в том, что она отслеживает не объект `msg`, проходящий через ноду, а мета-состояние самой ноды. Каждая нода в Node-RED может сообщать о своем текущем состоянии, и нода `Status` позволяет нам перехватить это сообщение о состоянии и превратить его в обычное `msg`, которое можно дальше обрабатывать в потоке.

Визуальные индикаторы состояния

Прежде чем использовать ноду `Status`, важно научиться читать визуальные подсказки, которые Node-RED предоставляет прямо под нодами в редакторе. Эти индикаторы состоят из формы и цвета.

| Элемент | Значение |

| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |

| Форма: Точка | Указывает на конечное, установившееся состояние. Например, "подключено", "ошибка", "успешно отправлено". |

| Форма: Кольцо| Указывает на промежуточный, временный процесс. Например, "подключение...", "отправка...", "ожидание ответа...". |

| Цвет: Зеленый| Успешное состояние. Нода работает в штатном режиме (например, `mqtt out` подключена к брокеру). |

| Цвет: Желтый | Предупреждение или промежуточное состояние. Нода находится в процессе выполнения задачи (например, `delay` в режиме ожидания). |

| Цвет: Красный| Ошибка. Произошел сбой, требующий внимания (например, `modbus-read` не смог подключиться к устройству). |

| Цвет: Синий | Информационное сообщение. Используется для индикации штатных, но не критичных событий (например, нода `inject` только что сработала). |

| Цвет: Серый | Неактивное или неопределенное состояние. Часто используется для обозначения отключенного состояния. |

Типичные сценарии использования

Нода `Status` незаменима в следующих ситуациях:

• Мониторинг подключений: Проверка статуса соединения с внешними системами и шинами. Это основной сценарий для создания отказоустойчивых систем. Примеры:

- Статус ноды `mqtt in/out` (подключено/отключено к брокеру).

- Статус ноды `modbus-getter` (связь с устройством установлена/ошибка/таймаут).

- Статус ноды `knx-out` (подключение к KNX IP-шлюзу).

• Отслеживание состояний устройств: Некоторые ноды могут отображать в своем статусе текущее состояние управляемого устройства (например, "включено", "выключено", "яркость 50%").
• Индикация длительных операций: Если у вас есть сложная `Function`, которая выполняет длительные вычисления, вы можете заставить ее менять свой статус ("обработка...", "завершено"), и нода `Status` позволит на это среагировать.

Пассивный мониторинг и активная установка статуса

Важно различать два подхода к работе со статусами:

Пассивный мониторинг: Мы используем ноду `Status` для "подслушивания" изменений состояния другой ноды. Мы не влияем на это состояние, а только реагируем на него.

Активная установка: Мы используем специальный код `node.status()` внутри ноды `Function` для того, чтобы самим задать ее визуальный статус. Это позволяет создавать кастомную, информативную индикацию работы нашей логики.

В этом уроке мы подробно разберем оба этих подхода.

---

Конфигурация ноды Status и структура выходного сообщения

Нода `Status` находится в палитре в категории "input" (ввод). Давайте добавим ее на холст и рассмотрим настройки и выходные данные.

Настройка ноды

Окно настроек ноды `Status` предельно простое. Оно содержит всего одну опцию:

• Target Nodes (Отслеживаемые ноды): Здесь вы определяете, за какими нодами будет следить данный экземпляр ноды `Status`.

- All Nodes (Все ноды): Режим по умолчанию. Нода будет генерировать `msg` при любом изменении статуса любой ноды на всех вкладках вашего проекта. Это полезно для глобального логирования, но может создавать очень большой поток сообщений.

- Selected Nodes (Выбранные ноды): Наиболее частый и полезный режим. Он позволяет указать одну или несколько конкретных нод для мониторинга.

Чтобы выбрать ноду для отслеживания:

Переключитесь в режим "Selected Nodes".

Нажмите на кнопку с иконкой карандаша. Курсор примет вид прицела.

Кликните на интересующую вас ноду в рабочей области. Она подсветится оранжевой рамкой, а ее ID и имя появятся в списке отслеживаемых.

Вы можете добавить несколько нод, повторяя шаг 3.

> 📋 Ключевые понятия: Каждая нода в проекте имеет уникальный ID. Именно по этому ID нода `Status` и находит свою "цель". Выбор ноды кликом – это просто удобный способ подставить этот ID в поле настроек.

Структура выходного сообщения

Когда отслеживаемая нода меняет свое состояние, нода `Status` генерирует на своем выходе объект `msg`. В отличие от большинства других нод, полезная информация здесь содержится не в `msg.payload`, а в свойстве `msg.status`.

Предположим, мы отслеживаем ноду `mqtt out`, и она теряет связь с брокером. Нода `Status` сгенерирует примерно следующее сообщение:

{
    "_msgid": "a1b2c3d4.5e4f32",
    "topic": "",
    "payload": "",
    "status": {
        "text": "disconnected",
        "fill": "red",
        "shape": "ring",
        "source": {
            "id": "f8e7d6c5.b4a321",
            "type": "mqtt out",
            "name": "Отправка телеметрии"
        }
    }
}

Разберем объект `msg.status` подробно:

| Поле | Тип | Описание | Пример значения |

| --------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |

| `text` | `string` | Текстовое описание статуса. Это основная информация, которую мы будем анализировать в дальнейшем. | `"connecting"`, `"active"`, `"Error: timeout"` |

| `fill` | `string` | Цвет индикатора. Может быть `"red"`, `"green"`, `"yellow"`, `"blue"`, `"grey"`. | `"red"` |

| `shape` | `string` | Форма индикатора. Может быть `"ring"` (кольцо) или `"dot"` (точка). | `"ring"` |

| `source` | `object` | Объект, содержащий информацию о ноде-источнике события. Позволяет понять, какая именно нода сменила статус. | (см. ниже) |

Объект `msg.status.source` содержит три ключевых поля:

• `id`: Уникальный идентификатор ноды-источника.
• `type`: Тип ноды (например, `mqtt out`, `modbus-read`).
• `name`: Имя, которое вы задали ноде в редакторе (например, "Опрос счетчика").

Именно эта структура позволяет нам строить гибкую логику. Мы можем реагировать на изменения от конкретной ноды (проверяя `msg.status.source.id`), на тип проблемы (проверяя `msg.status.fill == "red"`) или на конкретный текст ошибки (проверяя `msg.status.text`).

---

Пример: создание системы оповещения о потере связи с Modbus/RS-485

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

> ℹ️ Информация: Этот же паттерн применим для любых протоколов, работающих через физические или сетевые подключения: KNX (мониторинг шлюза), MQTT (статус брокера), DALI (состояние шины). Логика остается той же, меняется только отслеживаемая нода.

Постановка задачи: В системе автоматизации офиса используется счетчик электроэнергии с интерфейсом Modbus RTU, подключенный к контроллеру HI по шине RS-485. Необходимо реализовать поток, который будет немедленно отправлять сообщение в Telegram администратору, если контроллер потеряет связь со счетчиком (например, из-за обрыва кабеля, сбоя питания счетчика или электромагнитных помех). Сборка потока:

Нам понадобятся следующие ноды:

`Inject`: для запуска периодического опроса.

`Modbus-Getter`: для чтения данных со счетчика. Это наша "целевая" нода.

`Status`: для мониторинга состояния ноды `Modbus-Getter`.

`Switch`: для анализа статуса и принятия решения.

`Template`: для формирования текста тревожного сообщения.

`telegram sender` (из палитры `node-red-contrib-telegrambot`): для отправки уведомления.

`Debug`: для отладки.

ASCII-схема потока:

// Поток опроса устройства
[Inject: 10s] --> [Modbus-Getter: Read Energy]

// Поток мониторинга и оповещения
                          +-- (contains "active") ---> [Debug: "Связь ОК"]
                          |
[Status] --> [Switch] ---+-- (contains "error" или "timeout" или "disconnected") --> [Template: Alarm Msg] --> [Telegram Sender]
     ^             |
     |             +-- (otherwise) ---> [Debug: "Промежуточный статус"]
     |
     +----( отслеживает ноду "Modbus-Getter: Read Energy" )

Пошаговая настройка:

Настройте `Modbus-Getter`: Укажите в нем параметры вашего Modbus-клиента (COM-порт, скорость), Slave ID счетчика и адрес регистра, который вы хотите читать. Назовите ноду "Опрос счетчика ЭЭ".

Настройте ноду `Status`:

- Перетащите ее на холст.

- Откройте настройки, выберите режим "Selected Nodes".

- Нажмите кнопку с карандашом и кликните на вашу ноду "Опрос счетчика ЭЭ".

- Нажмите "Done". Теперь нода `Status` следит только за состоянием Modbus-ноды.

Настройте ноду `Switch`:

- Подключите выход ноды `Status` к входу ноды `Switch`.

- В поле "Property" укажите `msg.status.text`. Это свойство мы будем проверять.

- Добавьте два правила:

1. Правило 1 (Тревога): `contains` `error`. Добавьте еще по одному условию через `or` для `contains` `timeout` и `contains` `disconnected`. Сообщения об ошибках от `node-red-contrib-modbus` могут быть разными, поэтому лучше предусмотреть несколько вариантов. Этот выход будет первым.

2. Правило 2 (Штатная работа): `contains` `active`. Это означает, что опрос прошел успешно. Этот выход будет вторым.

- Остальные состояния (например, "connecting") будут проигнорированы или могут быть направлены на третий, "otherwise" выход для отладки.

Настройте ноду `Template`:

- Подключите первый (тревожный) выход `Switch` к входу `Template`.

- Задайте шаблон текста. Мы можем использовать информацию из объекта `msg.status` для создания подробного отчета.

- Синтаксис шаблона:

        ⚠️ТРЕВОГА! Потеря связи с устройством!


        Имя ноды: {{status.source.name}}
        Тип ноды: {{status.source.type}}
        ID ноды: {{status.source.id}}
        Текст ошибки: {{status.text}}

        Время: {{time}}
        

Настройте `telegram sender`: Подключите выход `Template` к входу ноды отправки в Telegram и настройте вашего бота и ID чата для получения уведомлений.

Теперь, если `Modbus-Getter` не сможет достучаться до счетчика, он установит себе статус "Error: Response timeout" (или похожий). Нода `Status` немедленно это перехватит, создаст `msg`, который нода `Switch` отправит по первому выходу, и администратор получит информативное сообщение в Telegram. Система стала отказоустойчивой.

---

Активное управление статусом из ноды Function

Мы научились "слушать" статусы других нод. Теперь научимся "говорить" — устанавливать собственный статус из ноды `Function`. Это мощный инструмент для визуализации работы вашей собственной логики.

> ⚠️ Внимание: Избегайте вызова `node.status()` в циклах или на каждое приходящее сообщение в высокочастотных потоках. Частые обновления статуса создают нагрузку на веб-интерфейс Node-RED и могут замедлить работу браузера, который пытается их отрисовать в реальном времени. Обновляйте статус только при значительном изменении состояния.

Внутри кода ноды `Function` доступен специальный метод `node.status()`. Он принимает на вход объект, описывающий желаемый статус.

Синтаксис и параметры

Синтаксис вызова выглядит так:

`node.status({fill:"цвет", shape:"фигура", text:"текст"});`

• `fill`: `"green"`, `"red"`, `"yellow"`, `"blue"`, `"grey"`.
• `shape`: `"dot"`, `"ring"`.
• `text`: Строка с текстом статуса (до 25-30 символов для корректного отображения).

Примеры:

// Установка статуса "OK"
node.status({fill:"green", shape:"dot", text:"OK: " + new Date().toLocaleTimeString()});

// Установка статуса "В процессе"
node.status({fill:"yellow", shape:"ring", text:"Processing data..."});

// Установка статуса "Ошибка"
node.status({fill:"red", shape:"dot", text:"Error: Invalid payload"});

Чтобы сбросить статус и вернуть ноде ее стандартный вид (просто синий квадратик), вызовите метод с пустым объектом:

// Сброс статуса
node.status({});

Практический кейс: счетчик событий

Представим задачу: нам нужно посчитать, сколько раз за день открывалась входная дверь. Сигнал с геркона приходит на универсальный вход контроллера и попадает в наш поток. Мы хотим видеть текущее значение счетчика прямо на ноде, не заглядывая в `Debug` или Dashboard.

Создайте ноду `Function` с именем "Счетчик открытий двери".

Подключите к ней источник событий (например, ноду, читающую дискретный вход `UI-01` или `mqtt in` с топиком `hi/main_door/contact/state`).

Вставьте в `Function` следующий код:

// Инициализируем счетчик при первом запуске потока
// Мы используем flow-контекст, чтобы значение сохранялось для всей вкладки.
// Для персистентности между перезагрузками используйте файловый контекст.
let count = flow.get("doorOpenCounter") || 0;

// Увеличиваем счетчик на 1 при каждом входящем сообщении
count++;

// Сохраняем новое значение в контекст
flow.set("doorOpenCounter", count);

// Обновляем статус ноды, чтобы показать текущее значение
node.status({
    fill: "green",
    shape: "dot",
    text: "Открытий сегодня: " + count
});

// Пропускаем сообщение дальше, если это необходимо
return msg;

Теперь при каждом срабатывании геркона число в статусе ноды "Счетчик открытий двери" будет увеличиваться. Это наглядно, удобно и не засоряет панель отладки. Для сброса счетчика можно создать отдельную ноду `Inject`, которая будет отправлять специальное сообщение, по которому `Function` выполнит `flow.set("doorOpenCounter", 0);` и обновит статус.

---

Итоги и лучшие практики

В этом уроке мы изучили ноду `Status` — мощный инструмент для мониторинга "здоровья" компонентов потока и создания отказоустойчивых систем автоматизации.

> 🔗 Связанный материал: Для полного понимания механизмов отладки и мониторинга рекомендуется повторно ознакомиться с уроками по нодам `Debug` (для анализа данных) и `Catch` (для перехвата ошибок). Эти три ноды (`Debug`, `Catch`, `Status`) образуют "святую троицу" отладки в Node-RED.

Давайте подведем итог и сформулируем лучшие практики.

Сравнительная таблица инструментов отладки:

| Инструмент | За что отвечает? | Когда использовать? |

| -------------- | ------------------------------------------- | ------------------------------------------------------------------------------------ |

| `Debug` | Данные (`msg` объект) | Для проверки содержимого сообщений, отладки логики, инспекции `payload` и `topic`. |

| `Catch` | Ошибки (сбои в работе нод) | Для централизованного перехвата и логирования исключений, создания аварийной логики. |

| `Status` | Состояние (работоспособность самой ноды) | Для мониторинга подключений, создания автоматических реакций на сбои связи. |

Лучшие практики

Всегда мониторить статус критически важных нод-интерфейсов. Любая нода, которая общается с внешним миром (оборудованием или сетевыми сервисами) — `Modbus`, `KNX`, `DALI`, `MQTT`, `HTTP Request` — является потенциальной точкой отказа. На каждую такую ноду в вашем проекте должна быть настроена связка `Status` -> `Switch` для обработки потери связи. Это признак профессионально спроектированной системы.

Использовать связку `Status` -> `Switch` для автоматической реакции. Не просто выводите статус в `Debug`, а заставляйте систему действовать. Потеря связи — это не просто запись в логе, это событие, которое может запустить резервный сценарий, отправить уведомление или перевести систему в безопасный режим.

Применять `node.status()` для наглядной индикации сложной логики. Если у вас есть `Function`-нода, реализующая конечный автомат (FSM) или многошаговый процесс (например, полив, состоящий из фаз "открытие клапана", "ожидание", "закрытие клапана"), используйте `node.status()` для отображения текущего шага. Это колоссально упрощает отладку и понимание того, что происходит в системе в данный момент, без необходимости просматривать десятки отладочных сообщений.

Что дальше?

Освоив `Debug`, `Catch` и `Status`, вы получили полный набор инструментов для создания и, что более важно, поддержки сложных и надежных потоков. В следующем уроке мы перейдем к журналированию — научимся сохранять важные события и ошибки не просто в лог-файл, а в структурированную базу данных MySQL, доступную на контроллере HI, для последующего анализа и построения отчетов.