Files
obsidian-vault/family/tech/t610-relay-off-log-forensics.md
T

170 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
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 1114) и как отдельные 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:1407:24:20`) — отвал шины вентиляции, HA перезагружает интеграции.
5. **Состояние `LastState`** в `select.*_power_outage_memory` — реле **само возвращается**
к прежнему состоянию после потери питания. Подтверждает: физического `off` не было.
6. **Напряжение живое**: `sensor.boiler_controller_power_voltage = 218220 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/<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 дня.** Логбук глубже истории, но тоже не бесконечен | Для долгого расследования — свой лог на диске ([[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:4012: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, координатор, поведение реле