Полезные сценарии Zigbee: влажность, открытая дверь и потеря данных

Три примера для своего дома

Разберём три примера автоматизаций. Подставьте свои сущности, пороги и время ожидания. Сначала проверьте запись в журнале HA, затем подключайте уведомления.

ДатчикОтчёт или изменение
Источник в HAСостояние и доступность
УсловияДлительность, контекст, повторы
РезультатЖурнал, затем напоминание

Сначала определить источник. Наш YNDX-00529 остаётся в сети Станции Макс. Наблюдение на двух датчиках подтверждает ответ после короткого нажатия кнопки, но не причину периодической надписи «нет связи». Примеры ниже требуют сущности Home Assistant с понятными состояниями. Они не читают радиосеть Яндекса напрямую.

учебный сценарий · влажность

1. Напомнить о влажности без дребезга порога

Если отправлять сообщение при каждом новом значении около порога, один долгий эпизод превратится в десятки уведомлений. Нужны отдельные границы входа и возврата — гистерезис.

Событие: Помощник с гистерезисом включил режим повышенной влажности при значении условного sensor.zigbee_example_humidity выше 70%. Режим сохраняется 5 минут.
Условия: Источник доступен, значение числовое, известен его обычный интервал отчётности. Сценарий ещё не сообщил об этом эпизоде.
Действие: Одно напоминание проверить помещение. Новый эпизод разрешается только после возврата ниже 60%. Между 60% и 70% предыдущее состояние сохраняется.
Проверка: На тестовых значениях пройти 65 → 71 → 69 → 72 → 59 → 71. Убедиться, что колебания в середине не создают новый эпизод; после возврата и повторного входа уведомление снова разрешено.
Ограничение: Пороги здесь условные, а не норма для комнаты. Сценарий не управляет вентилятором, увлажнителем или клапаном. Доступность источника сама по себе не доказывает свежесть последнего измерения.

Гистерезис можно задать помощником Threshold в HA: для этого условного примера upper: 65 и hysteresis: 5 дают вход строго выше 70 и возврат строго ниже 60. Проверяйте доступность исходного сенсора отдельно, даже если используете помощник.

numeric_state реагирует на пересечение порога, а не на каждое следующее измерение выше него. Он сам по себе не хранит правило «повтор разрешён только ниже 60%». Не превращайте unknown или unavailable в 0 через float(0): это может ошибочно разрешить новый эпизод. Сначала проверьте наличие пригодного числового состояния. Числовой триггер · Типы и преобразование значений.

учебный сценарий · контактный датчик

2. Дверь открыта слишком долго — одно напоминание

Основа — фактическое состояние контактного датчика. Команда открыть дверь или замок не подтверждает, что дверь открылась: тот же принцип уже используется в сценарии наших ворот.

Событие: binary_sensor.zigbee_example_contact перешёл в on и остаётся так 5 минут. Сначала проверьте, что у вашей сущности on действительно означает «открыто».
Условия: Перед действием дверь всё ещё открыта и источник доступен. Выбран подходящий адресат; техническое напоминание не озвучивается всему дому.
Действие: Один раз сообщить «Дверь осталась открыта». Закрытие прекращает эпизод; следующее открытие начинает новый.
Проверка: Открыть и закрыть до истечения периода — сообщения нет. Оставить открытой дольше периода — одна запись. Закрыть и открыть снова — новая запись после полного ожидания.
Ограничение: Переход в unknown или unavailable не равен закрытой двери. Ожидание for теряется после перезапуска HA или перезагрузки автоматизаций; дверь, уже открытая при включении сценария, не обязана создать новый триггер.

Это простой вариант для бытового напоминания. Если нужно переживать перезапуски, отдельно проектируйте сохранённый срок и проверку состояния при старте. Повторные напоминания также требуют своей политики: например, не чаще выбранного интервала и только пока дверь открыта. Состояние и ожидание в HA · Что происходит с ожиданием после перезапуска.

учебный сценарий · диагностика

3. Данные пропали — попросить проверить источник

В HA unknown означает неизвестное состояние, unavailable — недоступную сущность. Это разные наблюдения, и ни одно само по себе не доказывает поломку радиосети. Причина может находиться в устройстве, координаторе, MQTT, интеграции или доступе к внешней системе. Значения состояний в HA.

