Шаг 1: Проектирование графа состояний и приоритетов

Урок 1 · Сценарии умного дома: режимы, состояния, приоритеты · 30 мин · theory

Введение: Для чего нужен граф состояний на объекте?

Приступая к созданию комплексной системы автоматизации для финального проекта, мы сталкиваемся с главной инженерной задачей: как управлять десятками сценариев, которые могут конфликтовать друг с другом?

Базовые компоненты: краткое напоминание

Логика управления опирается на концепцию конечного автомата (FSM)

Разрешение конфликтов: Система приоритетов сценариев

азрешение конфликтов: Система приоритетов сценариев

Фундаментальную теорию проектирования графа состояний и иерархической системы приоритетов мы детально разбирали ранее в уроке «Базовые принципы FSM в умном доме» (Модуль 1, Урок 3). Чтобы исключить дублирование информации, в этом разделе мы полностью опускаем теоретическую базу и сосредотачиваемся исключительно на практическом применении для финального проекта: распределим все спроектированные вами узлы по конкретным рангам для корректного разрешения конфликтующих команд (например, когда режим `Отсутствие` выключает свет, а автоматика `ИмитацияПрисутствия` пытается его включить).

> 💡 Архитектурный паттерн: Менеджер Режимов

> В качестве центрального арбитра команд в нашем проекте выступит «Менеджер Режимов» — логический узел на базе Node-RED. Он аккумулирует текущее состояние графа и его приоритет, чтобы на лету решать: какие команды отправлять на исполнительные устройства, а какие — блокировать (применять логику переопределения — override).

Практическая шкала приоритетов для графа

В рамках финального проекта мы будем опираться на проверенную матрицу, где каждому состоянию (режиму или сценарию) присваивается конкретный вес от P0 (наивысший) до P4 (низший).

| :-------- | :----------------- | :---------------------------- | :----------------------------------------------------------------------------------------------------------------- |

| P0 | Критический | `Авария` / `Безопасность` | Защита от протечек, пожарная сигнализация. Блокирует все остальные сценарии. Принудительно закрывает клапаны, отключает вентиляцию. |

| P1 | Сервисный | `Обслуживание` / `Ручной ввод`| Режим для пусконаладки или ремонта. Автоматика Node-RED временно отключается, управление переходит в исключительно ручной режим. |

| P2 | Охрана | `Отсутствие` / `Охрана` | Режим, когда в доме никого нет. Берет на себя управление безопасностью, жесткой экономией энергии, блокирует локальные датчики движения. |

| P3 | Пользовательский| `Сценарий пользователя` | Явные команды через интерфейс панели или голосового ассистента: «Кино», «Ужин». Имеют приоритет (перехватывают управление) над фоновой автоматикой комфорта. |

Как «Менеджер Режимов» отрабатывает сценарии (Override)

На практике любая команда на исполнительное устройство не отправляется туда напрямую. Удобный и предсказуемый UX системы строится на том, что команда перехватывается «Менеджером Режимов», который сверяет приоритет инициатора с текущим активным режимом, блокирующим устройство:

Пропуск критических событий (P0): Активируется `Авария.Протечка`. Состояние отправляет команду на закрытие водяных клапанов и устанавливает флаг аппаратной блокировки этих узлов от любых команд уровней P1–P4. Если пользователь попытается открыть кран через интерфейс умного дома, команда низшего приоритета (P3) будет проигнорирована, а интерфейс покажет статус аварийной блокировки (это ключевой паттерн UX для предотвращения паники пользователя).

Техническое обслуживание (P1): Инженер активирует режим `Обслуживание`. "Менеджер Режимов" временно подавляет все сценарии комфорта (P4) и отключает реакцию на пользовательские моды (P3). Однако, если в процессе обслуживания случится протечка, команда от аварийного сценария (P0) пройдет успешно, так как логика строго подчиняется правилу `P0 > P1`.

Override автоматики явной командой (P3 vs P4): Пользователь включает сценарий `Квартира.Кино` (P3). Датчик движения (P4) в зоне кинотеатра фиксирует активность и пытается поднять яркость освещения. "Менеджер Режимов" сверяет ранги и отклоняет автоматическую команду, так как сценарий "Кино" имеет более высокий приоритет. Системы фонового комфорта жестко игнорируются (overridden) до тех пор, пока явно заданный сценарий не будет остановлен или сброшен по таймауту.

Разблокировка и возврат состояний (Fallback): Когда режим `Кино` деактивируется (пользователь выключает телевизор или нажимает «Стоп»), "Менеджер Режимов" снимает блокировки P3. Управление освещением плавно откатывается обратно к логике присутствия/комфорта (P4). Грамотный UX возврата гарантирует, что система «осмотрится»: если в комнате есть движение, свет автоматически вернется на базовый уровень яркости, а если нет — плавно выключится, не ослепляя пользователя.

Чек-лист: Распределение приоритетов вашего графа

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

[ ] Кажмому состоянию присвоен конкретный числовой уровень (P0–P4) в вашей таблице спецификаций или на визуальной схеме графа.
[ ] Выделено как минимум одно критическое/аварийное состояние (P0).
[ ] Предусмотрен сервисный режим для безопасного технического обслуживания (P1).
[ ] Размечены глобальные режимы отсутствия и постановки на охрану (P2).
[ ] Определены все явные пользовательские сценарии переопределения (Override), активируемые с панелей смартфона или голосом (P3).
[ ] Все фоновые датчики, климатические скрипты ПИД-регуляторов и базовые автоматизации отнесены к низшему уровню отработки (P4).
[ ] Проработана UX-логика возврата (Fallback): описано, что должно произойти при снятии приоритета P3 (доверяет ли система текущему состоянию датчиков P4 или применяет нейтральные настройки).

