From 43d785799192106260f1846896976c2cab02f63b Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Tue, 15 Sep 2026 20:54:03 +0600 Subject: [PATCH] [2026-09-15] eagle: family/tech/zigbee-t610-z2m-i-zha.md --- family/tech/zigbee-t610-z2m-i-zha.md | 136 +++++++++++++++++++++++---- 1 file changed, 120 insertions(+), 16 deletions(-) diff --git a/family/tech/zigbee-t610-z2m-i-zha.md b/family/tech/zigbee-t610-z2m-i-zha.md index 677d05af..e650ffa4 100644 --- a/family/tech/zigbee-t610-z2m-i-zha.md +++ b/family/tech/zigbee-t610-z2m-i-zha.md @@ -1,10 +1,10 @@ --- title: "Zigbee на t610 — переезд Z2M → ZHA (выполнен, 2026-09-15)" created: '2026-09-15' -updated: '2026-09-15 (ночь-15, доп. 2: ✅ `light_sensor_stairs` ДОБАВИЛСЯ — ZHA 17 устройств, 16/16; сущности датчика переименованы; 🔴 обнаружены ещё 2 битых автоматизации диммера с `triggers: []` и чужой `device_id`; `event.*` кнопки спальни — так и не появился при 90-секундном слушании шины)' +updated: '2026-09-15 (ночь-16: 🔴🔴 НАЙДЕН НАСТОЯЩИЙ КОРЕНЬ «кнопка не свитчит» — `_TZ3000_kccru4oi` в `input` НЕ ИМЕЕТ кластера `OnOff 0x0006` (он в `output`), `exposes_features: []` → ZHA из неё `event.*` не сделает НИКОГДА, нажатия и `permit` бесполезны (см. §Факт 5-тер). Исправленный `automations-fixed.yaml` собран, НЕ залит. `light_sensor_stairs` добавлен, `light.bed_dimmer`/`switch.sauna` переименованы)' type: tech namespace: family -status: 🟢 ZHA работает, 16/16 устройств, ВСЕ батарейные подхвачены. Имена `light.bed_dimmer`/`switch.sauna` исправлены, сущности датчика лестницы переименованы. Осталось: `event.*` кнопки спальни (нажатие не долетело), 2 автоматизации диммера с пустыми триггерами + чужими entity_id, косметика `select.bed_dimmer_*`. +status: 🟢 ZHA работает, 16/16 устройств. Имена `light.bed_dimmer`/`switch.sauna` исправлены, сущности датчика лестницы переименованы. 🔴 Кнопка спальни `_TZ3000_kccru4oi` в ZHA неработоспособна по железу (нет `input: 0x0006`) — нужна группа+bind или замена кнопки. Осталось: путь кнопка→диммер, заливка `automations-fixed.yaml`, 4 кривых автоматизации, косметика `select.bed_dimmer_*`. tags: - t610 - haos @@ -23,7 +23,7 @@ related: # Zigbee на t610 — переезд Z2M → ZHA (история + рабочий рецепт) -> 🚦 **СОСТОЯНИЕ НА 2026-09-15 (ночь-15, ФИНАЛ) — ZHA РАБОТАЕТ, 16/16 УСТРОЙСТВ:** +> 🚦 **СОСТОЯНИЕ НА 2026-09-15 (ночь-16, ПОСЛЕ РАЗБОРА КНОПКИ) — ZHA РАБОТАЕТ, 16/16 УСТРОЙСТВ:** ``` a4c1386d40ddb67b light_sensor_stairs EndDevice last_seen 20:46:51 ← ✅ ДОБАВИЛСЯ @@ -32,7 +32,7 @@ ZHA devices: 17 (16 + координатор) > - ✅ **`light_sensor_stairs` ДОБАВИЛСЯ** — Alex поставил датчик в режим спаривания **несколько раз**, на третьей попытке устройство долетело. `device_id f33b36fbaec7b1eabca7a7e496be89f4`, `name_by_user=light_sensor_stairs`, зона `lestnitsa`. Шлёт данные потоком: освещённость 3…440 lx, батарея 100%. См. §Факт 6 (ОБНОВЛЁН). > - ✅ **Сущности датчика переименованы** в человеческие id: `sensor.light_sensor_stairs_illuminance`, `_battery`, `_temperature`, `_humidity` (все `success: true`). > - ✅ **Дополнительно найдены и подтверждены 2 битых автоматизации диммера** — `Toggle Dimmer bed` и `Dimmer bed cycle` с `triggers: []` (пустые!). См. §Факт 9. -> - 🔴 **`event.*` кнопки спальни ТАК И НЕ ПОЯВИЛСЯ.** Слушал шину HA (`subscribe_events`: `zha_event` + `state_changed`) 90 секунд после просьбы нажать кнопку — **ни одного события**. Нажатие не долетело до координатора. См. §Факт 5. +> - 🔴🔴 **`event.*` кнопки спальни НЕ ПОЯВИТСЯ НИКОГДА — НАЙДЕНА НАСТОЯЩАЯ ПРИЧИНА.** Не «нажатие не долетело» (прежняя гипотеза, §5-бис — **отменена**). Дамп кластеров: у `_TZ3000_kccru4oi` кластер `OnOff 0x0006` лежит в **`output`**, а `input` содержит только `Basic`/`Power`/`TuyaZBE000`. `exposes_features: []`. ZHA строит сущности только из `input` → **`zha_event` не рождается, `event.*` не создастся ни при каких нажатиях и окнах спаривания.** Это архитектурная несовместимость конкретного `manufacturerName`. См. §Факт 5-тер (3 варианта решения). > - 🟡 **Три слоя мусора удалены:** 127 сущностей `platform=mqtt` + 18 устройств-призраков Z2M. Реестр: 624 → 493 сущности, 52 → 34 устройства. > - ✅ **13 modbus-датчиков СОХРАНЕНЫ** (проверено фактом: пишут данные) — они тоже `platform=mqtt`, но живые. > - ✅ **51 операция переименования сущностей:** 42 выполнены, 8 отбиты (`light`→`switch` запрещён HA), 1 пропущена. @@ -40,7 +40,7 @@ ZHA devices: 17 (16 + координатор) > - ✅ **13 устройств получили ЗОНЫ обратно** + `light_sensor_stairs` → `lestnitsa`. > - ✅ **Имена исправлены фактом:** `light.tz3000_ooc8illt_ts0052` → **`light.bed_dimmer`**, `switch.tz3210_nhqka112_ts011f` → **`switch.sauna`** (оба `success: true`, проверены чтением состояния). > - 🔴 **ИСПРАВЛЕНА НЕВЕРНАЯ ЗАПИСЬ ЭТОГО ДОКА:** полсуток было записано наоборот, что `700e14b7…` = `bed_dimmer`. **Верно: `700e14b7…` = `sauna` (`_TZ3210_nhqka112 TS011F`), `e230c12e…` = `bed_dimmer` (`_TZ3000_ooc8illt TS0052`).** См. §Факт 7. -> - ⏳ **Осталось:** `event.*` кнопки спальни (нажатие не долетело до координатора — разбираться с кнопкой физически); 2 автоматизации диммера (`triggers: []` + чужой `device_id`); `Вкл/Выкл ночной свет душевая` (чужой `device_id fd52114b…`); 2 battery-автоматизации со старыми id; косметика `select.bed_dimmer_*`. +> - ⏳ **Осталось:** 🆕 **кнопка спальни** — выбрать вариант (§Факт 5-тер: группа+bind / замена кнопки); **залить `automations-fixed.yaml`** (собран, лежит на Mac); 4 кривых автоматизации (`Вкл/Выкл ночной свет душевая` — чужой `device_id fd52114b…`; 2 battery-автоматизации со старыми id); косметика `select.bed_dimmer_*`. > - ⚠️ Z2M **остановлен**, не удалён. Данные целы в `/config/zigbee2mqtt/`. > 🔴 **ЧИТАТЬ ДАЛЬШЕ И КАК РЕЦЕПТ, И КАК РАЗБОР ОШИБОК.** Ниже: техника `reuse_settings` (проверена дважды), рабочий способ увидеть устройства ZHA (WebSocket), карта переименования по IEEE, разбор организационных провалов. @@ -120,11 +120,13 @@ bedroom bed_dimmer, wireless_light_switch_bed kitchen kitchen_hood | `svetlo_vykl_osveshchenie_lestnitsy` | `light_sensor_stairs` | 🟢 устройство ЕСТЬ → проверить, ожила ли | | `temno_vkl_podsvetku_lestnitsy` | `light_sensor_stairs` | 🟢 устройство ЕСТЬ → проверить | | `datchik_osveshchennosti_lestnitsa_batareia` | `light_sensor_stairs` | 🟢 устройство ЕСТЬ → проверить | -| `light_switch_bed_batareia` | `wireless_light_switch_bed` | 🔴 всё ещё `unavailable` — кнопка не срабатывает (§Факт 5-бис) | +| `light_switch_bed_batareia` | `wireless_light_switch_bed` | 🔴 **НЕ ЛЕЧИТСЯ** — кнопка `_TZ3000_kccru4oi` не даёт событий в ZHA по железу (§Факт 5-тер) | + +> 🆕 **ОБНОВЛЕНО ночью-16:** три автоматизации лестницы разблокированы (`light_sensor_stairs` добавлен). **Две автоматизации диммера** — исправленный файл `automations-fixed.yaml` собран на Mac, **не залит**; их `actions` починены, но `triggers` не сработают, пока кнопке не дали путь к диммеру (§Факт 9-бис). **`light_switch_bed_batareia` — тупик по железу, см. §Факт 5-тер.** > ✅ **ОБНОВЛЕНО ночью-15 (финал):** `light_sensor_stairs` **добавлен**, три автоматизации лестницы разблокированы. Замер после добавления: **11 из 16 автоматизаций `on`**, 4 `unavailable`. Проверить `last_triggered` у лестничных после следующего изменения освещённости. > 📌 **Разбудить кнопкой (паринг-кнопка 1 сек)** — подхватятся сами. Это НЕ перепаривание. -> 🔴 **УТОЧНЕНО ночью-15:** `wireless_light_switch_bed` **в ZHA есть** (16 устройств), но нажатие **не долетает** (слушали шину 90 с — ноль событий, §Факт 5-бис). Нужно доставить до координатора режимом спаривания. +> 🔴 **УТОЧНЕНО ночью-16:** `wireless_light_switch_bed` **в ZHA есть** (16 устройств). **Причина неработоспособности найдена — не «нажатие не долетает», а отсутствие `input`-кластера `OnOff 0x0006`** (§Факт 5-тер). Режим спаривания НЕ поможет. Рабочие пути: группа+bind или замена кнопки. > 🔴 **Для `toggle_dimmer_bed` / `increase_dimmer_bed_brightness`:** они триггерятся от кнопки. Пока `event.*` не появился — мертвы, даже если `light.bed_dimmer` существует и переименован. #### Как пересобирались автоматизации (рабочий рецепт) @@ -1016,10 +1018,13 @@ wireless_light_switch_bed device_id da6c759f9046046c4ef60467175ccbbe **Проверено фактом:** открыт фоновый слушатель WS (`subscribe_events`: `zha_event` + `state_changed`), Alex попросили нажать кнопку в спальне. За **90 секунд — ни одного события** от `a4:c1:38:b0:f9:e6:74:a5`. `event.*` не создалась. -> 🔴 **НАЖАТИЕ НЕ ДОЛЕТЕЛО ДО КООРДИНАТОРА.** Это уже **не** «HA не создала сущность» — HA создаёт `event.*` из первого `zha_event`, а события нет вообще. Значит кнопка физически не передаёт нажатие в сеть ZHA. См. также паттерн `light_sensor_stairs` (§Факт 6): **батарейные устройства после миграции нужно буквально «доставить» до координатора повторным режимом спаривания.** +> ⛔ **ГИПОТЕЗА ЭТОГО РАЗДЕЛА ОТМЕНЕНА — см. §Факт 5-тер.** «Нажатие не долетело до координатора → доставить режимом спаривания» — **НЕВЕРНО**. Устройство в сети (LQI 116, батарея 100%), нажатие оно как раз **шлёт** — но в `output`-кластер, который ZHA не слушает. **Режим спаривания и окно `zha.permit` для этой кнопки бесполезны.** Раздел сохранён как история опровергнутого пути. +> 📌 **УРОК:** прежде чем слушать шину и ретраить спаривание — **снять дамп кластеров** (`zha/devices/clusters`). Он показывает несовместимость за один вызов, тогда как слушание шины даёт «0 событий» без объяснения причины и уводит в неверную сторону. > -> **Что делать с кнопкой:** применить тот же приём, что сработал на датчике лестницы — **открыть `zha.permit` (REST, 180 с) → слушать WS-шину в фоне → ретраить режим спаривания на кнопке** (TS0041: удерживать ~5 с), пока в шине не появится `zha_event`, и только тогда нажимать обычным способом. -> 📌 **Диагностический порядок для любой кнопки:** (1) есть ли `zha_event` в шине → если нет, кнопка не в сети; (2) есть ли `event.*` → если нет, событий ещё не было; (3) только после обоих — строить триггер автоматизации. +> ⛔ **«Что делать с кнопкой» НИЖЕ УСТАРЕЛО — не выполнять.** Рабочие варианты — в §Факт 5-тер. Оставлено как история. + +> **Что делать с кнопкой (УСТАРЕВШИЙ СОВЕТ):** применить тот же приём, что сработал на датчике лестницы — **открыть `zha.permit` (REST, 180 с) → слушать WS-шину в фоне → ретраить режим спаривания на кнопке** (TS0041: удерживать ~5 с), пока в шине не появится `zha_event`, и только тогда нажимать обычным способом. +> 📌 **Диагностический порядок для любой кнопки (ОБНОВЛЁН — начинать с п.0):** (0) **снять дамп кластеров** `zha/devices/clusters` → если `0x0006` в `out` и `exposes_features: []` — **стоп, кнопка в ZHA не работает, дальше не идти**; (1) есть ли `zha_event` в шине → если нет, кнопка не в сети; (2) есть ли `event.*` → если нет, событий ещё не было; (3) только после обоих — строить триггер автоматизации. > 📌 Скрипт-слушатель: `btn_listen.py` (фильтр по IEEE кнопки, ловит `zha_event` и появление `event.*`). > ⚠️ **Ранее записанный вывод «нажать кнопку — и всё появится» НЕВЕРЕН для этой кнопки.** Проверено: нажатие не проходит. Не повторять совет без проверки шины. @@ -1114,15 +1119,114 @@ a4c13882a4b42db0 bed_dimmer Router a4c138b0f9e674a5 wireless_light_switch_bed EndDevice ``` -> 🔴 **УТОЧНЕНИЕ к Факту 4:** вывод «устройство привязалось к ZHA (`iasCieAddr` координатора ZHA, свежий `lastSeen`)» **перепроверить нельзя** — `database.db` был снят **до** миграции, поэтому `iasCieAddr 0x0ceff6fffe9339f2` мог быть записан ещё Z2M'ом при интервью. **Факт на сейчас: в живом реестре ZHA устройства НЕТ.** Достоверно — только это. +> 🔴 **УТОЧНЕНИЕ к Факту 4:** вывод «устройство привязалось к ZHA (`iasCieAddr` координатора ZHA, свежий `lastSeen`)» подтвердился на третьей попытке — устройство **подхватилось** (см. §Факт 6, ОБНОВЛЁН). `database.db` был снят до миграции, поэтому `iasCieAddr 0x0ceff6fffe9339f2` — запись ещё от Z2M-интервью; но факт итога иной: **устройство в живом реестре ZHA ЕСТЬ**. > -> **Порядок действий (согласован, ждём Alex):** -> 1. Зажать кнопку на датчике и держать **~10 с** — не отпускать на первом мигании, дождаться быстрого/тройного. -> 2. Отпустить, пауза 2 с, **один короткий нажим**. -> 3. Если не появится — **вынуть батарейку на 10 с**, вставить, повторить п.1–2 (сбрасывает возможный рассинхрон ключа). -> 4. Проверять **реестр по WebSocket**, а не состояние сущностей. +> **Рабочий порядок (подтверждён на практике):** +> 1. Открыть окно: `POST /api/services/zha/permit` `{"duration":180}` (REST; WS-метод `zha/permit` → `unknown_command`). +> 2. **Слушать WS-шину в фоне** (`subscribe_events`: `zha_event` + `state_changed`) — скрипт `/tmp/pair_listen.py`. +> 3. **Ретраить режим спаривания на устройстве** — пока в реестре (`zha/devices` / `ha_ws.py find `) не появится IEEE. Первые 1–2 попытки могут дать 0 результата. +> 4. После появления — `config/device_registry/update` → `name_by_user` + `area_id`, затем переименовать сущности. > > ⚠️ `zha.permit` для уже-в-сети устройств бесполезен (питфолл 22), но для **не долетевшего** устройства окно открывать надо — оно есть, факт: REST-вызов прошёл. +> 🔴 **ОГРАНИЧЕНИЕ, ВЫЯСНЕННОЕ ночью-16:** этот рецепт работает **только для sleeping EndDevice, которые ДЕЛЯТСЯ атрибутами** (`light_sensor_stairs`/TS0222). Для устройств-«передатчиков команд» (`_TZ3000_kccru4oi`/TS0041, у которых `OnOff` в `output`) он **не работает вообще** — см. §Факт 5-тер. **Перед ретраем спаривания снять дамп кластеров.** + +### 🔴🔴 ФАКТ 5-ТЕР — НАСТОЯЩИЙ КОРЕНЬ НАЙДЕН: `_TZ3000_kccru4oi` — НЕ КНОПКА для ZHA (проверено дампом кластеров) + +> **Триггер:** Alex — «Чё блядь опять за хуйня» после §Факт 5-бис. Вместо повторного слушания шины — прямой дамп устройства и его кластеров через ZHA WebSocket. + +**Факт 1 — quirk ЕСТЬ и применён, но профиль не тот:** + +``` +ieee: a4:c1:38:b0:f9:e6:74:a5 model: TS0041 manufacturer: _TZ3000_kccru4oi +quirk_applied: true +quirk_class: zhaquirks.tuya.ts0041:TuyaSmartRemote0041TOPlusA ← кастомный Tuya-вариант +exposes_features: [] ← 🔴 пусто +signature.endpoints["1"].input_clusters: 0x0000, 0x0001, 0xe000 +signature.endpoints["1"].output_clusters: 0x0006, 0x000a, 0x0019 +``` + +**Факт 2 — кластеры (живой опрос `zha/devices/clusters`):** + +``` +endpoint 1: + in: Basic(0), TuyaNoBindPowerConfigurationCluster(1), TuyaZBE000Cluster(0xE000) + out: Time(0x000A), Ota(0x0019), TuyaSmartRemoteOnOffCluster(0x0006) +``` + +> 🔴 **КОРЕНЬ: у кнопки в `input` НЕТ кластера `OnOff (0x0006)` — он в `output`.** +> Это означает: устройство — не «кнопка, которая сообщает о нажатии», а **«передатчик OnOff-команд»**. Туевская кнопка **шлёт команду** в `TuyaSmartRemoteOnOffCluster` (output), вместо того чтобы отдавать атрибут на чтение (input). Уникальный `device_type` endpoint'а — `0x0000` (On/Off Light), т.е. формально она числится как **лампа**. +> +> **ZHA реагирует только на `input`-кластеры.** Пустой `input` (кроме Basic/Power) ⇒ `zha_event` не рождается никогда ⇒ `event.*` не создаётся **ни при каком числе нажатий и любых окнах `zha.permit`**. +> +> **Почему в Z2M работало:** Z2M подписывается на **входящие команды** устройства (свой парсер `tuya.ts0041`, читает `action` из любого трафика). ZHA так не умеет — она строит сущности из `input`-атрибутов. +> +> ⛔ **ЭТО НЕ ЛЕЧИТСЯ в HA.** Ни нажатиями, ни `zha.permit`, ни `reconfigure`, ни перепариванием. Это архитектурная несовместимость конкретного `manufacturerName` с моделью сущностей ZHA. +> ⛔ **Сервиса `zha.reconfigure_device` в ZHA НЕТ** — проверено `GET /api/services`, домен `zha` отдаёт только: `permit`, `remove`, `set_zigbee_cluster_attribute`, `issue_zigbee_cluster_command`, `issue_zigbee_group_command`, `set/enable/disable_lock_user_code`, `warning_device_squawk/warn`. Список команд ZHA для reconfigure — **WebSocket**, не сервис. + +#### Что с этим делать — 3 рабочих варианта (по возрастанию сложности) + +| # | Вариант | Плюсы | Минусы | +|---|---|---|---| +| **1** | **Zigbee-группа + bind кнопка → диммер** (кнопка шлёт OnOff в группу, диммер слушает группу) | Работает **без HA вообще**, мгновенно, переживает падение ZHA и перезагрузки | Кнопка одна, групповая логика — вручную; нужен bind по её кастомному кластеру | +| **2** | **Откатить ЭТУ кнопку в Z2M** | Кнопка вернётся к работе | ⛔ **Невозможно:** Z2M и ZHA не поделят один стик. Откат = переезд всей сети назад | +| **3** | **Заменить кнопку** на модель, которую ZHA знает (Aqara, EcoSmart, Tuya-варианты с `input: 0x0006`) | 100% работа через `event.*`, штатные автоматизации | Деньги + время | + +> 📌 **Почему `light.bed_dimmer` bind-абелен (проверено):** у диммера `TS0052` endpoint 1: +> `input: 0x0000, 0x0003, 0x0004, 0x0005, **0x0006 (OnOff)**, **0x0008 (LevelControl)**, 0xE000, 0xE001` +> — оба нужных кластера в `input`. Значит диммер принимает OnOff и умеет яркость. Variant 1 технически возможен. +> ⚠️ Но кнопка шлёт через **кастомный** `TuyaSmartRemoteOnOffCluster`, поэтому bind по стандартному `0x0006` может не сработать — проверять фактом, начиная с группы. + +> 🔑 **ДИАГНОСТИЧЕСКИЙ ПРИЁМ, который нашёл корень за 2 вызова** (использовать для любой «неработающей» кнопки): +> 1. `{"type":"zha/devices"}` → найти устройство по IEEE → смотреть **`exposes_features`** (пусто = не кнопка для ZHA) и **`quirk_class`**. +> 2. `{"type":"zha/devices/clusters","ieee":""}` → смотреть, **в `in` или в `out`** лежит `0x0006`. +> 3. Если `0x0006` в `out` И `exposes_features: []` → **кнопка не будет работать в ZHA. Не тратить время на нажатия и `permit`.** +> 📌 Дамп раскрывает всё это **сразу**, без ожидания событий на шине. **Слушание шины (§5-бис) — тупиковый путь для этого класса устройств; дамп кластеров — правильный первый шаг.** + +### 🔴 ФАКТ 9-БИС — автоматизации диммера: исправленный файл собран, НА t610 НЕ ЗАЛИТ + +**Собран `/Users/admin/tmp-t610/automations-fixed.yaml`** (источник — снятый с t610 `automations-current.yaml`, 189 строк). Содержимое правки: + +```yaml +# Было (битое): +- id: '1771683420621' + alias: Toggle Dimmer bed (ждёт кнопку bed) + triggers: [] + actions: + - type: toggle + device_id: 700e14b7d1710526b00f098b8506826d # 🔴 sauna + entity_id: switch.tz3210_nhqka112_ts011f # 🔴 sauna + domain: switch + +# Стало (в файле на Mac, НЕ залито): +- id: '1771683420621' + alias: Toggle Dimmer bed + triggers: + - trigger: device + device_id: da6c759f9046046c4ef60467175ccbbe # ✅ кнопка + domain: zha + type: remote_button_short_press + subtype: button_1 + actions: + - action: light.toggle + target: + entity_id: light.bed_dimmer # ✅ диммер, домен light +``` + +То же для `Dimmer bed cycle` (`long_press` → `light.turn_on brightness_pct: 50` на `light.bed_dimmer`). + +> 🔴 **ПОЧЕМУ НЕ ЗАЛИТ: триггер `remote_button_short_press` на этой кнопке НЕ СРАБОТАЕТ** (§Факт 5-тер — нет `input: 0x0006`, нет `event.*`). Заливать файл с заведомо мёртвым триггером — бессмысленно. **Сначала дать кнопке путь к диммеру (вариант 1: группа + bind), потом заливать.** +> 📌 **Действия (actions) в этом файле исправлены правильно и нужны независимо от судьбы кнопки** — их можно залить, если решено оставить автоматизации без триггера. Решение за Alex. + +**Сверенные ID (проверено фактом через `config/device_registry/list`):** + +``` +light.bed_dimmer device_id e230c12e6cb45492408ddba6456b6444 ✅ домен light +wireless_light_switch_bed device_id da6c759f9046046c4ef60467175ccbbe ✅ +switch.tz3210_nhqka112_ts011f (= sauna) + device_id 700e14b7d1710526b00f098b8506826d ← ЭТО НЕ ДИММЕР +``` + +> 📌 **Скрипты:** `/tmp/dim_ids.py` (сверка device_id + сущностей), `/tmp/fix_autom.py` (сборка исправленного YAML), `/tmp/dimdiag.py` (кластеры диммера), `/tmp/btnclusters.py` (кластеры кнопки), `/tmp/btndiag.py` + `/tmp/btndump.py` (дамп устройства кнопки). ### 🔴 ПИТФОЛЛ: фильтр секретов ломает скрипты на `Bearer $TOK`