🔌 t610 — «реле котла выключилось»: как читать логи HA
Зачем эта дока. Alex 2026-09-17 спросил: «почему последний раз выключалась реле
адаптеров котлов». Разбор выявил класс ложных выводов, в который легко попасть
снова: HA пишет в логбук off и unavailable для Zigbee-реле когда связь с
координатором рвётся, а не когда реле физически щёлкнуло. Ниже — как это
разделять фактом, а не рассуждением.
1. Предмет разбора
Сущность
Что это
Устройство
switch.boiler_controller_power
розетка питания контроллера котла (NEO/Tuya, Zigbee)
котельная
switch.recirculation_pump
розетка циркуляции ГВС
—
switch.heating_cable_plug
розетка греющего кабеля ввода воды
котельная
switch.sauna
реле сауны
—
Все — Zigbee (ZHA), все сselect.*_power_outage_memory: LastState.
⚠️ Отдельного устройства «реле адаптеров котлов» в HA НЕТ. Адаптеры котлов
живут в ZONT (Modbus, slave 11–14) и как отдельные HA-сущности не выведены.
По контексту речь шла о switch.boiler_controller_power.
2. Время: таймзона — источник ошибок
Что
Значение
HA time_zone
Asia/Krasnoyarsk (+07)
Логбук / история HA
отдают UTC (+00:00)
Хост t610
TZ=Asia/Krasnoyarsk
Пересчёт: местное = UTC + 7. Примеры, на которых я ошибся:
UTC (в логе)
Местное
02:44:33
09:44:33
07:26:11
14:26:11
13:48:47
20:48:47
🔴Питфолл: Alex называет время по-местному. Лог отдаёт UTC. Пересчитывать
обязательно, и перепроверять у него, если расхождение с его словами — это не
«он ошибся», это чаще я пересчитал не туда.
3. 🔴 Главный вывод: off в логбуке ≠ выключение реле
Три разных события выглядят похоже, но означают разное:
Запись в логбуке
Что реально произошло
switch.X → offв серии со всеми Zigbee-реле сразу
Перезапуск интеграции / рестарт HA. HA записала состояние по умолчанию. Физически реле не щёлкало
switch.X → unavailable
Потеря связи с координатором. Состояние реле неизвестно
switch.X → offодиночная запись, перед ней ничего
Реальное выключение — команда или физическое
Признаки, по которым отличать (проверено на живых данных)
last_changed == last_updated до микросекунды → сущность пересоздана при
загрузке координатора, а не переключена.
Серия: одновременно меняются recirculation_pump, sauna, heating_cable_plug,
child_lock, firmware, identify, indicator_mode — это загрузка устройства, не щелчок.
02:44:33.033 recirculation_pump → off
02:44:40.946 sauna → off
02:44:42.104 heating_cable_plug → off
02:45:09.291 boiler_controller_power → on
Маркер старта рядом — в логбуке запись с entity_id = null и message = started
(02:44:33.663). Это старт HA Core.
Лавина unavailable по Modbus-заслонкам (34 сущности за 6 секунд,
07:24:14–07:24:20) — отвал шины вентиляции, HA перезагружает интеграции.
Состояние LastState в select.*_power_outage_memory — реле само возвращается
к прежнему состоянию после потери питания. Подтверждает: физического off не было.
Напряжение живое: sensor.boiler_controller_power_voltage = 218–220 V — питание на реле есть.
🔴Вывод по инциденту 2026-09-17:off по реле котла не зафиксировано ни разу.
В истории только on (06:09:01, 07:26:11 UTC). Всё, что выглядело как «выключилось» —
пересоздание сущности при рестарте ZHA/HA после отвала Modbus в 14:24 местного.
Само реле оставалось под питанием.
4. Как проверять (порядок)
B="https://mallexxx.duckdns.org";H_OPT="-H @/tmp/h1"# 0) ВРЕМЯ — всегда первым делом
curl -s -H @/tmp/h1 "$B/api/config"| jq -r '.time_zone'# Asia/Krasnoyarsk# 1) история с АТРИБУТАМИ (не minimal_response!) — видно last_changed vs last_updated
curl -s -H @/tmp/h1 \
"$B/api/history/period/2026-09-17T00:00:00+00:00?end_time=2026-09-17T23:59:59%2B00:00&filter_entity_id=switch.boiler_controller_power"\
| jq -r '.[] | .[] | "\(.last_updated) state=\(.state)"'# 2) логбук УЗКИМ окном вокруг подозреваемого момента
curl -s -H @/tmp/h1 \
"$B/api/logbook/2026-09-17T07:23:00+00:00?end_time=2026-09-17T07:27:00%2B00:00"\
| jq -r '.[] | select(.entity_id != null) | "\(.when) \(.entity_id) \(.state)"'# 3) фильтр по домену — логбук забит template-сводками, они вытесняют события# ... | jq -r '.[] | select(.entity_id|test("^(switch|light|automation)\\.")) | ...'# 4) артефакты перезапуска: пустой entity_id + message=started
curl -s -H @/tmp/h1 "$B/api/logbook/<start>?end_time=<end>+00:00"\
| jq -r '.[] | select(.entity_id == null) | "\(.when) msg=\(.message)"'
⚠️ Питфоллы инструментов разбора
#
Питфолл
Обход
87
🔴date -d — GNU, на macOS НЕТ (date: illegal option -- d)
BSD-форма: date -u -v-3d '+%Y-%m-%dT%H:%M:%S'. ⚠️ На t610 тоже BusyBox — там арифметика @$(( $(date +%s) - N ))
88
🔴history/periodсminimal_response не отдаёт last_updated — теряется ключевой признак (§3.1)
Убрать minimal_response/no_attributes, когда нужны метки времени
89
🔴Логбук забит template-сводками.sensor.*_summary пишутся каждые 5–10 с и вытесняют события реле из выдачи
Фильтровать по префиксу домена (select(.entity_id|test("^(switch|light|automation)\."))), либо тянуть ?entity=<id> точечно
90
⚠️history/period обрезается границей хранения recorder — окно в 10 дней вернуло пусто
Сужать окно (по 12 ч / по дню) и проверять число записей перед разбором
91
🔴Ретенция recorder ~2–3 дня. Логбук глубже истории, но тоже не бесконечен
🔴Команда сshutdown/reboot/restart в тексте блокируется хардлайном агента — включая grep -iE "...restart..."
Не писать эти слова в паттернах grep. Искать started, stopped, unavailable; либо искать через jq select
5. Что НЕ выяснено
Причина перезапуска HA Core в 09:44:33 местного — логбук видит факт старта,
причину не хранит. Пути: ha core logs, ha supervisor logs.
Причина отвала Modbus в 14:24 местного (34 заслонки → unavailable) — не копали.
Что видел Alex в UI в 18:52 (11:52 UTC) — в базе нет ни одной записи об
изменении реле котла в этом окне. В логбуке за 11:40–12:10 UTC только
light_stairs_left, кухонная вытяжка, свет кабинета и automation.greiushchii_kabel.
Возможные объяснения: UI-кэш, unavailable-карточка выглядит «выключено»,
либо событие не попало в логи. Не подтверждено — ждёт уточнения.
