--- title: "🔌 t610 — «реле котла выключилось»: как читать логи HA" aliases: - boiler controller off - реле котла выключилось - boiler_controller_power - как отличить выключение реле от перезапуска HA - Zigbee off артефакт tags: [family, tech, smarthome, t610, ha, diagnostics] created: 2026-09-17 updated: 2026-09-17 namespace: family type: tech related: - "[[family/how-to/home-automation]]" - "[[family/how-to/ha-automations]]" - "[[family/tech/t610-hw-metrics-addon]]" - "[[family/tech/zigbee-t610-z2m-i-zha]]" --- # 🔌 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` **одиночная запись**, перед ней ничего | **Реальное выключение** — команда или физическое | ### Признаки, по которым отличать (проверено на живых данных) 1. **`last_changed` == `last_updated` до микросекунды** → сущность **пересоздана** при загрузке координатора, а не переключена. ``` switch.boiler_controller_power state=on last_changed=2026-09-17T07:26:11.702420+00:00 last_updated=2026-09-17T07:26:11.702420+00:00 ← идентичны ``` 2. **Серия**: одновременно меняются `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 ``` 3. **Маркер старта рядом** — в логбуке запись с `entity_id = null` и `message = started` (`02:44:33.663`). Это **старт HA Core**. 4. **Лавина `unavailable`** по Modbus-заслонкам (34 сущности за 6 секунд, `07:24:14–07:24:20`) — отвал шины вентиляции, HA перезагружает интеграции. 5. **Состояние `LastState`** в `select.*_power_outage_memory` — реле **само возвращается** к прежнему состоянию после потери питания. Подтверждает: физического `off` не было. 6. **Напряжение живое**: `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. Как проверять (порядок) ```bash 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/?end_time=+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=` точечно | | 90 | ⚠️ **`history/period` обрезается границей хранения recorder** — окно в 10 дней вернуло **пусто** | Сужать окно (по 12 ч / по дню) и проверять число записей перед разбором | | 91 | 🔴 **Ретенция recorder ~2–3 дня.** Логбук глубже истории, но тоже не бесконечен | Для долгого расследования — свой лог на диске ([[family/tech/t610-hw-metrics-addon]]) | | 92 | 🔴 **Команда с `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`-карточка выглядит «выключено», либо событие не попало в логи. **Не подтверждено — ждёт уточнения.** --- ## 6. Связанные - [[family/how-to/home-automation]] — контур, ZONT/Modbus, §3.4 (носитель), §7 (питфоллы) - [[family/how-to/ha-automations]] — логика автоматизаций, §6 диагностика - [[family/tech/t610-hw-metrics-addon]] — свой лог метрик на диск (переживает зависание) - [[family/tech/zigbee-t610-z2m-i-zha]] — Zigbee: ZHA, координатор, поведение реле