diff --git a/family/how-to/t610-access.md b/family/how-to/t610-access.md index d46ebaf3..298bbdd5 100644 --- a/family/how-to/t610-access.md +++ b/family/how-to/t610-access.md @@ -478,6 +478,13 @@ jq -r '.data.devices[] | select((.identifiers|tostring)|contains(" **Статус (2026-09-14): Этап 1 ✅. Этап 2 ✅ ПОЛНОСТЬЮ. Этап 3 ✅ ОСНОВНОЕ ВЫПОЛНЕНО — реестры и конфиг перенесены, БД с нуля, `localtuya`/HACS сняты, z2m приведён к **14 живым** устройствам (удалены 3 мёртвых), все `entity_id` в HA переименованы в человеческие (**hex = 0**), `friendly_name` в z2m — латиница snake_case, `switch_as_x` восстановлены (виртуальные `light.*` работают), дашборд поправлен.** -> ⚠️ **ОСТАЛОСЬ ПОЧИНИТЬ (блокер): 13 из 16 автоматизаций `unavailable` — ссылаются на `device_id` с TrueNAS, которых нет на t610.** Маппинг собран, см. §«ПИТФОЛЛ: device_id ломаются при переносе реестра». Далее: `sensor.*_summary` template-ошибки (`default(0)`), Этап 4. +> ⚠️ **ОСТАЛОСЬ ПОЧИНИТЬ (блокер): 13 из 16 автоматизаций `unavailable`.** Причина установлена полностью — **две поломки одного класса** (обе от переноса между инстансами): ① `device_id` (9 шт., 20 вхождений) — маппинг собран **9/9**, файл-кандидат готов; ② hex-`entity_id` в `automations.yaml` (2 шт.). См. §«ПИТФОЛЛ: device_id ломаются при переносе реестра». Далее: `sensor.*_summary` template-ошибки (`default(0)`), Этап 4. > Сервисы: z2m (14), mbusd (502), modbus-bridge (MQTT + HA-опрос), MQTT-интеграция в HA. > Родительский план: [[family/plans/home-automation-migration-t610]] (Шаг 3 в нём заменяется на этот документ). > Доступ к хосту, CLI и питфоллы: [[family/how-to/t610-access]]. @@ -553,7 +553,7 @@ timeout 10 mosquitto_sub -h core-mosquitto -p 1883 -u zont -P "$MPW" \ ⚠️ **Питфолл:** при переносе реестров **`core.config_entries` тоже нужен**, если есть виртуальные сущности (`switch_as_x`, `template`, helper'ы) — иначе их entry теряются и сущности висят `unavailable`. Мы не переносили его ради сохранения MQTT-интеграции → добавляли `switch_as_x` точечно. -#### 🔴 ПИТФОЛЛ: `device_id` ломаются при переносе реестра (ОТКРЫТО, 2026-09-14) +#### 🔴 ПИТФОЛЛ: `device_id` ломаются при переносе реестра — ✅ МАППИНГ СОБРАН 9/9, ЗАЛИВКА НЕ ВЫПОЛНЕНА **Симптом:** после переноса реестров и старта HA **13 из 16 автоматизаций стали `unavailable`**. В `ha core logs`: ``` @@ -561,20 +561,27 @@ ERROR (MainThread) [homeassistant.components.automation] Automation with alias ' failed to setup triggers and has been disabled: Unknown device 'c42ce32c73731941884bcbf0c2b2d077' ``` -**Причина:** `device_id` — это **UUID, генерируемый HA при регистрации устройства в КОНКРЕТНОМ инстансе**. Хотя `core.device_registry` перенесён с TrueNAS, MQTT-интеграция t610 **зарегистрировала устройства заново** (запись MQTT-интеграции у нас своя, t610-шная) → выдала **новые** `device_id`. Реестр потом перезаписался перенесённым, но `device_id` в нём остались TrueNAS-овские... а фактические — другие. +**Причина:** `device_id` — это **UUID, генерируемый HA при регистрации устройства в КОНКРЕТНОМ инстансе**. Хотя `core.device_registry` перенесён с TrueNAS, MQTT-интеграция t610 **зарегистрировала устройства заново** (запись MQTT-интеграции у нас своя, t610-шная) → выдала **новые** `device_id`. Автоматизации остались со старыми TrueNAS-овскими. ⚠️ **Главный вывод: `device_id` НЕ переносятся между инстансами HA.** `entity_id` и `unique_id` — переносятся; `device_id` — НЕТ. Автоматизации/скрипты, ссылающиеся на `device_id` (а это все device-trigger'ы в UI), ломаются. -**Маппинг (TrueNAS → t610), собран 2026-09-14:** +##### ✅ Полный маппинг — 9/9, собран 2026-09-14 (метод: по `identifiers`) -| Устройство | `device_id` в автоматизациях (TrueNAS) | Актуальный на t610 | -|---|---|---| -| `recirculation_pump` (Насос обратки, `f8da8bc478`) | `234686e6c83f7d19c9e10b2f0d1fcc59` | `16d2c6f64ec399e5261c89b35c1e75c6` | -| `light_sensor_stairs` (`6d40ddb67b`) | `7f102ad2e78960fff6ebc5f01c0bba93` | `1ea8bbc2612dde303e4279bc5fbad57a` | -| `boiler_water_leak` (`3d5fcaa063`) | `c42ce32c73731941884bcbf0c2b2d077` | `b9d384a51b780a7924ed9504eddec12e` | -| `shower_2_presence_sensor` (`c4a94a6a31`) | `7f74e7077d7fa23e405f2c5e25f6fa17` | `4095e7c3b47b9dc9640cfb8c3aeff022` | -| `wireless_light_switch_bed` (`b0f9e674a5`) | `757e0e9b1e5771e0c700a9df852b0549` | `5cd5d9d2d289b5e470bbeaac0eb7905c` | -| `office_temperature_sensor` (`62d39377e6`) | `52266a1b4a9d301f0da0dfa6f97c4ea2` | `bcf47eeae909877978bdaf6c705210f8` | +**Метод (надёжный, воспроизводимый):** взять TrueNAS-реестр `core.device_registry` (оттуда, где `device_id` из автоматизаций ЕСТЬ) → для каждого устройства вытащить `identifiers` (для zigbee = `[[\"mqtt\",\"zigbee2mqtt_\"]]`) → найти на t610 устройство с **тем же `identifiers`** → его `id` и есть актуальный `device_id`. + +| # | Устройство | `device_id` TrueNAS (в автоматизациях) | `device_id` t610 (актуальный) | Замен | +|---|---|---|---|---| +| 1 | `night_light_shower_2` (`84fd27fffed9e137`) | `0c7a0eb6d60e852b447266da69a7785e` | `4d6e55505ff7dbad13d2674cdcb18d5a` | 2 | +| 2 | `recirculation_pump` (`f8da8bc478`) | `234686e6c83f7d19c9e10b2f0d1fcc59` | `16d2c6f64ec399e5261c89b35c1e75c6` | 2 | +| 3 | `bed_dimmer` (`82a4b42db0`) | `2862be34f5eaaa39b9d51084a1f921ee` | `098a641cb1d30f08f1ae293e00d9885b` | 1 | +| 4 | `office_temperature_sensor` (`62d39377e6`) | `52266a1b4a9d301f0da0dfa6f97c4ea2` | `bcf47eeae909877978bdaf6c705210f8` | 1 | +| 5 | `wireless_light_switch_bed` (`b0f9e674a5`) | `757e0e9b1e5771e0c700a9df852b0549` | `5cd5d9d2d289b5e470bbeaac0eb7905c` | 3 | +| 6 | `light_sensor_stairs` (`6d40ddb67b`) | `7f102ad2e78960fff6ebc5f01c0bba93` | `1ea8bbc2612dde303e4279bc5fbad57a` | 3 | +| 7 | `shower_2_presence_sensor` (`c4a94a6a31`) | `7f74e7077d7fa23e405f2c5e25f6fa17` | `4095e7c3b47b9dc9640cfb8c3aeff022` | 4 | +| 8 | `light_stairs` (`6d0839706a`) | `9d3f31b1b49c95433428afbb113d929b` | `028b7d9f489c87bdc9e563473a1d61e8` | 2 | +| 9 | `boiler_water_leak` (`3d5fcaa063`) | `c42ce32c73731941884bcbf0c2b2d077` | `b9d384a51b780a7924ed9504eddec12e` | 2 | + +**Итого: 9 `device_id` из автоматизаций (все 9 — zigbee), 20 вхождений.** ⚠️ Прежняя оценка «6 UUID» была неполной — реальных уникальных `device_id` **9**. В `scripts.yaml` device-ссылок **0** (проверено). **Как получить актуальные `device_id` (bash+jq на t610):** ```bash @@ -583,9 +590,23 @@ jq -r '.data.devices[] | select((.identifiers|tostring)|contains(""]]` → `id` = искомый `device_id`. -**План починки (НЕ выполнено):** `ha core stop` → заменить 6 UUID в `automations.yaml` (9 вхождений `device_id` + 12 `entity_id`-UUID) и в `scripts.yaml`, если есть → `ha core start` → проверить, что автоматизации `on`. Скрипт писать файлом (в аддоне **нет python3** — только bash+jq). +⚠️ **Получение TrueNAS-реестра:** `/mnt/RED_2TB/docker/ha/.storage/core.device_registry` **читается без sudo** (права 644, owner root) — `scp` работает напрямую. `sudo cat` падает (`a terminal is required to read the password`) — sudo не нужен. -⚠️ **Мораль для будущих переносов HA:** либо переносить `core.config_entries` целиком вместе с реестрами (тогда `device_id` согласуются), либо **после переноса обязательно перемапить `device_id`** в `automations.yaml`/`scripts.yaml` по `identifiers`. Мы выбрали не переносить `core.config_entries` (чтобы сохранить MQTT-интеграцию t610) — отсюда и разрыв. +##### 🔴 ВТОРАЯ ПОЛОМКА ТОГО ЖЕ КЛАССА: hex `entity_id` в `automations.yaml` (2 шт.) + +⚠️ **Тот же класс проблемы, что и `device_id`, её легко пропустить.** При переименовании реестра (`hex → человеческие entity_id`) **ссылки в `automations.yaml` не обновлялись** → в автоматизациях остались старые hex-`entity_id`: +- `light.0xa4c13882a4b42db0` → должно быть **`light.bed_dimmer`** (в реестре уже человеческое). +- `switch.0xa4c13873b5c1575b` → ⚠️ **неоднозначно**: у устройства теперь два канала `switch.office_table_light_switch_l1` / `_l2` (z2m разбил на каналы), а в автоматизации одна старая сущность. Требует разбора, какой канал использовался на TrueNAS (см. §«Осталось»). + +**Мораль:** при переносе HA надо чистить **и `device_id`, и hex-`entity_id`** одновременно — иначе автоматизация «чинится» наполовину. + +##### План починки (собран, НЕ залит) + +**Файл-кандидат:** `~/tmp-t610/etap3-fix/automations.fixed.yaml` — 20 замен `device_id`, 0 старых осталось, все 20 новых проверены по реестру t610 (`core.device_registry`), все ссылки валидны. Бэкап: `automations.yaml.bak-20260914-114235`. + +**Порядок:** доделать hex-`entity_id` (`light.0xa4c13882a4b42db0` → `light.bed_dimmer`; решить по `switch.0xa4c13873b5c1575b`) → `ha core stop` → залить `automations.yaml` → `ha core start` → проверить, что автоматизации `on`. + +⚠️ **Мораль для будущих переносов HA:** либо переносить `core.config_entries` целиком вместе с реестрами (тогда `device_id` согласуются), либо **после переноса обязательно перемапить `device_id`** в `automations.yaml`/`scripts.yaml` по `identifiers`, **и заодно проверить hex-ссылки `entity_id`**. Мы выбрали не переносить `core.config_entries` (чтобы сохранить MQTT-интеграцию t610) — отсюда и разрыв. #### ⚠️ `sensor.*_summary` — TemplateError (косметика, самоизлечится) @@ -674,15 +695,15 @@ cp /tmp/reg.new.json "$REG"; chown root:root "$REG"; chmod 644 "$REG" **Счётчики живого API:** 233 сущности, `unavailable` 45, `unknown` 82. -**🔴 ПЕРВООЧЕРЕДНОЕ (блокер):** починить `device_id` в 13 автоматизациях — см. §«ПИТФОЛЛ: device_id ломаются при переносе реестра». Маппинг из 6 UUID уже собран. +**🔴 ПЕРВООЧЕРЕДНОЕ (блокер) — ДИАГНОСТИКА ЗАВЕРШЕНА, ОСТАЛОСЬ ЗАЛИТЬ:** починить 13 автоматизаций `unavailable` — см. §«ПИТФОЛЛ: device_id ломаются при переносе реестра». **Маппинг `device_id` полный (9/9, 20 вхождений)**, файл-кандидат `~/tmp-t610/etap3-fix/automations.fixed.yaml` готов и проверен. **Осталось:** ① решить hex-`entity_id` `switch.0xa4c13873b5c1575b` (l1 или l2?); ② `light.0xa4c13882a4b42db0` → `light.bed_dimmer`; ③ `ha core stop` → залить → `ha core start`. **Далее:** -1. Проверить `scripts.yaml` на те же битые `device_id` (в нём device-ссылок не нашли, но перепроверить). +1. `scripts.yaml` — device-ссылок **0**, hex-`entity_id` **0** (проверено, чистить нечего). 2. `sensor.*_summary` — добавить `|default(0)` в template-сенсоры `configuration.yaml` (косметика). 3. Проверить дашборд `home_plan` визуально (ссылки теперь человеческие). 4. Этап 4: Caddy upstream → t610, GPON-редирект → t610, отключить TrueNAS. -**Ключевые пути/скрипты сессии:** `~/tmp-t610/` — `stage3/out/` (staged комплект), `backups/` (2 tar.gz), `z2m-new-config.yaml`, `do_rename_jq.sh`, `add_switchasx.py`, `apply_switchasx.sh`, `fix_dash2.sh`, `ha_token.txt`, `t610-config-entries.json`. На t610: `/config/.storage/*.bak-*`, `/config/zigbee2mqtt/configuration.yaml.bak-*`, `/tmp/stage3-prev/`. +**Ключевые пути/скрипты сессии:** `~/tmp-t610/` — `stage3/out/` (staged комплект), `backups/` (2 tar.gz), `z2m-new-config.yaml`, `do_rename_jq.sh`, `add_switchasx.py`, `apply_switchasx.sh`, `fix_dash2.sh`, `ha_token.txt`, `t610-config-entries.json`. **Правка автоматизаций:** `~/tmp-t610/etap3-fix/` — `automations.fixed.yaml`, `devid_mapping.json`, `automations.yaml.bak-20260914-114235`, `truenas.device_registry`, `core.device_registry`, `core.entity_registry`, `scripts.yaml`. На t610: `/config/.storage/*.bak-*`, `/config/zigbee2mqtt/configuration.yaml.bak-*`, `/tmp/stage3-prev/`. ### Этап 4 — проверка и отключение TrueNAS 18. [ ] Чек-лист из родительского плана §6