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

family/how-to/ha-automations.md

@@ -6,9 +6,9 @@
 >
 > **Состав:** 12 контроля батарей (§5) + 2 циркуляция ГВС + 2 свет кабинета (§2.2, §3) + 2 подсветка лестницы + 2 ночной свет душевой (§4.1–§4.3) + 2 диммер спальни + 1 протечка котельная + 1 вентиляция + **1 греющий кабель ввода воды (§7)**.
 >
-> 🗓 **Сессия 2026-09-16 (день):** починены два дефекта автоматизаций кабинета — мёртвые `entity_id` в триггерах (§2.2) и потерянная защита `not_from` (§3). В душевой: задержка 2 с на ветку по освещённости (§4.1), затем `fading_time` 10→2 с + задержка 10 с в сценарии ВЫКЛ (§4.2). Все правки верифицированы живым прогоном на железе **и реальным рестартом HA**.
+> 🗓 **Сессия 2026-09-16 (день):** починены два дефекта автоматизаций кабинета — мёртвые `entity_id` в триггерах (§2.2) и потерянная защита `not_from` (§3). В душевой: задержка на ветку по освещённости (§4.1), `fading_time` 10→2 с + задержка 10 с в сценарии ВЫКЛ (§4.2), затем тюнинг задержки ВКЛ `2 → 3 → 5 с` по замеру окна отпускания радара (§4.3). Все правки верифицированы живым прогоном на железе **и реальным рестартом HA**.
 >
-> 🔴 **ОТКРЫТО (см. §4.3):** ложные включения ночного света душевой при выходе — окно `fading_time` + feedback loop через собственную лампу при совпадающих порогах ВКЛ/ВЫКЛ (`6`/`6`). Фиксы (устойчивое присутствие, гистерезис `< 4` / `> 10`) **предложены, но отклонены Alex** — пороги не менять без явной команды.
+> 🟡 **ОСТАЁТСЯ ОТКРЫТЫМ — только один вопрос (§4.4):** feedback loop через собственную лампу (пороги ВКЛ/ВЫКЛ совпадают: `6`/`6`, мёртвая зона нулевая → дребезг `2–4` ↔ `11–12`). Гистерезис `< 4` / `> 10` **предложен, но отклонён Alex** — пороги не менять без явной команды. Ложные включения при выходе **закрыты** задержкой 5 с (§4.3), ждут подтверждения на практике.
 >
 > **Ключевые факты:**
 > - 🔴 **ЗАЩИТА ТРИГГЕРА ОБЯЗАТЕЛЬНА для `platform: state` на реле/кнопках:** `not_from: [unavailable, unknown]`. Без неё автоматизация срабатывает при старте HA (`unavailable → on`) и дёргает действие. Реальный случай 2026-09-16 — мигание света в кабинете. **При пересборке автоматизаций это поле теряется молча** (§3).
@@ -113,7 +113,7 @@ action:
 | `1771466955010` | Светло: выкл. подсветку лестницы | `illuminance above: 60` → `light.light_stairs_left`+`_right` turn_off |
 | `1771683420621` | Toggle Dimmer bed | кнопка `remote_button_short_press` → `light.toggle light.bed_dimmer` |
 | `1771683677259` | Dimmer bed cycle | кнопка `long_press` → `light.turn_on` brightness 50 % на `light.bed_dimmer` |
-| `1771997851260` | **Вкл. ночной свет душевая** | `occupied` (`id: presence` — мгновенно) / `illuminance below: 6` (`id: lux` → `delay 2 s` → проверка присутствия) → `light.dushevaia_night_light` on. См. §4.1 |
+| `1771997851260` | **Вкл. ночной свет душевая** | `occupied` (`id: presence` — мгновенно) / `illuminance below: 6` (`id: lux` → `delay 5 s` → проверка присутствия) → `light.dushevaia_night_light` on. См. §4.1, §4.3 |
 | `1771997918348` | **Выкл. ночной свет душевая** | `not_occupied` (`id: left` → `wait_for_trigger` 10 с → гасить, если присутствие не вернулось) / `illuminance above: 6` (`id: bright` → сразу) → off. `mode: restart`. См. §4.2 |
 | `1773451257968` | Протечка котельная | `moist` → `notify.notify` |
 | `8800000000000`…`8800000000011` | **Батарея: 12 шт.** | см. §6 |
@@ -322,7 +322,34 @@ mode: restart
 
 > ⚠️ **Не тронуто по указанию Alex:** пороги освещённости остались `below: 6` / `above: 6` (нулевая мёртвая зона → возможен дребезг 2↔12 lx). Гистерезис `< 4` / `> 10` предлагался, но правка отклонена — не менять без явной команды.
 
