Описание задачи и требований к проекту

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

остановка задачи для финального проекта

Вы приступаете к финальному проекту курса, в котором вам предстоит применить все полученные знания на практике. Ваша задача — разработать и внедрить полнофункциональный сценарный слой для управления виртуальным объектом «умная квартира».

> 🔗 Опора на пройденный материал:

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

> * Архитектура сценарного слоя: его цели, задачи и место в системе автоматизации (см. урок COURSE-07-M01-L01 «Архитектура сценарной логики»).

> * Режимы, состояния и приоритеты: принципы проектирования глобальных состояний (`home`, `away`, `night`) и обработки конфликтов управления (см. урок COURSE-07-M01-L02 «Проектирование режимов и приоритетов»).

Для успешного выполнения проекта вам потребуется продемонстрировать следующие навыки и реализовать обязательные механизмы:

• Управление состоянием (State Management): Создать и поддерживать глобальные режимы объекта, которые переживают перезагрузку контроллера.
• Обработка событий: Реагировать на сигналы от разнородных устройств (датчиков, выключателей) и принимать на их основе логические решения.
• Работа с протоколами: Интегрировать данные, поступающие по MQTT, и формировать команды для имитации управления оборудованием.
• Создание отказоустойчивой логики и обработка инцидентов: Предусмотреть обработку приоритетов управления, а также реализовать минимум 3 аварийных реакции (например: протечка, задымление, потеря связи с критически важным устройством) для обеспечения предсказуемого поведения системы в любых условиях.
• Интеграция Журнала событий: Обязательная реализация логирования всех значимых изменений в системе (смена режимов, запуск сцен, срабатывание аварий). Журнал событий должен отражать полную картину работы сценарного слоя для удобства отладки и мониторинга.

Ниже приведены подробное описание объекта, а также функциональные и технические требования, которым должен соответствовать ваш проект.

Обзор объекта: виртуальная квартира

бзор объекта: виртуальная квартира

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

> 💡 Материалы для повторения:

> Поскольку вся интеграция построена на обмене сообщениями, рекомендуем опираться на пройденный материал. Если необходимо освежить принципы маршрутизации топиков и работы с брокером, вернитесь к урокам первого модуля: «Введение в экосистему умного дома» и «Основы работы с MQTT».

> 💡 Подсказка по проектированию:

> Рекомендуем сразу составить для себя карту всех MQTT-топиков и их назначения. Это можно сделать в виде таблицы в текстовом редакторе или электронной таблице. Такой подход значительно сэкономит время на последующих этапах разработки и отладки, так как вам не придется каждый раз искать нужный топик в документации.

Чек-лист подготовки к разработке

Прежде чем приступать к написанию логики в Node-RED, убедитесь, что у вас:

• [ ] Отражена схема помещений со всеми устройствами.
• [ ] Выделены статусные топики (`.../state`, `.../event`) — это ваши триггеры логики и текущие состояния.
• [ ] Сгруппированы управляющие топики (`.../set`) — адресаты команд вашей автоматизации.
• [ ] Зафиксирован формат полезной нагрузки (Payload) для каждого типа устройств: `boolean` (`true`/`false`), строковые команды (`OPEN`/`CLOSE`) или числовые значения уставок.
• [ ] Спроектирована логика записи в Журнал событий — топик или узел для логирования критических изменений и действий пользователя.
• [ ] Определены минимум 3 аварийные реакции (например, протечка, задымление, несанкционированное движение) и зафиксированы UX-правила перехвата управления (override) при этих событиях.

Журнал событий и аварийные реакции (Override UX)

В рамках финального проекта обязательным требованием является реализация Журнала событий и обработка минимум трех аварийных ситуаций.

Аварийные события имеют наивысший приоритет (override). Это означает, что при срабатывании аварии (например, протечке), система должна игнорировать любые ручные команды открытия крана с планшета или расписания, пока статус аварии не будет квитирован (сброшен).

То же касается задымления (блокировка вентиляции и открытие штор на путях эвакуации) или срабатывания охранного датчика движения в режиме «Никого нет дома».

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

Описание помещений

Объект представляет собой квартиру со следующей планировкой:

Прихожая: Входная дверь, основной свет, датчик движения, датчик дыма.

Гостиная: Основной свет, декоративная подсветка, шторы на окне, настенная KNX-панель управления, информационная панель (планшет).

Спальня: Основной свет, прикроватные светильники, шторы, настенная KNX-панель.

Кухня: Основной свет, подсветка рабочей зоны, датчик протечки под раковиной, датчик дыма.

Санузел: Основной свет, ночная дежурная подсветка, датчик движения, датчик протечки, главный кран перекрытия воды.

Перечень оборудования и архитектура взаимодействия

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

