Режим 'Отпуск': имитация присутствия, отключение потребителей, климат-контроль

Режим 'Отпуск': Концепция и архитектура

ежим 'Отпуск': Концепция и архитектура

Режим «Отпуск» — это глобальный сценарий для управления домом во время длительного отсутствия владельцев. Его реализация решает три ключевые практические задачи:

Безопасность (Имитация присутствия): Отпугивание злоумышленников за счет автоматического включения/выключения света, управления шторами и медиасистемами. Это создает иллюзию, что дома идет обычная жизнь.

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

Защита от аварий: Непрерывный мониторинг ключевых параметров (протечки воды, критическое падение температуры, задымление) и автоматическое реагирование на нештатные ситуации с немедленным уведомлением владельца в мессенджер.

Архитектура управления состоянием

Чтобы дом всегда «знал», находится ли он в режиме отпуска, критически важно иметь единый и надежный источник состояния. Оптимальный паттерн для этого, как неоднократно подчеркивалось в уроках по архитектуре управления состояниями, — использование MQTT-топика с флагом `retain`. Этот подход гарантирует персистентность (сохранение) состояния и его мгновенное восстановление после перезагрузки сервера умного дома.

Как это реализуется:

• Глобальный топик: `hi/modes/vacation`
• Активация режима: В топик отправляется сообщение `true` с `retain=true`.
• Деактивация режима: В топик отправляется сообщение `false` с `retain=true`.

В Node-RED узел `mqtt in` подписывается на этот топик и сразу записывает полученное значение в глобальный контекст. Это обеспечивает надежность хранения через MQTT в связке с моментальным доступом к переменной в любом потоке сценариев.

> 💡 Пример кода Node-RED (сохранение состояния в контекст):

>

> // Узел Function ставится сразу после "mqtt in" (hi/modes/vacation)

> let isVacationMode = (msg.payload === 'true' || msg.payload === true);
> 
> // Записываем в память
> global.set('vacation_mode', isVacationMode);
> 
> // Выводим статус под узлом для удобства отладки
> node.status({
>     fill: isVacationMode ? "red" : "green", 
>     shape: "dot", 
>     text: isVacationMode ? "ОТПУСК АКТИВЕН" : "Дома"
> });
> 
> return msg;
> 

Приоритет режима и блокировка логики (Overriding)

Режим «Отпуск» имеет наивысший приоритет над всеми остальными сценариями («День», «Ночь», «Гости», «Уборка»). Это означает, что при его активации базовые автоматизации должны блокироваться. Логика проверки статуса (gatekeeping) ставится в самом начале каждого зависимого потока.

Упрощенная схема блокировки:

[Триггер: Датчик движения] -> [Switch: global.get('vacation_mode') == false?] -> [Выполнить сценарий 'Свет']
                                                                      | (Иначе — отпуск активен)
                                                                      +-> [Ничего не делать]

⚠️ UX-нюанс локального управления (Override): Обратите внимание, что блокировать нужно именно автоматические триггеры (датчики, расписания). Если кто-то (например, домработница или родственник, пришедший полить цветы) нажмет физическую клавишу выключателя на стене — свет должен включиться, несмотря на активный режим отпуска. Это правило хорошего тона в UX умного дома: ручные физические действия всегда имеют локальный приоритет над программными запретами.

Способы активации и деактивации

Для комфортного взаимодействия с системой нужно предусмотреть несколько способов включения/выключения:

• Физическая кнопка/выключатель: Располагается у входной двери. Зачастую это «мастер-кнопка». Долгое нажатие при уходе активирует этот глобальный режим.
• Интерфейс пользователя (UI): Выделенный визуальный тумблер в приложении умного дома или на настенной планшетной панели.
• Чат-бот: Текстовая команда бота `/vacanon` / `/vacatoff` или inline-кнопка в мессенджере.

Геолокация + Триггер: Система видит, что смартфоны всех членов семьи покинули радиус, например, в 100 км от дома. Она не включает режим автоматически (слишком рискованно), но отправляет интерактивное push-уведомление администратору: "Похоже, вы уехали далеко. Включить режим «Отпуск»?"*.

🛠 Практическое мини-задание

