[2026-09-14] eagle: family/how-to/home-automation.md family/how-to/truenas-infrastructure.md

family/how-to/home-automation.md

@@ -21,11 +21,16 @@ related:
 > **Статус на 2026-09-14:** домашняя автоматизация **перенесена на HP t610** (HA OS).
 > 📌 **Всё про миграцию** — хост, доступ, карта USB/гнёзд, аддоны, Zigbee, питфоллы, текущее состояние — **в единственном документе [[family/plans/t610-home-automation]]. НЕ дублировать сюда.**
 > 📌 **Этот документ — справочник по ЖЕЛЕЗУ:** AT2 (параметры/PWM), карта Slave ID, регистры заслонок/реле, ZONT relays. Оборудование и адреса Modbus при миграции не меняются.
-> **Текущее состояние:** `unavailable` в HA — **10** (было 44). Причина была в **перепутанных гнёздах аддонов** (`mbusd`↔`modbus-bridge`) — исправлено обменом привязок.
+> **Текущее состояние:** `unavailable` в HA — **8** (было 44 → 10 → 8). Оставшиеся все известные: 7 — slave 10 (AT2 fans, блок закомментирован, задача снята) + 1 — `todo.shopping_list` (системная). Первопричина массового отвала была в **перепутанных гнёздах аддонов** (`mbusd`↔`modbus-bridge`) — исправлено обменом привязок; ещё 2 (`dining_summary`/`dining_air_summary`) ожили после фикса сборки кадров bridge.
+>
+> **📷 Камера — ✅ ЗАВЕДЕНА 2026-09-14:** USB-вебка **Logitech `046d:0825`** (смотрит на счётчик воды BK-G4T) подключена к t610 и работает в HA как сущность **`camera.usb_camera`** (кадр JPEG 640×480). Заводится **чисто YAML** — `camera: platform: ffmpeg`, `input: /dev/video0` в `configuration.yaml` (⚠️ **именно прямой `/dev/video0`**, не by-id — by-id-путь внутри контейнера Core не существует и даёт HTTP 500). Подробно и все опровергнутые пути — [[family/plans/t610-home-automation]] §5-кватер-И-3.
 >
 > **✅ ZONT MQTT — ПЕРЕНАПРАВЛЕН 2026-09-14:** на роутере `192.168.2.2` (OpenWrt) DNAT-правила `redirect[0]` (name `MQTT`) и `rule[3]` (name `allow-1883`) переключены `dest_ip` `192.168.2.197` → **`192.168.2.176`**. ZONT теперь пишет в mosquitto-**аддон на t610** (живой поток `modbus/sensors/kids/*`, `bedroom/*`). В настройках ZONT ничего не менялось — адрес `mqtt://zont:…@192.168.0.10:1883` остался тот же (`192.168.0.10` = wan-интерфейс самого роутера `192.168.2.2`). Бэкап правил: `/root/firewall.bak-20260914-092555`. Детали и откат — [[family/plans/t610-home-automation]] §5-кватер-Д. Также `/etc/config/dhcp`: `list address '/mallexxx.duckdns.org/192.168.0.10'` — внутренний DNS-пин для ZONT-сети.
 >
-> **🔌 ZONT 485 спит на гнезде 4** (`/dev/serial/by-path/pci-0000:00:12.0-usb-0:4:1.0-port0`), вентиляция — гнездо 3. `modbus-bridge` (аддон на t610) сниффит ZONT-шину и публикует в MQTT топики `modbus/sensors/<комната>/<параметр>`. **Публикуются только `kids` и `bedroom`** (temperature/co2/humidity). **Причина по `dining/*` — НАЙДЕНА 2026-09-14 (финал): это BRIDGE, не ZONT.** `modbus-bridge` — **виртуальный slave-прокси**: снифит реальные 485-датчики ZONT (slave 2 детская, slave 3 спальня) и **отдаёт их ZONT'у под виртуальными адресами 101/102/103** (Гостиная=101, Детская=102, Спальня=103). По гостиной bridge **ни разу не снифил** реальный датчик (в логе `Sniff:` только `kids_*`/`bedroom_*`) → отдаёт ZONT'у **`0`** → в MQTT `dining/*` не публикуется (0 невалиден). ⚠️ **Прежние версии ОПРОВЕРГНУТЫ:** ① «нужен `|default(0)`» — враньё; ② «датчик отвечает 0» — датчик исправен (на TrueNAS валидные 24.2 °C как retained); ③ «ZONT сам не публикует» — тоже неверно, дело в mapping bridge. **Что делать:** разобрать mapping `modbus-bridge` (`/addons/modbus-bridge/`, `modbus_ha_bridge.py`). Детали — [[family/plans/t610-home-automation]] §5-кватер-Д.
+> **🔌 ZONT 485 сидит на гнезде 4** (`/dev/serial/by-path/pci-0000:00:12.0-usb-0:4:1.0-port0`), вентиляция — гнездо 3. `modbus-bridge` (аддон на t610) сниффит ZONT-шину и публикует в MQTT топики `modbus/sensors/<комната>/<параметр>`. **Публикуются `kids`, `bedroom` И `dining`.**
+>
+> **✅ `dining/*` — ПОЧИНЕН 2026-09-14 (коммит `3748feb`).** Настоящая причина: **баг сборки RTU-кадров в `modbus_ha_bridge.py`** — ответы рвались (`ser.read(ser.in_waiting or 1)` + короткий таймаут), байты-сироты копились в голове буфера → сдвиг выравнивания → **19-байтный** кадр гостиной не сходился по CRC и молча отбрасывался (12-байтные `kids`/`bedroom` проскакивали). Фикс по канону libmodbus/pymodbus: **T3.5-разграничение** (пауза ≥ 3.5 символа = конец кадра; при 9600 бод = 4.01 мс) + **сброс битого буфера** (`buf = b""`, аналог `resetFrame`). Итог: 7/7 полей `dining` публикуются, `unavailable` 10→8. Диагностика `MODBUS_DEBUG_RAW` снята.
+> **❌ ОПРОВЕРГНУТЫЕ версии (не повторять):** ① «нужен `|default(0)`» — не причина; ② «ZONT не публикует / датчик отвечает 0» — датчик исправен, **ответ 19 б на шине есть**, `CRC` валиден; ③ «bridge отдаёт ZONT'у 0, потому что не снифит гостиную» — **неверно: снифит, но терял кадр из-за бага сборки**; ④ «поднять таймаут» — против факта: 12-байтные ответы ловились тем же чтением. Детали разбора — [[family/plans/t610-home-automation]] §5-кватер-З и [[Modbus/RTU_Framing_Source_Analysis]].
 
 ## AT2 — калибровка PWM
 
