Практика: Декомпозиция сценария

Введение в декомпозицию: от идеи к алгоритму

Любой, даже самый сложный сценарий автоматизации, можно представить как последовательность простых и понятных шагов. Процесс разделения большой и непонятной задачи на мелкие, управляемые компоненты называется декомпозицией. В контексте инженерии систем автоматизации — это, возможно, самый важный навык, отделяющий любительские проекты от профессиональных, надежных инсталляций.

Представьте, что вы получили задачу: «Сделать так, чтобы дом переходил в спящий режим, когда хозяева ложатся спать». Это типичное требование. Но что оно означает на практике? Какие устройства задействованы? Какие условия должны быть выполнены? Декомпозиция помогает ответить на эти вопросы, превращая расплывчатую идею в четкий алгоритм, готовый к реализации.

> 💡 Подсказка: Всегда начинайте с четкого описания логики на бумаге или в текстовом редакторе. Это сэкономит часы отладки в Node-RED. Формализация требований — первый и самый важный шаг.

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

• Входы (Inputs): Что запускает сценарий? (Нажатие кнопки, время, показания датчика).
• Выходы (Outputs): Что происходит в результате? (Свет выключается, отправляется уведомление).

Когда мы переходим к реализации, мы вскрываем этот «черный ящик» и работаем с ним как с «белым ящиком». Нас интересует внутренняя структура и последовательность действий. И здесь на первый план выходят три ключевых элемента любого сценария:

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

• Триггеры (Triggers): Это события, которые инициируют выполнение сценария. Триггером может быть физическое действие (нажатие кнопки), событие по расписанию (наступление 23:00), изменение состояния системы (срабатывание датчика движения) или команда от внешнего интерфейса (приложение, голосовой ассистент).
• Действия (Actions): Это конкретные операции, которые выполняет контроллер в ответ на триггер. Примеры: отправить команду на реле, изменить уставку термостата, послать сообщение в мессенджер, записать значение в базу данных.

Состояния (States) и Условия (Conditions): Это логические переменные, которые определяют, как именно должен выполняться сценарий. Например, сценарий «Никого нет» должен выключить свет, но только если* сейчас не используется режим «Уборка». Состояние «Режим уборки» является условием, влияющим на логику. Текущее значение этого состояния хранится в памяти контроллера.

Фундаментом для качественной декомпозиции служит формализованное Техническое Задание (ТЗ). Чем детальнее ТЗ, тем проще разбить задачу на блоки. Если у вас нет ТЗ от заказчика, составьте его самостоятельно. Задайте себе и «пользователю» уточняющие вопросы: «А что, если...?», «Как система должна повести себя в случае...?», «Какие устройства должны быть затронуты?». Этот диалог и есть первый этап декомпозиции.

---

Шаг 1: Выбор и детализация сценария «Я ухожу»

В качестве практического примера мы возьмем один из самых популярных и полезных комплексных сценариев — «Я ухожу». Этот сценарий демонстрирует, как одна простая команда от пользователя может запустить целый каскад действий, затрагивающих безопасность, комфорт и энергосбережение.

> 🔗 Связанный материал: Данный сценарий объединяет несколько концепций, которые мы рассматривали ранее. Рекомендуем освежить знания по управлению освещением (COURSE-01-M05-L01), климатом (COURSE-01-M05-L02) и режимами безопасности (COURSE-01-M05-L04).

Представим, что мы получили от «заказчика» (владельца квартиры) следующие первоначальные требования: «Я хочу, чтобы при уходе из дома я мог нажать одну кнопку, и дом сам обо всем позаботился».

Наша задача как инженера — превратить это пожелание в конкретный список операций. Мы проводим интервью с заказчиком и совместно формализуем требования.

Детализированные требования к сценарию «Я ухожу»

1. Способы активации (Триггеры):

* Нажатие физической кнопки, установленной у входной двери.

* Нажатие виртуальной кнопки «Я ухожу» в мобильном приложении (например, iRidium).