Цель: Создать базовый механизм хранения состояния режима «Отпуск» по описанной архитектуре.

Создайте переключатели: Добавьте в рабочее пространство Node-RED два узла `inject`. Назовите их "Включить Отпуск" (payload `= true`, тип boolean) и "Выключить Отпуск" (payload `= false`).

Настройте MQTT-вывод: Соедините оба `inject` с узлом `mqtt out`. Настройте топик на `hi/modes/vacation`, обязательно установите флаг `Retain: true`.

Настройте MQTT-ввод: Добавьте узел `mqtt in`, подписанный на этот же топик.

Сохраните состояние: Подключите к нему узел `function` с кодом из блока `Пример кода Node-RED` (раздел выше).

Тестирование: Понажимайте `inject`. Убедитесь, что статус под узлом Function меняется. Перезапустите сервер Node-RED и проверьте, что после перезапуска узел моментально получает последнее состояние, сохраняя его в `global.get('vacation_mode')`.

Имитация присутствия: свет, шторы, медиа

митация присутствия: свет, шторы, медиа

Основная задача имитации — создать видимость естественной, немного хаотичной человеческой деятельности. Простая работа по жесткому расписанию (включать свет в 19:00, выключать в 23:00) легко распознается извне и неэффективна для защиты дома.

> 💡 Подсказка: Для максимальной реалистичности используйте не просто случайные интервалы, а логику, основанную на времени суток. Например, вечером активнее включайте свет в гостиной и на кухне, а поздно ночью — только в спальне и коридоре.

Логика работы: от расписания к умной случайности

Чтобы система вела себя как человек (а не как скрипт), процесс делится на независимые логические шаги:

Генерация "пульса" (расписание): Назначаем периоды, когда люди обычно активны (например, вечер с 18:00 до 23:30). В это время система регулярно "просыпается".

Принятие решения (вероятность): При каждом пробуждении система решает: делать ли что-то прямо сейчас?

Выбор действия (цель): Каким устройством управлять?

Внесение хаоса (задержка): Команда не выполняется мгновенно, а откладывается на случайное время (от 1 до 5 минут), чтобы не совпадать с ровными минутными тиками.

Реализация в Node-RED: Продвинутая рандомизация

Для создания реалистичного сценария мы будем использовать узел `cron-plus` для запуска основного окна активности и узел `function` для внедрения случайности.

Пример потока в Node-RED:

[cron-plus: 'Evening Pulse'] --> [function: 'Randomizer'] --> [delay: 'Random Wait'] --> [function: 'Build Command'] --> [Multi-protocol Output]

Шаг 1: Настройка `cron-plus` ("Пульс")

Настраиваем узел на периодический запуск — например, каждые 15 минут в вечернее время. Это триггер, который заставляет систему задуматься о следующем действии.

Шаг 2: Создание узла `function` "Randomizer"

Этот узел содержит логику вероятностей и формирует динамическую задержку `msg.delay`, которую встроенный узел задержки Node-RED прочитает автоматически.

// Список доступных для имитации устройств/групп с весовыми коэффициентами
const scenes = [
    { target: 'living_room_main_light', protocol: 'dali', chance: 0.6 },
    { target: 'kitchen_spots', protocol: 'knx', chance: 0.5 },
    { target: 'bedroom_blinds', protocol: 'modbus', chance: 0.2 },
    { target: 'media_tv_power', protocol: 'tcp', chance: 0.1 }
];

// 1. Решаем, будет ли вообще действие в этот "тик" таймера
// С вероятностью 70% что-то произойдет (Math.random > 0.3)
if (Math.random() > 0.3) {

    // 2. Выбираем первую подходящую сцену из списка, учитывая ее "шанс"
    const randomScene = scenes.filter(s => Math.random() < s.chance)[0];

    if (randomScene) {
        // Формируем полезную нагрузку
        msg.payload = {
            action: (Math.random() > 0.5) ? 'ON' : 'OFF', // Случайно включаем или выключаем
            target: randomScene.target,
            protocol: randomScene.protocol
        };

        // 3. Добавляем случайную задержку от 1 до 5 минут.
        // Переменную msg.delay (в миллисекундах) подхватит стандартный узел Delay.
        msg.delay = Math.floor(Math.random()  4  60 * 1000) + 60000;

        return msg;
    }
}