@@ -215,8 +220,9 @@ ZONT relays
 ```
 
 > **ℹ️ Про «виртуальные sensor 101/102/103» — механика (уточнено 2026-09-14):**
-> 101/102/103 — это **виртуальные Modbus-slaves**, которые контейнер `modbus-bridge` подставляет на шине: реальные 485-датчики **Гостиная=1, Детская=2, Спальня=3** сниффятся, и их значения выдаются ZONT'у как датчики 101/102/103 (регистр 100). ZONT (Modbus master) опрашивает их как внешние датчики.
-> **🔑 Уточнение 2026-09-14 (по логу, см. [[family/plans/t610-home-automation]] §5-кватер-Д):** bridge работает **двусторонне** — он не только публикует в MQTT, но и **отвечает ZONT'у** под адресами 101/102/103. В логе это видно явно: `Slave: 101 → sniff:dining_temperature = 0 [00 00]`, `Slave: 102 → sniff:kids_temperature = 25.26`, `Slave: 103 → sniff:bedroom_temperature = 25.12`. **По гостиной (101) bridge отдаёт `0`**, потому что реальный датчик гостиной он **не снифит** (в логе `Sniff:` только `kids_*`/`bedroom_*`; `Slave: 1` у ZONT читает 7 регистров с адреса 2 — это внутренние параметры, не датчик). **Поэтому** `modbus/sensors/dining/*` не публикуется и `sensor.dining_*` в HA = `unknown`.
+> 101/102/103 — это **виртуальные Modbus-slaves**, которые аддон `modbus-bridge` подставляет на шине: реальные 485-датчики **Гостиная=1, Детская=2, Спальня=3** сниффятся, и их значения выдаются ZONT'у как датчики 101/102/103 (регистр 100). ZONT (Modbus master) опрашивает их как внешние датчики.
+> **🔑 Уточнение (по логу, см. [[family/plans/t610-home-automation]] §5-кватер-Д):** bridge работает **двусторонне** — он и публикует в MQTT, и **отвечает ZONT'у** под адресами 101/102/103. В логе видно: `Slave: 101 → sniff:dining_temperature`, `Slave: 102 → sniff:kids_temperature`, `Slave: 103 → sniff:bedroom_temperature`.
+> **❌ ОПРОВЕРГНУТО (2026-09-14):** прежняя запись «по гостиной bridge отдаёт `0`, потому что датчик не снифится» — **неверна**. Реальная причина была в **баге сборки RTU-кадров** (см. блок выше): 19-байтный кадр гостиной рвался и отбрасывался. После фикса `3748feb` все три комнаты публикуются.
 > Если `modbus-bridge` не запущен/не слушает шину → ZONT показывает эти датчики **«недоступные»**. На TrueNAS известная первопричина была гонка docker/udev после рестарта (см. `[[family/how-to/zont-modbus-bridge-udev-race-protection]]`); **на t610 неактуально** — Supervisor сам ждёт устройство.
 
 ## Карта регистров контроллера вентиляторов

family/how-to/truenas-infrastructure.md

@@ -9,8 +9,9 @@
 > **2026-09-14 (вечер-3) — ZONT MQTT ПЕРЕНАПРАВЛЕН НА t610:**
 > - DNAT на роутере `192.168.2.2`: `firewall.@redirect[0]` (name `MQTT`) и `firewall.@rule[3]` (name `allow-1883`) — `dest_ip` `192.168.2.197` → **`192.168.2.176`**. `uci commit firewall` + `/etc/init.d/firewall reload`. Бэкап: `/root/firewall.bak-20260914-092555`.
 > - **Результат:** ZONT пишет в mosquitto-**аддон на t610** (живой поток `modbus/sensors/kids/*`, `bedroom/*`). В настройках ZONT ничего не менялось (`mqtt://…@192.168.0.10:1883`, где `.0.10` = wan-интерфейс роутера `192.168.2.2`, не отдельный GPON-роутер).
-> - ⚠️ **`dining/*` ZONT не публикует ни в один брокер** — вопрос ZONT-стороны, не маршрута (retained-значения на TrueNAS были валидными → датчик исправен). Подробно — [[family/plans/t610-home-automation]] §5-кватер-Д.
-> - **Не перенесено с TrueNAS:** камера (`cam.*` → мёртвый upstream `.197:8090`); погашение TrueNAS-стека (Этап 4 п.6 — заблокировано: Caddy на TrueNAS держит точку входа).
+> - ✅ **`dining/*` тоже публикуется (2026-09-14, позже):** прежняя версия «ZONT не публикует / мёртвый upstream» — **❌ ОПРОВЕРГНУТА**. Причина была в **баге сборки RTU-кадров в `modbus-bridge`** (19-байтный кадр гостиной рвался), фикс `3748feb` → все 7 полей `dining` живы. Подробно — [[family/plans/t610-home-automation]] §5-кватер-З.
+> - **❌ «Камера на TrueNAS» — ОПРОВЕРГНУТО (2026-09-14):** камера — это **USB-вебка Logitech `046d:0825`**, физически подключённая **к t610**, а не контейнер на TrueNAS. Заведена в HA как `camera.usb_camera` (ffmpeg). Мёртвый upstream `cam.*:8090` в Caddy к камере отношения не имеет. Подробно — [[family/plans/t610-home-automation]] §5-кватер-И-3.
+> - **Не перенесено с TrueNAS:** погашение TrueNAS-стека (Этап 4 п.6 — заблокировано: Caddy на TrueNAS держит точку входа).
 
 > Обновлено: 2026-09-02 (vpn.mallexxx:443 = РАБОЧИЙ Xray-сервер, проверено end-to-end; vless-proxy outbound мёртв)