* Голосовая команда «Алиса, я ухожу».

2. Последовательность действий (Действия и Условия):

* Управление освещением:

* Немедленно выключить свет во всех помещениях (гостиная, спальня, кухня).

* Оставить включенным свет в прихожей на 1 минуту, чтобы пользователь мог комфортно обуться и выйти. По истечении 1 минуты — выключить.

* Климат-контроль:

* Все термостаты (в гостиной и спальне) перевести в энергосберегающий режим «Эко» с уставкой +18°C.

* Выключить систему вентиляции.

* Безопасность и проверка:

* Система должна проверить состояние всех оконных и дверных герконов.

Условие: Если* хотя бы одно окно или балконная дверь открыты, сценарий не должен переходить к постановке на охрану. Вместо этого система должна отправить пользователю тревожное push-уведомление в Telegram с текстом: `Внимание! Невозможно поставить на охрану. Открыто окно в спальне.`.

Условие: Если* все окна и двери закрыты, продолжить выполнение сценария.

* Активация охранных функций:

* Через 1.5 минуты (после того, как пользователь покинул помещение) активировать охранный режим.

* В этом режиме система включает мониторинг датчиков движения и активирует сценарий «Защита от протечек», который мы рассматривали ранее.

* Обратная связь:

* После успешного выполнения всех шагов и постановки на охрану, отправить пользователю подтверждающее push-уведомление: `Система успешно поставлена на охрану. Все в порядке.`.

Такая детализация дает нам четкую карту для дальнейшей работы. Мы определили все триггеры, действия и, что крайне важно, условную логику, которая делает сценарий «умным».

---

Шаг 2: Разделение сценария на логические блоки и триггеры

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

> ⚠️ Внимание: Остерегайтесь «состояния гонки» (race conditions). Например, при постановке на охрану необходимо предусмотреть задержку, чтобы пользователь успел покинуть помещение до активации датчиков движения. Используйте узел `delay` или стройте последовательные цепочки вызовов.

Давайте представим наш сценарий в виде псевдокода:

```

СЦЕНАРИЙ "Я УХОЖУ":

ТРИГГЕР:

Получено сообщение от (Кнопка_у_двери) ИЛИ (Кнопка_в_приложении) ИЛИ (Голосовая_команда)

ДЕЙСТВИЯ:

БЛОК "УПРАВЛЕНИЕ ОСВЕЩЕНИЕМ":

- Отправить команду ВЫКЛ на группу света "Гостиная"

- Отправить команду ВЫКЛ на группу света "Спальня"

- Отправить команду ВЫКЛ на группу света "Кухня"

- ЗАПУСТИТЬ ТАЙМЕР "Свет в прихожей" на 60 секунд.

- По истечении таймера: Отправить команду ВЫКЛ на группу света "Прихожая"

БЛОК "КЛИМАТ-КОНТРОЛЬ":

- Отправить команду (уставка=18.0) на Modbus-адрес "Термостат Гостиная"

- Отправить команду (уставка=18.0) на Modbus-адрес "Термостат Спальня"

- Отправить команду ВЫКЛ на реле "Система Вентиляции"

БЛОК "ПРОВЕРКА БЕЗОПАСНОСТИ" (условная логика):

- Проверить состояние "Геркон Окно Спальня" (из переменной контекста)

- Проверить состояние "Геркон Ок-но Гостиная" (из переменной контекста)

- Проверить состояние "Геркон Дверь Балкон" (из переменной контекста)

- ЕСЛИ (хотя бы один геркон == "ОТКРЫТО"):

- ВЫЗВАТЬ БЛОК "УВЕДОМЛЕНИЕ" с текстом "Тревога! Окно открыто."

- ПРЕРВАТЬ выполнение сценария.

- ИНАЧЕ:

- Продолжить выполнение.

БЛОК "ПОСТАНОВКА НА ОХРАНУ":

- Установить задержку 90 секунд (время на выход из помещения).

- По истечении задержки: