[2026-09-14] eagle: family/how-to/t610-access.md family/plans/home-automation-migration-t610.md family/plans/t610-addons-deployment.md

family/how-to/t610-access.md

@@ -7,7 +7,7 @@
 > ✅ **Состояние на 2026-09-14 (Этап 3 ЗАКРЫТ, z2m = 15 устройств):** z2m, mbusd (порт 502), modbus-bridge (MQTT + HA-опрос) — развёрнуты аддонами и **работают**. В HA добавлена **MQTT-интеграция**. **HA-конфиг перенесён с TrueNAS** (`.storage` реестры + конфиги + `www/`): HA запущен, **11 зон, MQTT-интеграция цела, ошибок нет**. Zigbee-розетки добавлены: `heating_cable_plug` (NEO NAS-WR01B, греющий кабель) и **`boiler_controller_power`** (`0xa4c1381694217e10`, TS011F, Котельная — питание контроллеров котлов), мёртвые устройства (3 шт.) **удалены из z2m**. Реестр HA = **332 сущности, hex = 0**. **Зоны проставлены у 18 устройств.**
 > ✅ **Автоматизации: 16 шт., 15 `on` + 1 `off`, 0 `unavailable`** (было 13 «мёртвых» — `device_id` перемаплены + hex-`entity_id` почищен **и в триггерах**).
 > ✅ **HTTP-варнинг устранён** (блок `http:` → `.storage/http`), **`modbus.host` = `192.168.2.176`** (НЕ `127.0.0.1` — см. питфолл ниже), **modbus-bridge 404 исправлены** (+rebuild аддона).
-> ⏸️ **ОСТАЛСЯ ОДИН БЛОКЕР — аппаратный:** 32 заслонки вентиляции `unavailable` (шина не отвечает, exception 0x0B) → CH340 #2 нужно физически подключить к линиям A/B шины. Конфиг верный. **Разбор доведён 2026-09-14:** mbusd слушает 502, TCP принимает соединения, но лог показывает только `conn_open/close` (ни байта в serial), Modbus-запрос к slave 11 → пусто. См. §«Диагностика шины вентиляции (mbusd)».
+> ⚠️ **ОШИБКА В ПРЕДЫДУЩЕЙ РЕДАКЦИИ — ИСПРАВЛЕНО 2026-09-14 (поздняя сессия).** Ранее здесь было записано «блокер аппаратный: шина не подключена, работа за Alex». **ЭТО НЕВЕРНО — шина вентиляции РАБОТАЕТ.** Прямая проверка Modbus-запросами (регистры **из конфига HA**, не reg 0!) дала живые ответы: `slave 11 reg 5 → OK data=640001`, `slave 11 reg 8 → OK`, `slave 12 reg 1 → OK data=640001`, `slave 10 → OK` (значение 100), `slave 2 → OK`, `slave 3 → OK`, `slave 20 → OK`. Ответы **нестабильны** (то `OK`, то `EXC 0x0B`) — вероятная причина: короткий `timeout` mbusd (1000 мс) + `retries 3`, тогда как реле-модули заслонок отвечают медленно. **Что осталось выяснить:** почему HA не получает эти данные, хотя снаружи они есть (смотреть лог `homeassistant.components.modbus` в HA, а не mbusd). См. §«Диагностика шины вентиляции (mbusd)».
 > 🔑 **CH340 привязывать ТОЛЬКО по `by-path`.** Доказано: у двух CH340 нет серийников → в `/dev/serial/by-id/` для них **один общий симлинк** (ведёт на `ttyUSB1`, на `ttyUSB0` ссылки нет). 🔴 Перепутывание кабелей CH340 #1/#2 **не даст ошибки** — аддоны поднимутся, но будут работать не с теми шинами. См. §«ГЛАВНЫЙ ПИТФОЛЛ».
 >
 > 🔑 **Ключевой вывод:** HA связывает сущности по **`unique_id`**, а не по `entity_id`. Смена `friendly_name` в z2m **сохраняет человеческие `entity_id`** — дублей нет.
@@ -298,24 +298,61 @@ ZONT (modbus-bridge):       /dev/serial/by-path/pci-0000:00:12.0-usb-0:3:1.0-por
 
 > ✅ **Плюс аддонов:** старая проблема гонки udev ([[family/how-to/zont-modbus-bridge-udev-race-protection]]) на t610 **неактуальна** — Supervisor сам ждёт устройство при старте аддона, скрипты ожидания tty не нужны.
 