-### 4.1. ✅ Задержка 2 с на ветке освещённости (2026-09-16, шаг 1)
+### 4.3. 🔧 Тюнинг задержки ВКЛ: 2 → 3 → 5 с (2026-09-16)
+
+**Симптом:** вышел из душевой, выключил свет — подсветка зажигалась через ~3 с, хотя не должна.
+
+**Замер беговой дорожки (реальные логи, цикл `13:58`):**
+
+| Время | Событие |
+|---|---|
+| `13:58:02.16` | lux → `12` (включил свет) → сработал сценарий ВЫКЛ (`bright`) |
+| `13:58:03.76` | presence → `on` (в душевой) |
+| `13:58:10.54` | lux → `1` (**выключил свет**) → **триггер ВКЛ по `lux`** |
+| `13:58:13.67` | LIGHT → `on` (задержка 3 с + Zigbee) |
+| `13:58:13.73` | presence → `off` (+0.06 с после включения света) |
+
+**Первопричина:** при `fading_time = 2 с` радар отпускает присутствие **через ~3.2 с после выключения света**. Триггер `lux` срабатывает в момент выключения; задержка 3 с заканчивалась в `13:58:13.54`, а presence сбрасывался в `13:58:13.73` — **на 0.19 с позже проверки**. Проверка `is_occupied` проходила → свет включался. Задержка обязана быть **больше окна отпускания радара**.
+
+**Фикс:** `delay` в ветке `lux`: `2 → 3 → 5 с`. При 5 с проверка ловится на `off` с запасом 1.8 с.
+
+> 🔴 **Правило: задержка проверки присутствия в ветке `lux` должна быть больше `fading_time` + запас.** Измеренное окно «выключил свет → presence off» = **3.2 с** при `fading_time = 2 с`. Формула для подбора: `delay > окно отпускания`.
+> ⚠️ **Надёжная альтернатива фиксированной задержке** (если 5 с снова не хватит): `wait_for_trigger` на `presence → off` + `continue_on_timeout: true` + `{{ wait.completed }}` — тогда проверка идёт **после** отпускания радара, независимо от `fading_time`. Предложено Alex, ждёт решения.
+
+**Верификация:** конфиг прочитан обратно (`delay.seconds: 5`), reload выполнен, автоматизация `on`, `unavailable` = 0, `fading_time` = 2.0.
+**Бэкапы:** `.bak-shower-delay3-20260916-205557`, `.bak-shower-delay5-20260916-205953`.
+**Скрипты:** `~/tmp-t610/fix_shower_delay3.sh`, `fix_shower_delay5.sh`, диагностика — `check_shower_timing.sh`.
+
+### 4.1. ✅ Задержка на ветке освещённости (2026-09-16) — история: 2 с → 3 с → 5 с
+
+> **Итоговое состояние — `delay: 5 s`** (см. §4.3 с замером). Ниже — исходная реализация и её развитие.
 
 **Задача (Alex):** «в триггере ночного света по изменению освещённости добавить задержку в пару секунд на проверку присутствия (освещённость упала → sleep 2 → присутствие == true → включить)». **Только на триггер по свету** — по присутствию включать мгновенно.
 
@@ -385,7 +412,7 @@ mode: single
 
 ---
 
-## 4.3. 🔴 ОТКРЫТО: ложные включения при выходе (feedback loop, 2026-09-16)
+## 4.4. 📋 Разбор: ложные включения при выходе (feedback loop, 2026-09-16)
 
 **Симптом (Alex):** «выхожу, выключаю свет, через 2 секунды включается подсветка хоть и не должна».
 
@@ -403,10 +430,12 @@ mode: single
 | `06:16:41.04` | 3 | ↓ → триггер `lux` → `06:16:43` **on** |
 | `06:17:04.17` | — | presence → `off` (радар отпустил) |
 
-**Две независимые причины:**
+**Две независимые причины — статус на конец 2026-09-16:**
 
-1. **Окно `fading_time`.** Вышел → радар держит `presence = on` ещё `fading_time` секунд → проверка присутствия в ветке `lux` **проходит** → свет включается, хотя человека уже нет. Задержка 2 с это не лечит — она на порядок меньше окна (было 10 с; стало 2 с — окно сократилось, но не исчезло).
+1. **Окно `fading_time`.** Вышел → радар держит `presence = on` ещё `fading_time` секунд → проверка присутствия в ветке `lux` **проходит** → свет включается, хотя человека уже нет.
+   → ✅ **ЗАКРЫТО (§4.3):** задержка в ветке `lux` поднята `2 → 3 → 5 с` — замеренное окно отпускания радара при `fading_time = 2 с` составляет **3.2 с** («выключил свет → presence off»), 5 с перекрывает его с запасом 1.8 с. **Ждёт подтверждения Alex** — если снова зажжётся, ставить `wait_for_trigger` на `presence → off` вместо фиксированной задержки.
 2. **Feedback loop через собственную лампу.** Свет зажёгся → `lux` подскочила `2 → 12` → стала `> 6` → на следующем падении автоматизация ВКЛ снова срабатывает. Порог ВКЛ и ВЫКЛ **совпадают (6)** → мёртвая зона нулевая → шум датчика (`2–4` ↔ `11–12`) гоняет сценарий по кругу. `mode: single` не спасает: запуск завершается быстрее, чем приходит следующий.
