Логика инициализации при старте: шаблон 'Inject-Once'

Урок 2 · Исполнительные устройства: интерлоки, таймауты · 30 мин · theory

Введение: Проблема инициализации состояния при старте

При эксплуатации любой системы автоматизации, особенно на необслуживаемых объектах, одним из ключевых аспектов надежности является предсказуемость ее поведения после перезапуска. Перезапуск контроллера HI может быть вызван различными факторами: плановым обновлением программного обеспечения, кратковременным сбоем электропитания или срабатыванием систем защиты. В момент старта операционной системы и загрузки среды Node-RED возникает критически важный вопрос: в каком состоянии находятся подключенные исполнительные устройства?

Предположим, до сбоя питания свет в помещении был включен. После восстановления питания контроллер перезагрузится. Должен ли свет остаться включенным? Или система должна принудительно его выключить, перейдя в заранее определенное "безопасное" состояние? Ответ на этот вопрос не должен быть случайным. Оставление системы в неопределенном состоянии несет в себе прямые риски:

Безопасность: Невыключенный нагревательный прибор, насос или станок может привести к аварийной ситуации.
Энергоэффективность: Бесконтрольно включенные группы освещения или климатические системы в пустом здании приводят к неоправданному расходу энергоресурсов.
Комфорт пользователя: Непредсказуемое поведение системы (например, включение всего света в доме в 3 часа ночи после сбоя) подрывает доверие к автоматизации.

🔗 Связанный материал: Как мы детально разбирали в уроке `COURSE-05-M08-L01`, попытка решить эту проблему с помощью MQTT-сообщений с флагом `Retain` является опасной и нерекомендуемой практикой. Использование `Retain` приводит к так называемому "эффекту Replay", когда контроллер при старте получает "застрявшее" на брокере, потенциально неактуальное состояние, что может инициировать нежелательные действия.

Следовательно, для построения профессиональной и отказоустойчивой системы автоматизации абсолютно необходим явный, надежный и полностью контролируемый механизм инициализации. Этот механизм должен гарантировать, что сразу после старта контроллера все критически важные подсистемы будут переведены в известное, безопасное и документированное начальное состояние. Именно для решения этой задачи в архитектуре Node-RED существует фундаментальный шаблон проектирования, который мы рассмотрим в данном уроке.

---

Теория: Шаблон 'Inject-Once' как решение

Для реализации надежной логики инициализации в Node-RED используется простой, но чрезвычайно мощный шаблон проектирования — 'Inject-Once' (однократный запуск). Этот шаблон основан на стандартном узле `inject`, входящем в базовую палитру Node-RED, но использует его специфическую, часто упускаемую из виду возможность.

Большинство инженеров знакомы с узлом `inject` как с инструментом для ручного запуска потоков (нажатием на кнопку узла) или для периодического запуска (с заданным интервалом). Однако в его настройках скрыта третья, ключевая для нашего случая, опция: "Inject once after ... seconds, then ...".

При активации этой опции узел `inject` автоматически сгенерирует и отправит сообщение ровно один раз после того, как поток будет развернут (`Deploy`) или после перезапуска среды Node-RED (что происходит при старте контроллера HI). Это событие становится идеальным триггером для запуска специализированного потока инициализации.

> ℹ️ Информация: Событие "развертывание" (Deploy) и "старт Node-RED" являются для узла `inject` эквивалентными с точки зрения однократного запуска. Это означает, что логика инициализации будет отрабатывать не только при включении контроллера, но и каждый раз, когда вы вносите изменения в потоки и нажимаете кнопку "Deploy", что чрезвычайно удобно для отладки.

Применение шаблона 'Inject-Once' решает проблему начальной неопределенности:

Гарантированный запуск: Мы получаем 100% гарантию, что наш поток инициализации будет выполнен при каждом старте системы.

Централизованная точка входа: Вся логика, связанная с первоначальной настройкой системы, начинается с одного конкретного узла. Это делает поток легко читаемым и поддерживаемым.