-## Диагностика шины вентиляции (mbusd) — состояние на 2026-09-14
+## Диагностика шины вентиляции (mbusd) — ИСПРАВЛЕНО 2026-09-14 (поздняя сессия)
 
-**mbusd настроен ВЕРНО, проблема аппаратная.** Полный разбор (чтобы не переделывать):
+> 🔴 **ВНИМАНИЕ: предыдущая версия этого раздела была ОШИБОЧНОЙ.** Два ложных вывода, оба опровергнуты:
+> 1. ~~«проблема аппаратная, линии A/B не подключены / шина обесточена, работа за Alex»~~ → **НЕВЕРНО. Шина работает, устройства отвечают.**
+> 2. ~~«в логе mbusd только `conn_open/close` → запросы до порта не доходят»~~ → **НЕВЕРНО. Эти `conn_open` от `192.168.2.157` — МОИ СОБСТВЕННЫЕ запросы: Mac сидит за роутером, и через NAT все запросы к `192.168.2.176:502` выглядят как трафик от `.157` (роутер «Rasputin», eth0 `192.168.2.157`). Никакого «постороннего клиента, который жрёт слоты mbusd» не существует.**
+
+### Как проверять шину ПРАВИЛЬНО
+
+**Ключевая ошибка:** слать Modbus-запрос на **reg 0**. В конфиге HA заслонки читаются с **reg 5, 7, 8** (и т.д.), а не с 0. У молчащего устройства ответа не будет ни на одном регистре, у живого — ответ по своим регистрам. **Сначала смотреть адреса в конфиге:**
+
+```bash
+ssh root@192.168.2.176 "sed -n '95,130p' /config/configuration.yaml"
+# у заслонок: slave: 11, address: 5 / 7 / 8, write_type: holding, command_on: 256, command_off: 512
+```
+
+**Проверка (Python, TCP на mbusd):**
+```python
+import socket, struct
+def rd(slave, addr, qty=1, timeout=4):
+    pdu = struct.pack('>BHH', 3, addr, qty)
+    mbap = struct.pack('>HHHB', 1, 0, len(pdu)+1, slave)
+    s = socket.create_connection(('192.168.2.176', 502), timeout=timeout)
+    s.sendall(mbap+pdu); r = s.recv(256); s.close()
+    return 'OK '+r[9:].hex() if len(r)>=9 and not (r[7]&128) else 'EXC 0x%02X' % r[8]
+```
+
+**Фактические результаты (2026-09-14):**
+
+| Slave | Что это (по [[family/how-to/home-automation]]) | reg | Ответ |
+|---|---|---|---|
+| **11** | **Relay module — заслонки** (спальня/гостиная/детская/кухня) | 5 | ✅ `OK data=640001` |
+| **11** | | 8 | ✅ `OK data=00` |
+| **11** | | 7 | ❌ `EXC 0x0B` |
+| **12** | **Relay module — заслонки 2** (кабинет/север/вытяжки) | 1 | ✅ `OK data=640001` |
+| **10** | Vent control (AT2 вентиляторы) | — | ✅ `OK` (значение 100) |
+| **2, 3** | датчики Детская / Спальня | — | ✅ `OK` |
+| **20** | Газ котёл вкл | — | ✅ `OK` |
+
+**Вывод:** шина вентиляции **живая**, mbusd **работает**, заслонки (11, 12) **отвечают**. Ответы **нестабильны** — один и тот же slave на reg 5 отвечает, на reg 7 нет.
+
+**Гипотеза причины нестабильности:** `timeout = 1000 мс` в mbusd слишком короткий — реле-модули заслонок отвечают медленнее, mbusd не дожидается и отдаёт `0x0B` (`GATEWAY TARGET DEVICE FAILED TO RESPOND`). **Что делать:** поднять `timeout` до 3000 мс, `retries` снизить до 1, перезапустить `local_mbusd`, проверить, уйдут ли `unavailable` из HA.
+
+**Что остаётся невыясненным:** почему HA видит `unavailable`, если снаружи данные приходят (44 `unavailable`: ~32 заслонки `intake_damper_*`/`exhaust_damper_*` + вентиляторы `fan_3_*`/`fan_at2_*`). **Смотреть нужно лог HA** (`homeassistant.components.modbus`, `pymodbus`), а НЕ лог mbusd — mbusd как транспорт исправен.
+
+### Актуальные проблемы (не путать с «аппаратным блокером»)
 
 | Проверка | Команда | Результат |
 |---|---|---|
