Использование ноды Trigger для создания таймера watchdog

Урок 3 · Датчики и входы: нормализация сигналов · 30 мин · theory

Нода Trigger как стандарт для создания Watchdog

В предыдущих уроках мы рассмотрели концепцию watchdog (сторожевого таймера) и реализовали базовый сценарий его работы с использованием ноды `Function`. Такой подход, основанный на периодической проверке временной метки (`msg.timestamp`), является гибким, но сопряжен с рядом недостатков, особенно в проектах промышленного уровня:

Избыточность кода: Кастомный скрипт в ноде `Function` требует написания и поддержки дополнительного JavaScript-кода, что увеличивает вероятность ошибок.
Сложность чтения: Поток с кастомной логикой менее нагляден. Инженеру, не знакомому с проектом, потребуется время на изучение кода внутри ноды `Function`, чтобы понять принцип работы watchdog.
Неэффективность ресурсов: Логика, основанная на `Inject` и периодической проверке состояния, создает постоянную фоновую нагрузку на процессор контроллера, даже если с датчиком все в порядке.

> 🔗 Связанный материал: Для полного понимания альтернативного подхода и его ограничений, мы настоятельно рекомендуем изучить урок `COURSE-04-M07-L03`, где мы подробно разбирали создание watchdog-сценария с использованием ноды `Function` и анализа временных меток.

В противоположность этому, Node-RED предлагает встроенный, более нативный и элегантный инструмент для решения этой задачи — ноду `Trigger`. Она является стандартным решением для реализации простых сторожевых таймеров.

Основной принцип ее работы идеально подходит для задачи мониторинга. Вместо того чтобы периодически проверять, приходило ли сообщение, нода `Trigger` работает по принципу отреагировать, если сообщение не пришло в течение заданного времени.

| Подход | Принцип работы | Преимущества / Недостатки |

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

| Кастомный скрипт (`Function`) | "Я буду каждую минуту проверять, не старше ли последняя метка времени, чем 60 секунд". | - Сложность, ресурсоемкость.
+ Гибкость для сложных сценариев (группы датчиков). |

| Нода `Trigger` (нативный подход) | "Я буду ждать сообщения. Если оно придет, я сброшу свой таймер. Если оно не придет за 60 секунд, я отправлю тревогу". | + Простота, наглядность, эффективность.
- Менее гибок для динамических систем. |

Нода `Trigger` реализует пассивное ожидание. Она не выполняет никаких действий до тех пор, пока не истечет ее внутренний таймаут. Каждое входящее сообщение от отслеживаемого датчика выполняет сброс таймера, запуская его с начала. Если же поток сообщений от датчика прекращается (из-за обрыва связи, отказа самого датчика или сбоя питания), таймер не сбрасывается, его время истекает, и нода `Trigger` генерирует собственное, "аварийное" сообщение. Это делает ее идеальным, легковесным и надежным инструментом для построения watchdog-сценариев.

---

Конфигурация ноды Trigger для мониторинга

Правильная настройка ноды `Trigger` — ключ к созданию надежного сторожевого таймера. Давайте детально разберем каждый параметр в контексте нашей задачи.

> 💡 Подсказка: Выбирайте таймаут с запасом. Если датчик отправляет данные каждые 60 секунд, установите таймаут в `Trigger` на 70-75 секунд (т.е. +15-25%). Это компенсирует возможные микро-задержки в сети (MQTT, KNX) и предотвратит ложные срабатывания watchdog из-за незначительных колебаний времени доставки сообщений.

Основные параметры настройки

Представим, что мы отслеживаем датчик температуры, который отправляет данные раз в 30 секунд.

Отправлять (Send): Этот параметр определяет, что нода делает сразу после получения входящего сообщения. Для задачи watchdog нам не нужно ничего отправлять немедленно — мы лишь хотим "засечь" факт получения сообщения.

* Настройка: `nothing` (ничего).

затем ждать (then wait for): Это и есть таймаут нашего watchdog. Здесь мы устанавливаем время, в течение которого нода будет ожидать следующего сообщения. Если оно не придет, сработает следующее действие.

* Настройка: `35` секунд (с учетом запаса +5 секунд к периоду датчика).

затем отправлять (then send): Это действие, которое выполнится по истечении таймаута. Здесь мы формируем "аварийное" сообщение. Крайне важно, чтобы это сообщение имело четкую структуру, соответствующую контракту сообщений нашего проекта.

* Настройка: `JSON`.

* Содержимое:

{ "error": "sensor_timeout", "sensor_id": "temp-sensor-livingroom-01", "description": "No data from living room temperature sensor for over 35 seconds" }

Такой `payload` легко обработать в последующих нодах `Switch` для отделения аварийной логики от штатной.

Ключевая опция: Обработка входящих сообщений

