[2026-09-14] eagle: family/how-to/t610-access.md family/plans/home-automation-migration-t610.md family/plans/t610-addons-deployment.md
This commit is contained in:
Alexey Martemyanov
@@ -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` |
|
||||
| Порт слушается | `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) ✅ |
|
||||
| Параметры | там же | speed 9600, mode 8n1, retries 3, timeout 1000, trx `addc` |
|
||||
| Modbus-запрос к slave 11 | `printf '\x0b\x03\x00\x00\x00\x01\xd5\xba' \| nc 192.168.2.176 502` | ❌ **пусто (нет ответа)** |
|
||||
| Лог mbusd | `ha apps logs local_mbusd \| tail -20` | только `conn_open()`/`conn_close()` — **запросы до порта не доходят** |
|
||||
| Аддон запущен | `ha apps info local_mbusd` | `state: started` ✅ |
|
||||
| Порт слушается | `nc -z 192.168.2.176 502` | ✅ открыт |
|
||||
| Устройство | `ha apps info local_mbusd \| grep -A8 'options:'` | `by-path ...0:4:1.0-port0` (CH340 #2, порт 4) ✅ |
|
||||
| Параметры | там же | speed 9600, mode 8n1, **timeout 1000** ⚠️, retries 3, trx `addc` |
|
||||
| Шина отвечает | Python-запрос на reg из конфига HA | ✅ **ДА** (см. таблицу выше) |
|
||||
|
||||
**Интерпретация:** 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`.
|
||||
|
||||
**Вывод: конфиг верный, дело в физике.** Варианты: линии **A/B** вентиляционной шины не подключены к CH340 #2, либо шина обесточена, либо неверны slave-адреса/скорость. **Работа за Alex** — проверить физическое подключение CH340 #2 к шине вентиляции.
|
||||
|
||||
> ⚠️ Проверить, что CH340 #2 действительно смотрит на вентиляцию (а не перепутан с ZONT), **без физического вмешательства нельзя** — на шине вентиляции никто не отвечает, эталонного трафика для сравнения нет. См. §«ОПАСНОСТЬ ТИХОГО СБОЯ» выше.
|
||||
> ⚠️ **Не путать при диагностике:** раньше бытовало мнение «в логе mbusd `conn_open/close` от `.157` = посторонний клиент забивает слоты». **Это ложный след.** `.157` — это eth0 роутера Rasputin, через который идёт весь трафик из локалки 192.168.2.x; источник — сам Mac. Источник в логе mbusd — всегда адрес того, кто реально открывает TCP-соединение. ⚠️ **Также:** `nc` на OpenWrt (busybox) не поддерживает `-z` — для проверок портов с роутеров использовать `curl`/`wget`.
|
||||
>
|
||||
> ℹ️ **Конфиг 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» — чтобы не блокировать опрос заслонок. После починки шины — раскомментировать.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user