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

family/how-to/home-automation.md

@@ -10,8 +10,8 @@ tags:
   - how-to
   - smarthome
   - modbus
-updated: '2026-09-12'
+updated: 2026-09-14
-related:
+related: ["[[family/how-to/router-bishkek-asus]]", "[[family/plans/t610-home-automation]]", "[[family/how-to/truenas-access]]"]
   - '[[family/how-to/router-bishkek-asus]]'
   - '[[family/plans/t610-home-automation]]'
 ---
@@ -20,6 +20,8 @@ related:
 > **Статус на 2026-09-14:** домашняя автоматизация **перенесена на HP t610** (HA OS). Всё про перенос, доступ к хосту, карту USB/Zigbee/аддоны, питфоллы и текущее состояние — в едином документе [[family/plans/t610-home-automation]]. **ZONT ещё НЕ перенаправлен** на MQTT t610 — редирект GPON-роутера пока смотрит на TrueNAS.
 >
 > Карты Slave ID и регистров ниже **остаются в силе** — оборудование и адреса Modbus не меняются.
+>
+> ⚠️ **Про 44 `unavailable` заслонок на t610:** конфиг `modbus:` на t610 **построчно ИДЕНТИЧЕН** эталону TrueNAS (`/mnt/RED_2TB/docker/ha/configuration.yaml`) — сверено 2026-09-14. Значит проблема **не в адресах/регистрах**, а в шине: замер дал **76% `EXC 0x0B`**, главная гипотеза — **два Modbus-мастера на одной RS-485** (TrueNAS-HA + t610-HA). Детали и питфоллы — §5 в [[family/plans/t610-home-automation]].
 
 ## AT2 — калибровка PWM
 

family/plans/t610-home-automation.md

@@ -24,7 +24,7 @@
 
 | Что | Состояние |
 |---|---|
-| **44 сущности `unavailable`** | ~32 заслонки (`switch.intake_damper_*`, `exhaust_damper_*`) + вентиляторы (`switch.fan_3_*`, `sensor.fan_at2_*`). **Причина НАЙДЕНА 2026-09-14 (поздняя), три слоя — см. §5 «ТРИ реальные причины»:** ① шторм ~28 параллельных TCP-коннектов HA при `mbusd maxconn: 8`; ② регистры отвечают нестабильно (`EXC 0x0B` через раз); ③ `verify` с `state_on: 1`/`state_off: 0` не может сойтись с живым `0x640001`. План фикса согласован, **не применён**. |
+| **44 сущности `unavailable`** | ~32 заслонки (`switch.intake_damper_*`, `exhaust_damper_*`) + вентиляторы (`switch.fan_3_*`, `sensor.fan_at2_*`). **Диагностика 2026-09-14 (позднейшая) — см. §5.** Итог: ① попытка фикса опций mbusd **провалилась** (`maxconn 16` сломал конфиг аддона → откат); ② замер 30 запросов → **76% `EXC 0x0B`**; ③ **эталон TrueNAS (/mnt/RED_2TB/docker/ha/configuration.yaml) ИДЕНТИЧЕН t610** → причина НЕ конфиг; ④ **главная гипотеза: два Modbus-мастера на одной RS-485** (TrueNAS-HA + t610-HA) — **НЕ подтверждена**, ждёт проверки отключением TrueNAS-стека. |
 | **`sensor.fan_at2_*` — сироты** | В `configuration.yaml` **все `sensors:` закомментированы** → эти сущности физически не могут получать данные. Разобраться с происхождением (2026-09-14 поздняя) |
 | `switch.sauna` = `unknown` | Розетка физически отключена (`lastSeen` 8+ ч) — не баг |
 | ZONT не перенаправлен | MQTT-редирект GPON-роутера ещё смотрит на TrueNAS |
