[2026-09-15] eagle: family/how-to/ha-automations.md family/plans/t610-zigbee-ids-battery-freshsensors-modbus.md

family/how-to/ha-automations.md

@@ -2,11 +2,14 @@
 
 > **Справочник логики автоматизаций** (`automations.yaml` на t610). Топология/команды/Modbus — [[family/how-to/home-automation]].
 
-> 🟢 **АКТУАЛЬНО 2026-09-15 (поздний вечер): 26 АВТОМАТИЗАЦИЙ — 25 `on`, 1 `off` (`Ventilation automation on`, намеренно), `unavailable` = 0.** Zigbee работает на ZHA.
+> 🟢 **АКТУАЛЬНО 2026-09-15 (поздний вечер): 24 АВТОМАТИЗАЦИИ — 23 `on`, 1 `off` (`Ventilation automation on`, намеренно), `unavailable` = 0.** Zigbee работает на ZHA.
+>
+> 📌 **Сверка счёта:** в §1 ниже упоминается «26» — это счёт **включая 2 удалённые батарейные**, которые ещё числились сиротами в реестре. После чистки реестра фактически **24**. Брать 24.
 >
 > **➕ Добавлено в этот вечер: 12 автоматизаций контроля батарей** (id `8800000000000`…`8800000000011`, все `on`). Порог **20 %**, выдержка **2 ч**, двойной канал: `persistent_notification` + push `notify.mobile_app_sm_s931b`; при возврате заряда уведомление гасится (`notification_id: bat_<slug>`). Детали — §5.
 > ⛔ **Удалены 2 прежние батарейные** (`1773451323415`, `1773459663218`) — были с порогом 10 и без push. Их осиротевшие записи в реестре вычищены (питфолл §5.1).
-> 🔄 **Переименованы** ссылки после единообразия ID: `light.night_light_shower_2` → `light.dushevaia_night_light`, `sensor.tz3000_akqdg6g7_ts0201_batareia` → `sensor.kabinet_temperature_battery`.
+> 🔄 **Переименованы** ссылки после единообразия ID: `light.night_light_shower_2` → `light.dushevaia_night_light`, `sensor.tz3000_akqdg6g7_ts0201_batareia` → `sensor.kabinet_temperature_battery` → `sensor.garderobnaia_temperature_battery` (датчик перенесён в Гардеробную).
+> 🔴 **`entity_id` автоматизаций HA перегенерировал по alias** — искать автоматизацию по `attributes.id`, не по `entity_id`. Пример: `automation.datchik_protechki_kotelnaia_batareia` → `automation.batareia_kotelnaia_datchik_protechki`.
 > 📄 Полный отчёт о работах: [[family/plans/t610-zigbee-ids-battery-freshsensors-modbus]].
 >
 > Переезд Zigbee Z2M → ZHA выполнен. Автоматизации были сломаны не по `entity_id`, а глубже — они ссылались на `device_id` + внутренний `entity_id`-UUID, а устройства Z2M удалены. **Пересобраны заново** на ZHA-шные `device_id` + актуальные `entity_id`.
@@ -31,8 +34,8 @@
 ## 1. Где живёт
 
 - **Файл:** `/config/automations.yaml` в HA Core на t610.