Независимость от внешних факторов: В отличие от MQTT `Retain`, этот механизм полностью автономен и находится под контролем самого контроллера. Он не зависит от состояния внешнего брокера или других систем.

Таким образом, 'Inject-Once' — это не просто удобная функция, а фундаментальный строительный блок для создания отказоустойчивых систем на платформе HI. Он позволяет инженеру-инсталлятору принудительно перевести систему из хаотического "состояния после сбоя" в предсказуемое и безопасное "начальное рабочее состояние".

📋 Ключевые понятия:

Инициализация состояния: Процесс принудительной установки всех исполнительных устройств и логических переменных системы в заранее определенное начальное состояние при старте контроллера.
Шаблон 'Inject-Once': Метод использования узла `inject` с опцией однократного запуска после старта для инициирования потока инициализации.

---

Практика: Настройка узла 'Inject' для однократного запуска

Реализация шаблона 'Inject-Once' на практике не требует сложных настроек или установки дополнительных модулей. Все необходимое уже есть в стандартной поставке Node-RED на контроллере HI.

Рассмотрим пошаговый процесс настройки:

Добавьте узел `inject` на холст. Перетащите его из левой панели палитры в рабочую область. Рекомендуется сразу дать ему осмысленное имя, например, "Запуск при старте".

Откройте окно настроек. Сделайте двойной щелчок по узлу, чтобы открыть диалоговое окно его свойств.

Настройте полезную нагрузку (Payload). По умолчанию узел отправляет временную метку (`timestamp`). Для потока инициализации само значение `msg.payload` часто не имеет значения, так как узел используется лишь как триггер. Можно оставить `timestamp` или изменить на `boolean` значение `true` для большей наглядности.

Активируйте режим однократного запуска. Найдите в настройках опцию "Inject once after ... seconds, then..." и поставьте галочку напротив нее.

Настройка узла Inject

Установите задержку. Сразу после активации опции появится поле для ввода задержки. Здесь необходимо указать, через сколько секунд после старта Node-RED должно быть отправлено сообщение.

> 💡 Подсказка: Используйте минимальную, но достаточную задержку (например, 1-2 секунды). Это даст время на запуск всех фоновых сервисов контроллера HI, таких как MQTT-брокер, MySQL-сервер и драйверы шин (Modbus, CAN). Слишком малая задержка (например, 0.1 секунды) может привести к тому, что инициализирующее сообщение будет отправлено в MQTT-топик до того, как MQTT-брокер полностью запустится, и сообщение будет потеряно. Задержка в 1-2 секунды является надежным компромиссом.

Отключите периодический запуск. Убедитесь, что в выпадающем списке `Repeat` выбрано значение `none`. Нам не нужен периодический запуск, только однократный при старте.

Сохраните настройки. Нажмите кнопку "Done".

Теперь узел `inject` полностью сконфигурирован. После каждого развертывания или перезапуска контроллера он будет выжидать указанную задержку, а затем отправит одно-единственное сообщение, которое запустит всю последующую цепочку инициализации.

---

Пример: Установка безопасного состояния по умолчанию

Рассмотрим самый распространенный и важный сценарий применения шаблона 'Inject-Once': приведение всех исполнительных устройств в безопасное состояние по умолчанию. Для большинства объектов это означает выключение всего освещения, розеток, остановку приводов и перевод климатических систем в режим ожидания.

Задача: Гарантировать, что все реле, управляющие освещением в офисном центре, будут выключены после перезагрузки контроллера. Это предотвратит расход электроэнергии в случае, если сбой питания произошел ночью или в выходной день.

Построим для этого следующий поток:

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

                           +-------------------+    +----------------------+
[Inject: 'Inject-Once'] -> |  Change: Set OFF  | -> |  MQTT Out: All Lights|
                           +-------------------+    +----------------------+

Конфигурация узлов:

Узел `Inject: 'Inject-Once'`