Событие: Сущность перешла в unknown или unavailable и сохранила конкретное состояние 15 минут.
Условия: Настройка доступности источника соответствует поведению устройства. После периода ожидания состояние всё ещё совпадает с тем, которое запустило проверку.
Действие: Записать в журнал исходное состояние и предложение проверить источник. Причину не назначать автоматически.
Проверка: В отдельном тестовом HA воспроизвести проблемное состояние на условной сущности. Восстановить до 15 минут — записи нет. Оставить на весь период — запись есть. Затем проверить оба состояния отдельно.
Ограничение: Это техническая диагностика. Пример не является системой пожарной, охранной или аварийной сигнализации и не проверяет исправность всех устройств сети.

У спящего батарейного устройства интервал связи может быть большим. В Zigbee2MQTT контроль availability настраивается отдельно; правила активных и пассивных устройств отличаются. Наши дополнительные 15 минут отсчитываются после изменения состояния в HA, а не с последнего радиопакета. Не сокращайте сетевой таймаут до этого значения для всех датчиков. Как работает availability в Zigbee2MQTT.

Через хаб другой экосистемы HA получает доступные интеграции сведения: её unavailable может относиться к связи с хабом. В нашем наблюдении YNDX короткое нажатие кнопки обновляло показания. Поэтому диагностическое сообщение полезнее формулировать «проверьте источник», а не «датчик сломан». Следующий шаг — разбор типичных проблем Zigbee.

Скачиваемый пример: только запись в журнале

Откройте новую автоматизацию в YAML-редакторе. Ниже YAML 1.2 в JSON-совместимой записи: фигурные скобки и кавычки сохраняют типы значений. Замените условный binary_sensor.zigbee_example_contact во всех трёх местах на выбранную сущность. Нужны доступное действие logbook.log и проверенные правила доступности источника.

{
  "alias": "Zigbee — учебная диагностика состояния",
  "triggers": [
    {
      "trigger": "state",
      "entity_id": "binary_sensor.zigbee_example_contact",
      "to": "unavailable",
      "for": {"minutes": 15}
    },
    {
      "trigger": "state",
      "entity_id": "binary_sensor.zigbee_example_contact",
      "to": "unknown",
      "for": {"minutes": 15}
    }
  ],
  "conditions": [
    {
      "condition": "template",
      "value_template": "{{ trigger.to_state is not none and trigger.to_state.state in ['unknown', 'unavailable'] and states(trigger.entity_id) == trigger.to_state.state }}"
    }
  ],
  "actions": [
    {
      "action": "logbook.log",
      "data": {
        "name": "Учебная диагностика Zigbee",
        "entity_id": "binary_sensor.zigbee_example_contact",
        "message": "{{ trigger.entity_id }} остаётся в состоянии {{ trigger.to_state.state }} после периода ожидания. Проверьте источник данных; причина не установлена."
      }
    }
  ],
  "mode": "single"
}

Скачать учебный пример · YAML

Границы примера. Он создаёт только запись активности. Переход unknown → unavailable прекращает первое ожидание и начинает другое: это не единый таймер «нет пригодных данных». for сбрасывается при restart/reload. Пример не выполняет проверку при запуске HA и не шлёт периодические повторы.

Проверьте трассировку реального изменения состояния в тестовом контуре и запись «Учебная диагностика Zigbee». Если запись не видна, проверьте фильтры журнала для выбранной сущности. «Run actions» не проверяет триггер и условия верхнего уровня; здесь нужны данные trigger, поэтому такой запуск не заменяет тест перехода состояния. Действие записи активности · Проверка автоматизаций.

Связать сценарий с голосом, телефоном и экраном

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

В прототипе TV Floorplan уже отображались план и состояния дома. Для будущего экрана готовим понятные подписи: «дверь закрыта», «дверь открыта» и «нет данных». Правила показа ещё дорабатываются.

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

Если сценарий молчит — пройти путь данных

Типичные проблемы Zigbee · Размещение и стабильность сети · Как выбирать координатор · Бытовые сценарии и их статусы · Весь маршрут Zigbee

Проверить бытовое наблюдение

Напоминание о проветривании →Спад влажности в ванной →Температура морозильника и свежесть данных →

Датчик передал данные.Что полезного сделать дальше?