Практикум: Проектирование графа для типовой квартиры

В этом разделе мы опускаем подробное объяснение теории графа состояний и системы приоритетов (они детально разобраны в Уроке M01-L03 и Уроке M03-L03) и сразу переходим к практике применения этих концепций для финального проекта.

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

Шаг 1: Декомпозиция верхнеуровневых состояний

Первым делом выделим основные, взаимоисключающие состояния всего объекта. Это самые глобальные режимы, в которых может находиться квартира.

`AtHome` (Хозяева дома): Стандартный режим, когда в квартире есть люди. Активны сценарии комфорта.
`Away` (Хозяева отсутствуют): Режим экономии и безопасности. Активируется при уходе всех жильцов.
`Guests` (Гости): Специальный режим, который может изменять логику работы некоторых сценариев (например, не выключать свет в гостевом санузле так быстро).
`Service` (Сервисный режим): Режим для обслуживания системы. Вся автоматика отключена.
`Alarm` (Тревога): Аварийный режим (протечка, взлом, пожар). Имеет наивысший приоритет пути исполнения.

Шаг 2: Детализация (вложенные состояния)

Некоторые верхнеуровневые состояния слишком общие. Их можно и нужно детализировать. Например, состояние `AtHome` сильно зависит от времени суток.

`AtHome` подразделяется на:

`Morning` (Утро): С 07:00 до 09:00. Плавное включение света, открытие штор, тёплый свет.
`Day` (День): С 09:00 до 18:00. Максимальное использование естественного освещения, шторы открыты.
`Evening` (Вечер): С 18:00 до 2

Формализация и документирование графа состояний

Визуальной диаграммы недостаточно для сложного проекта. Чтобы превратить граф в техническое задание для программирования, его необходимо формализовать — представить в виде структурированной таблицы (матрицы состояний). Эта таблица станет основой для реализации логики и основным документом при сдаче-приёмке объекта.

> 💡 Опора на теорию: Математические основы графов состояний мы детально разбирали в Модуле 1 (Урок 3), а правила системы приоритетов и защиты состояний (override) — в Модуле 3 (Урок 3). Здесь мы опускаем повторное объяснение теории и фокусируемся исключительно на практической формализации графа для финального проекта и составлении документации.

Структура таблицы описания состояний

Каждая строка таблицы описывает один узел вашего графа. Для полноценного технического задания таблица должна включать следующие столбцы:

ID Состояния: Уникальный строковый идентификатор, который будет использоваться непосредственно в коде Node-RED (например, `Away` или `Security.Alarm`).
Наименование: Человекочитаемое название режима для документации и пользовательского интерфейса (например, «Хозяева отсутствуют»).
Приоритет: Числовой уровень приоритета (например, `P2`), определяющий иерархию. Он показывает, имеет ли данное состояние права на переопределение (override) логики более низких уровней.
Условия входа (События-триггеры): Исчерпывающий перечень всех событий (ручные действия пользователя, срабатывания датчиков, логические таймеры), которые активируют данное состояние.
Условия выхода (События-триггеры): Перечень событий, которые деактивируют данное состояние и отдают управление фоновому режиму (либо передают эстафету более приоритетному состоянию).
Задействованная логика/устройства: Описание того, что происходит в системе при активации. Какие устройства и подсистемы затрагиваются, какие команды отправляются оборудованию (освещение, климат, вода).

Пример заполнения таблицы для состояния «Хозяева отсутствуют»

| :--------------- | :---------------------- | :-------- | :--------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| `Away` | Хозяева отсутствуют | P2 | 1. Нажатие кнопки «Выключить всё» у выхода.
2. Постановка на охрану через приложение.
3. Уход последнего жильца (геолокация). | 1. Снятие с охраны.
2. Приход первого жильца (геолокация).
3. Сработка охранного датчика (переход в состояние `Alarm.Intrusion`).
4. Активация `Service` режима. | - Освещение: Выключить все группы света, кроме дежурных.
- Розетки: Отключить все неприоритетные розеточные группы (утюг, медиацентр).
- Климат: Перевести все зоны в режим «Эко» (+18°C зимой, +28°C летом).
- Шторы: Закрыть все шторы.
- Безопасность: Активировать сценарий «Имитация присутствия» после заката.
- Вода: Перекрыть вводные клапаны холодной и горячей воды (опционально). |

Отражение Override-логики в документации

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

Блокировки (Override ручного управления автоматикой): В столбце «Задействованная логика» явно прописывайте запрет на работу подчиненных сценариев. Если активен приоритет `P2` (Away), документируйте блокировку `P4` словами: «Заблокировать работу датчиков движения» или «Игнорировать фоновый контроль освещенности».

Перехват снизу-вверх (Escalation): В столбце «Условия выхода» обязательно перечисляйте события, которые вызывают экстренный переход в более высокий приоритет. Например, для режима `P2` укажите: «Переход в P1 (Авария) при поступлении сигнала от датчика протечки».

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

Итоги и следующие шаги

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