Датчик молчит. С чего начать проверку?

Сначала определите масштаб сбоя

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

Для Zigbee2MQTT цепочка включает устройство → Zigbee2MQTT → MQTT → HA → действие. У ZHA нет обязательного отдельного MQTT-перехода. В экосистеме Яндекса сначала сравните датчик и приложение владельца сети, затем доступное состояние в HA. Похожий порядок для остальных подсистем — в общей диагностике умного дома.

Неизменная температура ещё не означает потерянное сообщение

Датчик мог передать те же 23 °C. В HA last_changed отражает изменение значения, last_updated — значения или атрибутов. last_reported отражает запись состояния интеграцией, но не гарантирует новый радиопакет: некоторые интеграции не записывают повтор одинакового значения. Эти различия описаны в State and state object.

Поэтому сверяйте сообщение на стороне Zigbee-интеграции, а не только ровную линию графика. В Zigbee2MQTT можно включить last_seen; варианты и исходное выключенное состояние приведены в All settings. Даже новое сообщение устройства не обязательно содержит новое измерение температуры. Для климата отдельно нужны свежесть измерения и исправность связи.

Приложение может показать сохранённое значение после переподключения. В MQTT retained-сообщение доставляется новому подписчику из сохранённого состояния брокера; оно само по себе не доказывает, что датчик сейчас проснулся. Настройка retained для устройств описана в Devices and Groups.

Если молчит один датчик

1. Сохраните симптом. Запишите модель, питание, место, последнее известное сообщение и работающие соседние устройства. Длинное удержание кнопки может быть сбросом; используйте обычное действие из инструкции модели.
2. Проверьте питание. Старый процент батареи не является проверкой батареи под нагрузкой. Посмотрите контакты и тип элемента; при сомнении попробуйте заведомо исправный элемент, подходящий по инструкции.
3. Разбудите и проследите новое сообщение. Успешный ответ подтверждает обмен в этот момент. Он не доказывает, что все автоматические отчёты приходят вовремя.
4. Сравните место. Временно поставьте датчик в хорошие радиоусловия, оставив тот же координатор и настройки. Не меняйте канал в этом же опыте.
5. Сравните устройства. Если есть одинаковый исправный датчик, поменяйте их местами и повторите действие. Проблема места и проблема конкретного устройства дают разные направления проверки.

В нашем наблюдении YNDX-00529 после нажатия кнопки показания обновлялись. Причина периодической надписи offline этим не доказана. Новый материал даёт порядок наблюдения; он не объявляет новый тест датчиков или установленный координатор HA.

Когда «недоступно» появилось у спящего устройства

Посмотрите, включён ли контроль доступности и какое молчание он считает ошибкой. В Zigbee2MQTT этот контроль по умолчанию выключен. При включении правила различаются: активные устройства можно проверять запросом, пассивные батарейные — нельзя. Стандартные интервалы в текущей документации составляют 10 минут и 25 часов, но это настройки интеграции, а не обещанная частота отчётности любого датчика. Источник — Device Availability.

ZHA также имеет разные пороги для питаемых и батарейных устройств; для редко просыпающейся модели слишком короткий порог может создавать ложную тревогу. Проверьте свои настройки по Global options ZHA. Увеличение порога меняет момент предупреждения, но не чинит доставку сообщения. Не назначайте всем датчикам один «правильный» таймаут.

Если перестали отвечать многие устройства

В Zigbee2MQTT Health показывает соединение с MQTT, очередь и счётчики сообщений. Счётчики относятся к своему периоду работы; сравнивайте их до и после события. Рабочий процесс не доказывает качество каждого маршрута, но разрыв MQTT не стоит лечить перепривязкой датчиков.

Если владельцем сети остаётся Станция Макс, проблемы её приложения, интеграции и интернета исследуйте отдельно от радио. Доступное состояние в HA не показывает всю внутреннюю Zigbee-диагностику станции. Для своего адаптера порядок размещения и проверки ветвей есть в разборе стабильности сети.

Если Zigbee работает, а сценарий — нет

Вызовите реальное событие и откройте Trace автоматизации HA. Нет нового выполнения — проверьте включение автоматизации и её триггер. Выполнение остановилось на условии — посмотрите фактическое состояние, а не ожидаемое. Ошибка на действии — проверьте целевую сущность, параметры и доступность исполнителя. Этот порядок описан в Troubleshooting automations.

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

Перепривязка — после понятной причины

Если устройство ни разу не добавилось, отличайте отсутствие попытки соединения от ошибки interview. В первом случае проверьте разрешение присоединения и способ входа в него; во втором — питание, пробуждение во время опроса и страницу конкретной модели. Такая развилка есть в FAQ Zigbee2MQTT.

Уже подключённый датчик не нужно удалять при каждой надписи offline. Сначала сохраните наблюдения и резервную копию сети, затем выберите процедуру для своей модели и интеграции. Переезд с Яндекса в ZHA или Zigbee2MQTT создаёт другую сеть и требует отдельного плана. Выбор архитектуры и восстановления разобран в материале о координаторе.