// Если ничего не выбрано, прерываем поток (возвращаем null)
return null;

Шаг 3: Динамическая задержка `delay`

После узла-функции устанавливается стандартный узел `delay`. В его настройках необходимо выбрать: Delay by > "override delay with msg.delay". Теперь сообщение повиснет в памяти на рассчитанное случайное количество секунд.

Шаг 4: Формирование команды и управление оборудованием

Узел "Build Command" преобразует абстрактные `target` и `action` в команды конкретных протоколов.

• Пример `msg.payload` для управления светильником DALI/KNX:

Команда отправляется на соответствующий узел KNX-шины или шлюз DALI.

    {

        "payload": true,
        "knx": {
            "dst": "1/1/10",
            "dpt": "1.001"
        }
    }
    

• Пример `msg.payload` для управления Zigbee-лампой через MQTT:

Сообщение отправляется в топик `zigbee2mqtt/living_room_light/set`. Мы напрямую берем сгенерированный `action`.

    {

        "payload": "ON" // Сгенерировано на Шаге 2
    }
    

Интеграция со шторами и медиа

Логика расширяется простым добавлением новых типов устройств в массив `scenes` в узле "Randomizer". Учитывайте физический смысл устройств в разное время суток, чтобы избежать абсурдных действий вроде открытия штор в 2 часа ночи.

• Управление шторами (RS-485/CAN): Могут быть добавлены действия "открыть на 30%" или "закрыть". Для этого в узел "Build Command" добавляется ветка (switch), которая конвертирует команду в специфичный запрос на привод штор (например, `modbus-write` или `can-out`).
• Управление медиа-системами: Включение телевизора — один из лучших способов имитировать присутствие за счет динамического свечения экрана в окне. Это делается отправкой TCP-команды на IP-адрес ТВ (Wake-on-LAN + команда по API) или замыканием умной розетки, к которой подключена ТВ-приставка.

⚠️ Важный UX-аспект: Обязательно добавьте проверку состояния — перед тем, как отправить команду на медиа или шторы, система должна убедиться, что глобальный виртуальный переключатель «Режим Отпуск» всё ещё активен. Иначе симуляция может сработать, когда хозяева только что вернулись домой.

---

🛠 Практическое мини-задание: Тестирование симулятора

Задача: Создайте и проверьте базовый рандомизатор присутствия в Node-RED без подключения к реальным лампам, используя только `Inject`, `Function`, `Delay` и `Debug`. Шаги (Чек-лист):

[ ] Добавьте узел `Inject` и настройте его на цикличный запуск раз в 10 секунд (это сымитирует "пульс" для ускоренного теста).

[ ] Подключите узел `Function` и вставьте код Randomizer из примера выше, изменив строку генерации задержки на от 2 до 5 секунд:

`msg.delay = Math.floor(Math.random() * 3000) + 2000;`

[ ] Добавьте стандартный узел `Delay`, в настройках выставив Action: override delay with msg.delay.

[ ] Выведите результат в узел `Debug` (отображать `msg.payload` и целиком объект `msg`).

Ожидаемый результат:

В панели Debug вы не будете получать сообщения строго каждые 10 секунд. Сообщения будут появляться с непредсказуемыми интервалами (включая пропуски, когда выпадает вероятность `< 0.3`). Объект `msg.payload` должен содержать случайные `action` ('ON'/'OFF') и `target` из списка. Убедитесь, что логика задержек работает безупречно.

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

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

Отключение второстепенных потребителей при отъезде решает две задачи: экономит электроэнергию и снижает риск возгорания от техники, оставленной под напряжением.

> ⚠️ Внимание: Всегда проводите тщательный аудит нагрузок перед настройкой сценариев. Ошибочное отключение критичной системы (например, циркуляционного насоса отопления зимой) может привести к замерзанию труб и дорогостоящему ремонту.

Шаг 1. Отбор и классификация нагрузок

Первый этап — составить карту нагрузок объекта и жестко разделить их на две группы. От этого зависит базовая логика работы сценария.