-- **Всего:** **26 автоматизаций — 25 `on`, 1 `off`** (`Ventilation automation on`, намеренно, `last_triggered` 12 марта), **`unavailable` = 0**. Файл = 228 строк.
+- **Всего:** **24 автоматизации — 23 `on`, 1 `off`** (`Ventilation automation on`, намеренно, `last_triggered` 12 марта), **`unavailable` = 0**. Файл = 228 строк.
-- **Бэкапы перед правками 2026-09-15 (поздний вечер):** `/config/automations.yaml.bak-preids-20260915-223427`; рабочая копия — `~/tmp-t610/autfix-20260915-223427/automations.yaml` (плюс `.pre-bat` — до добавления батарейных).
+- **Бэкапы перед правками 2026-09-15 (поздний вечер):** `/config/automations.yaml.bak-preids-20260915-223427`, `/config/automations.yaml.bak-gard-20260915-225404` (перед переносом датчика в Гардеробную); рабочая копия — `~/tmp-t610/autfix-20260915-223427/automations.yaml` (плюс `.pre-bat` — до добавления батарейных).
 - **Удалены 4 «призрака»** (записи в реестре без тела): `svetlo_vykl_osveshchenie_lestnitsy`, `temno_vkl_podsvetku_lestnitsy`, `datchik_osveshchennosti_lestnitsa_batareia`, `light_switch_bed_batareia`. Тела не было (`config/automation/config/<id>` → 404) — лестничные сценарии **пересозданы заново** с теми же id.
 - **Локальная копия:** `~/tmp-t610/automations/automations.yaml`; после пересборки — `~/tmp-t610/automations-new.yaml`, `~/tmp-t610/automations-fixed.yaml`.
 - **Читать живьём через API** (не по памяти):
@@ -174,7 +177,7 @@ REST `GET/POST /api/config/automation/config/<id>` использует поля
 | `8800000000001` | Лестница (освещённость) | `sensor.light_sensor_stairs_battery` |
 | `8800000000002` | Душевая (тёплый пол) | `sensor.dushevaia_floor_temperature_battery` |
 | `8800000000003` | Котельная (протечка) | `sensor.boiler_water_leak_battery` |
-| `8800000000004` | Кабинет (температура) | `sensor.kabinet_temperature_battery` |
+| `8800000000004` | Гардеробная (температура) — датчик перенесён из Кабинета 2026-09-15 | `sensor.garderobnaia_temperature_battery` |
 | `8800000000005` | Гостиная (тёплый пол) | `sensor.living_room_floor_temperature_battery` |
 | `8800000000006` | Серая (тёплый пол) | `sensor.severnaia_floor_temperature_battery` |
 | `8800000000007` | Кабинет (тёплый пол) | `sensor.kabinet_floor_temperature_battery` |
@@ -198,8 +201,18 @@ REST `GET/POST /api/config/automation/config/<id>` использует поля
    Реальный случай: после удаления тел `1773451323415` / `1773459663218` обе сущности остались `unavailable`.
 5. ⚠️ **`sensor.wireless_light_switch_bed_battery` = `unknown`** — кнопка спальни спит. Автоматизация создана, но триггера не будет, пока датчик не проснётся (лечится нажатием кнопки).
 6. ⚠️ **Проверять имена сущностей после переименований:** в ZHA домен бывает `_batareia`, но `trigger: battery_level` (не `battery`).
+7. 🔴 **`id_reuse: Identifier values have to increase` при переименовании сущности** (проверено 2026-09-15: 6 из 7 упало, хотя целевые `entity_id` свободны). Это внутренний счётчик реестра, **не поломка**. Обход — промежуточное имя:
+   ```python
+   {"type":"config/entity_registry/update","entity_id": old, "new_entity_id": tmp}  # dom.tmp_xxx
+   {"type":"config/entity_registry/update","entity_id": tmp, "new_entity_id": new}
+   # при провале 2-го шага — откат: tmp → old
+   ```
+   Общий принцип: **любая операция реестра, падающая с `id_reuse`, лечится промежуточным состоянием** (для сирот-автоматизаций — `disabled_by: user`, см. питфолл 4).
+8. 🔴 **HA перегенерирует `entity_id` автоматизаций по alias при `reload`.** Проверять/искать по `attributes.id`, не по `entity_id`. Пример: `automation.datchik_protechki_kotelnaia_batareia` → `automation.batareia_kotelnaia_datchik_protechki`.
 