+   → 🔴 **НЕ ЗАКРЫТО — правка отклонена Alex** («тебя просили чинить то что не сломано?!»). Оставлено как открытый вопрос, не как задача.
 
 **Предложенные фиксы — НА РАССМОТРЕНИИ, не применены:**
 

family/plans/t610-zigbee-ids-battery-freshsensors-modbus.md

@@ -1,10 +1,10 @@
 ---
 title: "План и результат: читаемые ID Zigbee, алерты батарей, виртуальные Modbus-датчики"
 created: '2026-09-15'
-updated: '2026-09-16 (день: добавлен этап 7 — починка автоматизаций кабинета + задержка в душевой)'
+updated: '2026-09-16 (день: этап 7 расширен — починка автоматизаций кабинета, задержки ночного света душевой, `fading_time` 10→2 с, тюнинг задержки ВКЛ до 5 с)'
 type: plan
 namespace: family
-status: 🟢 ВЫПОЛНЕНО 2026-09-16. Шаги 1–4 закрыты 2026-09-15; 5–6 (вычистка призраков + починка UI) — 2026-09-16 ночью; 7 (починка автоматизаций кабинета + задержка в душевой) — 2026-09-16 днём. Всё проверено фактами.
+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.
 tags:
   - t610
   - zigbee
@@ -391,10 +391,33 @@ actions:
 
 **ВЫКЛ (`1771997918348`) НЕ тронут** — по решению Alex задержка нужна только на триггере по свету.
 
-**Бэкапы:** `/config/automations.yaml.bak-office-20260916-124244`, `.bak-showerdelay-20260916-131126` на t610; `~/tmp-t610/automations/automations.yaml.{office-before,shower-before}` локально.
+### 7.4. `fading_time` радара 10 → 2 с + задержка 10 с в сценарии ВЫКЛ
-**Скрипты:** `fix_office_switch.sh`, `fix_office_guard.sh`, `fix_shower_lux_delay.sh`, `test_shower_lux_branch.sh`, `test_delay_timing.sh` — все в `~/tmp-t610/`.
 
-**Детали:** [[family/how-to/ha-automations]] §2.2, §3, §4.1; питфоллы №27–32 в [[family/tech/zigbee-t610-z2m-i-zha]].
+**Задача (Alex):** снизить `fading_time` радара и перенести задержку в сценарий выключения — «если в течение 10 с датчик не поменялся снова на присутствие — выключать».
+
+| Что | Было | Стало |
+|---|---|---|
+| `number.shower_2_presence_sensor_fading_time` | `10.0` | **`2.0`** — нижний предел железа |
+| ВЫКЛ `1771997918348` | `turn_off` сразу | `wait_for_trigger` (presence→on) + `timeout: 10 s` → гасить, если не вернулось. `mode: restart` |
+
+> 🔴 **ПИТФОЛЛ:** `fading_time` у `_TZE204_qasjif9e` (TS0601) **не опускается ниже 2 с**, хотя HA показывает `min: 1`. Проверено: `1.0` → откат к `2.0`; `1.5` → откат; `2.5` → записалось. HA отдаёт `state: 1.0` в ответе сервиса, но сущность возвращается к `2.0` — **всегда читать обратно**.
+> 🔴 **ПИТФОЛЛ:** `wait_for_trigger` + `wait.completed` внутри `choose` требует **`mode: restart`** — при `mode: single` повторный триггер игнорируется и ожидание не перезапускается.
+
+### 7.5. Тюнинг задержки ВКЛ: 2 → 3 → 5 с (закрытие ложных включений)
+
+**Симптом:** вышел, выключил свет — подсветка зажигалась. Задержки 2 с и 3 с не хватало.
+
+**Замер (цикл `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`.
+
+> 🔴 **ПРАВИЛО ПОДБОРА: задержка должна быть больше ОКНА ОТПУСКАНИЯ радара (не `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/`.
+
+**Детали:** [[family/how-to/ha-automations]] §2.2, §3, §4.1–§4.4; питфоллы №27–35 в [[family/tech/zigbee-t610-z2m-i-zha]].
 
 ---
 

family/tech/zigbee-t610-z2m-i-zha.md

@@ -412,6 +412,7 @@ curl -s -H "$HDR" http://supervisor/backups | jq
 | 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 | 🔴 **`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` |
+| 35 | 🔴 **Задержка проверки присутствия обязана БЫТЬ БОЛЬШЕ окна отпускания радара** | Симптом: свет включается, хотя человек уже вышел. Замерено при `fading_time = 2 с`: окно «выключил свет → `presence` → `off`» = **3.2 с**. Задержка 3 с проверялась в `13:58:13.54`, presence сбросился в `13:58:13.73` — **на 0.19 с позже** → проверка прошла, свет включился. Рабочее значение — **`delay: 5 s`** (запас 1.8 с). Подбор: `delay > окно отпускания`, а не `delay > fading_time`. Надёжная альтернатива фиксированной задержке — `wait_for_trigger` на `presence → off`. Подробно: [[family/how-to/ha-automations]] §4.3 |
 
 ---