| Оборудование | Помещение | Протокол управления | MQTT-топик для управления/состояния |

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

| Основной свет (DALI) | Все | MQTT (DALI Gateway) | `hi/apt/room/light/main/set` и `.../state` |

| Декоративная подсветка (DALI) | Гостиная | MQTT (DALI Gateway) | `hi/apt/livingroom/light/ambient/set` и `.../state` |

| Шторы (RS-485 привод) | Гостиная, Спальня | MQTT (RS-485 Gateway)| `hi/apt/room/curtain/set` (`OPEN`, `CLOSE`, `STOP`) и `.../state` |

| Климат-контроль (FCU) | Гостиная, Спальня | MQTT (Modbus TCP GW)| `hi/apt/room/climate/temp/set` и `.../state` (температура) |

| | | | `hi/apt/room/climate/mode/set` и `.../state` (`comfort`, `eco`) |

| Датчик движения | Прихожая, Санузел | MQTT | `hi/apt/room/motion/state` (`true`/`false`) |

| Датчик протечки | Кухня, Санузел | MQTT | `hi/apt/room/leak/state` (`true`/`false`) |

| Датчик дыма (Пожарная) | Прихожая, Кухня | MQTT | `hi/apt/room/smoke/state` (`true`/`false`) |

| Главный кран воды | Санузел | MQTT | `hi/apt/water/valve/set` (`OPEN`/`CLOSE`) и `.../state` |

| KNX-панель | Гостиная, Спальня | MQTT (KNX/IP GW) | `hi/apt/room/switch/scene/event` (`night`, `movie`, etc.) |

Принципиальная схема взаимодействия:

  [Датчики MQTT] ----> |                              |
 [KNX выключатели] --> |           [CTRL:HI-Core]     | ---> [MQTT Брокер] ---> (Виртуальные устройства)
  [DALI светильники] -> |            (Node-RED)        |
  [RS-485 шторы] ----> |                              |
[Modbus TCP климат] --> |                              |

Как видно из схемы, ваша задача — реализовать в Node-RED логику, которая будет "слушать" топики состояний и событий (`.../state`, `.../event`) и публиковать команды в топики управления (`.../set`). Вся сложность заключается в том, чтобы эти команды были осмысленными, своевременными и корректно обрабатывали возможные коллизии (внедрение UX/override правил), учитывая общий режим работы квартиры.

Функциональные требования: что должна делать система?

ункциональные требования: что должна делать система?

> 💡 Напоминание: При реализации опирайтесь на базовую архитектуру топиков и принципы интеграции, которые мы заложили в первых модулях. В частности, используйте паттерны из уроков M01-L01 (Базовая архитектура) и M01-L02 (Принципы интеграции).

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

1. Режим «Хозяева дома»

• Триггер активации: Срабатывание датчика движения в прихожей (`hi/apt/hall/motion/state` = `true`), если текущий режим системы — «Никого нет».
• Действия:

1. Включить основной свет в прихожей на 100% яркости.

2. Установить режим климат-контроля в гостиной и спальне на «comfort».

3. Перевести систему в глобальное состояние `home`.

2. Режим «Никого нет»

• Триггер активации: Явная команда от пользователя (например, через интерфейс Node-RED Dashboard или специальную MQTT-команду `hi/apt/mode/set` = `away`).
• Действия:

1. Выключить всё освещение во всех помещениях.

2. Перевести климат-контроль во всех помещениях в режим «eco».

3. Закрыть все шторы.

4. Активировать режим охраны: система должна начать мониторить датчики движения. Любое срабатывание датчика движения в этом режиме должно генерировать аварийное уведомление.

5. Перевести систему в глобальное состояние `away`.

3. Сценарий «Ночь»

• Триггер активации: Команда с KNX-панели в спальне (`hi/apt/bedroom/switch/scene/event` = `night`) или явная команда `hi/apt/mode/set` = `night`.
• Действия:

1. Установить основной свет в спальне и гостиной на 10% яркости.

2. Выключить всю декоративную и дополнительную подсветку.

3. Выключить информационные панели (симулируется отправкой команды).

4. Активировать под-сценарий «Ночное посещение санузла»: при срабатывании датчика движения в санузле включать не основной свет, а только дежурную подсветку на 20% и выключать ее через 1 минуту после прекращения движения.

5. Перевести систему в глобальное состояние `night`.

4. Обработка приоритетов управления (Ручное переопределение / Override)

• Требование: Ручное управление с физического устройства всегда имеет более высокий приоритет, чем автоматический сценарий. С точки зрения UX, умный дом никогда не должен «спорить» с пользователем: если человек сделал явное действие глазами и руками, автоматика отступает.