-**Скрипты:** `~/tmp-t610/add_battery_autos.py` (генератор), `~/tmp-t610/rm_orphans.py`, `rm_orphan2.py`, `rm_orphan3.py`.
+**Скрипты:** `~/tmp-t610/add_battery_autos.py` (генератор), `~/tmp-t610/rm_orphans.py`, `rm_orphan2.py`, `rm_orphan3.py`, `gard_fix.py` (правка ссылок при переносе датчика), `fix_aut_entid.py` (правка `entity_id` автоматизации).
+
+> ⚠️ **ОТКРЫТО (на 2026-09-15):** Alex сообщил, что HA ругается на «**Office temperature sensor battery** — нет уникального id, устройство недоступно». **Проверено: призрака в бэкенде НЕТ** (нет в `/api/states`, нет в реестре из 572 записей, MQTT-сущностей без `unique_id` — 0, config entries все `loaded`). Вероятный источник — UI-кэш или дашборд-карточка. **Нужно уточнить у Alex экран** (Настройки → Устройства → MQTT / дашборд / Developer Tools) и вычистить прицельно.
 
 > 📄 Полный отчёт о работах: [[family/plans/t610-zigbee-ids-battery-freshsensors-modbus]]
 

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

@@ -195,7 +195,7 @@ ssh -i ~/.ssh/id_rsa root@192.168.2.176 'cat /config/automations.yaml' \
 
 | Slave | HA-сущность |
 |---|---|
-| **100** | `sensor.kabinet_temperature_temperature` (исторический «Room temp») |
+| **100** | `sensor.garderobnaia_temperature_temperature` (исторический «Room temp»; был `office_temperature_sensor` → `kabinet_temperature`) |
 | 105 | `sensor.living_room_floor_temperature_temperature` |
 | 106 | `sensor.severnaia_floor_temperature_temperature` |
 | 107 | `sensor.kabinet_floor_temperature_temperature` |
@@ -237,6 +237,74 @@ ssh root@192.168.2.176 'ha apps rebuild local_modbus-bridge && ha apps start loc
 
 ---
 