@@ -349,16 +349,64 @@ HA **пишет** 256/512 в reg 5, а **читает** из того же reg 5
  "trx_control":"addc","maxconn":8,"wait":500,"pause":100,"retries":3,"timeout":1000}
 ```
 
-**ПЛАН ФИКСА (согласован, НЕ применён — ждём ОК Alex):**
+### 🔴🔴 РЕЗУЛЬТАТ ПОПЫТКИ ФИКСА 2026-09-14 (позднейшая сессия) — maxconn СЛОМАЛ mbusd
 
-| # | Правка | Зачем | Риск |
+**Итог: фикс применён, сломал mbusd, откачен. Причина `unavailable` НЕ опции, а коллизия двух мастеров (гипотеза, требует подтверждения).**
-|---|---|---|---|
-| 1 | `timeout 1000 → 3000`, `retries 3 → 1` | Дать медленным реле ответить (причина 2) | обратимый |
-| 2 | `maxconn 8 → 16` | Снять лимит при ~28 параллельных опросах (причина 1) | обратимый |
-| 3 | Разобраться с `verify` (убрать/смягчить) | Иначе `unavailable` не уйдёт даже при живом регистре (причина 3) | требует проверки на живом |
 
-**Порядок:** ① бэкап текущих опций аддона → ② правка `timeout`/`retries`/`maxconn` через Supervisor API (§8) → ③ `ha apps restart local_mbusd` → ④ проверка ухода `unavailable` → ⑤ только потом трогать `verify`.
+**Что сделано:**
-> ⚠️ Правки в `/config/configuration.yaml` — через **HA stop → правка → HA start** (или `ha core check` перед стартом). Бэкап обязателен.
+1. Бэкап: `/config/mb-fix-backup-20260914-145419/` (`mbusd-options.json`, `configuration.yaml`).
+2. Правка через Supervisor API: `timeout 1000→3000`, `retries 3→1`, `maxconn 8→16` → POST `{"result":"ok"}` → `ha apps restart local_mbusd`.
+3. **mbusd упал → `state: "error"`.** Лог:
+   ```
+   [mbusd] conf written:
+   maxconn=16
+   wait=500
+   ...
+   mbusd: can't read config file /etc/mbusd/mbusd.conf: error at line 13:
+   ```
+4. **Откат** к рабочим (`timeout 1000`, `retries 3`, `maxconn 8`) → mbusd снова `started`, HA подключился (`conn_open from 192.168.2.176`).
+
+> 🔴 **ПИТФОЛЛ (КРИТИЧНЫЙ): `maxconn` НЕ ТРОГАТЬ.** Генератор конфига в `run.sh` аддона `local_mbusd` собирает `mbusd.conf` так, что при `maxconn=16` (двузначное) ломается разметка файла → `error at line 13` → mbusd не стартует. Значения `maxconn=8` (однозначное) хватало. Есть подозрение, что дело именно в **двузначном** числе/отсутствии перевода строки в шаблоне. **Правило: `maxconn` не менять. Остальные опции (`timeout`, `retries`) — можно, проверять отдельно.**
+> ⚠️ Симптом провала аддона: `ha apps info local_mbusd --raw-json | jq -c '.data.state'` → `"error"`. Смотреть `ha apps logs local_mbusd | tail`.
+> ✅ **Откат рабочий рецепт:** POST опций `{timeout:1000, retries:3, maxconn:8}` → `ha apps restart local_mbusd` → ждать ~15 с → `state` должен стать `"started"`.
+
+**Кто на самом деле опрашивает шину (объективный замер 30 запросов):**
+```
+30 запросов подряд, slave 11 reg 7  → OK=7  FAIL=23   (76% потерь, EXC 0x0B)
+30 запросов подряд, slave 11 reg 5  → OK=7  FAIL=23
+```
+и среди ответов попался **чужой ответ на запрос, которого я не слал** (`…060b 01 00000001`) — признак, что **на шине есть второй мастер/источник трафика**.
+
+**🔴 ГЛАВНАЯ ГИПОТЕЗА (2026-09-14 позднейшая): два Modbus-мастера на одной физической RS-485.**
+TrueNAS-HA (mbusd на TrueNAS) и t610-HA (mbusd на t610) висят на **одной паре A/B** (кабель один, через CH340 #2). Два мастера = коллизии = 76% `EXC 0x0B`. **Не подтверждено** — прервано на вопросе «запущен ли TrueNAS-стек».
+> ⚠️ **НЕ принято за факт.** Проверка, которую надо доделать: остановить/убедиться в остановке TrueNAS-стека (`docker stop homeassistant mbusd modbus-bridge`) → повторить замер 30 запросов → если потери упадут до ~0, гипотеза верна, и «фикс» = Этап 4 (отключение TrueNAS), а **не** правка опций mbusd.
+> ✅ Чистый тест (не доделан): `ha core stop` → замер шины → `ha core start`. Прошлый прогон повис по таймауту 300 с (HA не ответил), но HA вернулся сам (HTTP 200). **Вывод: `ha core stop` в SSH-сессии может блокировать команду — проверять состояние после, не полагаться на вывод теста.**
+
+### ✅ ЭТАЛОН TRUENAS НАЙДЕН — modbus-блок ИДЕНТИЧЕН t610
+
+Путь эталона (чинится без sudo, права 644): **`/mnt/RED_2TB/docker/ha/configuration.yaml`**
+(⚠️ не `/mnt/RED_2TB/docker/homeassistant/` — та папка ПУСТА, `find` показывает реальный путь `/mnt/RED_2TB/docker/ha/`).
+
+**Сверка построчная (2026-09-14 позднейшая):** `intake_damper_*` (dining right/left, kids, bedroom, office, north) + `exhaust_damper_*` (kitchen, bathroom, office, toilet_1, shower_2) — **32 записи, slave/address/`verify` СОВПАДАЮТ ВСЕ**. Закомментированная slave 10 (AT2 fans) — тоже идентична.
+
+> ✅ **ВЫВОД: конфиг при миграции перенесён КОРРЕКТНО. Расхождений в `modbus:` между TrueNAS и t610 НЕТ.** Значит причина `unavailable` — **НЕ конфиг**. На TrueNAS работало при том же конфиге → разница только в транспорте/шине (два мастера).
+> 📌 **Ключевая разница хостов:** на TrueNAS HA бил в **свой локальный mbusd** по `192.168.2.197:502`; на t610 HA (`172.30.32.1`) ходит в `192.168.2.176:502` (порт на хосте). Плюс **только один кабель** на физическую шину → возможны два мастера.
+
+**Как снять эталон (команды):**
+```bash
+ssh truenas_admin@mallexxx.duckdns.org
+find /mnt/RED_2TB/docker -maxdepth 3 -name "configuration.yaml"     # → /mnt/RED_2TB/docker/ha/configuration.yaml
+# список заслонок эталона:
+awk '/^modbus:/{f=1} f' /mnt/RED_2TB/docker/ha/configuration.yaml \
+  | grep -E "^      - name:|^        slave:|^        address:" | paste - - -
+```
+
+### 📌 Сверка .157 — ПОВТОРНЫЙ урок (не путать)
+
+`192.168.2.157` = **Rasputin, MAC `36:ae:87:04:08:dc`** (подтверждено по `dhcp.leases` роутера `192.168.2.2`). Под NAT Rasputin **выглядит ЛЮБОЙ трафик из локалки — включая запросы самого агента** (с Mac и из SSH-аддона). В логе mbusd **53 коннекта от `.157`** = это МОИ же диагностические запросы, **НЕ** посторонний клиент и **НЕ** TrueNAS.
+> 🔴 **Правило: по IP `.157` НЕЛЬЗЯ определить, кто клиент.** Для этого — `netstat` ВНУТРИ t610 (покажет `172.30.33.0` = контейнер HA Core) или смотреть на роутере.
+
+**Рабочие файлы этой сессии:** `~/tmp-t610/mbdiag1..4.sh`, `mb_backup.sh`, `mb_fix_opts.sh`, `mb_rollback.sh`, `mb_dump_t610.sh`, `mb_stress.sh`, `mb_master_test.sh`.
 
 ### ZONT (шина на CH340 #1)
 
@@ -640,7 +688,8 @@ curl -s -X POST -H "$HDR" -H "Content-Type: application/json" \
 
 | # | Задача | Кто |
 |---|---|---|
-| 1 | **Фикс 44 `unavailable`** — диагноз готов (§5 «ТРИ реальные причины»). План: ① `mbusd timeout 1000→3000`, `retries 3→1`; ② `maxconn 8→16`; ③ разобраться с `verify` (не сходится с `0x640001`). Правки опций — через Supervisor API, бэкап до. **Ждёт ОК Alex** | я |
+| 1 | **Фикс 44 `unavailable`** — ~~план опций mbusd~~ **ОТМЕНЁН: `maxconn` ломает аддон (откатано).** Эталон TrueNAS идентичен → причина НЕ конфиг. **Проверить гипотезу двух мастеров:** убедиться, что TrueNAS-стек остановлен (`docker stop homeassistant mbusd modbus-bridge`) → замер 30 запросов → если потери упали, «фикс» = Этап 4 (задача 6), а не опции | я |
+| 1b | **`verify` в заслонках** — `state_on: 1`/`state_off: 0` не сходится с живым `0x640001`. Трогать **только после** стабилизации шины | я |
 | 2 | Раскомментировать slave 10 (AT2 fans) в `configuration.yaml` — был закомментирован «not responding on bus» | я |
 | 3 | `sensor.*_summary` — добавить `\|default(0)` в template-сенсоры (косметика, самоизлечится) | — |
 | 4 | **Камера** — найти образ/папку, поднять на t610, поправить upstream в Caddy | отдельно |
@@ -676,6 +725,10 @@ docker restart caddy
 
 **Бэкапы (Mac):** `~/tmp-t610/backups/config-t610-20260914-115034.tar.gz`, `truenas-ha-backup-20260913-215043.tar.gz`.
 
+**Попытка фикса mbusd (2026-09-14 позднейшая):** `~/tmp-t610/mb_backup.sh` (бэкап опций+конфига), `mb_fix_opts.sh` (правка опций → СЛОМАЛ), `mb_rollback.sh` (**откат → рабочий**), `mb_dump_t610.sh` (дамp modbus-блока), `mb_stress.sh` (замер 30 запросов), `mb_master_test.sh` (тест «стоп HA → замер», повис по таймауту).
+**Бэкап опций на t610:** `/config/mb-fix-backup-20260914-145419/` (`mbusd-options.json`, `configuration.yaml`).
+**Эталон TrueNAS:** `/mnt/RED_2TB/docker/ha/configuration.yaml` (читать без sudo, права 644).
+
 ---
 
 ## 11. История документа