* Name: `[INIT] Запуск при старте`

* Payload: `boolean` `true` (для наглядности)

* Topic: `init/start`

* Inject once after: `2` `seconds`

* Repeat: `none`

Узел `Change: Set OFF`

* Name: `Формировать команду OFF`

* Rules: `Set` `msg.payload` to `boolean` `false`.

* Это правило заменяет полезную нагрузку от узла `inject` на конкретную команду, которую поймет наше реле. Для выключения мы отправляем `false`.

Узел `MQTT Out: All Lights`

* Name: `Выключить всё освещение`

* Server: Выбрать настроенный локальный MQTT-брокер контроллера HI.

* Topic: `hi/commands/lights/all/set`

* QoS: `1` - Гарантированная доставка хотя бы один раз.

* Retain: `false` - Категорически `false`, чтобы избежать проблем, описанных ранее.

Логика работы потока:

Контроллер HI включается. Запускается Node-RED.

Узел `[INIT] Запуск при старте` активируется и начинает отсчет 2 секунд.

Через 2 секунды он отправляет сообщение с `msg.payload = true`.

Сообщение поступает в узел `Формировать команду OFF`. Он изменяет `msg.payload` на `false`.

Новое сообщение с `msg.payload = false` отправляется в узел `Выключить всё освещение`.

Узел публикует `false` в MQTT-топик `hi/commands/lights/all/set`.

Все потоки, подписанные на этот групповой топик, получают команду и выключают соответствующие реле.

Этот же подход можно использовать для более сложных устройств. Важно лишь сформировать правильный "контракт сообщения".

| Тип устройства | Цель инициализации | Пример `msg.payload` в узле `Change` |

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

| Реле (Relay) | Выключить | `false` (boolean) |

| Диммер (Dimmer) | Выключить и сбросить яркость | `{"state": false, "brightness": 0}` (JSON Object) |

| Привод штор/жалюзи | Остановить движение | `{"command": "STOP"}` (JSON Object) |

| Клапан на трубе (2-поз.) | Закрыть (безопасное положение) | `false` (boolean) |

| Термостат | Режим "Ожидание" ("Standby") | `{"mode": "standby", "setpoint": 18}` (JSON Object) |

Используя этот простой, но надежный поток, вы обеспечиваете предсказуемое и безопасное начальное состояние для всей системы.

---

Расширенное применение: Восстановление состояния из персистентного контекста

Установка безопасного состояния по умолчанию — это жизненно важный, но не единственный сценарий. В системах, ориентированных на комфорт пользователя (например, "умный дом"), часто требуется более интеллектуальное поведение: восстановить то состояние, которое было до перезагрузки. Например, если пользователь установил комфортную температуру `23°C` на термостате, он ожидает, что после перезапуска контроллера эта уставка сохранится.

Для этого мы объединим шаблон `Inject-Once` с механизмом персистентного контекста, который мы подробно изучили ранее.

🔗 Связанный материал: Напомним, в уроке `COURSE-05-M08-L02` мы рассмотрели, как настроить на контроллере HI персистентное хранилище (`contextStorage`) для сохранения переменных `flow` или `global` контекста в файловой системе или базе данных MySQL, что позволяет им "пережить" перезагрузку.

Логика работы:

При работе системы: Каждый раз, когда пользователь меняет состояние (например, включает свет), мы сохраняем это состояние в персистентную `flow`-переменную.

При старте системы: Шаблон `Inject-Once` запускает поток, который читает значение из этой переменной и отправляет его соответствующему устройству.

ASCII-схема потока восстановления:

                           +------------------------+      +-------------------------+      +---------------------+
[Inject: 'Inject-Once'] -> | Change: Read from Ctx  | ->   | Switch: State is valid? | --+--> | MQTT Out: Set State |
                           +------------------------+      +-------------------------+   |    +---------------------+
                                                                      |                |
                                                                   (otherwise)         |
                                                                      |                |
                                                                      v                |
                                                     +------------------------------+  |
                                                     | Change: Set default if empty | -+
                                                     +------------------------------+