| Группа | Описание | Примеры | Действие в режиме 'Отпуск' |

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

| Критичные | Оборудование, отключение которого ведет к ущербу или потере данных. | Холодильники, отопление (котлы, насосы), серверы/роутеры, видеонаблюдение, охранная сигнализация. | Никогда не отключать! |

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

Переход от теории к практике: когда списки сформированы, мы переносим эту логику на контроллер для физического управления.

Шаг 2. Программная реализация отключения

Отключение реализуется через отправку команд на релейные модули. Рассмотрим базовые примеры формирования команд для популярных шин в среде Node-RED.

1. Управление через Modbus RTU

Предположим, группа розеток в гостиной подключена к модулю с Modbus RTU (`Unit ID = 1`), а реле №5 (`Coil 4`) отвечает за их питание.

В Node-RED создается узел `function`, который при активации режима "Отпуск" формирует payload для отключения:

// fc: 5 - Force Single Coil (запись в одно реле)
// unitid: 1 - Адрес Modbus-устройства
// address: 4 - Адрес реле (Coil #5 имеет адрес 4, так как нумерация с 0)
// value: 0 - Значение для записи (0 = OFF)

msg.payload = { 
    'value': 0, 
    'fc': 5, 
    'unitid': 1, 
    'address': 4 
};
return msg;

Далее это сообщение передается в стандартный узел `modbus-write`.

2. Управление через KNX

В KNX управление строится вокруг групповых адресов. Если на группу розеток выделен адрес `2/1/1`:

• При старте "Отпуска" Node-RED генерирует простое сообщение: `msg.payload = false`.
• Сообщение передается в узел `knx-out`, где в настройках указан целевой адрес `2/1/1` и тип данных `DPT 1.001` (вкл/выкл).

Шаг 3. Последовательное (каскадное) отключение

> ℹ️ Информация: Одновременное переключение десятка мощных реле или контакторов создает пиковый скачок тока (inrush current). Это вызывает просадку напряжения на блоке питания контроллера и может привести к аппаратной перезагрузке всей системы умного дома.

Чтобы система оставалась стабильной, выключайте группы по очереди. В Node-RED для реализации задержек можно использовать узлы `delay` или специализированные узлы `link-call` для вызова подпотоков с ожиданием.

Логика каскадного отключения:

[Режим: Отпуск ВКЛ] 
  -> [Откл: Розетки гостиной]
  -> (Пауза 500 мс)
  -> [Откл: Розетки спальни]
  -> (Пауза 500 мс)
  -> [Откл: Бойлер]
  -> [Лог: Все второстепенные нагрузки каскадно отключены]

Практическое мини-задание: Настройка каскадного отключения

Задача: Собрать в Node-RED безопасную цепочку поочередного выключения трех групп потребителей (Свет, Розетки, Теплый пол) для режима "Отпуск". Шаги реализации:

Вынесите на рабочее поле узел `inject` (эмуляция активации "Отпуска").

Создайте три узла `change` подряд. В каждом задайте правило: Set `msg.payload` to `false`.

Подключите к каждому узлу `change` узел `debug` (они будут эмулировать конечное реле Света, Розеток и Пола).

Между узлами `change` установите узлы `delay`, настроив каждую задержку ровно на `1 секунду`. Объедините все элементы в единую цепочку.

Ожидаемый результат (Тест-план):

Сделайте деплой потока и нажмите на кнопку узла `inject`.

В боковой панели отладки (Debug) с интервалом ровно в 1 секунду должны поочередно появиться три сообщения `false`. Это подтверждает, что команды управления будут уходить на промышленную шину каскадом с безопасной паузой, страхуя блок питания от перегрузки по току.

Климат-контроль и мониторинг инженерных систем

лимат-контроль и мониторинг инженерных систем

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

> 🔗 Связанный материал: Подробные схемы настройки интеграции с климатическим оборудованием по Modbus TCP и KNX рассматриваются в модуле `COURSE-05-M02: Интеграция с инженерными системами`.

Экономичный климатический режим

Вместо остановки систем, они переводятся в базовый поддерживающий режим:

