diff --git a/family/how-to/ha-automations.md b/family/how-to/ha-automations.md index 90a977c9..03d8c3d9 100644 --- a/family/how-to/ha-automations.md +++ b/family/how-to/ha-automations.md @@ -6,6 +6,8 @@ > > **Состав:** 12 контроля батарей (§5) + 2 циркуляция ГВС + 2 свет кабинета (§2.2, §3) + 2 подсветка лестницы + 2 ночной свет душевой (§4.1–§4.6.2) + 2 диммер спальни + 1 протечка котельная + 1 вентиляция + **1 греющий кабель ввода воды (§7)**. > +> 🟠 **РЕШЕНИЕ ПРИНЯТО 2026-09-16 (вечер): объединение двух автоматизаций душевой в ОДНУ по таблице истинности — см. §4.7.** Дизайн согласован и ждёт применения. Дрожание радара (§4.6.2) лечится структурно: `mode: restart` гарантирует **ровно одно выполнение** — новый триггер убивает предыдущее ожидание. Отдельный выбор по `fading_time` снят с повестки. +> > 🗓 **Сессия 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):** `condition:` внутри `sequence:` НЕ отменяет остальные `actions` — прерывает только свою `sequence`, а родительский список продолжается. `light.turn_on`, стоявший **после** `choose`, выполнялся **всегда**, даже когда проверка присутствия вернула `false` (доказано трассировкой: `result: false` и через 1 мс — включение). **Действие обязано быть ВНУТРИ ветки `choose`, после проверки.** Это была ошибка проектирования, а не настройки. @@ -119,8 +121,8 @@ 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` → `wait_for_trigger` на `presence → off`, 6 с → включать только если присутствие держалось) → `light.dushevaia_night_light` on. См. §4.1, §4.5 | -| `1771997918348` | **Выкл. ночной свет душевая** | `not_occupied` (`id: left` → `wait_for_trigger` 10 с → гасить, если присутствие не вернулось) / `illuminance above: 6` (`id: bright` → сразу) → off. `mode: restart`. См. §4.2 | +| `1771997851260` | **Вкл. ночной свет душевая** | `occupied` (`id: presence` — мгновенно) / `illuminance below: 6` (`id: lux` → `wait_for_trigger` на `presence → off`, 6 с → включать только если присутствие держалось) → `light.dushevaia_night_light` on. См. §4.1, §4.5. 🟠 **Подлежит объединению с `1771997918348` в один сценарий — §4.7** | +| `1771997918348` | **Выкл. ночной свет душевая** | `not_occupied` (`id: left` → `wait_for_trigger` 10 с → гасить, если присутствие не вернулось) / `illuminance above: 6` (`id: bright` → сразу) → off. `mode: restart`. См. §4.2. 🟠 **Подлежит отключению при объединении — §4.7** | | `1773451257968` | Протечка котельная | `moist` → `notify.notify` | | `8800000000000`…`8800000000011` | **Батарея: 12 шт.** | см. §6 | | `heating_cable_ctl_0001` | **Греющий кабель: управление** | `time_pattern /15` + `numeric_state ZONT below −8` + отвал датчика → `choose` 5 веток на `switch.heating_cable_plug`. См. §7 | @@ -524,6 +526,8 @@ mode: single 1. **«Зашёл — зажглась будто с задержкой».** Причина: если одновременно с приходом дёрнулась освещённость, срабатывает **ветка `lux`** (с `delay: 5`), а не ветка `presence` (мгновенная). Ощущение задержки — цена 5-секундной паузы в `lux`. 2. **«Зажглось и сразу погасло»** — при заходе без света. Разобрано в §4.6.2: дрожание радара. +> 🟠 **Оба симптома закрываются объединением сценариев (§4.7)** — там ветка `presence` мгновенная, а `mode: restart` не даёт дрожанию радара порождать параллельные прогоны. + ### 4.6.2. 🔴 ДРОЖАНИЕ РАДАРА — источник серий `on/off` (2026-09-16) **Измерено фактом.** Радар `shower_2_presence_sensor` выдаёт `on`/`off` короткими интервалами: @@ -552,12 +556,13 @@ mode: single **Проверено, что реле исправно:** ручной `light.turn_on` → **27 опросов подряд с шагом 200 мс** — состояние `on` стабильно, сброса нет. Значит железо удерживает состояние, а дрожание идёт от логики/датчика. -**Предложенные варианты (НЕ применены, ждут решения Alex):** +**Предложенные варианты (НЕ применены; 🟠 актуальность снята решением §4.7):** | # | Мера | Что лечит | |---|---|---| | 1 | Вернуть `fading_time` → **10 с** | дрожание радара, серии `on/off` | | 2 | Поднять `minimum_range` / сузить зону | если радар задевает движение за дверью | | 3 | Оставить как есть, наблюдать | — | +| 4 | 🟠 **Объединить ВКЛ+ВЫКЛ в один сценарий с `mode: restart`** | дрожание **структурно** — параллельных выполнений не бывает. **Выбрано Alex, см. §4.7** | > ⚠️ **Методическое замечание:** при диагностике Alex **сам дёргал `light.turn_on`/`turn_off` через API** для проверки удержания реле — это загрязняло логи. Записи `LIGHT=on` **без** `AUT-ON` рядом = внешний вызов, а не сценарий. Учитывать при разборе. @@ -602,6 +607,74 @@ mode: single --- +## 4.7. 🟠 ОБЪЕДИНЕНИЕ двух автоматизаций душевой в ОДНУ (2026-09-16, вечер) — ДИЗАЙН СОГЛАСОВАН, ЖДЁТ ПРИМЕНЕНИЯ + +> **Статус:** Alex дал явную команду «если все выполнимо и понятно то делай». Бэкап сделан, конфиг подготовлен (`~/tmp-t610/shower_merged.yaml`), применение — следующим шагом. Проверять актуальное состояние **в живом конфиге**, не по этому разделу. + +**Проблема, которую решаем.** Две автоматизации (`1771997851260` ВКЛ + `1771997918348` ВЫКЛ) реагируют на **одни и те же** события presence/lux и тянут свет в противоположные стороны. Одно движение радара = оба сценария подряд. HA **не имеет** взаимной блокировки между автоматизациями: `mode` действует только внутри своей автоматизации (у ВКЛ `single`, у ВЫКЛ `restart`) — запуск одной не останавливает другую. Это и есть источник гонок. + +**Решение — одна автоматизация, 4 триггера, 4 ветки `choose`, `mode: restart`.** + +### Таблица истинности (согласована Alex) + +| # | presence | lux | trigger | Действие | +|---|---|---|---|---| +| 1 | 1 | low | `P` | вкл | +| 2 | 1 | low | `Llow` | wait 3 c → проверка presence → вкл | +| 3 | 0 | low | `Poff` | ждём 10 c → если не вернулся → выкл | +| 4 | X | hi | `Lhi` | выкл | + +### Триггеры + +```yaml +mode: restart +triggers: +- {platform: device, type: occupied, entity_id: binary_sensor.shower_2_presence_sensor_presence, id: P} +- {platform: device, type: not_occupied, entity_id: binary_sensor.shower_2_presence_sensor_presence, id: Poff} +- {platform: device, type: illuminance, entity_id: sensor.shower_2_presence_sensor_illuminance, below: 6, id: Llow} +- {platform: device, type: illuminance, entity_id: sensor.shower_2_presence_sensor_illuminance, above: 6, id: Lhi} +``` +Все четыре — на одном `device_id: c9d62c9d04a231c4642c705088633121`. + +### Ветки (действие — ВНУТРИ ветки, урок §4.4) + +```yaml +actions: +- choose: + - conditions: [trigger P, presence on, lux below 6] → light.turn_on + - conditions: [trigger Llow, presence on, lux below 6] → delay 3 s → presence on? → light.turn_on + - conditions: [trigger Poff, presence off, lux below 6, light on] + → wait_for_trigger {presence → on}, timeout 10 s, continue_on_timeout: true + → condition: template {{ not wait.completed }} → light.turn_off + - conditions: [trigger Lhi, lux above 6, light on] → light.turn_off + default: [] +``` + +### Ключевые решения и их обоснование + +1. **`mode: restart` — прямой ответ на запрос Alex** («чтобы предыдущий запуск если он ждёт останавливался и по новой прогонялся с другим триггером»). `restart`: новый триггер → текущий запуск **немедленно убивается** (включая `delay`/`wait_for_trigger`) → стартует новый с корректным `trigger.id`. **Лечит дрожание радара (§4.6.2) структурно:** сколько бы раз радар ни флипнул, параллельных выполнений не бывает — всегда ровно одно. Отдельный выбор по `fading_time` больше не нужен. + - ⚠️ Побочный эффект: убитый запуск не докатывает хвост. Если в ветке `Llow` шла `delay: 3`, а прилетел новый триггер — `turn_on` не выполнится, задержка начнётся заново. + - Сравнение режимов: `single` = новое событие игнорируется (опасно с `delay` — зашёл, свет не зажёгся, потому что сценарий занят), `restart` = убить и начать, `queued` = в очередь. +2. **Триггер lux = переход через 6, не любое изменение.** `type: illuminance` с `below`/`above` — это `numeric_state`, срабатывает только на **пересечение порога**. Изменение `1 → 2` сценарий **не** вызывает. Alex формулировал это отдельно и настойчиво; фиксирую как требование. +3. **Ветка 3 — подтверждение ухода.** `wait_for_trigger` на `presence → on`, таймаут 10 с. Гасим **только** если присутствие не вернулось (`{{ not wait.completed }}`). Если вернулось — сработает триггер `P`, `restart` убьёт ожидание, свет не тронем. +4. **Ветка 4 без фильтров.** Alex подтвердил: если lux перешёл 6 вверх и свет горит → гасим. Сознательно **не** добавлен фильтр «не гасить только что включённое» — не выдумывать сверх постановки. +5. **lux остаётся триггером** (Alex отдельно возмутился попытке его убрать). В таблице он используется и как триггер, и как условие — это осознанное решение владельца, не менять. + +### ⚠️ Что дальше делать (применение) + +1. Записать конфиг через REST `POST /api/config/automation/config/1771997851260` (**поля во множественном числе**: `triggers`/`conditions`/`actions`). +2. **Прочитать обратно и сверить** — POST отдаёт `200 ok` даже когда значения не поменялись. +3. Вторую автоматизацию `1771997918348` **отключить** (`automation.turn_off`), **не удалять** — как откат. +4. `POST /api/services/automation/reload`, проверить 25/24 `on`/1 `off`, `unavailable` = 0. + +**Бэкап:** `/config/automations.yaml.bak-shower-merge-20260916-214012` (t610). +**Подготовленный конфиг:** `~/tmp-t610/shower_merged.yaml` (черновик `shower_merged.json` — брак, удалить/игнорировать). + +> ⛔ **ПИТФОЛЛ ПРОЦЕССА (повторялся дважды в этой сессии):** на **вопрос** Alex («могут ли взаимоисключаться», «знает ли сценарий свой триггер») отвечать **словами**, а не лезть читать сенсоры/историю. Каждый преждевременный поход в систему = «какого хуя ты пошел чето делать». Действия — только после явного «делай». +> ⛔ **Не объяснять устройство датчика заново.** Alex дважды резко отреагировал на рассуждение «подсветка засвечивает датчик» — он это знает и считает irrelevant к постановке. Не повторять. + +--- + ## 5. 🔋 Контроль батарей — 12 автоматизаций (2026-09-15) **Единый шаблон**, id `8800000000000`…`8800000000011`: diff --git a/family/tech/zigbee-t610-z2m-i-zha.md b/family/tech/zigbee-t610-z2m-i-zha.md index c2153590..93970d5e 100644 --- a/family/tech/zigbee-t610-z2m-i-zha.md +++ b/family/tech/zigbee-t610-z2m-i-zha.md @@ -560,6 +560,35 @@ curl -s -H "$H" "$B/api/logbook/$T+00:00?entity=automation." ``` Без этого легко «найти» баг автоматизации там, где был ручной тестовый вызов. +### 13.5.5. 🔴 `mode` автоматизации действует ТОЛЬКО внутри неё (2026-09-16, вечер) + +**Взаимной блокировки между автоматизациями в HA НЕТ.** Запуск одной не останавливает другую, даже если обе управляют одной сущностью. Две автоматизации душевой (ВКЛ `single` + ВЫКЛ `restart`) реагируют на одни и те же события presence/lux и тянут свет в противоположные стороны — побеждает тот `turn_*`, что выполнился последним. Это **гонка**, а не логический конфликт условий. + +| `mode` | Поведение при новом триггере во время работы | +|---|---| +| `single` | новое событие **игнорируется** | +| `restart` | текущий запуск **убивается** (включая `delay`/`wait_for_trigger`), стартует новый | +| `queued` | встаёт в очередь, выполнится после | + +> ⚠️ **`single` + `delay` — скрытая потеря срабатываний.** Пока идёт `delay`, новый триггер молча отбрасывается: «зашёл, свет не зажёгся, потому что сценарий был занят». +> ✅ **`restart` — правильный выбор, когда нужен ровно один прогон.** Он структурно лечит дрожание датчика: сколько бы раз радар ни флипнул, параллельных выполнений не бывает. + +**`trigger.id` — как сценарий узнаёт, какой триггер сработал:** +- каждый триггер получает метку `id`; в `actions` доступно `trigger.id` / `trigger.platform`; +- доступен **только сработавший сейчас** триггер — проверить оба состояния можно лишь через `condition: state`, не через `trigger`; +- **`automation.trigger` без `skip_condition` даёт пустой `trigger.id`** — ветки `condition: trigger` уходят в `default`, так тестировать нельзя; +- у триггера без `id` значение будет `null`, а не имя. + +> 📌 **Триггер по освещённости `type: illuminance` с `below`/`above` = `numeric_state`** — срабатывает только на **пересечение порога**. Изменение `1 → 2` сценарий не запускает. (Alex проговаривал это отдельно как требование.) + +### 13.5.6. 🧠 Процессный питфолл: вопрос ≠ команда действовать + +Дважды за сессию Alex резко реагировал («какого хуя ты пошел чето делать», «хули ты полез делать») на попытку **проверить систему вместо ответа на вопрос**. Вопросы вида «могут ли два сценария взаимоисключаться?», «знает ли сценарий свой триггер?» — это **теоретические вопросы**, ответ на них даётся словами, из уже известных фактов. + +Правило: **пока нет явного «делай/применяй» — только текст.** Чтение живого конфига/сенсоров/истории = действие, требует команды. + +**Связанный питфолл:** не переобъяснять Alex устройство его же системы. Рассуждение «подсветка засвечивает датчик освещённости» он дважды отклонил как irrelevant — он это знает. Если он говорит «олень»/«нихуя не понял» — значит ответ был **не на его вопрос**, а не то, что он не понимает тему. + --- ## Связанные заметки