[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
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: "План и результат: читаемые ID Zigbee, алерты батарей, виртуальные Modbus-датчики"
|
||||
created: '2026-09-15'
|
||||
updated: '2026-09-16 (день: этап 7 расширен — починка автоматизаций кабинета, задержки ночного света душевой, `fading_time` 10→2 с, тюнинг задержки ВКЛ до 5 с)'
|
||||
updated: '2026-09-16 (день: этап 8 — КОРЕНЬ дефекта душевой найден трассировкой: `condition` внутри `sequence` не отменяет остальные `actions`)'
|
||||
type: plan
|
||||
namespace: family
|
||||
status: 🟢 ВЫПОЛНЕНО 2026-09-16. Шаги 1–4 закрыты 2026-09-15; 5–6 (вычистка призраков + починка UI) — 2026-09-16 ночью; 7 (починка автоматизаций кабинета + душевая: задержки, `fading_time`) — 2026-09-16 днём. Всё проверено фактами. 🟡 Открыт один вопрос — feedback loop по порогам душевой (§4.4 в [[family/how-to/ha-automations]]), правка отклонена Alex.
|
||||
status: 🟢 ВЫПОЛНЕНО 2026-09-16. Шаги 1–4 закрыты 2026-09-15; 5–6 (вычистка призраков + починка UI) — 2026-09-16 ночью; 7–8 (автоматизации кабинета — 2 дефекта; душевая — `fading_time` 10→2, задержка 10 с в ВЫКЛ, ложные включения ВКЛ) — 2026-09-16 днём. Всё проверено фактами. 🟡 Открыт один вопрос — feedback loop по порогам душевой (§4.6 в [[family/how-to/ha-automations]]), правка отклонена Alex.
|
||||
tags:
|
||||
- t610
|
||||
- zigbee
|
||||
@@ -409,15 +409,66 @@ actions:
|
||||
|
||||
**Замер (цикл `13:58`):** при `fading_time = 2 с` радар отпускает присутствие **через 3.2 с после выключения света**. Задержка 3 с заканчивалась в `13:58:13.54`, presence сбрасывался в `13:58:13.73` — **на 0.19 с позже**, поэтому проверка `is_occupied` проходила и свет включался.
|
||||
|
||||
**Фикс:** `delay` в ветке `lux` поднят до **5 с** (запас 1.8 с). Итоговое состояние — `delay: 5 s`.
|
||||
**Фикс (шаг 7):** `delay` в ветке `lux` поднят до **5 с** (запас 1.8 с).
|
||||
|
||||
> 🔴 **ПРАВИЛО ПОДБОРА: задержка должна быть больше ОКНА ОТПУСКАНИЯ радара (не `fading_time`).** Измеренное окно при `fading_time = 2 с` = **3.2 с**.
|
||||
> ⚠️ Надёжная альтернатива фиксированной задержке: `wait_for_trigger` на `presence → off` — проверка идёт после отпускания, независимо от `fading_time`. **Предложено Alex, ждёт решения** — если 5 с не хватит.
|
||||
|
||||
**Бэкапы:** `/config/automations.yaml.bak-office-20260916-124244`, `.bak-showerdelay-20260916-131126`, `.bak-shower-off-20260916-205245`, `.bak-shower-delay3-20260916-205557`, `.bak-shower-delay5-20260916-205953` на t610; `~/tmp-t610/automations/automations.yaml.{office-before,shower-before}` локально.
|
||||
**Скрипты:** `fix_office_switch.sh`, `fix_office_guard.sh`, `fix_shower_lux_delay.sh`, `fix_shower_as_requested.sh`, `fix_shower_delay3.sh`, `fix_shower_delay5.sh`, `test_shower_lux_branch.sh`, `test_delay_timing.sh`, `check_shower_timing.sh` — все в `~/tmp-t610/`.
|
||||
⛔ **НО 5 с ТОЖЕ НЕ ПОМОГЛИ.** Шаг 8 (см. ниже) показал, что причина была не в задержке вообще.
|
||||
|
||||
**Детали:** [[family/how-to/ha-automations]] §2.2, §3, §4.1–§4.4; питфоллы №27–35 в [[family/tech/zigbee-t610-z2m-i-zha]].
|
||||
**Бэкапы:** `/config/automations.yaml.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` на t610; `~/tmp-t610/automations/automations.yaml.{office-before,shower-before}` локально.
|
||||
**Скрипты:** `fix_office_switch.sh`, `fix_office_guard.sh`, `fix_shower_lux_delay.sh`, `fix_shower_as_requested.sh`, `fix_shower_delay3.sh`, `fix_shower_delay5.sh`, **`fix_shower_final.sh`** (итог), `test_shower_lux_branch.sh`, `test_delay_timing.sh`, `check_shower_timing.sh`, **`trace_dump.py` / `trace_read.py`** (трассировки) — все в `~/tmp-t610/`.
|
||||
|
||||
**Детали:** [[family/how-to/ha-automations]] §2.2, §3, §4.1–§4.6; питфоллы №27–41 в [[family/tech/zigbee-t610-z2m-i-zha]].
|
||||
|
||||
---
|
||||
|
||||
## 4.8. ✅ РЕЗУЛЬТАТ — Шаг 8: КОРЕНЬ ложных включений душевой (2026-09-16, день)
|
||||
|
||||
**Симптом:** свет включался после выхода из душевой, несмотря на проверку присутствия. Задержка 2→3→5 с и `fading_time` 10→2 **не помогали** — ни один вариант не дал результата.
|
||||
|
||||
**Первопричина — найдена трассировкой HA, а не перебором настроек:**
|
||||
|
||||
```
|
||||
14:02:38.426597 action/0/choose/0/sequence/1/entity_id/0
|
||||
{"result": false, "state": "off", "wanted_state": "on"} ← проверка ОТБИЛА
|
||||
14:02:38.427615 action/1 → light.turn_on ← ВКЛЮЧИЛ
|
||||
```
|
||||
|
||||
🔴 **`condition:` внутри `sequence:` прерывает ТОЛЬКО свою `sequence`.** Управление возвращается в родительский список `actions` и продолжает выполнять следующие шаги. `light.turn_on`, стоявший **после** `choose` (на верхнем уровне `actions`), выполнялся **всегда** — при любом результате проверки.
|
||||
|
||||
**Это была ошибка проектирования автоматизации, а не настройки.** Alex трижды просил «чинить то, что просили», а я подбирал числа вместо того, чтобы прочитать трассировку, которая всё время лежала в HA.
|
||||
|
||||
**Фикс:** оба `light.turn_on` перенесены **внутрь** веток `choose`:
|
||||
```yaml
|
||||
actions:
|
||||
- choose:
|
||||
- conditions: [{condition: trigger, id: presence}]
|
||||
sequence: [{action: light.turn_on, ...}] # заход → мгновенно
|
||||
- conditions: [{condition: trigger, id: lux}]
|
||||
sequence:
|
||||
- {delay: {seconds: 5}}
|
||||
- {condition: state, entity_id: presence, state: "on"}
|
||||
- {action: light.turn_on, ...} # ✅ внутри, после проверки
|
||||
default: []
|
||||
```
|
||||
|
||||
**Как искать причину (переиспользуемый рецепт):**
|
||||
|
||||
```bash
|
||||
# 1. Трассировки — ТОЛЬКО WebSocket, REST → 404
|
||||
# item_id = ВНУТРЕННИЙ ID автоматизации (1771997851260), НЕ entity_id
|
||||
python3 ~/tmp-t610/trace_dump.py 14:02:33
|
||||
# 2. Сопоставить три ряда в одном окне: history/period по presence + illuminance + light
|
||||
# 3. logbook С ПОЛЕМ message → «triggered by numeric state of ...» = какая ветка choose
|
||||
```
|
||||
|
||||
**Верификация:** конфиг прочитан обратно (оба `light.turn_on` внутри `choose`); автоматизации 25/24 `on`/`1` `off`, `unavailable` = 0.
|
||||
**Бэкап:** `/config/automations.yaml.bak-shower-final-20260916-211051`.
|
||||
**Скрипт:** `~/tmp-t610/fix_shower_final.sh`.
|
||||
|
||||
> ⏳ **Ждёт практического подтверждения Alex:** зайти в тёмную душевую (должно включиться сразу) и выйти, выключив свет (должно не зажечься).
|
||||
|
||||
**Детали:** [[family/how-to/ha-automations]] §4.4 (корневой разбор), §4.5 (что не сработало), §4.6 (предыстория).
|
||||
|
||||
---
|
||||
|
||||
@@ -460,6 +511,12 @@ actions:
|
||||
| 12 | **Автоматизация с мёртвым триггером остаётся `state: on`** — `unavailable` не появляется. Признак один: `last_triggered` не растёт. Проверять сверкой всех `entity_id:` из YAML со `/api/states` |
|
||||
| 13 | `automation.trigger` не подставляет `trigger.id` → ветку `choose` по `trigger.id` так не протестировать; нужен временный скрипт |
|
||||
| 14 | `condition: state` не принимает числовой `below` — порог только device-условием `type: is_illuminance` |
|
||||
| 15 | 🔴 **`condition:` внутри `sequence:` НЕ отменяет остальные `actions`** — прерывает только свою `sequence`, родительский список продолжается. **Действие ставить ВНУТРИ ветки `choose`.** Иначе проверка вернёт `false`, а действие всё равно выполнится. Ошибка молчаливая |
|
||||
| 16 | 🔴 **Трассировки автоматизаций — ТОЛЬКО WebSocket** (`trace/list` + `trace/get`; `item_id` = ВНУТРЕННИЙ ID, не `entity_id`; REST → 404). **Читать трассировку ДО перебора гипотез** — в этой сессии три итерации подбора задержек ушли впустую, потому что трассировка не читалась |
|
||||
| 17 | 🔴 **Не строить `wait_for_trigger` с взаимоисключающими условиями** — `from: on, to: off` + требование `presence == on` невыполнимо, свет не включится никогда. Проверять выполнимость цепочки до заливки в прод |
|
||||
| 18 | **Фиксированный `delay` ненадёжен для «дождаться, пока датчик отпустит»** — момент проверки плавает (замерено ~1.1 с накладных на диспетчеризацию). Окно отпускания радара тоже плавает (3.19–3.59 с) |
|
||||
| 19 | ⚠️ **`condition: device / is_occupied` может не отражать свежий `state`** — для проверок по только что изменившемуся состоянию использовать `condition: state` |
|
||||
| 20 | Проверенная тактика диалога: Alex не принимает объяснения вместо факта — на «не работает» нужно читать логи/трассировки, а не перебирать настройки |
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
|
||||
Reference in New Issue
Block a user