Перейти к содержанию

Главная / Сценарии

событие → действие → результат

Что делает дом
в обычной жизни

Кто пришёл к калитке, куда отправить пылесос и что проверить у датчика. У каждой задачи — понятный запуск, условия и результат, который можно увидеть.

3 кейса · 1 наблюдение · Планы и прототипы: 5

Показано 9 из 9 сценариев

Кейс · работает в описанной схеме

Человек у калитки — снимок в Telegram и камера на ТВ

Уведомление помогает увидеть, кто пришёл, а короткий показ на телевизоре даёт контекст без поиска камеры в приложении.

Событие
Frigate обнаруживает человека на выбранной камере у калитки.
Условие
Событие дошло через MQTT до Home Assistant и прошло условия соответствующего сценария.
Действие
Home Assistant отправляет снимок напрямую в Telegram. Поток калитки показывается на ТВ примерно на 30 секунд.
Как проверить
Сверить время одного события в Frigate, новое сообщение со снимком и фактический показ нужной камеры на телевизоре.

Граница сценария: NVR параллельно пишет полный архив восьми камер. Frigate анализирует только выбранные прямые RTSP-потоки.

Рабочая схема описана в кейсе.

FrigateMQTTHome AssistantTelegramTVкалиткакамера
Реальная схема камер и событий →

Кейс · работает в описанной схеме

Ворота открылись — сохранить минутный клип

Короткий событийный файл позволяет быстро найти открытие ворот в дополнение к непрерывному архиву регистратора.

Событие
Подтверждённое изменение положения ворот, а не только команда «открыть».
Условие
Сценарий связан с реальным состоянием ворот и соответствующей камерой D4.
Действие
Архиватор сохраняет ролик gates примерно на 60 секунд. Непрерывная запись NVR остаётся отдельной веткой.
Как проверить
При повторной проверке найти файл по времени открытия и просмотреть событие. При исходной проверке MP4 имел фактическую длительность 58,85 секунды.

Граница сценария: Пересекающийся запуск может попасть в уже записываемый клип: дедупликация не создаёт второй параллельный ролик.

Исходная проверка событийного архива описана в кейсе.

воротавидеоархивFrigateHome Assistant60 секундHDD
Проверка событийного архива →

Кейс · работает в описанной схеме

Убрать одну комнату — три понятных сценария Roborock

Для комнаты Артёма, прихожей и кухни есть отдельные сценарии Home Assistant. Выбирать комнату каждый раз в приложении не нужно.

Событие
Ручной запуск сценария нужной комнаты в Home Assistant.
Условие
В пылесосе сохранена карта комнат; используется действующий облачный контур Mi Home.
Действие
Roborock запускает уборку выбранной комнаты: комнаты Артёма, прихожей или кухни.
Как проверить
Убедиться, что пылесос поехал в выбранную комнату. После пересоздания карты или изменения комнат повторно проверить каждый сценарий.

Граница сценария: Это облачная схема Mi Home. Точная модель пылесоса и универсальные идентификаторы комнат в кейсе не публикуются; автономность без интернета не подтверждена.

Три комнаты проверены в описанной схеме.

RoborockMi HomeоблакоуборкакомнатыпылесосHome Assistant
История покомнатной уборки →

Наблюдение · ручная проверка

Датчик «без связи» — проверить данные после кнопки

Это ручное наблюдение, а не готовая автоматизация: датчик YNDX-00529 может отвечать после пробуждения, хотя Яндекс считает его недоступным.

Повод для проверки
Приложение Яндекса сообщает «нет связи», а экран датчика продолжает работать.
Что учесть
Симптом записан до изменений. Датчик остаётся в сети Станции Макс; отдельный Zigbee-координатор HA здесь не используется.
Ручной шаг
Коротко нажать кнопку без сброса и посмотреть, пришли ли новые температура и влажность.
Что записать
Записать время и результат. Если показания обновились, обмен состоялся в этот момент; затем наблюдать повторяемость симптома.

Граница сценария: Один ответ после кнопки не доказывает постоянную стабильность сети и не устанавливает причину редких отчётов.

Наблюдение воспроизведено на двух датчиках.

YNDX-00529ЯндексZigbeeСтанция Максдатчикofflineнет связитемпература
Разбор ручной проверки YNDX →

Прототип · разработка продолжается

Экран дома на ТВ — довести прототип до сценария

План, температуры и базовые состояния уже выводились на реальный телевизор. Автоматический показ камер и возврат экрана ещё разрабатываются.