В нижней части окна настроек находится важнейший переключатель, который превращает `Trigger` из простого таймера в полноценный watchdog.

Опция: `Продлить задержку, если придет новое сообщение` (Extend delay if new message arrives).
Действие: Необходимо активировать эту опцию.

Именно этот флажок реализует логику сброса. Когда он активен, каждое новое входящее сообщение заставляет `Trigger` отбросить текущий отсчет и запустить 35-секундный таймер заново. Если сообщения приходят штатно (каждые 30 секунд), таймер никогда не дойдет до конца. Но как только поток прервется, последнее полученное сообщение запустит таймер, который уже не будет сброшен, и через 35 секунд нода отправит наше аварийное JSON-сообщение.

Опция `Обрабатывать каждое сообщение` (Handle every message): В данном сценарии она должна быть отключена. Если ее включить, нода будет генерировать множество независимых таймеров для каждого сообщения, что не является поведением watchdog.

Таким образом, финальная конфигурация для нашего примера выглядит так:

Отправлять `nothing`.

затем ждать `35` секунд.

затем отправлять `{"error": "sensor_timeout", ...}`.

Включить `Продлить задержку, если придет новое сообщение`.

---

Практический пример: Watchdog для датчика движения KNX

Рассмотрим реальный сценарий на объекте "Умный офис". Нам необходимо контролировать работоспособность датчика движения KNX в переговорной. Датчик при обнаружении движения отправляет значение `1` на групповой адрес `1/1/1`. Для подтверждения своей работоспособности он также периодически (каждые 5 минут) отправляет свое текущее состояние, даже если это `0` (нет движения). Если контроллер не получает от датчика никаких сообщений в течение 6 минут, мы должны считать датчик аварийным.

Соберем поток для этой задачи.

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

[knx-in: Движение 1/1/1] -----> [trigger: Watchdog 6 мин] -----> [switch: Проверка на аварию] --+--> [debug: Авария датчика]
                                                                                            |
                                                                                            +--> [debug: Штатная работа]

Шаг 1: Настройка источника данных (`knx-in`)

Нода: `knx-in device` (предполагаем, что KNX-шлюз уже настроен в конфигурации).
Group Adress: `1/1/1`.
Listen to: `all group adresses`.
Name: `Датчик движения (Переговорная)`.

Эта нода будет захватывать все сообщения, приходящие на данный групповой адрес. Штатное сообщение от нее будет выглядеть примерно так:

{
    "payload": 1,
    "topic": "1/1/1",
    "knx": {
        "event": "GroupValue_Write",
        "source": "1.1.25",
        "destination": "1/1/1",
        "rawValue": ""
    }
}

Шаг 2: Настройка ноды `Trigger`

Нода: `trigger`.
Name: `Watchdog 6 минут`.
Отправлять: `nothing`.
затем ждать: `6` минут (или `360` секунд).
затем отправлять (JSON):

{ "payload": { "error": "sensor_timeout", "sensor_id": "knx-motion-meetingroom-01", "group_address": "1/1/1", "ts": 1678886400000 } }

> ℹ️ Информация: Для динамической установки временной метки `ts` можно изменить тип поля на `J: expression` и вписать `{"payload": {"error": "...", "sensor_id": "...", "ts": $now()}}`. `$now()` вернет текущее время в миллисекундах.

Обработка входящих сообщений: Включить `Продлить задержку, если придет новое сообщение`.

Шаг 3: Настройка ноды `Switch` для разделения потоков

Эта нода — логический разветвитель. Она будет анализировать сообщения от `trigger` и направлять их по разным выходам.

Нода: `switch`.
Name: `Проверка на аварию`.
Свойство (Property): `msg.payload.error` (путь к нашему полю в аварийном сообщении).
Правила:

1. `is not null` (не является null) -> Выход 1 (для аварийных сообщений).

2. `иначе` (otherwise) -> Выход 2 (для всех остальных, т.е. штатных сообщений, которые `trigger` может пропускать, если настроен иначе).

Результат в панели отладки (Debug)

При штатной работе: Датчик присылает сообщения, `trigger` их "поглощает" и сбрасывает таймер. На выходе `trigger` ничего нет.
При отказе датчика: Проходит 6 минут. `trigger` генерирует и отправляет свое аварийное сообщение. `switch` направляет его на первый выход. В панели Debug мы увидим:

{ "payload": { "error": "sensor_timeout", "sensor_id": "knx-motion-meetingroom-01", "group_address": "1/1/1", "ts": 1678889940000 }, "_msgid": "..." }

Это сообщение является сигналом для запуска аварийной автоматики.

---

Интеграция Watchdog в систему автоматизации

Обнаружение отказа датчика — это только половина задачи. Гораздо важнее правильно отреагировать на это событие, чтобы обеспечить безопасность и предсказуемость работы системы. "Аварийный" выход ноды `trigger` является отправной точкой для сценариев обработки отказа.