• Зима (Отопление): Уставка температуры понижается до +15°C...+16°C. Это предотвращает промерзание стен и труб, но при этом сокращает расход газа или электричества на 30–40%.
• Лето (Охлаждение): Кондиционирование отключается полностью. Приточная вентиляция переводится в режим минимальной производительности (например, 10–20% мощности), чтобы обновлять воздух без лишних затрат энергии на его охлаждение/подогрев.
• Реализация: При активации режима "Отпуск" Node-RED массово отправляет новые уставки температуры (`setpoint`) в топики термостатов или регистры климатического оборудования.

// Пример полезной нагрузки Node-RED для массового изменения уставки
{
    "topic": "climate/thermostat_living_room/set_temperature",
    "payload": 15.0
}

Поддержание климата — лишь часть защиты. Во время пустования дома система автоматизации становится его главными "глазами и ушами", отслеживая потенциально опасные ситуации.

Мониторинг инженерных систем

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

• Датчики протечки воды: Устанавливаются в местах повышенного риска — под раковинами, ванными, стиральными посудомоечными машинами, в котельной. Могут использовать выход "сухой контакт" (базовое замыкание цепи) или цифровую шину (RS-485/KNX).
• Температурный мониторинг: Контроль температуры теплоносителя на подаче из котла. Если зимой температура в трубе падает ниже +30°C, это сигнал об аварийной остановке котла — дом может замерзнуть.
• Датчики дыма: Базовая противопожарная интеграция, позволяющая системе не только включить локальные сирены, но и отключить приточную вентиляцию (чтобы не раздувать огонь).

Логика автоматической защиты при протечке

Это самый критичный сценарий в режиме "Отпуск". Алгоритм должен работать строго локально, не полагаясь на облачные сервисы и наличие интернета. Подробный разбор механик срабатывания и типов запорной арматуры представлен в уроке COURSE-07-M07-L01: Автоматизация систем водоснабжения и защита от протечек.

Триггер: Узел `mqtt in` подписывается на изменения состояния датчиков протечки (например, `hi/sensors/leak_kitchen/state`).

Проверка: Узел `switch` фильтрует сообщения, пропуская дальше только значение `true` (или строку `"LEAK"`).

Немедленное действие (Аппаратный уровень): Контроллер моментально отправляет команду на электроприводы шаровых кранов (вводные вентили ХВС и ГВС). Подается команда на реле `modbus-write` или GPIO — подача воды физически перекрывается до выяснения обстоятельств.

Оповещение (Программный уровень): Одновременно узел `function` собирает текст тревоги, подставляя понятное описание зоны срабатывания:

    // Узел Function: Формирование тревожного сообщения

    let sensor_name = msg.topic.split("/")[2]; // например, leak_kitchen
    let location_map = {
        "leak_kitchen": "на кухне",
        "leak_bathroom": "в ванной"
    };
    let location = location_map[sensor_name] || "в неизвестной зоне";

    msg.payload = `🚨 ВНИМАНИЕ! ОБНАРУЖЕНА ПРОТЕЧКА ВОДЫ ${location}!\nПодача воды автоматически перекрыта. Требуется проверка.`;
    return msg;
    

Отправка и индикация: Сообщение пересылается через узел `telegram sender` владельцу. На локальных настенных панелях или в веб-интерфейсе статус дома меняется на красную индикацию "АВАРИЯ".

Такая связка "обнаружение -> аппаратное действие -> софтверное оповещение" гарантирует минимизацию ущерба за секунды.

Практика: Настройка и тестирование защиты

Мини-задание:

Соберите описанный выше алгоритм перекрытия воды в Node-RED:

Создайте триггер `mqtt in` от эмулятора датчика протечки.

Реализуйте ветвление узлом `switch`.

Разделите флоу: первый выход пустите на узел перекрытия крана (заглушка `debug` или реальный топик реле), а второй — на узел `function` для генерации текста по коду выше.

Чек-лист для тестирования (Test-plan аварийного сценария):

• [ ] Шаг 1: Замкните контакты физического датчика влажной салфеткой (или отправьте тестовый MQTT-топик с подтверждением протечки).
• [ ] Шаг 2 (Ожидаемый результат 1): Щелчок реле перекрытия вводного крана (или получение команды `ON` / `CLOSE` в топик крана) происходит моментально — задержка не более 1 секунды.
• [ ] Шаг 3 (Ожидаемый результат 2): В Telegram (или `debug` панель) приходит уведомление с корректно подставленной зоной ("на кухне", а не системное имя датчика).