-| Аддон запущен | `ha apps info local_mbusd` | `state: started` |
+| Аддон запущен | `ha apps info local_mbusd` | `state: started` ✅ |
-| Порт слушается | `nc -z 192.168.2.176 502` | ✅ **открыт** |
+| Порт слушается | `nc -z 192.168.2.176 502` | ✅ открыт |
-| Устройство в опциях | `ha apps info local_mbusd \| grep -A8 'options:'` | `device: /dev/serial/by-path/pci-0000:00:12.0-usb-0:4:1.0-port0` (CH340 #2, порт 4) ✅ |
+| Устройство | `ha apps info local_mbusd \| grep -A8 'options:'` | `by-path ...0:4:1.0-port0` (CH340 #2, порт 4) ✅ |
-| Параметры | там же | speed 9600, mode 8n1, retries 3, timeout 1000, trx `addc` |
+| Параметры | там же | speed 9600, mode 8n1, **timeout 1000** ⚠️, retries 3, trx `addc` |
-| Modbus-запрос к slave 11 | `printf '\x0b\x03\x00\x00\x00\x01\xd5\xba' \| nc 192.168.2.176 502` | ❌ **пусто (нет ответа)** |
+| Шина отвечает | Python-запрос на reg из конфига HA | ✅ **ДА** (см. таблицу выше) |
-| Лог mbusd | `ha apps logs local_mbusd \| tail -20` | только `conn_open()`/`conn_close()` — **запросы до порта не доходят** |
 
-**Интерпретация:** TCP-уровень работает (соединение принимается, `conn_open` от `192.168.2.176`, `172.30.32.1`, `192.168.2.157`), но **по serial-шине обмена нет** → Modbus RTU не получает ответов от slave 11 (заслонки). HA показывает exception **0x0B** = `GATEWAY TARGET DEVICE FAILED TO RESPOND`.
+> ⚠️ **Не путать при диагностике:** раньше бытовало мнение «в логе mbusd `conn_open/close` от `.157` = посторонний клиент забивает слоты». **Это ложный след.** `.157` — это eth0 роутера Rasputin, через который идёт весь трафик из локалки 192.168.2.x; источник — сам Mac. Источник в логе mbusd — всегда адрес того, кто реально открывает TCP-соединение. ⚠️ **Также:** `nc` на OpenWrt (busybox) не поддерживает `-z` — для проверок портов с роутеров использовать `curl`/`wget`.
-
-**Вывод: конфиг верный, дело в физике.** Варианты: линии **A/B** вентиляционной шины не подключены к CH340 #2, либо шина обесточена, либо неверны slave-адреса/скорость. **Работа за Alex** — проверить физическое подключение CH340 #2 к шине вентиляции.
-
-> ⚠️ Проверить, что CH340 #2 действительно смотрит на вентиляцию (а не перепутан с ZONT), **без физического вмешательства нельзя** — на шине вентиляции никто не отвечает, эталонного трафика для сравнения нет. См. §«ОПАСНОСТЬ ТИХОГО СБОЯ» выше.
 >
 > ℹ️ **Конфиг HA modbus:** `configuration.yaml` → `modbus: [{name: rtu_bus, type: tcp, host: 192.168.2.176, port: 502}]`. Slave 10 (AT2 fans) **закомментирован** в конфиге с пометкой «not responding on vent bus» — чтобы не блокировать опрос заслонок. После починки шины — раскомментировать.
 

family/plans/home-automation-migration-t610.md

@@ -20,7 +20,8 @@ related:
 # Перенос домашней автоматизации на HP t610
 
 > **Статус: Этап 1 ✅. Этап 2 ✅ ПОЛНОСТЬЮ. Этап 3 ✅ ЗАКРЫТ (2026-09-14).** z2m — 15 устройств, mbusd — порт 502, modbus-bridge — MQTT + HA-опрос. HA-конфиг перенесён с TrueNAS, автоматизации 16/16 живы, реестр 332 сущности (hex=0), зоны у 18 устройств. Детали Этапа 3 и питфоллы переноса — [[family/plans/t610-addons-deployment]].
-> **⏸️ Остался один блокер — аппаратный:** 32 заслонки вентиляции `unavailable` (шина не отвечает, exception 0x0B) → CH340 #2 подключить к линиям A/B шины. Далее — Этап 4 (Caddy upstream → t610, GPON-редирект, отключение TrueNAS).
+> 🔴 **ИСПРАВЛЕНО 2026-09-14 (поздняя сессия): записи про «аппаратный блокер» ниже были ОШИБОЧНЫМИ, читать с поправкой.** Шина вентиляции **РАБОТАЕТ**, заслонки (slave 11, 12) отвечают — проверено прямыми Modbus-запросами на **регистры из конфига HA** (`slave 11 reg 5 → OK 640001`, `slave 12 reg 1 → OK 640001`, живы также slave 10/2/3/20). Прежний вывод опирался на два ложных следа: (1) запросы по **reg 0** вместо реальных 5/7/8; (2) `conn_open` от `192.168.2.157` в логе mbusd — это **свои же запросы через NAT роутера Rasputin**, а не «посторонний клиент». **Осталось выяснить:** почему HA даёт 44 `unavailable` (≈32 заслонки + вентиляторы `fan_3_*`/`fan_at2_*`), если mbusd отдаёт данные — смотреть лог HA (`homeassistant.components.modbus`), не mbusd. Полный разбор: [[family/how-to/t610-access]] §«Диагностика шины вентиляции (mbusd)».
+> Далее — Этап 4 (Caddy upstream → t610, GPON-редирект, отключение TrueNAS).
 > **⚠️ Проверено экспериментом 2026-09-14:** `unknown` у реле/кнопок **возвращается после каждой перезагрузки HA** — `retain`/`cache_state` в z2m не спасают; первое нажатие кнопки после рестарта не срабатывает. Открытый фикс — убрать `not_from: [unknown]` из триггеров (не применён). Детали: [[family/plans/t610-addons-deployment]] §«ДОБАВЛЕНО В КОНЦЕ СЕССИИ» ③‑бис.
 > Цель: убрать всю домашнюю автоматизацию с TrueNAS (он перегружен — 17/21 ГБ RAM) на выделенный HP t610, с бэкапом конфигов на TrueNAS и в git.
 >
@@ -369,7 +370,7 @@ system/start-modbus.sh        # скрипт ожидания tty перед doc
 - [x] ✅ **Serial:** by-path/b-id видны в аддонах (`uart: true`); привязка по `/dev/serial/by-path/...` (НЕ tty-алиасы — они на HA OS невозможны)
 - [x] ✅ **Zigbee:** z2m работает — **16 устройств** подхватились из старой базы, координатор EmberZNet 7.4.5
 - [x] ✅ **MQTT:** трафик z2m идёт (discovery-сообщения публикуются), логин `zont` работает
-- [ ] **Modbus вентиляция:** HA видит AT2, заслонки переключаются (проверить физически!) — требует Этапа 3 (перенос HA-конфига)
+- [ ] **Modbus вентиляция:** HA видит AT2, заслонки переключаются (проверить физически!) — ⚠️ **поправка 2026-09-14:** шина **работает** (прямые запросы дают ответы от slave 11/12), HA-конфиг перенесён (Этап 3 ✅). Остаётся выяснить, почему HA держит 44 `unavailable` при живом mbusd — смотреть лог HA. См. [[family/how-to/t610-access]] §«Диагностика шины вентиляции».
 - [ ] **ZONT:** датчики 485 (Dining/Kids/Bedroom) в ZONT **не «недоступные»**, температуры идут — требует `ha_token` в modbus-bridge + Этап 3
 - [x] ✅ **modbus-bridge:** sniffer работает, MQTT подключён, **13 discovery-топиков** `modbus/sensors/*` опубликованы, **HA-опрос работает** (`ha.url` = `http://192.168.2.176:80`)
 - [x] ✅ **mbusd:** порт 502 открыт, устройство на by-path CH340 #2 (порт 4)

family/plans/t610-addons-deployment.md

@@ -22,8 +22,8 @@ related:
 > **HTTP-варнинг устранён:** блок `http:` удалён из `configuration.yaml`, настройки перенесены в `.storage/http` (UI → Network).
 > **modbus.host исправлен: `127.0.0.1` → `192.168.2.176`** (mbusd в отдельном контейнере — `127.0.0.1` изнутри HA его не видел).
 > **modbus-bridge: HTTP 404 → 200.** Опрашивал HA по hex-`entity_id`; правился `modbus_ha_bridge.py` + `data/config.template.tmpl` + **обязательный rebuild аддона**.
-> ⚠️ **ЕДИНСТВЕННЫЙ ОСТАВШИЙСЯ БЛОКЕР (физика, не конфиг): 32 заслонки вентиляции `unavailable`.** mbusd работает (TCP отвечает), но шина **не отвечает** — exception **0x0B** (GATEWAY TARGET DEVICE FAILED TO RESPOND). Вывод: **CH340 #2 воткнут в USB, но линии A/B вентиляционной шины к нему не подключены / шина обесточена.** За Alex.
+> 🔴 **ОШИБКА ПРЕДЫДУЩЕЙ РЕДАКЦИИ — ИСПРАВЛЕНО 2026-09-14 (поздняя сессия).** Ранее здесь стояло: «ЕДИНСТВЕННЫЙ БЛОКЕР (физика): 32 заслонки `unavailable`, шина не отвечает — CH340 #2 не подключён к линиям A/B / шина обесточена, за Alex». **ЭТО НЕВЕРНО.** Прямая проверка Modbus (регистры **из конфига HA**: slave 11 → reg 5/7/8, slave 12 → reg 1) показала, что **шина РАБОТАЕТ и устройства отвечают**: `slave 11 reg 5 → OK data=640001`, `slave 12 reg 1 → OK data=640001`, `slave 10 → OK` (100), `slave 2/3/20 → OK`. Ответы нестабильны (то `OK`, то `EXC 0x0B`) — вероятно из-за короткого `timeout = 1000 мс` в mbusd. **Что осталось:** выяснить, почему HA ставит `unavailable`, хотя снаружи данные есть — смотреть лог HA (`homeassistant.components.modbus`), не mbusd. ⚠️ **Ложный след, который привёл к ошибке:** `conn_open` от `192.168.2.157` в логе mbusd был принят за «постороннего клиента, забивающего слоты» — на самом деле **`.157` это роутер Rasputin, через который ходит сам Mac**, и весь трафик из локалки выглядит как `.157`. Полный разбор: [[family/how-to/t610-access]] §«Диагностика шины вентиляции».
-> 🔍 **Разбор mbusd доведён 2026-09-14 (конец сессии):** аддон настроен верно — `device` = `by-path ...0:4:1.0-port0` (CH340 #2, порт 4), speed 9600, mode 8n1, порт **502 открыт**, TCP принимает соединения (`conn_open` в логе). Но лог mbusd показывает **только `conn_open`/`conn_close` — ни одного байта в serial**, Modbus-запрос к slave 11 (`printf '\x0b\x03\x00\x00\x00\x01\xd5\xba' | nc 192.168.2.176 502`) → **пусто**. Значит проблема **не в конфиге**, а в физике шины. Полная таблица проверок: [[family/how-to/t610-access]] §«Диагностика шины вентиляции (mbusd)».
+> 🔍 **Разбор mbusd (ПЕРЕСМОТРЕН 2026-09-14, поздняя сессия):** аддон настроен верно — `device` = `by-path ...0:4:1.0-port0` (CH340 #2, порт 4), speed 9600, mode 8n1, порт **502 открыт**. **Прежний вывод «в логе только `conn_open/close`, значит запросы не доходят до serial» — ОШИБОЧЕН:** эти `conn_open` от `192.168.2.157` суть запросы самого Mac (роутер Rasputin за NAT). Прямые Modbus-запросы на **правильные регистры** (из конфига HA, не reg 0!) получают **живые ответы** — `slave 11 reg 5 → OK 640001`, `slave 12 reg 1 → OK 640001`, `slave 10/2/3/20 → OK`. Шина и заслонки работают. Полная таблица ответов: [[family/how-to/t610-access]] §«Диагностика шины вентиляции (mbusd)».
 > ⚠️ **`unknown` после рестарта HA — ПРОВЕРЕНО ЭКСПЕРИМЕНТОМ 2026-09-14.** Реле/кнопки слетают в `unknown` при каждой перезагрузке HA, но **состояния возвращаются сами через ~40–60 с** (без нажатий) — их переопубликовывает z2m, увидев birth-message HA (`homeassistant/status`). `retain` для этого НЕ нужен и фактически не публикуется. ✅ **ФИКС ПРИМЕНЁН: `not_from: [unavailable, unknown]` убран из триггеров** (`automations.yaml`, 2 шт.) — кнопка срабатывает **с первого нажатия**, проверено на живом (l1 и l2, вкл+выкл). Полностью: §«ДОБАВЛЕНО В КОНЦЕ СЕССИИ» ③‑тер.
 > **✅ ЗОНЫ ВОССТАНОВЛЕНЫ (18 устройств):** при переносе `area_id` теряются так же, как `device_id` (устройства ре-регистрируются) → все 14 zigbee были **без зон**. Проставлены по эталону с TrueNAS по zigbee-адресу. См. §«ДОБАВЛЕНО В КОНЦЕ СЕССИИ» ①.
 > **✅ office-переключатель управляет светом:** устранены hex-`entity_id` **в триггерах** автоматизаций (`switch.0xa4c13873b5c1575b_l1/l2` → человеческие) + реле выведены из `unknown` физическим нажатием. Цепочка `light → switch_as_x → z2m → реле` проверена. См. §«ДОБАВЛЕНО В КОНЦЕ СЕССИИ» ②③.
@@ -1075,7 +1075,7 @@ curl -s -K /tmp/curl.auth http://192.168.2.176/api/states \
 - [x] ✅ **ИСПРАВЛЕНО 2026-09-14 — modbus.host:** `127.0.0.1` → `192.168.2.176`.
 - [x] ✅ **ИСПРАВЛЕНО 2026-09-14 — modbus-bridge 404:** hex-entity_id в коде аддона → человеческие + `ha addons rebuild`.
 - [x] ✅ **ВЫПОЛНЕНО 2026-09-14 (поздняя сессия) — Zigbee-розетка `boiler_controller_power` добавлена** (`0xa4c1381694217e10`, TS011F, зона Котельная) как питание контроллеров котлов; 13 сущностей переименованы из hex. **Итого z2m = 15 устройств, реестр = 332 сущности, hex = 0.**
-- [ ] ⏸️ **ГЛАВНЫЙ ОСТАВШИЙСЯ БЛОКЕР (аппаратный, за Alex):** 32 заслонки вентиляции `unavailable` — шина не отвечает (exception 0x0B). Подключить линии A/B к CH340 #2 (`by-path ...0:4:1.0-port0`, slave 11). Конфиг верный, оживут сами. **Разбор доведён 2026-09-14:** mbusd слушает 502, TCP принимает, но в логе только `conn_open/close` (ни байта в serial), Modbus-запрос → пусто. Значит физика, не конфиг. Детали: [[family/how-to/t610-access]] §«Диагностика шины вентиляции».
+- [x] ✅ **ИСПРАВЛЕНО 2026-09-14 (поздняя сессия): «аппаратного блокера» НЕТ.** Шина вентиляции **работает**, заслонки (slave 11, 12) отвечают — проверено прямыми Modbus-запросами на регистры из конфига HA: `slave 11 reg 5 → OK 640001`, `slave 12 reg 1 → OK 640001`, `slave 10/2/3/20 → OK`. Прежний вывод «шина не подключена, за Alex» был **ошибочным** — он опирался на ложный след (`.157` в логе mbusd = свои же запросы через NAT роутера) и на запросы по **reg 0** вместо реальных регистров 5/7/8. **Осталось выяснить:** почему HA показывает 44 `unavailable` (~32 заслонки + вентиляторы `fan_3_*`/`fan_at2_*`), хотя mbusd отдаёт данные. Смотреть лог HA (`homeassistant.components.modbus`). Гипотеза: `timeout 1000 мс` в mbusd мал для медленных реле-модулей. Детали: [[family/how-to/t610-access]] §«Диагностика шины вентиляции».
 - [x] ✅ **ПОДТВЕРЖДЕНО 2026-09-14 (конец сессии) — привязка CH340 только по `by-path`.** На живом t610 доказано: в `/dev/serial/by-id/` для двух CH340 существует **ровно ОДИН симлинк** (`usb-1a86_USB_Serial-if00-port0 → ttyUSB1`) — ссылки на `ttyUSB0` через by-id нет вообще (оба адаптера без серийников). by-id физически не может адресовать второй адаптер. 🔴 **Плюс зафиксирована опасность тихого сбоя:** перепутывание кабелей CH340 #1/#2 не проявится ошибкой (оба аддона поднимутся, но будут работать не с теми шинами) — детали в [[family/how-to/t610-access]] §«ГЛАВНЫЙ ПИТФОЛЛ».
 - [ ] Камера (§8 родительского плана) — не аддон, разбираться отдельно
 - [x] ✅ **ВЫПОЛНЕНО 2026-09-14 (конец сессии) — ЗОНЫ восстановлены у 18 устройств.** `area_id` теряется при ре-регистрации устройств (как `device_id`) — все 14 zigbee были без зон. Проставлены по эталону с TrueNAS по `identifiers[0][1]` (`zigbee2mqtt_<ieee>`). Скрипт: `~/tmp-t610/etap3-fix/set_all_areas.jq`.