Детализация потока:

`Inject: 'Inject-Once'`: Настроен аналогично предыдущему примеру, запускается через 2 секунды после старта.
`Change: Read from Ctx`: Этот узел читает сохраненное состояние.

* Rules: `Set` `msg.payload` `to` `flow.livingRoomLightState`. Переменная `livingRoomLightState` должна была быть ранее сохранена в `flow` контексте, настроенном на персистентное хранение.

`Switch: State is valid?`: Это важнейший узел для обеспечения отказоустойчивости.

* Property: `msg.payload`

* Rule 1: `is not null`. Эта ветка сработает, если в контексте было найдено сохраненное значение.

* Rule 2 (otherwise): Эта ветка сработает при самом первом запуске системы, когда `flow.livingRoomLightState` еще не существует и вернет `undefined` (или `null`).

> ⚠️ Внимание: При чтении из персистентного контекста всегда проверяйте, что полученное значение не является `undefined` или `null`. Это может произойти при первом запуске системы на новом объекте или после очистки контекста. Использование узла `switch` для обработки таких случаев и установки значения по умолчанию, если сохраненное состояние отсутствует, является обязательной практикой для создания надежной логики.

`Change: Set default if empty`: Этот узел находится на "otherwise" ветке `switch` и задает безопасное состояние по умолчанию (`false`) на случай, если контекст пуст. Это делает систему надежной даже при первом старте.
`MQTT Out: Set State`: Отправляет либо восстановленное, либо дефолтное состояние в MQTT-топик устройства.

Сравнение подходов

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

| Установка безопасного состояния | Максимальная безопасность и предсказуемость, простота реализации. | Не учитывает предпочтения пользователя, может вызывать дискомфорт. | Промышленные объекты, системы безопасности (клапаны), общественные зоны (офисы, гостиницы). |

| Восстановление из персистентного контекста | Сохраняет пользовательские настройки, повышает комфорт и удобство. | Сложнее в реализации, требует тщательной обработки "первого запуска". | Частные дома и квартиры (освещение, климат), персональные рабочие места. |

---

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

В этом уроке мы изучили один из самых важных шаблонов проектирования в Node-RED для создания надежных систем — 'Inject-Once'. Он решает фундаментальную проблему неопределенности состояния системы после перезагрузки контроллера.

Ключевые выводы:

Шаблон 'Inject-Once' является обязательным к применению стандартом для любой профессиональной инсталляции на платформе HI. Он обеспечивает детерминированный и контролируемый запуск системы.
Использование небольшой задержки (1-2 секунды) в узле `inject` критически важно для того, чтобы все системные сервисы успели стартовать до отправки инициализирующих команд.
Существует два основных сценария использования шаблона:

1. Установка безопасного состояния по умолчанию: Простой и надежный метод для систем, где безопасность и энергоэффективность превыше всего.

2. Восстановление состояния из персистентного контекста: Более сложный, но ориентированный на пользователя подход, сохраняющий комфорт и персональные настройки.

При восстановлении состояния из контекста всегда предусматривайте ветку для обработки случая, когда сохраненного состояния еще нет (первый запуск).

Для повышения читаемости и упрощения поддержки проекта всегда документируйте логику инициализации. Размещайте потоки инициализации на отдельной вкладке с названием "Инициализация" или "Startup Logic". Используйте узлы `comment` для описания того, какое состояние и для каких устройств устанавливается при старте. Это сэкономит часы времени при дальнейшей диагностике и модернизации системы.

Что дальше

Теперь, когда мы научились гарантировать правильный старт системы, на следующем уроке мы перейдем к обеспечению ее стабильной работы в реальном времени. Мы рассмотрим механизмы контроля работоспособности, такие как "сторожевые таймеры" (watchdogs), которые позволяют автоматически обнаруживать "зависание" потоков или устройств и предпринимать действия по их восстановлению.