[ ] Шаг 4 (Проверка UX): Убедитесь, что кнопка ручного открытия крана в интерфейсе панели временно заблокирована*. Она должна быть недоступна до тех пор, пока пользователь явно не нажмет кнопку «Сброс аварии» (Acknowledge/Reset). Это предотвращает удаленное случайное открытие крана, если вода всё ещё на полу.

Итоги и чек-лист внедрения

тоги и чек-лист внедрения

Режим «Отпуск» — это комплексная стратегия автоматизации, напрямую влияющая на безопасность и комфорт владельца. Его качественная реализация строится на трех китах:

Имитация присутствия (пассивная безопасность).

Экономия ресурсов (централизованное управление нагрузками и климатом).

Предотвращение аварий (активный мониторинг протечек и возгораний).

Чек-лист для инженера перед сдачей объекта

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

• [ ] Сохранение состояния: Управление режимом реализовано через MQTT-топик с флагом `retain: true`? (Режим должен гарантированно «выживать» после перезагрузки контроллера).
• [ ] Жесткие приоритеты: Режим «Отпуск» корректно блокирует все второстепенные сценарии (включение света по движению, локальные дневные/ночные режимы, расписания климата)?
• [ ] Классификация нагрузок: Разделен ли электрощит на отключаемые и неотключаемые (холодильник, сервер, котел, роутер) линии? Согласован ли этот список с заказчиком?
• [ ] Реализм имитации: Сценарий присутствия выглядит естественно? Используются ли случайные интервалы (randomize ±15-30 минут) вместо точного включения света изо дня в день в 19:00?

[ ] Возврат климата: При деактивации режима система климат-контроля не просто «включается», а восстанавливает предыдущие* комфортные уставки (например, возвращается с +15°C на +22°C)?

• [ ] Аварийные сценарии: Вводные краны перекрываются локально при протечке, даже если отпал интернет? Приходит ли push-уведомление с высоким (Critical) приоритетом?

Пользовательский опыт (UX) и временные переопределения (Overrides)

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

> 💡 UX-совет: Исключения и визит доверенных лиц

> В реальной жизни во время долгого отпуска в дом может прийти сосед (полить цветы) или клининг. Предусмотрите вариант временного переопределения (Override). Например, при вводе сервисного PIN-кода на панели или по нажатию скрытой кнопки режим «Отпуск» ставится на паузу на 2 часа: включается дежурный свет, блокируется сирена. По истечении таймера дом автоматически возвращается в режим «Отпуск».

Практическое мини-задание: Тестовый прогон

Никогда не передавайте объект заказчику без полноценной симуляции работы режима. Выполните следующий план-минимум и сверьтесь с ожидаемыми результатами:

Шаг 1. Активация режима Действие:* Включите тумблер «Отпуск» в приложении. Ожидаемый результат:* Отключаются контакторы неприоритетных розеток, выключается весь свет и медиа, кондиционеры переводятся в `OFF`, отопление снижается до +15°C (зимой), приходит уведомление «Режим Отпуск активирован». Шаг 2. Проверка приоритетов (Изоляция) Действие:* Пройдите перед датчиками движения в гостиной и коридоре. Ожидаемый результат:* Свет не включается. Локальная автоматика игнорирует движение, так как приоритет режима «Отпуск» выше. (Опционально: в лог или Telegram падает тихое уведомление о фиксации движения). Шаг 3. Симуляция вечера (Имитация) Действие:* Переведите системное время на контроллере вперед (на часы заката) или запустите скрипт тестирования имитации. Ожидаемый результат:* Шторы закрываются, в заданных комнатах включается свет с настроенной случайной задержкой. Шаг 4. Деактивация (Восстановление) Действие:* Выключите режим «Отпуск». Ожидаемый результат:* Сразу восстанавливается комфортная температура, включаются контакторы розеток, восстанавливается штатная реакция на датчики движения.

Что дальше

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