[2026-09-16] eagle: family/how-to/ha-automations.md family/how-to/home-automation.md family/plans/t610-zigbee-ids-battery-freshsensors-modbus.md family/tech/zigbee-t610-z2m-i-zha.md
This commit is contained in:
Alexey Martemyanov
@@ -2,10 +2,10 @@
|
||||
title: "Zigbee на t610 — ZHA (справочник)"
|
||||
created: '2026-09-15'
|
||||
updated: 2026-09-16
|
||||
note: "ночь: вычищены 185 призраков Z2M из архива реестра deleted_entities 360→175; план этажей починен — ссылка на снесённого light.smart_light_stairs_l1 → light.light_stairs_left; H2000_PRO °F→°C сбросом sensor.private override; 🍳 kitchen_hood — ZHA отдаёт как 3 × light.*; ✅ выведен в 🌀 fan.kitchen_hood Template-хелпером → [[family/tech/kitchen-hood-fan-template]]"
|
||||
note: "ночь: вычищены 185 призраков Z2M из архива реестра deleted_entities 360→175; план этажей починен — ссылка на снесённого light.smart_light_stairs_l1 → light.light_stairs_left; H2000_PRO °F→°C сбросом sensor.private override; 🍳 kitchen_hood — ZHA отдаёт как 3 × light.*; ✅ выведен в 🌀 fan.kitchen_hood Template-хелпером → [[family/tech/kitchen-hood-fan-template]]; вечер: §13.5 — трассировки HA только по WebSocket, дрожание радара душевой, floor `fading_time` = 2 с, проверка удержания реле"
|
||||
type: tech
|
||||
namespace: family
|
||||
status: "🟢 РАБОТАЕТ. ZHA: 24 записи (23 устройства + координатор), unavailable = 0. Все устройства с читаемыми ID в едином виде, все в зонах. 24 автоматизации: 23 on, 1 off намеренно. Bridge: 9 Zigbee-температур отдаются ZONT'у (slave 100–112). Призраки Z2M в архиве реестра вычищены; план этажей и H2000_PRO исправлены. unavailable всего 8 — вентиляция AT2 + todo.shopping_list (намеренно)."
|
||||
status: "🟢 РАБОТАЕТ. ZHA: 24 записи (23 устройства + координатор), unavailable = 0. Все устройства с читаемыми ID в едином виде, все в зонах. 25 автоматизаций: 24 on, 1 off намеренно (обновлено 2026-09-16 вечер). Bridge: 9 Zigbee-температур отдаются ZONT'у (slave 100–112). Призраки Z2M в архиве реестра вычищены; план этажей и H2000_PRO исправлены. unavailable всего 8 — вентиляция AT2 + todo.shopping_list (намеренно). 🔴 Радар душевой `shower_2_presence_sensor` дрожит (`on`/`off` сериями, вплоть до `on` на 1.8 с) — усилено снижением `fading_time` до 2 с; см. [[family/how-to/ha-automations]] §4.6.2"
|
||||
tags:
|
||||
- t610
|
||||
- haos
|
||||
@@ -413,12 +413,12 @@ curl -s -H "$HDR" http://supervisor/backups | jq
|
||||
| 33 | 🔴 **`fading_time` радара `_TZE204_qasjif9e` (TS0601) не опускается ниже 2 с** | HA показывает `min: 1` и отдаёт `state: 1.0` в ответе `number.set_value`, но сущность откатывается к `2.0`. Проверено: `1.0` → `2.0`, `1.5` → `2.0`, `2.5` → `2.5`. Прошивка молча игнорирует < 2. **Всегда читать обратно** |
|
||||
| 34 | 🔴 **`condition:` внутри `sequence:` НЕ отменяет остальные `actions`** | Прерывает только свою `sequence`; управление возвращается в родительский список `actions` и выполняет следующие шаги. `light.turn_on` **после** `choose` выполнится ВСЕГДА, даже если проверка вернула `false`. Действие обязано быть **внутри** ветки, после проверки. Доказано трассировкой: `sequence/1/entity_id/0 → {"result": false}` и через 1 мс `action/1 → light.turn_on`. Разбор: [[family/how-to/ha-automations]] §4.4 |
|
||||
| 35 | 🔴 **Трассировки автоматизаций — ТОЛЬКО WebSocket** | REST (`/api/trace/...`) → 404. Команды `trace/list` + `trace/get`, домен `automation`. 🔴 `item_id` = **внутренний ID** (`1771997851260`), **НЕ** `entity_id`. `.storage/trace.saved_traces` хранит только сохранённые вручную через UI; живые — в памяти. 🧰 `~/tmp-t610/trace_dump.py` (Mac; на t610 python3 НЕТ). **Читать трассировку ДО перебора гипотез** |
|
||||
| 34 | 🔴 **Фиксированный `delay` ненадёжен для «дождаться, пока датчик отпустит»** | Момент проверки плавает: замер `call → свет on` при `delay: 5` дал **6.1 с** (≈1.1 с накладных на диспетчеризацию). Окно отпускания радара тоже плавает (замерено 3.19–3.59 с). Таймер `2 → 3 → 5 с` в ветке `lux` душевой **не сработал ни разу**. Использовать `wait_for_trigger` по событию: `- {platform: state, entity_id: ..., to: "off"}` + `timeout` + `continue_on_timeout: true` + `{{ wait.trigger is none }}`. Разбор: [[family/how-to/ha-automations]] §4.5 |
|
||||
| 35 | 🔴 **`wait_for_trigger` с взаимоисключающими условиями — свет не включится никогда** | Ошибка проектирования: `wait_for_trigger` на `from: on, to: off` + следующее условие `presence == on` требует presence одновременно `off` и `on`. Проверять выполнимость цепочки **до** заливки. ⚠️ Семантика: `wait.completed` = `true` при срабатывании, `false` при таймауте → «дождаться ухода» = `{{ wait.trigger is none }}`, «дождаться возврата» = `{{ wait.completed }}` |
|
||||
| 36 | 🔴 **`logbook` без поля `message` не различает ветки `choose`** | Версию по `presence` и по `lux` не отличить. Читать с `message`: `jq -r '.[] \| "\(.when) \(.state) \(.message // "")"'` → видно `triggered by state of <entity>` (какая именно ветка). Диагностика ложных включений: сопоставить три ряда `history/period` (`presence` + `illuminance` + `light`) с логбуком обеих автоматизаций в одном окне |
|
||||
| 37 | ⚠️ **`condition: device / is_occupied` может не отражать свежий `state`** | При проверке присутствия сразу после сброса радара device-условие давало «занято», тогда как `condition: state` на той же сущности корректно читала `off`. Для проверок по свежему состоянию использовать `condition: state`, не device-условие |
|
||||
| 38 | 🔴 **`wait_for_trigger` + `wait.completed` в `choose` требует `mode: restart`** | В сценарии «ждать возврат присутствия N секунд, иначе гасить»: `wait_for_trigger` с `timeout` + `continue_on_timeout: true`, затем `condition: template` с `value_template: "{{ wait.completed }}"` внутри `choose.sequence`. При `mode: single` повторный триггер игнорируется и ожидание НЕ перезапускается → старый таймер догасит свет, хотя человек вернулся. Ставить `mode: restart` |
|
||||
| 39 | 🔴 **Задержка проверки присутствия обязана БЫТЬ БОЛЬШЕ окна отпускания радара** | Симптом: свет включается, хотя человек уже вышел. Замерено при `fading_time = 2 с`: окно «выключил свет → `presence` → `off`» = **3.2 с**. Задержка 3 с проверялась в `13:58:13.54`, presence сбросился в `13:58:13.73` — **на 0.19 с позже** → проверка прошла, свет включился. ⛔ **5 с тоже не помогли — таймер отброшен, см. п.34 и §4.5.** Подробно: [[family/how-to/ha-automations]] §4.3 |
|
||||
| 36 | 🔴 **Фиксированный `delay` ненадёжен для «дождаться, пока датчик отпустит»** | Момент проверки плавает: замер `call → свет on` при `delay: 5` дал **6.1 с** (≈1.1 с накладных на диспетчеризацию). Окно отпускания радара тоже плавает (замерено 3.19–3.59 с). Таймер `2 → 3 → 5 с` в ветке `lux` душевой **не сработал ни разу**. Использовать `wait_for_trigger` по событию: `- {platform: state, entity_id: ..., to: "off"}` + `timeout` + `continue_on_timeout: true` + `{{ wait.trigger is none }}`. Разбор: [[family/how-to/ha-automations]] §4.5 |
|
||||
| 37 | 🔴 **`wait_for_trigger` с взаимоисключающими условиями — свет не включится никогда** | Ошибка проектирования: `wait_for_trigger` на `from: on, to: off` + следующее условие `presence == on` требует presence одновременно `off` и `on`. Проверять выполнимость цепочки **до** заливки. ⚠️ Семантика: `wait.completed` = `true` при срабатывании, `false` при таймауте → «дождаться ухода» = `{{ wait.trigger is none }}`, «дождаться возврата» = `{{ wait.completed }}` |
|
||||
| 38 | 🔴 **`logbook` без поля `message` не различает ветки `choose`** | Версию по `presence` и по `lux` не отличить. Читать с `message`: `jq -r '.[] \| "\(.when) \(.state) \(.message // "")"'` → видно `triggered by state of <entity>` (какая именно ветка). Диагностика ложных включений: сопоставить три ряда `history/period` (`presence` + `illuminance` + `light`) с логбуком обеих автоматизаций в одном окне |
|
||||
| 39 | ⚠️ **`condition: device / is_occupied` может не отражать свежий `state`** | При проверке присутствия сразу после сброса радара device-условие давало «занято», тогда как `condition: state` на той же сущности корректно читала `off`. Для проверок по свежему состоянию использовать `condition: state`, не device-условие |
|
||||
| 40 | 🔴 **`wait_for_trigger` + `wait.completed` в `choose` требует `mode: restart`** | В сценарии «ждать возврат присутствия N секунд, иначе гасить»: `wait_for_trigger` с `timeout` + `continue_on_timeout: true`, затем `condition: template` с `value_template: "{{ wait.completed }}"` внутри `choose.sequence`. При `mode: single` повторный триггер игнорируется и ожидание НЕ перезапускается → старый таймер догасит свет, хотя человек вернулся. Ставить `mode: restart` |
|
||||
| 41 | 🔴 **Задержка проверки присутствия обязана БЫТЬ БОЛЬШЕ окна отпускания радара** | Симптом: свет включается, хотя человек уже вышел. Замерено при `fading_time = 2 с`: окно «выключил свет → `presence` → `off`» = **3.2 с**. Задержка 3 с проверялась в `13:58:13.54`, presence сбросился в `13:58:13.73` — **на 0.19 с позже** → проверка прошла, свет включился. ⛔ **5 с тоже не помогли — таймер отброшен, см. п.36 и §4.5.** Подробно: [[family/how-to/ha-automations]] §4.3 |
|
||||
|
||||
---
|
||||
|
||||
@@ -500,6 +500,68 @@ ssh root@192.168.2.176 'bash /tmp/fix_plan_stairs.sh /config/.storage/lovelace.h
|
||||
|
||||
---
|
||||
|
||||
## 13.5. 📡 Диагностика HA через трассировки и параметры радара (2026-09-16, вечер)
|
||||
|
||||
### 13.5.1. 🔴 Трассировки автоматизаций — ТОЛЬКО WebSocket
|
||||
|
||||
**Единственный способ увидеть реальные значения условий в момент выполнения.** Три итерации подбора задержек в душевой провалились именно потому, что трассировку не читали (разбор — [[family/how-to/ha-automations]] §4.4).
|
||||
|
||||
| Что | Значение |
|
||||
|---|---|
|
||||
| REST `/api/trace/...` | **404** — не использовать |
|
||||
| WS `trace/list`, `trace/get` | рабочие, домен `automation` |
|
||||
| `item_id` | 🔴 **внутренний ID** (`1771997851260`), **НЕ** `entity_id` |
|
||||
| `.storage/trace.saved_traces` | только сохранённые вручную через UI; живые — в памяти |
|
||||
|
||||
🧰 Инструмент: `~/tmp-t610/trace_dump.py` (Mac, `python3` + `websocket-client`, токен из `/tmp/.hatok`).
|
||||
🔴 **На t610 `python3` НЕТ** — скрипты выполнять с Mac.
|
||||
|
||||
### 13.5.2. ⚠️ Радар `shower_2_presence_sensor` дрожит
|
||||
|
||||
**Измерено:** присутствие выдаётся короткими сериями, включая `on` длительностью **1.8 с**, хотя человек находился в помещении.
|
||||
|
||||
```
|
||||
14:11:17.97 on → 14:11:25.35 off (7.4 с)
|
||||
14:11:33.92 on → 14:11:42.10 off (8.2 с)
|
||||
14:11:43.90 on → 14:11:48.68 off (1.8 с)
|
||||
14:11:55.86 on → 14:12:24.18 off (36.3 с)
|
||||
```
|
||||
|
||||
**Причина — сниженный `fading_time`.** Радар отпускает присутствие через `fading_time` после последнего движения. При **2 с** любое замирание даёт `off`, следующее движение — `on`. Исходные **10 с** прощали неподвижность.
|
||||
|
||||
**Параметры устройства `shower_2_presence_sensor`** (`_TZE204_qasjif9e`, TS0601, mmWave):
|
||||
|
||||
| Сущность | Значение | Диапазон | Смысл |
|
||||
|---|---|---|---|
|
||||
| `number.*_detection_delay` | `0.1` | 1…10 | задержка **до** объявления «есть» |
|
||||
| `number.*_fading_time` | `2.0` | 1…1500 (факт: ≥2) | удержание **после** ухода |
|
||||
| `number.*_radar_sensitivity` | `7` | — | чувствительность |
|
||||
| `number.*_minimum_range` | `0.6` | — | ближняя граница зоны, м |
|
||||
| `number.*_maximum_range` | `2.85` | — | дальняя граница зоны, м |
|
||||
|
||||
> 🔴 **`fading_time` не опускается ниже 2 с**, хотя HA показывает `min: 1` и ответ `number.set_value` возвращает `state: 1.0`. Проверено: `1.0` → `2.0`, `1.5` → `2.0`, `2.5` → принято. Прошивка молча игнорирует < 2 — **всегда читать обратно**.
|
||||
|
||||
### 13.5.3. ✅ Проверка, что реле исправно
|
||||
|
||||
**Реле `night_light_shower_2` (TS0001) удерживает состояние:** ручной `light.turn_on` → 27 опросов подряд с шагом 200 мс — стабильно `on`, сброса нет.
|
||||
|
||||
→ Значит **подсекундные пары `on→off` (0.12–0.13 с) в истории идут от логики/команд, а не от поломки реле**. Проверять это первым, прежде чем чинить алгоритм.
|
||||
|
||||
### 13.5.4. ⚠️ Как отличить внешний вызов от сценария
|
||||
|
||||
**Правило:** изменение состояния сущности **без** соответствующей записи триггера автоматизации в `logbook` = **внешний вызов** (ручной `light.turn_on`, другая интеграция), а не сценарий.
|
||||
|
||||
Сверять два ряда в одном окне:
|
||||
```bash
|
||||
# изменения цели
|
||||
curl -s -H "$H" "$B/api/history/period/$T+00:00?filter_entity_id=light.x&minimal_response&no_attributes"
|
||||
# триггеры автоматизации (поле message = какая ветка)
|
||||
curl -s -H "$H" "$B/api/logbook/$T+00:00?entity=automation.<alias>"
|
||||
```
|
||||
Без этого легко «найти» баг автоматизации там, где был ручной тестовый вызов.
|
||||
|
||||
---
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[family/how-to/home-automation]] — топология, аддоны t610, первопричина RCU stall, Modbus
|
||||
|
||||
Reference in New Issue
Block a user