[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

family/how-to/ha-automations.md

@@ -4,19 +4,25 @@
 
 > 🟢 **25 АВТОМАТИЗАЦИЙ — 24 `on`, 1 `off`** (`Ventilation automation on`, намеренно), `unavailable` = 0. Zigbee работает на ZHA.
 >
-> **Состав:** 12 контроля батарей (§5) + 2 циркуляция ГВС + 2 свет кабинета (§2.2, §3) + 2 подсветка лестницы + 2 ночной свет душевой (§4.1–§4.5) + 2 диммер спальни + 1 протечка котельная + 1 вентиляция + **1 греющий кабель ввода воды (§7)**.
+> **Состав:** 12 контроля батарей (§5) + 2 циркуляция ГВС + 2 свет кабинета (§2.2, §3) + 2 подсветка лестницы + 2 ночной свет душевой (§4.1–§4.6.2) + 2 диммер спальни + 1 протечка котельная + 1 вентиляция + **1 греющий кабель ввода воды (§7)**.
 >
-> 🗓 **Сессия 2026-09-16 (день):** починены два дефекта автоматизаций кабинета — мёртвые `entity_id` в триггерах (§2.2) и потерянная защита `not_from` (§3). В душевой: задержка на ветку по освещённости (§4.1), `fading_time` 10→2 с + задержка 10 с в сценарии ВЫКЛ (§4.2). ⛔ **Задержка ВКЛ `2 → 3 → 5 с` проблему НЕ решила** — фиксированный таймер отброшен, ветка `lux` переведена на `wait_for_trigger` по событию `presence → off` (§4.5).
+> 🗓 **Сессия 2026-09-16 (день):** починены три дефекта автоматизаций — мёртвые `entity_id` в триггерах кабинета (§2.2), потерянная защита `not_from` (§3), ложные включения ночного света душевой (§4.4). В душевой также: задержка на ветку по освещённости (§4.1), `fading_time` 10→2 с + задержка 10 с в сценарии ВЫКЛ (§4.2). **Итог приёмки (§4.6.1):** ложное включение при выходе устранено; осталось дрожание радара (§4.6.2).
 >
-> 🟡 **ОСТАЁТСЯ ОТКРЫТЫМ — только один вопрос (§4.4):** feedback loop через собственную лампу (пороги ВКЛ/ВЫКЛ совпадают: `6`/`6`, мёртвая зона нулевая → дребезг `2–4` ↔ `11–12`). Гистерезис `< 4` / `> 10` **предложен, но отклонён Alex** — пороги не менять без явной команды. Ложные включения при выходе переведены на событийную проверку (§4.5) — **ждёт подтверждения на практике**.
+> 🔴 **ГЛАВНЫЙ УРОК СЕССИИ (§4.4):** `condition:` внутри `sequence:` НЕ отменяет остальные `actions` — прерывает только свою `sequence`, а родительский список продолжается. `light.turn_on`, стоявший **после** `choose`, выполнялся **всегда**, даже когда проверка присутствия вернула `false` (доказано трассировкой: `result: false` и через 1 мс — включение). **Действие обязано быть ВНУТРИ ветки `choose`, после проверки.** Это была ошибка проектирования, а не настройки.
+>
+> 🟡 **ОСТАЁТСЯ ОТКРЫТЫМ — два вопроса:**
+> 1. **§4.6 — feedback loop через собственную лампу** (пороги ВКЛ/ВЫКЛ совпадают: `6`/`6`, мёртвая зона нулевая → дребезг `2–4` ↔ `11–12`). Гистерезис `< 4` / `> 10` **предложен, но отклонён Alex** — пороги не менять без явной команды.
+> 2. **§4.6.2 — дрожание радара** (серии `on/off`, включая `on` на 1.8 с). Усилено снижением `fading_time` до 2 с. Предложен возврат к 10 с — **решения Alex нет**.
 >
 > **Ключевые факты:**
 > - 🔴 **ЗАЩИТА ТРИГГЕРА ОБЯЗАТЕЛЬНА для `platform: state` на реле/кнопках:** `not_from: [unavailable, unknown]`. Без неё автоматизация срабатывает при старте HA (`unavailable → on`) и дёргает действие. Реальный случай 2026-09-16 — мигание света в кабинете. **При пересборке автоматизаций это поле теряется молча** (§3).
+> - 🔴 **Действие — ВНУТРИ ветки `choose`, после проверки.** Не на верхнем уровне `actions` (§4.4).
+> - 🔴 **Трассировки автоматизаций — ТОЛЬКО WebSocket** (`trace/list` + `trace/get`, `item_id` = **внутренний ID**, не `entity_id`; REST → 404). **Читать трассировку ДО перебора гипотез.** Инструмент: `~/tmp-t610/trace_dump.py` (на t610 python3 НЕТ).
 > - 🔴 **`entity_id` автоматизаций HA перегенерирует по alias** — искать по `attributes.id`, не по `entity_id`.
 > - 🔴 **REST `GET/POST /api/config/automation/config/<id>` использует поля во множественном числе** — `triggers`/`conditions`/`actions` (в файле — единственное). Ошибка молча уходит в пустоту: POST → `200 ok`, значения НЕ меняются. **Всегда читать обратно.**
 > - ⚠️ **Кнопка спальни** шлёт `remote_button_short_press` только после `zha/devices/reconfigure`.
 >
-> **Бэкапы перед правками:** `automations.yaml.bak-cable3-20260915-*` (кабель), `.bak-preids-*`, `.bak-gard-*` (единообразие ID). Локальные копии в `~/tmp-t610/`.
+> **Бэкапы сессии 2026-09-16:** `.bak-office-20260916-124244` (кабинет), `.bak-showerdelay-20260916-131126`, `.bak-shower-off-20260916-205245`, `.bak-shower-delay3-20260916-205557`, `.bak-shower-delay5-20260916-205953`, `.bak-shower-final-20260916-211051` (душевая). Локальные копии в `~/tmp-t610/`.
 > 📄 Рецепт пересборки после Z2M→ZHA и питфоллы — [[family/tech/zigbee-t610-z2m-i-zha]].
 >
 > 🔴 **ПИТФОЛЛЫ, найденные при починке:**
@@ -503,6 +509,58 @@ mode: single
 
 **Что применено в рамках этого разбора:** `fading_time 10 → 2` + задержка 10 с в сценарии ВЫКЛ (§4.2), затем перевод ветки ВКЛ на событийную проверку `wait_for_trigger` (§4.5) — всё по прямому указанию Alex.
 
+### 4.6.1. ✅ ПРИЁМКА Alex (2026-09-16, вечер) — что подтверждено, что осталось
+
+**Подтверждено Alex после фикса §4.4:**
+
+| Сценарий | Поведение | Статус |
+|---|---|---|
+| Вышел + выключил свет | подсветка **НЕ** зажглась | ✅ работает |
+| Не выходя — выключил свет | подсветка зажглась через 5 с | ✅ работает (так и задумано) |
+| Зашёл в тёмную | зажигается **сразу** | ✅ (ветка `presence`) |
+
+**Остаточные симптомы, зафиксированные Alex (НЕ закрыты):**
+
+1. **«Зашёл — зажглась будто с задержкой».** Причина: если одновременно с приходом дёрнулась освещённость, срабатывает **ветка `lux`** (с `delay: 5`), а не ветка `presence` (мгновенная). Ощущение задержки — цена 5-секундной паузы в `lux`.
+2. **«Зажглось и сразу погасло»** — при заходе без света. Разобрано в §4.6.2: дрожание радара.
+
+### 4.6.2. 🔴 ДРОЖАНИЕ РАДАРА — источник серий `on/off` (2026-09-16)
+
+**Измерено фактом.** Радар `shower_2_presence_sensor` выдаёт `on`/`off` короткими интервалами:
+
+```
+14:11:17.97  on
+14:11:25.35  off   (7.4 с)
+14:11:33.92  on    (8.6 с)
+14:11:42.10  off   (8.2 с)
+14:11:43.90  on    (1.8 с!)  ← радар потерял присутствие, хотя человек внутри
+14:11:48.68  off   (4.8 с)
+14:11:55.86  on    (36.3 с)
+14:12:24.18  off
+```
+
+**Пары `LIGHT=on → LIGHT=off` за 0.12–0.13 с происходят БЕЗ записи `AUT-OFF` в logbook:**
+```
+14:11:43.897  AUT-ON   triggered by presence
+14:11:44.082  LIGHT=on
+14:11:44.201  LIGHT=off          ← 0.12 с, триггера ВЫКЛ НЕТ
+14:11:48.683  AUT-OFF  triggered by presence
+```
+Между `44.201` и `48.683` прошло **4.5 с** — сценарий ВЫКЛ сработал позже, значит погасил **не он**.
+
+> 🔴 **Усилитель проблемы — `fading_time = 2 с` (снижен мной по прямому указанию Alex, §4.2).** Радар отпускает присутствие за 2 с вместо 10, поэтому любое замирание даёт `off`, а следующее движение — `on`. **Исходное значение 10 с как раз прощало неподвижность в душевой.**
+
+**Проверено, что реле исправно:** ручной `light.turn_on` → **27 опросов подряд с шагом 200 мс** — состояние `on` стабильно, сброса нет. Значит железо удерживает состояние, а дрожание идёт от логики/датчика.
+
+**Предложенные варианты (НЕ применены, ждут решения Alex):**
+| # | Мера | Что лечит |
+|---|---|---|
+| 1 | Вернуть `fading_time` → **10 с** | дрожание радара, серии `on/off` |
+| 2 | Поднять `minimum_range` / сузить зону | если радар задевает движение за дверью |
+| 3 | Оставить как есть, наблюдать | — |
+
+> ⚠️ **Методическое замечание:** при диагностике Alex **сам дёргал `light.turn_on`/`turn_off` через API** для проверки удержания реле — это загрязняло логи. Записи `LIGHT=on` **без** `AUT-ON` рядом = внешний вызов, а не сценарий. Учитывать при разборе.
+
 ---
 
 ## 4.5. ⛔ ЧТО НЕ СРАБОТАЛО: полная хронология перебора (2026-09-16)