[2026-09-15] eagle: family/tech/zigbee-t610-z2m-i-zha.md

2026-09-15 20:54:03 +06:00
parent f0e9a423ff
commit 43d7857991
1 changed files with 120 additions and 16 deletions
@@ -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>`) не появится 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":"<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`