+## 4bis. ✅ ПОСЛЕ ПЛАНА — датчик перенесён в Гардеробную (2026-09-15, 22:54–23:56)
+
+**Задача Alex (вне исходного плана):** «Переименуй этот датчик в датчик гардеробная и перемести в нее и обнови конфиг моста» → «Кабинет который» (т.е. исторический `office_temperature_sensor`).
+
+**Контекст:** в UI датчик не находился под старым именем (`office_temperature_sensor`) — потому что был переименован в `kabinet_temperature` шагом 1. Именно он и был перенесён.
+
+| Что | Было | Стало |
+|---|---|---|
+| Имя устройства | `kabinet_temperature` | `garderobnaia_temperature` |
+| Зона | `kabinet` | `garderobnaia` |
+| Сущности (7) | `sensor.kabinet_temperature_*` | `sensor.garderobnaia_temperature_*` |
+| Bridge slave 100 | `sensor.kabinet_temperature_temperature` | `sensor.garderobnaia_temperature_temperature` |
+| Автоматизация батареи | «Кабинет (температура)», `bat_kabinet_temperature` | «Гардеробная (температура)`, `bat_garderobnaia_temperature` |
+| entity_id автоматизации | `automation.batareia_kabinet_temperatura` | `automation.batareia_garderobnaia_temperatura` |
+
+**Проверено фактом:** `Response: 1 register(s) from 100 (ha:sensor.garderobnaia_temperature_temperature) = 24.61 [00 F6]`.
+
+### 🔴 Питфолл: `id_reuse: Identifier values have to increase`
+
+При переименовании сущностей **6 из 7 упали** с этой ошибкой (хотя целевые `entity_id` были свободны). Это внутренний счётчик реестра, **не поломка**.
+
+**Обход (проверен, 6/6 успешно):** переименовать в промежуточное имя, затем из него в целевое.
+
+```python
+# entity_id → dom.tmp_xxx → dom.новое_имя
+{"type":"config/entity_registry/update","entity_id": old, "new_entity_id": tmp}
+{"type":"config/entity_registry/update","entity_id": tmp, "new_entity_id": new}
+# при провале second step — откат на old
+```
+
+> 📌 Тот же приём уже применялся для сироты-автоматизации (§3.2, `disabled_by` + `remove`). Общее правило: **любая операция реестра с `id_reuse` лечится промежуточным состоянием.**
+
+### 🔴 Питфолл: HA сам перегенерировал `entity_id` автоматизаций
+
+После `automation/reload` автоматизации получили новые `entity_id` **по alias**: `automation.datchik_protechki_kotelnaia_batareia` → `automation.batareia_kotelnaia_datchik_protechki`. Проверять автоматизации по **`attributes.id`**, а не по `entity_id`.
+
+### Аудит автоматизаций (запрошен Alex: «убедись что автоматизация вся корректная»)
+
+| Метрика | Значение |
+|---|---|
+| Всего | 24 |
+| `on` | 23 |
+| `off` | 1 — `Ventilation automation on` (намеренно) |
+| `unavailable` | **0** |
+| Битых ссылок | **0** (22 проверено) |
+| Батарейных | 12, все `on` |
+
+**Бэкапы этого этапа:** `/config/automations.yaml.bak-gard-20260915-225404`, `/addons/modbus-bridge/data/config.template.tmpl.bak-gard-20260915-225404`, реестры в `~/tmp-t610/backup-gard-20260915-225404.json`.
+
+**Скрипты:** `~/tmp-t610/{gard_step1,gard_step2,gard_step2b,gard_fix,fix_aut_entid}.py`.
+**Коммит vault:** `db20bb8`.
+
+### ⚠️ НЕ ЗАКРЫТО (на момент записи)
+
+Alex сообщил: «**Office temperature sensor battery** — HA ругается что у устройства нет уникального id и оно недоступно».
+
+**Проверено — призрака в бэкенде НЕТ:**
+- `sensor.office_temperature_sensor*` в `/api/states` — отсутствует;
+- в реестре сущностей (572 записи) — нет упоминаний;
+- MQTT-сущности без `unique_id` — **0**;
+- MQTT-устройства-призраки Z2M — 4, все легитимные (3 сниффера + H2000);
+- config entries `mqtt`/`zha`/`generic` — 3, все `loaded`, призраков нет;
+- лог HA Core на `unique_id`/`office` — пусто.
+
+**Вывод:** источник сообщения — UI-кэш (браузер/приложение) либо дашборд-карточка. Требуется уточнение от Alex: **в каком именно экране ругается** (Настройки → Устройства → MQTT / дашборд / Developer Tools / лог автоматизаций). Следующая сессия: спросить экран и вычистить прицельно.
+
+---
+
 ## 5. ✅ РЕЗУЛЬТАТ — Шаг 5: дока обновлена
 
 - `family/tech/zigbee-t610-z2m-i-zha.md` — карта 16 → 23 устройств, §2.1 «как переименовывать», §4 батареи, §5 виртуальные Modbus, питфоллы 17–21.
@@ -269,6 +337,9 @@ ssh root@192.168.2.176 'ha apps rebuild local_modbus-bridge && ha apps start loc
 | 5 | Bridge нельзя проверить без ZONT'а иначе, чем через `HA poll ->` в логе |
 | 6 | `rebuild` (не `restart`) после правки `data/config.template.tmpl` |
 | 7 | Русские имена устройств → HA транслитерирует в мусорные `entity_id` |
+| 8 | `id_reuse: Identifier values have to increase` — штатная ошибка реестра, обходится промежуточным именем (`old → tmp → new`) |
+| 9 | HA перегенерирует `entity_id` автоматизаций по alias при `reload` — искать по `attributes.id` |
+| 10 | Датчик, «не находимый в UI», может быть переименован — искать по IEEE в реестре, а не по старому имени |
 
 ## Связанные заметки