Запуск и замысел
В прототипе — подача локального медиапотока на ТВ. Будущий запуск по событию Home Assistant ещё нужно завершить.
Что потребуется
Есть план дома, данные HA и рендерер. Читаемость, итоговый состав состояний и правила временного показа требуют доводки.
Шаг разработки
Работающий прототип показывает план и данные. Планируемое продолжение — временно вывести нужную камеру, затем вернуть экран или обычный просмотр.
Критерий готовности
Принять финальный экран на реальном ТВ: читаемость с дивана, соответствие состояний HA, показ нужной камеры и предсказуемый возврат после события.

Граница сценария: Скриншоты в дневнике показывают промежуточный результат. Финальная автоматика не считается готовой.

Дневник разработки: правила показа и окончательный экран ещё дорабатываются.

TVтелевизорFloorplanдашбордплан домакамерапрототипHome Assistant
Дневник TV Floorplan →

План · ещё предстоит проверить

Пропало питание — сохранить управление и завершить работу

План резервирования начинается с функций: сеть и Home Assistant важнее случайного набора розеток рядом с ИБП.

Запуск и замысел
Предполагаемый запуск: подтверждённый переход резервного питания на батарею.
Что потребуется
Сначала нужны установленное резервирование, измеренная нагрузка и проверенное получение статуса питания. Финального замера автономии пока нет.
Шаг разработки
Планируется переждать короткий провал, а при длительном отключении корректно остановить гости и хост. Связь рассматривается отдельно от тяжёлой видеоаналитики.
Критерий готовности
После установки провести контролируемый тест: измерить время на своей нагрузке, проверить порядок остановки и полное восстановление сети, HA, MQTT и видео.

Граница сценария: Это проектный контур. Выбор кандидата ИБП и расчёт не подтверждают время автономии или готовую автоматизацию выключения.

План проверки резервного питания; результаты blackout-теста ещё не опубликованы.

UPSИБПпитаниерезервсерверProxmoxHome Assistantсеть
План резервного питания →

План · ещё предстоит проверить

Влажность долго высокая — напомнить о проветривании

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

Запуск и замысел
Предполагаемый запуск: помощник с гистерезисом включился при влажности выше 70% и сохраняет режим 5 минут.
Что потребуется
Нужны проверенный источник влажности в HA, доступное числовое измерение и его обычный интервал отчётности. Пороги условные.
Шаг разработки
Сначала проверить запись в журнале, затем подключить нужное уведомление. Новый эпизод разрешается после возврата ниже 60%.
Критерий готовности
Пройти 65 → 71 → 69 → 72 → 59 → 71; проверить один эпизод, повтор после возврата, недоступность и перезапуск HA.

Граница сценария: Это пример, ещё не испытанный в нашем доме. Между 60% и 70% режим сохраняется: 5 минут относятся к состоянию помощника. Unknown/unavailable не заменяются нулём; for сбрасывается при перезапуске.

Пример для настройки в своей системе.

ZigbeeвлажностьклиматHome Assistantпример
Условия и проверки учебного сценария →

План · ещё предстоит проверить

Дверь долго открыта — одно понятное напоминание

Учебный план: состояние контакта и длительность открытия определяют повод для сообщения.

Запуск и замысел
Предполагаемый запуск: подтверждённое on выбранного контакта сохраняется дольше нужного интервала.
Что потребуется
Нужно проверить, какое состояние конкретной сущности означает открытую дверь, и исключить unavailable/unknown.
Шаг разработки
Сначала записать событие в журнале; после проверки подобрать ненавязчивое напоминание и правило повторов.
Критерий готовности
Открыть и закрыть дверь, выдержать интервал, проверить возврат и отдельное поведение после перезапуска HA.

Граница сценария: План не является охранной системой. Датчик, интеграция и питание могут отказать; for не переживает перезапуск или reload.

Пример для настройки в своей системе.

ZigbeeдверьконтактнапоминаниеHome Assistantпример
Условия и проверки учебного сценария →

План · ещё предстоит проверить

Датчик недоступен — оставить повод для диагностики

Учебный пример пишет в журнал HA после длительного unknown или unavailable, сохраняя различие состояний.

Запуск и замысел
Сущность контакта переходит в unknown либо unavailable и остаётся там 15 минут.
Что потребуется
Нужны корректная модель доступности и интервал для конкретного датчика. Спящий узел не должен объявляться аварийным только за тишину.
Шаг разработки
После адаптации примера записать состояние в журнал без управления устройствами и внешней отправки.
Критерий готовности
Проверить длительное состояние, восстановление до 15 минут, переход между unknown и unavailable, restart/reload.

Граница сценария: 15 минут — условное ожидание уже возникшего статуса, не правило обнаружения обрыва радио. Пример не запущен в нашем доме и не заменяет аварийную сигнализацию.

Пример для настройки в своей системе.

Zigbeeofflineнет связидиагностикаHome Assistantпример
Условия и проверки учебного сценария →