[2026-09-16] eagle: family/how-to/ha-automations.md family/tech/zigbee-t610-z2m-i-zha.md

2026-09-16 20:12:37 +06:00
parent 64dfc5762c
commit 75d053ceb4
2 changed files with 74 additions and 24 deletions
@@ -411,6 +411,8 @@ curl -s -H "$HDR" http://supervisor/backups | jq
 | 31 | 🔴 **`condition: state` с числовым порогом не принимает `below`** | POST → `Message malformed: not a valid option at 'conditions[0].below'`. Порог освещённости — только device-условием `type: is_illuminance`. Ошибка валидации конфиг НЕ портит (проверено) |
 | 32 | 🔴 **`automation.trigger` НЕ подставляет `trigger.id`** | Прогон через него всегда уходит в `choose.default` — ветку по `trigger.id` так не протестировать. Проверять временным скриптом: `POST /api/config/script/config/<tmp>` → `script/reload` → вызов → `DELETE`. ⚠️ `delay` живёт только в `actions:` и не знает, какой триггер сработал — ветки различать через `trigger.id` + `choose` |
 | 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`) с логбуком обеих автоматизаций в одном окне |