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

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.
-> 🔍 **Разбор 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)».
+> 🔴 **ОШИБКА ПРЕДЫДУЩЕЙ РЕДАКЦИИ — ИСПРАВЛЕНО 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 открыт**. **Прежний вывод «в логе только `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`.