> ⚠️ Внимание: Никогда не направляйте "аварийный" выход watchdog напрямую на исполнительное устройство без дополнительной логики. Это может привести к непредсказуемому поведению системы. Например, аварийный сигнал от датчика освещенности не должен напрямую включать свет на 100% мощности. Всегда используйте ноды `Switch` для разделения потоков и `RBE` для фильтрации дублирующихся тревог.

Сценарий 1: Уведомление администратора

Самый простой и обязательный сценарий — информирование службы эксплуатации. Аварийный выход ноды `switch` подключается к ноде отправки уведомлений.

Логика: `[switch: Выход 1]` -> `[function: Форматировать алерт]` -> `[telegram sender]`
Код `function`:

    let sensorId = msg.payload.sensor_id;
    let ts = new Date(msg.payload.ts).toLocaleString();

    msg.payload.content = `🚨 Авария датчика! 🚨\n\n` +
                          `ID: ${sensorId}\n` +
                          `Время отказа: ${ts}\n\n` +
                          `Система не получает данные от устройства. Требуется проверка.`;

    return msg;

Сценарий 2: Перевод системы в безопасный режим

Это более сложный, но критически важный сценарий. Если отказал ключевой датчик, связанная с ним автоматика должна перейти в предсказуемое безопасное состояние.

Пример: Отказ датчика протечки `leak-sensor-bathroom-01`.
Логика:

1. `[trigger: Watchdog]` обнаруживает отказ.

2. `[switch]` направляет аварийный `msg` по аварийной ветке.

3. `[change]` устанавливает `msg.payload` в команду для закрытия крана, например, `{ "command": "CLOSE" }`.

4. `[modbus-write]` или `[rpi gpio out]` отправляет команду на привод шарового крана, перекрывающего воду.

5. Параллельно запускается сценарий уведомления.

Сценарий 3: Визуализация статуса на дашборде

Пользователь и администратор должны видеть актуальное состояние всех компонентов системы.

Логика: `[switch: Выход 1]` -> `[change: Установить статус]` -> `[ui_text]` / `[mqtt out]`.
Нода `change`:

* `Set` (установить) `global.sensor_status[msg.payload.sensor_id]`

* `to the value` (в значение): `"error"`.

(Это предполагает, что у вас есть глобальный объект `sensor_status` для хранения состояний).

Теперь любой элемент дашборда может обращаться к `global.get("sensor_status.leak-sensor-bathroom-01")` и отображать статус датчика (например, менять иконку на красную).

Предотвращение "шторма" уведомлений с нодой RBE

Если датчик "умер" надолго, наш `trigger` будет отправлять аварийное сообщение каждые 6 минут. Это приведет к "шторму" одинаковых уведомлений. Чтобы этого избежать, используйте ноду `RBE` (Report by Exception).

Размещение: `[switch: Выход 1]` -> `[rbe]` -> `[telegram sender]`.
Настройка `rbe`:

* Mode: `block unless value changes`.

Принцип работы: `rbe` пропустит первое аварийное сообщение. Все последующие идентичные сообщения (с тем же `msg.payload`) будут заблокированы. Сообщение пройдет снова только тогда, когда датчик "оживет" и watchdog перестанет срабатывать, а затем снова откажет. Это гарантирует, что вы получите только одно уведомление на каждое событие отказа.

---

Резюме и ключевые выводы

В этом уроке мы изучили стандартный и наиболее эффективный способ создания сторожевых таймеров в Node-RED с помощью ноды `Trigger`.

Предпочтительный инструмент: Нода `Trigger` является встроенным, декларативным и легко читаемым решением для реализации watchdog для одного устройства или группы, работающей как единое целое. Она превосходит кастомные скрипты в нодах `Function` по простоте, надежности и эффективности.
Ключевая настройка: Сердце watchdog-механизма — это опция `Продлить задержку, если придет новое сообщение`. Она обеспечивает автоматический сброс таймера при получении штатных данных.
Надежный паттерн: Типовая архитектура мониторинга с обработкой отказов выглядит так:

`[Источник данных]` -> `[Trigger: Watchdog]` -> `[Switch: Анализ ошибки]`

Этот `Switch` разделяет поток на два: один для штатной логики, другой — для аварийных сценариев (уведомления, безопасный режим, визуализация).

Масштабируемость: Нода `Trigger` отлично подходит для мониторинга десятков датчиков, когда для каждого из них создается своя небольшая цепочка. Однако для систем, где необходимо динамически отслеживать сотни устройств, могут потребоваться более продвинутые подходы, основанные на хранении состояний в глобальном контексте. Эти архитектурные паттерны будут подробно рассмотрены в курсах уровня `Integration` и `Architect`.

Что дальше

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