Паттерн 'Rules Engine'
LESS-06-M05-L06: Введение в паттерн 'Rules Engine'
Паттерн Rules Engine (или Движок Правил) — это мощный архитектурный подход, который позволяет отделить и централизовать логику принятия решений от основного потока выполнения программы. Вместо того чтобы "размазывать" бизнес-логику по множеству узлов `switch` и `function`, мы создаем единый механизм, который декларативно, то есть на основе описания, определяет, какое действие необходимо выполнить в ответ на определенный набор входящих данных.
Представьте себе работу диспетчерского центра на промышленном объекте. Диспетчер не принимает решения хаотично. У него есть четкий регламент — набор правил:
- "Если давление в котле превысило N атмосфер И температура в норме, то снизить подачу топлива на 10%".
- "Если сработал датчик задымления И не поступило подтверждение отмены тревоги в течение 60 секунд, то активировать систему пожаротушения и оповестить службу безопасности".
- "В ночную смену (с 23:00 до 07:00) все извещения о движении в складской зоне должны классифицироваться как критические".
В этой аналогии:
- Входящие данные (давление, температура, сигналы датчиков, время) — это Факты (Facts).
- Регламент (набор инструкций "если... то...") — это Правила (Rules).
- Диспетчер, который сопоставляет факты с правилами и отдает распоряжения,— это и есть Rules Engine.
- Распоряжения (снизить подачу, активировать систему) — это Действия (Actions).
Основное преимущество такого подхода — централизация. Когда вся логика принятия решений собрана в одном месте и описана в виде структурированного набора правил, систему становится значительно проще понимать, поддерживать и масштабировать. Если завтра изменится регламент, инженеру не придется искать нужный узел `function` в десятках потоков. Ему достаточно будет изменить или добавить правило в централизованном движке. Это кардинально снижает риск внесения ошибок и ускоряет модификацию системы.
В контексте Node-RED на контроллере HI, классический подход с разветвленными потоками, где каждый `switch` узел проверяет одно условие, быстро приводит к так называемой "лапше" (Spaghetti Flow). Движок правил позволяет превратить сложную, запутанную схему в линейный, понятный и легко читаемый поток:
| Подход с разрозненной логикой | Подход с 'Rules Engine' |
| ----------------------------------------------------------- | -------------------------------------------------------- |
| Множество узлов `switch` и `function` по всему потоку. | Один или несколько централизованных узлов движка правил. |
| Логика принятия решений смешана с логикой преобразования данных. | Логика принятия решений отделена (декларативна). |
| Изменение одного правила может потребовать правки нескольких узлов. | Изменение правила затрагивает только его описание. |
| Сложно понять общую картину автоматизации. | Вся логика видна в одном месте (в наборе правил). |
| Высокий риск логических ошибок при модификации. | Низкий риск, так как структура потока не меняется. |
Таким образом, паттерн 'Rules Engine' — это переход от императивного стиля ("как делать") к декларативному ("что делать"), что является признаком зрелого и профессионального подхода к проектированию систем автоматизации.
---
Компоненты 'Rules Engine': Факты, Правила и Действия
Любой движок правил, независимо от его реализации, оперирует тремя фундаментальными сущностями: Фактами, Правилами и Действиями. Понимание их ролей и взаимодействия — ключ к успешному применению паттерна.
> 🔗 Связанный материал: Факты часто представляют собой состояние системы. Рекомендуем повторить урок COURSE-06-M05-L03 'Паттерн State Machine' для лучшего понимания управления состоянием.
### Факты (Facts)
Факты — это атомарные единицы информации, которые служат "сырьем" для движка правил. Это объективные данные о текущем состоянии системы и окружающей среды, на основе которых будут приниматься решения.В системе на базе контроллера HI фактами могут быть:
- Данные из `msg.payload`: Показания датчика, которые только что поступили в поток. Например, сообщение от Modbus-датчика влажности.
- Состояние устройств: Текущее состояние реле (включено/выключено), положение сервопривода.
- Значения из контекста: Сохраненное состояние из паттерна State Machine (например, `flow.get('heating_mode')`), текущий выбранный сценарий (`'День'`, `'Ночь'`, `'Отпуск'`), данные, полученные из внешних API (например, прогноз погоды).
- Системное время: Текущее время суток, день недели, дата.
Факты должны быть представлены в простом и понятном формате "ключ-значение". Например, для нашего движка мы можем собрать все факты в один объект:
{
"temperature_living_room": 24.5,
"humidity_living_room": 55,
"motion_detected": true,
"illuminance": 350,
"window_open": false,
"active_scene": "День",
"time_of_day": "14:30"
}
### Правила (Rules)
Правила — это сердце движка. Каждое правило представляет собой формализованную логическую конструкцию "Если (условие), то (действие)".- Условие (Condition): Логическое выражение, которое применяется к набору фактов. Условие может быть простым (`temperature > 25`) или составным, объединяя несколько проверок с помощью логических операторов И/ИЛИ (`motion_detected == true` AND `illuminance < 100`).
- Действие (Action): Инструкция о том, что нужно сделать, если условие истинно. Важно понимать, что на этом этапе движок правил сам не выполняет действие, а лишь _генерирует намерение_ или _команду_ на его выполнение.
### Действия (Actions)
Действия — это результат работы движка. Когда факты соответствуют условию одного или нескольких правил, движок генерирует одно или несколько действий. Эти действия затем передаются дальше по потоку для исполнения.Примеры действий:
- Изменить `msg.payload`, чтобы передать команду дальше по потоку.
- Отправить команду на исполнительное устройство через MQTT (например, `hi/commands/light/set`).
- Вызвать API стороннего сервиса (например, отправить уведомление в Telegram).
- Изменить состояние системы, записав новое значение в контекст (`flow.set('heating_mode', 'eco')`).
### Инструменты для реализации в Node-RED
В Node-RED для создания движка правил можно использовать инструменты разной степени сложности и гибкости:
Выбор инструмента зависит от задачи. Для простого управления светом по датчику движения достаточно узла `switch`. Для сложной системы управления климатом в отеле, где правила могут настраиваться для каждого номера, необходим полноценный декларативный движок.
---
Практическая реализация: узел 'switch' как простой движок правил
Рассмотрим, как создать простой, но эффективный движок правил для сценария "Умное освещение" с помощью стандартного узла `switch`. Этот узел идеально подходит для задач, где правила статичны и их количество невелико.
Задача: Автоматизировать освещение в гостиной. Логика должна следовать трем правилам:Для реализации нам понадобятся датчики, подключенные к универсальным входам контроллера HI, которые передают данные в Node-RED. Предположим, у нас есть поток, который собирает факты в одно сообщение.
Пример входящего сообщения (факт):{
"payload": {
"device_id": "sensor_living_room",
"motion": true,
"illuminance": 45
},
"topic": "telemetry/living_room"
}
Также предположим, что текущий режим сцены хранится в контексте потока: `flow.get('scene_mode')`, который может принимать значения 'День', 'Вечер', 'Ночь'.
### Построение потока
Логика выключения по отсутствию движения в течение 5 минут удобно реализуется с помощью узла `trigger`. Он будет отправлять сообщение "выключить" спустя 5 минут после последнего сообщения о наличии движения. Наш движок правил на `switch` сосредоточится на логике включения.
ASCII-схема потока: +---------------------------+
[Датчик движения/освещенности]-->| Function: "Собрать факты" |---+
+---------------------------+ |
|
+----------------------------------------------------+
|
v
+-----------------------------+
| Switch: "Движок правил освещения" |
+-----------------------------+
| (Выход 1: ВКЛ Свет) | (Выход 2: Игнор)
| |
v v
+--------------------------+ +----------------+
| Function: "Форм. команду ON"| | Comment: "Ничего не делать" |
+--------------------------+ +----------------+
|
v
+--------------------+
| MQTT Out: Команда реле |
+--------------------+
### Настройка узла `switch`
Узел `switch` — это наш мини-движок правил. Мы настроим его на проверку нескольких свойств одновременно, используя его способность работать с JSONata и переменными контекста.
payload.motion = true and payload.illuminance < 50 and $flowContext('scene_mode') != 'Ночь'
- `payload.motion = true`: Проверяем факт наличия движения.
- `payload.illuminance < 50`: Проверяем факт недостаточной освещенности.
- `$flowContext('scene_mode') != 'Ночь'`: Проверяем факт, что система не в режиме 'Ночь'. Функция `$flowContext()` позволяет получить доступ к переменным контекста потока прямо в выражении.
- `and`: Логический оператор, который требует, чтобы все три условия были истинными.
### Результат работы
- Если на вход `switch` поступает сообщение:
{ "payload": { "motion": true, "illuminance": 45 } }
и в контексте `flow.scene_mode` установлено значение 'Вечер', то JSONata-выражение вернет `true`. Сообщение пойдет на Выход 1. Узел `Function` за ним сформирует команду для реле, и свет включится.
// Код в узле "Форм. команду ON"
msg.payload = "ON";
msg.topic = "hi/commands/living_room/light_main/set";
return msg;
- Если на вход поступает то же сообщение, но в контексте `flow.scene_mode` стоит 'Ночь', то выражение `... and $flowContext('scene_mode') != 'Ночь'` станет ложным. Всё выражение вернет `false`. Сообщение пойдет на Выход 2 (otherwise), и никаких действий не произойдет.
- Если освещенность > 50 люкс, условие также не выполнится, и свет не включится.
Этот пример демонстрирует, как даже один узел `switch` с правильно составленным выражением может служить компактным и читаемым движком правил для несложных сценариев автоматизации. Главное — правильно подготовить факты перед подачей на вход движка.
---
Продвинутый подход: динамические правила с node-red-contrib-json-rules
Когда логика становится сложнее, а правила должны быть гибкими и изменяемыми без перезагрузки потоков, стандартные узлы достигают своего предела. Здесь на помощь приходят специализированные решения, такие как `node-red-contrib-json-rules`. Этот узел реализует полноценный декларативный движок правил, где сами правила являются данными в формате JSON.
> 💡 Подсказка: Динамическое управление правилами идеально подходит для кастомизации автоматизаций конечным пользователем через UI. Вы можете создать в интерфейсе редактор правил, который будет сохранять JSON в `global` контекст, а движок будет их подхватывать.
### Установка и принцип работы
Для начала установите узел через `Manage palette` в интерфейсе Node-RED:
# В терминале контроллера HI в директории ~/.node-red
npm install node-red-contrib-json-rules
После перезапуска Node-RED у вас появится узел `rules`.
Принцип его работы следующий:
Ключевое преимущество в том, что правила — это не код, а данные. Их можно хранить в файле, в базе данных MySQL на контроллере или в глобальном контексте, что позволяет изменять их "на лету".
### Практический пример: Управление климатом
Задача: Создать гибкую систему управления кондиционером в офисном помещении. Правила должны быть легко изменяемы. Факты, которые мы будем собирать:- `temperature`: текущая температура с датчика.
- `humidity`: текущая влажность.
- `window_open`: состояние геркона на окне (`true`/`false`).
- `presence`: наличие людей в помещении (PIR-сенсор).
- `work_hours`: является ли текущее время рабочим (`true`/`false`).
Мы можем сохранить этот JSON в глобальном контексте с помощью узла `Inject` при старте.
[
{
"if": [
{ "fact": "temperature", "operator": ">=", "value": 25 },
{ "fact": "presence", "operator": "==", "value": true },
{ "fact": "window_open", "operator": "==", "value": false }
],
"then": [
{
"action": "set_ac",
"params": { "state": "cool", "temperature": 22, "fan_speed": "auto" }
}
]
},
{
"if": [
{ "fact": "presence", "operator": "==", "value": false }
],
"then": [
{
"action": "set_ac",
"params": { "state": "off" }
}
]
},
{
"if": [
{ "fact": "window_open", "operator": "==", "value": true }
],
"then": [
{
"action": "set_ac",
"params": { "state": "off" }
},
{
"action": "notify_user",
"params": { "message": "Кондиционер выключен, так как открыто окно." }
}
]
}
]
- `"if"`: Массив условий. Все они должны быть истинны (логическое "И").
- `"operator"`: Оператор сравнения (`>`, `<`, `==`, `!=`, etc.).
- `"value"`: Значение для сравнения.
- `"then"`: Массив действий, которые нужно выполнить.
- `"params"`: Параметры этого действия.
### Построение потока и обработка результатов
ASCII-схема:[Inject: правила] --(2)-->+-----------------+
| rules |
[Сбор фактов] ----(1)-->| (Движок правил) | --(результат)-->[Switch: `action`]
+-----------------+ |
+--(set_ac)-->[Формирование команды AC]
|
+--(notify_user)-->[Отправка уведомления]
{
"temperature": 26,
"humidity": 60,
"window_open": false,
"presence": true,
"work_hours": true
}
и подает его на первый вход узла `rules`.
{
"action": "set_ac",
"params": {
"state": "cool",
"temperature": 22,
"fan_speed": "auto"
},
"if": [ / ...условия, которые сработали... / ]
}
Используя `node-red-contrib-json-rules`, мы получаем невероятно гибкую систему. Добавить новое правило или изменить порог температуры теперь можно, просто отредактировав JSON-объект в глобальном контексте через UI Dashboard, без единого изменения в логике потока Node-RED.
---
Интеграция с другими паттернами и антипаттерны
Паттерн 'Rules Engine' не существует в вакууме. Наибольшую эффективность он показывает в комбинации с другими паттернами проектирования, рассмотренными нами ранее. Однако, как и любой мощный инструмент, его можно использовать неправильно.
> ⚠️ Внимание: Слишком большое количество сложных правил (>50-100), выполняемых на высокой частоте, может привести к заметной нагрузке на CPU контроллера HI. Профилируйте производительность при построении комплексных систем.
### Интеграция с другими паттернами
Эта комбинация позволяет выполнять проверку правил не по каждому изменению фактов, а по расписанию. Это крайне полезно для некритичных систем, чтобы снизить нагрузку.
* Пример: Система управления отоплением. Нет смысла пересчитывать логику каждую секунду. Достаточно запускать `Rules Engine` раз в 5-10 минут с помощью узла `Inject`, настроенного как Scheduler. Он инициирует сбор свежих фактов (температуры, уставки) и подает их на вход движка.
Движок правил отлично подходит для определения переходов в конечном автомате.
* Пример: Система управления поливом.
* Состояния: `Idle`, `Watering`, `Paused_Rain`.
* Факты: `soil_moisture`, `rain_sensor_active`, `time_of_day`.
* Правило: `IF state is 'Idle' AND soil_moisture < 30% AND rain_sensor_active = false THEN action = 'change_state_to_watering'`.
* Движок правил определяет, что нужно сменить состояние, а сам механизм смены состояния и хранения (`flow.context`) реализуется, как описано в уроке про `State Machine`.
Это одна из самых важных комбинаций для создания надежных систем. Движок правил не должен напрямую управлять оборудованием. Его задача — выразить намерение.
* Пример: `Rules Engine` решает, что нужно включить насос (`action: 'set_pump_on'`). Это действие отправляется в виде MQTT-сообщения `.../set` с командой. Отдельный субпоток, реализующий паттерн `Cmd/Ack`, принимает эту команду, отправляет ее на Modbus-устройство, ждет подтверждения `.../state` и сообщает об успешном выполнении. Таким образом, сложная логика правил отделена от низкоуровневой логики взаимодействия с оборудованием.
### Распространенные антипаттерны
* Проблема: Попытка реализовать всю логику системы, включая десятки сложных правил, внутри одного гигантского узла `function`. Такой код становится абсолютно нечитаемым, его невозможно отлаживать и поддерживать. Любое изменение превращается в испытание.
* Решение: Разделяй и властвуй. Если правила можно сгруппировать по функциональности (управление светом, управление климатом), создайте для каждой группы свой, отдельный движок правил. Если правила сложны, но их можно описать декларативно — используйте специализированные узлы вроде `node-red-contrib-json-rules`.
* Проблема: Множество "магических чисел" и условий, зашитых прямо в код узлов `function` или `switch`. Например, `if (msg.payload.temp > 22.5 && msg.payload.hour > 8) ...`. Чтобы изменить порог `22.5` на `23`, нужно найти этот узел, отредактировать код и заново развернуть поток.
* Решение: Выносите все пороговые значения и параметры в переменные контекста (`flow.get('heating_threshold')`) или используйте декларативный подход, где правила являются данными (JSON). Это позволит менять логику работы системы через панель управления или конфигурационный файл, что особенно важно для систем, которые будет обслуживать не только разработчик, но и конечный пользователь.
### Что дальше
В этом уроке мы рассмотрели паттерн 'Rules Engine' как мощный инструмент для централизации и декларативного описания логики автоматизации. Мы научились строить простые движки на базе узла `switch` и продвинутые, динамические системы с помощью `node-red-contrib-json-rules`.
В следующих уроках мы перейдем к финальному этапу проектирования надежных систем и рассмотрим, как создавать переиспользуемые компоненты с помощью субпотоков (Subflows) и организовывать взаимодействие между разными потоками, чтобы строить по-настоящему масштабные и поддерживаемые проекты.