Пример логики: Система находится в режиме «Никого нет» (весь свет выключен). Пользователь вручную включает свет в гостиной с KNX-панели. Система должна включить свет в гостиной, но не должна* переключать глобальный режим в «Хозяева дома». Остальная часть квартиры должна оставаться в состоянии «Никого нет». Сценарий авто-отключения этого света (если такой предусмотрен) должен получить статус `override` и быть временно заблокирован, пока пользователь снова не выключит его вручную.

5. Аварийные сценарии (Минимум 3 реакции)

• Требование: Система должна немедленно реагировать на критические события, игнорируя текущий режим и override-блокировки. В рамках финального проекта необходимо реализовать минимум 3 аварийных реакции.

Реакция 1: «Протечка»

• Триггер активации: Срабатывание любого из датчиков протечки (`hi/apt/kitchen/leak/state` = `true` или `hi/apt/bathroom/leak/state` = `true`).
• Действия:

1. Отправить команду на перекрытие главного водяного клапана.

2. Отправить высокоприоритетное push-уведомление (симулируется записью в лог и отправкой MQTT-сообщения) с указанием места протечки.

3. Опционально: Включить мигание основного света в прихожей (паттерн alert) для визуального оповещения.

Реакция 2: «Задымление»

• Триггер активации: Срабатывание датчика дыма (`hi/apt/kitchen/smoke/state` = `true`).
• Действия:

1. Немедленно отключить приточную вентиляцию и кондиционеры, чтобы предотвратить распространение дыма.

2. Включить основное освещение на 100% для облегчения эвакуации.

3. Сгенерировать критическое уведомление.

Реакция 3: «Экстремальный уровень CO2»

• Триггер активации: Уровень CO2 в спальне или гостиной превышает критическую норму (`hi/apt/bedroom/co2/value` > `1500`).
• Действия:

1. Принудительно включить приточную вентиляцию на максимальную мощность.

2. Отправить предупреждающее уведомление о снижении качества воздуха.

6. Журнал событий

• Требование: Обязательная интеграция механизма логирования. Все ключевые изменения в системе должны фиксироваться для последующего анализа, отладки и вывода пользователю.
• Что логировать:

1. Переключения глобальных режимов («Хозяева дома», «Никого нет», «Ночь»).

2. Все срабатывания аварийных сценариев (протечки, дым, CO2).

3. Активацию ручного переопределения (Override).

• Действия: Формировать события в виде JSON-объектов и отправлять их в выделенный топик (например, `hi/apt/log/system`), записывать в локальный файл через Node-RED или выводить в интерфейс Dashboard.

Форматы обмена данными (MQTT)

Для симуляции отправки команд в систему, вы будете использовать MQTT-сообщения. Например, команда на закрытие клапана выглядит так:

// Topic: hi/apt/water/valve/set
// Payload:
"CLOSE"

Аварийное уведомление и записи для Журнала событий могут быть представлены в виде структурированного JSON-сообщения в специальном топике:

// Topic: hi/apt/notifications/critical
// Payload:
{
  "event_id": "EVT-LEAK-001",
  "timestamp": 1678886400000,
  "type": "leak_detected",
  "location": "kitchen",
  "message": "Обнаружена протечка воды на кухне! Главный кран перекрыт.",
  "priority": "high"
}

Технические требования и ограничения

ехнические требования и ограничения

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

Среда реализации

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

Сохранение состояний (Персистентность)

Глобальные состояния (режимы) объекта, такие как `home`, `away`, `night`, должны храниться в персистентном контексте Node-RED. Это гарантирует, что система вернется в корректное актуальное состояние после перезагрузки контроллера, обновления потоков или сбоя питания.

> 🔗 Связанный материал:

> Принципы работы с персистентным контекстом, который сохраняет данные в файловой системе контроллера, детально разбирались в уроке COURSE-07-M01-L02 «Управление состояниями в Node-RED». Перед началом работы над проектом настоятельно рекомендуется повторить данный материал.

Протокол взаимодействия (MQTT)

Единственным протоколом для обмена данными между вашей логикой управления и виртуальными (или реальными) устройствами является MQTT.

• Вы должны создать потоки, которые подписываются на топики состояний (например, `.../state` или `.../status`).
• Управление устройствами осуществляется строго через публикацию сообщений в топики управления (`.../set` или `.../command`) в соответствии с предоставленной архитектурой адресного пространства.

Журнал событий и обработка аварий

В финальном проекте обязательно применение концепции приоритетов, отказоустойчивости и информирования пользователя:

