> **ℹ️ Про «виртуальные 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`.
> Если `modbus-bridge` не запущен/не слушает шину → ZONT показывает эти датчики **«недоступные»**. На TrueNAS известная первопричина была гонка docker/udev после рестарта (см. `[[family/plans/zont-modbus-bridge-udev-race-protection]]`); **на t610 неактуально** — Supervisor сам ждёт устройство.
> Если `modbus-bridge` не запущен/не слушает шину → ZONT показывает эти датчики **«недоступные»**. На TrueNAS известная первопричина была гонка docker/udev после рестарта (см. `[[family/how-to/zont-modbus-bridge-udev-race-protection]]`); **на t610 неактуально** — Supervisor сам ждёт устройство.
- [[family/how-to/home-automation]] — общая автоматизация дома
- [[family/plans/t610-home-automation]] — миграция на t610, §5-кватер-Г (перенос flows) и §5-кватер-З (фикс датчика столовой)
- [[Modbus/RTU_Framing_Source_Analysis]] — канон сборки RTU-кадров (почему `dining` молчал и как починили)
## Статус данных для автоматики (2026-09-14)
✅ **Все три комнаты (`bedroom`, `kids`, `dining`) публикуют данные в MQTT.** Датчик столовой (`slave 1`) был сломан багом сборки кадров в `modbus-bridge` — починен 2026-09-14 (см. [[family/plans/t610-home-automation]] §5-кватер-З). До фикса автоматика вентиляции по CO₂ работала без данных столовой.
⚠️ **`fan.fan_at2_1/2` (slave 10) — `unavailable`** (блок закомментирован в `configuration.yaml`) → исполнительный контур вентиляторов AT2 не работает. Задача по slave 10 Alex'ом не ставилась.
> - Защита от рецидива (план, НЕ внедрён — ждёт OK Alex): `family/plans/zont-modbus-bridge-udev-race-protection.md` — POSTINIT init script с ожиданием симлинков + `docker start`.
> - Защита от рецидива (план, НЕ внедрён — ждёт OK Alex): `family/how-to/zont-modbus-bridge-udev-race-protection.md` — POSTINIT init script с ожиданием симлинков + `docker start`.
> **⚠️ ДРУГОЕ (открытое):** пул `DEST` (IronWolf) на 2026-08-24 `DEGRADED` — разобраться, почему (отвалился mirror-член). TimeMachine (~277G) не возвращён (бэкапы macOS, вероятно не нужен — решение Alex не подтверждено). SSH с Mac по 192.168.2.197 нестабилен — использовать `mallexxx.duckdns.org`.
> ## 🔒 ИСТОРИЯ: статус до восстановления (2026-08-24)
@@ -342,7 +342,7 @@ error gathering device information while adding custom device "/dev/ttyZONT": no
**Ручной фикс:**`docker start modbus-bridge mbusd` (после того как симлинки созданы).
**Защита от рецидива (план, НЕ внедрён, ждёт OK Alex):**`family/plans/zont-modbus-bridge-udev-race-protection.md` — POSTINIT init script `/mnt/RED_2TB/system/start-modbus.sh`, который ждёт появления `ttyZONT`/`ttyVent` (≤25с) и делает `docker start modbus-bridge mbusd`.
**Защита от рецидива (план, НЕ внедрён, ждёт OK Alex):**`family/how-to/zont-modbus-bridge-udev-race-protection.md` — POSTINIT init script `/mnt/RED_2TB/system/start-modbus.sh`, который ждёт появления `ttyZONT`/`ttyVent` (≤25с) и делает `docker start modbus-bridge mbusd`.
## 1. Состояние на 2026-09-14 (актуализировано 15:33 → дополнено вечерней сессией)
**Этап 1 ✅ · Этап 2 ✅ · Этап 3 ✅ ЗАКРЫТ.** Этап 4 — **ПОЧТИ ЗАКРЫТ (3 из 4):** ① Caddy → t610 (`mallexxx.duckdns.org` → HA на t610, HTTP 200); ② Node-RED flows перенесены, `Connected to HA`, наружу не выпущен (решение Alex «оставляем так», доступ через ingress); ③ **ZONT MQTT-редирект переключён на t610** (DNAT на роутере `.197`→`.176`, живой поток идёт). **ОСТАЛОСЬ:** погасить/отключить сервисы TrueNAS (заблокировано — Caddy на TrueNAS держит точку входа) + хвосты (static IP, бэкап).
**Последняя верификация: 2026-09-14 (вечер-6) — ФИКС СДЕЛАН, ГОСТИНАЯ РАБОТАЕТ. ✅✅ ЗАКРЫТО.** Причина (вечер-5, фактом): кадры приходят разорванными, байты-сироты `00` копились в голове буфера → сдвиг выравнивания → 19-байтный ответ гостиной отбрасывался молча. **Фикс (вечер-6): сборка кадров по канону — T3.5-разграничение (пауза ≥3.5 символа = конец кадра) + сброс битого буфера (= `resetFrame` в pymodbus)**, коммит `3748feb` → Gitea → scp → `ha apps rebuild`. **Итог: все 7 полей `dining` публикуются, `dining_summary`/`dining_air_summary` ожили, `unavailable` 10 → 8** (остались только slave 10 «снято Alex'ом» + `todo.shopping_list`). **Загадка «замерзания» лога на 7 ч — тот же баг, устранена.** Диагностика включена (`MODBUS_DEBUG_RAW=1`), выключить после наблюдения. Детали — §5-кватер-З, §11 (журнал вечер-6).
**Последняя верификация: 2026-09-14 (вечер-7) — ФИКС ПОДТВЕРЖДЁН, ДИАГНОСТИКА СНЯТА. ✅✅ ЗАКРЫТО.** Причина (вечер-5, фактом): кадры приходят разорванными, байты-сироты `00` копились в голове буфера → сдвиг выравнивания → 19-байтный ответ гостиной отбрасывался молча. **Фикс (вечер-6): сборка кадров по канону — T3.5-разграничение (пауза ≥3.5 символа = конец кадра) + сброс битого буфера (= `resetFrame` в pymodbus)**, коммит `3748feb` → Gitea → scp → `ha apps rebuild`. **Итог: все 7 полей `dining` публикуются, `dining_summary`/`dining_air_summary` ожили, `unavailable` 10 → 8** (остались только slave 10 «снято Alex'ом» + `todo.shopping_list`). **Загадка «замерзания» лога на 7 ч — тот же баг, устранена.** Диагностика ✅ снята (вечер-7), `dining` стабилен. Детали — §5-кватер-З, §11 (журнал вечер-6/7).
4. **Правку в продакшене делать через git-репо, не «на месте»** (сначала коммит, потом scp+rebuild) — даёт чистую историю и откат.
5. **Перед правкой сложной логики — офлайн-тест на реальных данных** (`test_framing.py`) дешевле и быстрее, чем rebuild+деплой-цикл (~1 мин каждый).
#### 📌 Осталось (по этой задаче)
#### 📌 Итог по задаче — ЗАКРЫТА
- **Диагностика ВКЛЮЧЕНА** (`MODBUS_DEBUG_RAW=1` в `run.sh` на t610) — понаблюдать за стабильностью `dining`, затем **выключить**: закомментировать строку в `run.sh` → `ha apps rebuild local_modbus-bridge`. Ждёт команды Alex.
- **Диагностика ✅ СНЯТА 2026-09-14 (вечер-7).** Наблюдение показало стабильность: `dining` 7 публикаций за окно против 6 у `kids`/`bedroom` (тот же порядок), `BUF-DROP` = 1 (единичный, не накопление), `[RAW*]` в логе = 0. `MODBUS_DEBUG_RAW=1` закомментирован в `run.sh` → `ha apps rebuild local_modbus-bridge` → рестарт. Проверено: лог чистый, все 7 полей `dining` публикуются.
- **Как включить снова при отладке framing:** раскомментировать `export MODBUS_DEBUG_RAW=1` в `run.sh` → rebuild → рестарт.
- **Крон-наблюдение** за `dining` (не пропадает ли снова) — не заводилось.
| ~~1b~~ | ~~`verify` в заслонках~~ — **✅ ОПРОВЕРГНУТО:** заслонки ожили при том же `verify`. Не причина. | — |
| ~~1c~~ | ~~ZONT-шина на других гнёздах~~ — **✅ СДЕЛАНО:** физический тест доказал (ZONT = гнездо 4, вентиляция = гнездо 3), привязки аддонов обменяны, док приведён в соответствие. Осталась только проверка «① подтвердить у Alex» — **закрыто**: он сам это и тестировал. | — |
| ~~2~~ | ~~Раскомментировать slave 10 (AT2 fans)~~ — **СНЯТО с плана (Alex 2026-09-14): задачи по slave 10 НЕ БЫЛО.** | — |
| ~~3-гт~~ | ~~**Gitea remote для `~/Automation/HA-ZONT-Modbus`**~~ — **✅ СДЕЛАНО 2026-09-14 (см. §5-кватер-Е «GITEA»).** Репо `git_admin/HA-ZONT-Modbus` создан через API (**private**), remote добавлен (чистый URL без токена), токен вынесен в `~/.git-credentials` (chmod 600) + `credential.helper=store`, первый push прошёл (`7e0b281`, ветка `main`). **Осталось:** ⚠️ ротировать/вынести токен из НАМЕРТВО открытого remote у `nolvu-landing` (`https://git_admin:<token>@…` — светился в выводах команд). Детали — §5-кватер-Е | ✅ сделано |
| 4 | **Камера** — найти образ/папку, поднять на t610, поправить upstream в Caddy | отдельно |
| ~~5~~ | ~~**Этап 4:** Caddy upstream → t610~~ — **✅ ЧАСТЬ «CADDY» ЗАКРЫТА 2026-09-14 (см. §5-кватер-Б/В):** Caddyfile залит (Alex подменил файл + `restart caddy`), `mallexxx.duckdns.org` → **HTTP 200** (HA на t610, подтверждено Alex'ом), попутно исправлен `trusted_proxies` в `.storage/http` (§5-кватер-В-1). **ОСТАЛОСЬ из Этапа 4:** ① `nodered.*` — починить порт (см. задачу 5-нр ниже); ② GPON-редирект → t610; ③ ZONT MQTT → t610. **🔴 Архитектурный вывод: Caddy НЕ переносить** (17 из 20 доменов — сервисы TrueNAS) | — |
| ~~**B2**~~ | ~~**Node-RED наружу** — выставить порт аддона и поправить Caddy~~ | — | **✅ СНЯТО (2026-09-14 вечер-7):** решение Alex — «оставляем так». Node-RED доступен через **ingress** HA (`http://192.168.2.176/api/hassio_ingress/<token>/`), наружу не выпускается. Домен `nodered.*` не используется. См. §5-кватер-Г и `[[family/how-to/nodered-ventilation]]` |
**Вариант B — Этап 4 целиком** (№5: Caddy upstream → t610 + GPON-редирект → t610 + ZONT MQTT → t610). 🔴 Трогает рабочее → нужно окно и согласование с Alex. **Caddy-часть СДЕЛАНА (§5-кватер-Б/В).**
**Открытые вопросы к Alex:**
1. **Node-RED:** на t610 **пустой** (124 B flows), на TrueNAS — с потоками. Нужен ли t610-Node-RED, или переносить flows? Порт выставляем? (§5-кватер-В-2)
2. **Датчик столовой:** почему отдаёт 0 — копать ZONT сейчас или в бэклог? (§5-кватер-А)
3. **«Замерзание» лога bridge** — копать сейчас или отложить.
4. **Этап 4 / погасить TrueNAS:** где живёт точка входа, если Caddy нельзя уносить с TrueNAS? (§5-кватер-Б)
**Открытые вопросы к Alex — ✅ ВСЕ ЗАКРЫТЫ по итогу 2026-09-14 (вечер-7):**
1. ~~**Node-RED:** на t610 пустой…~~ → **✅ РЕШЕНО (вечер-2, §5-кватер-Г):** flows перенесены (68 узлов), узел server `addon: true`. Порт **не выставляем** — решение Alex «оставляем так», доступ через ingress. Задача B2 снята.
2. ~~**Датчик столовой:** почему отдаёт 0 — копать?~~ → **✅ РЕШЕНО (вечер-5/6, §5-кватер-Ж/З):** причина **не** в ZONT/шине (ответ был, CRC валиден) — баг сборки кадров в `modbus-bridge`. Фикс коммит `3748feb`. Все 7 полей `dining` живы в HA.
3. ~~**«Замерзание» лога bridge**~~ → **✅ РЕШЕНО:** тот же баг сборки кадров (байты-сироты копились в буфере, `[BUF-LEFT 1] 00` ×20). Устранён фиксом `3748feb`.
4. **Этап 4 / погасить TrueNAS:** где живёт точка входа, если Caddy нельзя уносить с TrueNAS? (§5-кватер-Б) — **открыт**: Caddy оставлен на TrueNAS осознанно (17 из 20 доменов — сервисы TrueNAS).
> 📌 **Процессный урок (положительный):** Alex дал **гипотезу + просьбу проверить канон** — агент **не гадал**, а: (1) нашёл реальный код libmodbus/pymodbus, (2) офлайн-тест на реальных байтах **до** деплоя, (3) деплой + верификация через независимый источник (HA API, а не только лог самого bridge). Схема «гипотеза → канон → офлайн-тест → деплой → независимая проверка» сработала с первого раза.
> ⚠️ **Питфолл Hermes (трижды за сессию):** inline `$( … | jq … )` / `$( … | sed … )` + токены → **маскируются и ломаются**. Только **скрипт файлом**.
> ⚠️ **Питфолл `ha apps info --raw-json`:** путь `.data.options.ha_token`, не `.options`. Значение `ha_token` в выводе маскируется → использовать программно.
### 2026-09-14 (вечер-7: снятие диагностики + приведение доков в актуал)
**Контекст:** Alex — *«Проверь и выключай диаг. Доки в актуал. Обязательно убедись что есть доки по всей automation папке и залинковано всё»*.
**Что сделано:**
| Шаг | Факт |
|---|---|
| 🔍 Проверка стабильности | `dining` — **7 публикаций** за окно против **6** у `kids`/`bedroom` (тот же порядок); `BUF-DROP` = 1 (единичный, не накопление); `[RAW*]` в логе = **0** → фикс держится |
| 📚 Аудит доков | Проверены все доки по автоматике. **`~/Automation` — НЕ папка HA-автоматики**, а общая свалка скриптов (Xcode-скриптлеты, yt-сабы, xliff, zoom); HA-проект там один — `HA-ZONT-Modbus` |
| 🔴 Битая ссылка | `family/how-to/home-automation.md` ссылался на `[[family/plans/zont-modbus-bridge-udev-race-protection]]`, а файл лежит в `family/how-to/` → **исправлено** |
| 🔗 Изолированный док | `Modbus/RTU_Framing_Source_Analysis.md` (ресёрч канона) — **0 входящих ссылок** → дописан целиком + залинкован из плана и `nodered-ventilation` |
| ✅ Уже было актуально | `family/how-to/gitea-config.md` — `HA-ZONT-Modbus` в таблице репо + питфолл про токен в URL; `family/how-to/nodered-ventilation.md` — статус переноса flows |
**Что менялось в железе:** только `run.sh` аддона `modbus-bridge` на t610 (снятие env-флага) → rebuild + restart. Код `modbus_ha_bridge.py` не трогался.
**Проверено фактами:** лог bridge (dining 7/7), счётчики `[RAW*]`/`BUF-DROP`, наличие/отсутствие файлов доков и их ссылок.
> ⚠️ **Питфолл (Hermes):** `execute_code` — это Python-песочница; вызов bash через `subprocess` там лишний (и упал на отсутствии `psutil`). **Для grep/поиска — `terminal` + `grep`, не Python.**
---
## Связанные заметки
@@ -2116,3 +2141,6 @@ ssh root@192.168.2.176 'ha apps rebuild local_modbus-bridge && ha apps restart l
- [[family/how-to/nodered-ventilation]] — автоматика вентиляции в Node-RED (flows на t610)
- [[family/how-to/truenas-sata-ports-and-zfs-pools]] — железо TrueNAS (диски/пулы, для контекста)
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Alexey Martemyanov