• Журнал событий (Event Log): Проект должен включать интеграцию с механизмом ведения системного журнала. Все ключевые действия — смена глобальных режимов, ручные переопределения (override) работы автоматики, запуск комплексных сцен, а также фиксация системных сбоев — должны корректно логироваться.
• Аварийные реакции: Строгое требование — реализовать минимум 3 аварийных реакции (например, срабатывание датчика протечки, задымления, или критическое падение температуры). Обработка аварий должна иметь наивысший приоритет, блокировать или переопределять фоновые пользовательские сценарии (освещения, климата) до момента устранения (или квитирования) проблемы, формировать тревожные уведомления и обязательно фиксироваться в Журнале событий.

> 🔗 Связанный материал:

> Архитектурные паттерны работы с наивысшими приоритетами (включая аварийные переопределения оборудования) рассматривались в уроке COURSE-07-M01-L01 «Архитектура сценариев автоматизации».

Структура и качество кода

Организация потоков так же важна, как и их работоспособность.

• Субпотоки (Subflows): Повторяющиеся логические блоки должны быть инкапсулированы и вынесены в субпотоки. Кандидатами на вынесение являются:

* Логика отправки уведомлений и записи в Журнал событий (принимает на вход текст, категорию и приоритет).

* Парсеры и нормализаторы сложных сообщений (например, приведение статусов KNX к единому JSON-формату).

* Стандартизированные обработчики команд для однотипных устройств (например, субпоток «Управление диммируемым светом» с учетом плавности перехода).

• Комментарии и документация: Все сложные, ветвящиеся участки потоков, а также каждый созданный субпоток, должны быть снабжены узлами `Comment`. В них необходимо описать назначение блока, ожидаемые входные данные (`msg.payload` и другие свойства) и выходные результаты.
• Обработка ошибок (Error Handling): Обязательно использование узлов `Catch` для перехвата и логирования возможных исключений. Например, при получении невалидного JSON или неверного формата MQTT-сообщения система не должна «падать» или уходить в бесконечный цикл — ошибка должна корректно фиксироваться.

> ⚠️ Внимание:

> «Чистота» и структурированность вашего проекта в Node-RED является одним из ключевых критериев оценки. Проект, реализованный в виде одного гигантского, запутанного потока («спагетти»), получит более низкую оценку, даже если он выполняет все функциональные и аварийные требования. Рекомендуется распределять логику по разным вкладкам (Flows) в соответствии со смысловыми блоками (например: «Интеграции», «Режимы», «Освещение», «Климат», «Аварии и Логи»).

Резюме и следующие шаги

езюме и следующие шаги

В этом уроке мы заложили фундамент для нашего финального проекта. Мы сформулировали комплексную задачу по созданию сценарного слоя, который работает как центральный «мозг» умного дома и координирует работу всех подсистем, опираясь на принципы архитектуры и базовые требования, заложенные в первых модулях (материалы уроков M01-L01, M01-L02).

Основная задача проекта — создать в среде Node-RED логику для виртуальной квартиры, опираясь на четкие функциональные и технические требования. Мы рассмотрели список оборудования, протоколы взаимодействия (приведенные к MQTT) и архитектуру связи через контроллер. Были сформулированы:

• Обязательные к реализации режимы глобального состояния объекта (`Хозяева дома`, `Никого нет`, `Ночь`).
• Обязательная реализация минимум 3 аварийных реакций (например, `Протечка`, `Задымление`, `Потеря связи`), обрабатываемых с наивысшим приоритетом контроля.
• Интеграция системного Журнала событий для информативного логирования всех смен состояний, действий автоматики и тревог.
• Важнейшие правила обработки приоритетов ручного управления (UX/override), гарантирующие предсказуемое поведение системы при вмешательстве пользователя.

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

Чек-лист готовности к старту разработки

Перед тем как писать код, убедитесь, что вы:

• [ ] Четко понимаете общую архитектуру: как сообщения MQTT ходят между Node-RED (сценарным слоем) и виртуальным оборудованием.
• [ ] Ознакомились с картой топиков и форматами payload для каждого устройства.
• [ ] Понимаете бизнес-логику каждого из трех ключевых режимов и условия перехода между ними.
• [ ] Выбрали минимум 3 аварийных сценария для реализации и продумали структуру их записи в Журнал событий.
• [ ] Усвоили концепцию перехвата управления (override), когда ручное действие блокирует автоматику на заданное время.

Что дальше?

В следующем уроке мы перейдем от теории к практике и приступим к реализации функционала. Мы начнем с создания базовой структуры проекта в Node-RED, настроим персистентный контекст и создадим ядро нашей системы — машину состояний (State Machine).

Этот механизм позволит нам элегантно, предсказуемо и без состояния «гонки» (race conditions) управлять глобальными режимами квартиры. Мы соберем надежный скелет системы, на который в последующих практических шагах будем последовательно наслаивать конкретную логику автоматизаций, аварийных алгоритмов и логирования в системный журнал.