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

family/plans/t610-home-automation.md

@@ -9,7 +9,7 @@
 ## 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 (вечер-4, разбор кода + git/Gitea) — регресса нет, в железе ничего не менялось. Код `modbus_ha_bridge.py` разобран построчно: причина потери ответа гостиной локализована в **приёме кадра** (стр. 675 `ser.read(ser.in_waiting or 1)`), а лог bridge **структурно слеп** к этой ошибке (печатает только валидные кадры, стр. 692–694; битые уходят молча — стр. 687). Гипотеза «поднять таймаут» снята фактом (12-байтные ответы kids/bedroom ловятся тем же чтением). План фикса — задача A0/№3 (§9), **ждёт ОК Alex**. Также: проект-репозиторий — `~/Automation/HA-ZONT-Modbus` (не `/addons/`!), **Gitea-remote СОЗДАН (`git_admin/HA-ZONT-Modbus`, private, push `7e0b281`) — задача 3-гт ✅ ЗАКРЫТА (§5-кватер-Е).** Детали — §5-кватер-Д («РАЗБОР КОДА»), §5-кватер-Е («GITEA»), §9, §11 (журнал вечер-4).
+**Последняя верификация: 2026-09-14 (вечер-5) — правка логирования bridge ВЫПОЛНЕНА, ПРИЧИНА НАЙДЕНА фактом. Диагностический лог сырых байт показал: кадры приходят РАЗОРВАННЫМИ (1+7 байт), нераспознанные байты-сироты (`00`) НАКАПЛИВАЮТСЯ в буфере и не чистятся (стр. 960–961) → сдвигают выравнивание → длинный 19-байтный ответ гостиной отбрасывается молча. `timeout` как причина окончательно снят. Это же объясняет «замерзание» лога на 7 ч. План фикса (A/B/C) предложен Alex'у, выбор — за ним (§5-кватер-Ж). Детали — §5-кватер-Д («РАЗБОР КОДА» + «РАЗГАДКА»), §5-кватер-Е («GITEA»), §5-кватер-Ж, §9, §11 (журнал вечер-5).
 
 | Что | Факт |
 |---|---|
@@ -1023,10 +1023,31 @@ Alex дал решающую наводку: **«ответ есть или не
 **🔴 ВЫВОД: датчик гостиной ИСПРАВЕН и ОТВЕЧАЕТ на шине. Данные есть.**
 2. **Конфиг bridge на t610 проверен — `dining` ТАМ ЕСТЬ.** `/addons/modbus-bridge/data/config.template.tmpl`, шаблон 3934 б: `slave_id: 1`, `base_register: 2`, `quantity: 7`, `device_name: "Dining Sensor"`, поля `dining_co2/formaldehyde/tvoc/pm2_5/pm10/temperature/humidity` с `offset` 0…6, `divider: 10`, `correction_offset: -1` у температуры. **Конфиг идентичен эталону TrueNAS** (`/mnt/RED_2TB/docker/modbus-bridge/config.yml` — тот же блок sniff с теми же offset/divider).
 
+**✅ РАЗГАДКА НАЙДЕНА (2026-09-14, вечер-5) — правка логирования ВЫПОЛНЕНА, сырые байты показали МЕХАНИЗМ:**
+
+Правка логирования (Шаг 1 плана) **применена**; сырой лог снят и дал ответ. Ниже — что именно видно, и это **отменяет** формулировку «три кандидата, различить только замером»: замер сделан, картина однозначная.
+
+Полный разбор новой сессии — §5-кватер-Ж. Кратко — **механизм бага:**
+
+1. **Кадры приходят РАЗОРВАННЫМИ на разные итерации чтения.** В логе: `[RAW 1] 64` (только адрес slave) → `[BUF-LEFT 2] 00 64` → `[RAW 7] 03 00 64 00 01 cc 20` (остальные 7 байт). 8-байтный кадр приходит **двумя кусками (1 + 7)**. Bridge склеивает их в `buf` — и **короткий (12 б) ответ успевает собраться**.
+2. **Мусорные байты-сироты накапливаются в буфере и НЕ чистятся.** В логе по 15–20 подряд `[BUF-LEFT 1] 00`. Одиночный байт (`00`, `64`, `66`, `65`) **не образует валидный кадр по CRC**, а `del buf[i:j+1]` не срабатывает (`found == False`) → байт **остаётся в начале `buf` навсегда** и **сдвигает выравнивание** для всех последующих кадров.
+3. **Длинный кадр гостиной (19 байт) страдает первым** — он рвётся на больше кусков, и при сдвиге на байт-сироту сканер начинает с `i=0`, где лежит мусор → `frame[0]` = `00` вместо `01` → CRC не сходится → **ответ отбрасывается молча**.
+
+**🔴 Вывод: причина — НЕ таймаут. Причина — сканер не обрезает нераспознанный префикс буфера, и длинный кадр теряется из-за сдвига выравнивания.** Гипотеза «поднять таймаут» окончательно снята (12-байтные ответы ловятся при том же `timeout`).
+
+**План фикса (предложен Alex'у, ждёт выбора — см. §5-кватер-Ж):**
+- **(A)** минимальная правка буфера: в конце сканера обрезать нераспознанный префикс (`if not found and i > len(buf)-5: del buf[:i]`).
+- **(B)** правильное чтение по межбайтовой паузе (≥3.5 символа = Modbus RTU inter-frame) вместо `in_waiting` — лечит причину целиком.
+
+---
+
+**📜 ПРЕЖНЯЯ ФОРМУЛИРОВКА (сохранена как история, частично опровергнута замером):**
+
 **🔴 ГДЕ ЛОМАЕТСЯ (гипотеза, требует проверки кодом):** bridge **знает** про `dining_temperature` (в логе есть `sniff:dining_temperature`), но получает **0**. При этом сырой ответ 14 байт на шине **есть**. Значит bridge **не доводит приём ответа slave 1 до конца**:
 - ответ гостиной — **14 байт** (`0x0E`), у работающих датчиков — **12 байт** (`0x0C`). Разная длина.
 - в `modbus_ha_bridge.py` приём: `buf += ser.read(ser.in_waiting or 1)` (стр. ~675) — читает «сколько успело лечь в буфер»; на длинном кадре может прочитать **часть** → CRC не сходится → ответ молча отбрасывается → значение = 0.
 - усугубляет узкий `serial.timeout: 0.05` (50 мс) в шаблоне.
+  > ❌ **`timeout` как причина — ОПРОВЕРГНУТО замером (вечер-5):** 12-байтные ответы kids/bedroom ловятся тем же чтением при том же `timeout: 0.05`. Реальная причина — сдвиг выравнивания буфера из-за байтов-сирот (см. §5-кватер-Ж).
 
 **Это особенность реализации bridge, а не железо, не конфиг, не ZONT и не маршрут.**
 
@@ -1073,7 +1094,7 @@ if raw:
 
 **Три кандидата-причины (различить только замером сырых байт):** ① узкий `serial.timeout: 0.05` (50 мс) — **но ПРОТИВ него факт: 12-байтные ответы kids/bedroom ловятся тем же чтением**, значит таймаут сам по себе не блокер; ② `in_waiting or 1` забирает куски (читает «сколько легло», а не «сколько ждём»); ③ потеря первых байт из-за `rts_de: true` (RTS-переключение направления на длинном кадре). **Не угадывать — замерять.**
 
-> 📌 **ПРАВКА ЛОГИРОВАНИЯ (Шаг 1 плана) — TO DO, ждёт ОК Alex.** Правка продакшена → нужен бэкап `modbus_ha_bridge.py` + `ha addons rebuild local_modbus-bridge` (питфолл: код/шаблон впекается в образ, без rebuild не применится, см. §4).
+> ✅ **ПРАВКА ЛОГИРОВАНИЯ (Шаг 1 плана) — ВЫПОЛНЕНА 2026-09-14 (вечер-5).** Правка сделана **в git-репозитории** `~/Automation/HA-ZONT-Modbus` (коммит `ad6345a`, запушен в Gitea), затем задеплоена на t610 (`scp` → `ha apps rebuild local_modbus-bridge` → `restart`). Сырой лог дал механизм — §5-кватер-Ж. Питфолл подтверждён: **`Dockerfile` делает `COPY modbus_ha_bridge.py`**, поэтому без `rebuild` правка кода не применится.
 
 **Что делать дальше (НЕ СДЕЛАНО):** починка приёма кадра — читать ответ **до конца кадра по межбайтовой паузе** (≥3.5 символа = Modbus RTU inter-frame), а не по `in_waiting`. Плюс проверить, почему `dining_temperature` в логе = 0, а не «нет данных» (bridge подставляет дефолт вместо пропуска).
 
@@ -1130,6 +1151,101 @@ git push -u origin main
 > ⚠️ **ПИТФОЛЛ shell (Hermes):** inline-команда вида `TOKEN=$(git remote get-url origin | sed -E 's|…|…|')` **не работает** — приём shell в Hermes спотыкается на `|` внутри `$( )`. Решение: **писать скрипт файлом** (`write_file` → `bash file.sh`). Проявилось дважды в этой сессии → сохранён `~/tmp-t610/setup_gitea_creds.sh`.
 > 📌 **Что кладём/не кладём в git (решение Alex):** `nodered-flows-*.json` — **да** (это артефакты потоков); `project_home.pdf` (3 МБ бинарь) — **нет**, в `.gitignore`.
 
+### 5-кватер-Ж. 🔬 modbus-bridge: правка логирования ВЫПОЛНЕНА + НАЙДЕНА ПРИЧИНА потери ответа гостиной (2026-09-14, вечер-5)
+
+**Контекст:** Alex — *«конечно правим»* / *«Продолжай»* на план Шага 1 (диагностическое логирование bridge). Перед этим добавил в Gitea remote — задача 3-гт (§5-кватер-Е).
+
+#### ✅ Что сделано (порядок — «сначала git, потом прод»)
+
+| # | Шаг | Факт |
+|---|---|---|
+| 1 | Синк репо с продом | `~/Automation/HA-ZONT-Modbus`: `modbus_ha_bridge.py` + `config.yml` приведены к версии t610 (различия были только в `entity_id`) — коммит **`6a8ca3f`** «Sync bridge files from t610 prod» |
+| 2 | Правка логирования | Скрипт `~/tmp-mbbridge/patch_bridge_logging.py` (питфолл: не sed, а скриптом). 3 диагностические точки, **логика не тронута**, `python3 -m py_compile` → OK |
+| 3 | Коммит + push | **`ad6345a`** «Add diagnostic raw-byte logging to modbus-bridge» → Gitea |
+| 4 | Бэкап прода | на t610 `/addons/modbus-bridge/modbus_ha_bridge.py.bak-prelogging-20260914-155143` (40 016 б) |
+| 5 | Деплой | `scp modbus_ha_bridge.py root@192.168.2.176:/addons/modbus-bridge/` (40 725 б, патч на месте) |
+| 6 | Rebuild + restart | `ha apps rebuild local_modbus-bridge` (46 с) → `ha apps restart local_modbus-bridge` → `state: started` |
+
+**3 добавленные точки логирования (диагностика, снять после фикса):**
+```python
+# 1) сырые байты из порта (перед сканером кадров)
+_raw = ser.read(ser.in_waiting or 1)
+buf += _raw
+if _raw:
+    print(f"[RAW {len(_raw)}] {_raw.hex(' ')}")
+
+# 2) нераспознанный остаток буфера (в конце цикла сканера)
+if len(buf) > 0:
+    print(f"[BUF-LEFT {len(buf)}] {bytes(buf).hex(' ')}")
+
+# 3) байты, выброшенные вокруг найденного кадра
+if i > 0:
+    print(f"[DROP-HEAD {i}] {bytes(buf[:i]).hex(' ')}")
+_tail = len(buf) - (j + 1)
+if _tail > 0:
+    print(f"[DROP-TAIL {_tail}] {bytes(buf[j+1:]).hex(' ')}")
+```
+
+#### 🔴 СЫРОЙ ЛОГ — ЧТО ПОКАЗАЛ (это и есть ответ)
+
+**А. Кадры приходят РАЗОРВАННЫМИ (склейка работает — короткие ответы проходят):**
+```log
+[RAW 1] 02                                    ← 1 байт: только адрес slave 2
+[BUF-LEFT 1] 02
+[RAW 16] 03 0c 44 9f cd c7 41 ee 89 c8 42 1a 5d 30 37 24   ← остальные 16 байт
+→ skлейка в buf → кадр собрался → Sniff: kids_co2 = 353.43 → MQTT publish [OK]
+```
+12-байтные ответы kids/bedroom **собираются и публикуются** — несмотря на разрыв.
+
+**Б. Байты-сироты КОПЯТСЯ и НЕ ЧИСТЯТСЯ (главное):**
+```log
+[RAW 5] 14 01 40 55 f8
+[BUF-LEFT 5] 14 01 40 55 f8      ← застряло НАВСЕГДА, повторяется 16+ раз подряд
+```
+```log
+[BUF-LEFT 1] 00   (×20 подряд!)
+[RAW 1] 64
+[BUF-LEFT 2] 00 64               ← мусорный 00 застрял ПЕРЕД адресом следующего кадра
+[RAW 7] 03 00 64 00 01 cc 20
+```
+Ответ slave 20 и мусорные `00` **не образуют валидный кадр по CRC** → `del` не срабатывает → байты **остаются в начале `buf`** → **сдвигают выравнивание** следующих кадров.
+
+**В. Запрос гостиной есть, ответа нет:**
+```log
+Raw RTU: 01 03 00 02 00 07 A5 C8          ← запрос гостиной (slave 1, reg 2, 7 regs)
+→ Sniff / публикации dining — НЕТ
+  → Response: 1 register(s) from 100 (sniff:dining_temperature) = 0 [00 00]   ← ложное срабатывание
+```
+
+#### 🎯 МЕХАНИЗМ БАГА (проверено фактом, а не гипотеза)
+
+1. **Кадры приходят кусками** (1 + 7, 1 + 16) — bridge склеивает их в `buf`. Для коротких ответов склейки хватает.
+2. **Нераспознанные байты-сироты не удаляются** — стр. 960–961 `if not found: i += 1` двигает `i`, **но буфер не обрезает**. Мусор накапливается в голове `buf`.
+3. **Сдвиг выравнивания убивает длинные кадры первыми.** 19-байтный ответ гостиной рвётся на больше кусков; при сдвиге на байт-сироту сканер стартует с `i=0`, где лежит `00` → `frame[0]` = `00`, а не `01` → CRC не сходится → **ответ отбрасывается молча** (стр. 687 `continue`).
+
+**🔴 Причина — НЕ `timeout`** (окончательно снято: 12-байтные ответы ловятся при том же `timeout: 0.05`). **Причина — сканер не обрезает нераспознанный префикс буфера + разрыв кадров.**
+
+**➡️ Бонус: это же объясняет «замерзание» лога на 7 ч (§1).** Застрявший мусор (`[BUF-LEFT 5] … ×16`) блокирует распознавание новых кадров → лог перестаёт писать валидные кадры, хотя аддон `started`.
+
+#### 📋 ПЛАН ФИКСА (предложен Alex'у, ждёт выбора)
+
+| Вариант | Что | Оценка |
+|---|---|---|
+| **A** | Минимальная правка буфера: в конце сканера обрезать нераспознанный префикс (`if not found and i > len(buf) - 5: del buf[:i]`) | 3 строки, низкий риск, но **гарантии по гостиной нет** (мусор мог быть симптомом) |
+| **B** | Правильное чтение по межбайтовой паузе (≥3.5 символа = Modbus RTU inter-frame) вместо `in_waiting` | лечит причину целиком, больше правок |
+| **C** | Ещё диагностика: дамп буфера в момент прихода адреса `01` | 5 мин, покажет сырую форму ответа гостиной |
+
+**Рекомендация агента:** (B) как цель, (A) как быстрый тест, (C) — если нужен ещё один факт перед правкой.
+
+**Откат диагностики:** откатить коммит `ad6345a` + `scp` бэкап `.bak-prelogging-20260914-155143` → `ha apps rebuild` → `restart`. Либо `ha apps restart` с прежним файлом из бэкапа.
+
+**Файлы:** `~/tmp-mbbridge/patch_bridge_logging.py` (патчер), `~/tmp-mbbridge/before-logging-patch.py.bak` (до правки), `~/tmp-mbbridge/modbus_ha_bridge.py` (копия с t610), на t610 `.bak-prelogging-20260914-155143`. Git: `~/Automation/HA-ZONT-Modbus` — коммиты `6a8ca3f` (sync), `ad6345a` (logging patch).
+
+> ⚠️ **Питфолл деплоя (подтверждён):** `Dockerfile` → `COPY modbus_ha_bridge.py /app/` — **код впекается в образ**. Правка файла на диске **без `ha apps rebuild`** не применится (§4). После rebuild аддон `started` за ~46 с.
+> ⚠️ **Питфолл shell (Hermes):** inline `TOKEN=$(… | sed -E 's|…|…|')` ломается на `|` внутри `$( )` — писать **скриптом файлом** (`write_file` → `bash`).
+
+---
+
 ### 5-кватер-Г. ✅ Node-RED: перенос flows с TrueNAS на t610 (2026-09-14, вечер-2)
 
 **Триггер:** Alex открыл `nodered.mallexxx.duckdns.org` → увидел basic auth вместо страницы Node-RED. В ходе разбора выяснилось, что **на t610 `flows.json` = 124 байта (пусто)** — агент при миграции **не перенёс flows Node-RED с TrueNAS**. Alex: *«в смысле чистый лист?? ты не перенёс все с truenas значит»* → команда **«переносим как есть»**.
@@ -1465,7 +1581,7 @@ curl -s -X POST -H "$HDR" -H "Content-Type: application/json" \
 | ~~1b~~ | ~~`verify` в заслонках~~ — **✅ ОПРОВЕРГНУТО:** заслонки ожили при том же `verify`. Не причина. | — |
 | ~~1c~~ | ~~ZONT-шина на других гнёздах~~ — **✅ СДЕЛАНО:** физический тест доказал (ZONT = гнездо 4, вентиляция = гнездо 3), привязки аддонов обменяны, док приведён в соответствие. Осталась только проверка «① подтвердить у Alex» — **закрыто**: он сам это и тестировал. | — |
 | ~~2~~ | ~~Раскомментировать slave 10 (AT2 fans)~~ — **СНЯТО с плана (Alex 2026-09-14): задачи по slave 10 НЕ БЫЛО.** | — |
-| 3 | **`sensor.dining_summary` / `dining_air_summary`** — **✅ ПРИЧИНА ЛОКАЛИЗОВАНА КОДОМ (2026-09-14, вечер-4; §5-кватер-Д «РАЗБОР КОДА»): ответ на шине ЕСТЬ, bridge его не публикует — баг ПРИЁМА кадра.** Сырьё: запрос `01 03 00 02 00 07` → ответ `01 03 0E 03 1A …` (19 байт: 794/14/25/11/13/256/1). Конфиг bridge содержит Dining-блок (идентичен эталону TrueNAS). **Код (`modbus_ha_bridge.py`, 987 стр.):** `buf += ser.read(ser.in_waiting or 1)` (стр. 675), сканер перебирает кадры, **битый по CRC отбрасывается молча** (`continue`, стр. 687), логируется **только валидный кадр** (стр. 692–694) → **лог слеп к багу**. Остаток буфера не чистится (стр. 960–961) → мусор копится (объясняет «замерзание» лога, §1). **3 кандидата:** ① `timeout 0.05` (против него факт: 12-байтные kids/bedroom ловятся), ② `in_waiting or 1` берёт куски, ③ `rts_de: true` теряет первые байты. **ПЛАН: Шаг 1 — правка логирования (`[RAW n] <hex>` до сканера) → rebuild → прогон; Шаг 2 — фикс чтения по межбайтовой паузе.** Ждёт ОК Alex | отдельно |
+| 3 | **`sensor.dining_summary` / `dining_air_summary`** — **🎯 ПРИЧИНА НАЙДЕНА ФАКТОМ (2026-09-14, вечер-5; §5-кватер-Ж): диагностическое логирование внедрено, сырой лог показал МЕХАНИЗМ.** Кадры приходят **разорванными** (1+7, 1+16 байт); нераспознанные байты-сироты (`00`) **накапливаются в буфере и не чистятся** (стр. 960–961 `if not found: i += 1` — `buf` не обрезается) → **сдвиг выравнивания** → 19-байтный ответ гостиной отбрасывается молча. `timeout` снят окончательно. **Правка логирования сделана** (git `~/Automation/HA-ZONT-Modbus`, коммиты `6a8ca3f` sync + `ad6345a` logging patch → Gitea; scp на t610 + `ha apps rebuild` + `restart`; бэкап `.bak-prelogging-20260914-155143`). **ОСТАЛОСЬ: выбор фикса (A/B/C, §5-кватер-Ж) — за Alex** | отдельно |
 | ~~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) | — |
@@ -1510,7 +1626,7 @@ curl -s -X POST -H "$HDR" -H "Content-Type: application/json" \
 | Шаг | Задача | Риск | Действие |
 |---|---|---|---|
 | ~~A1~~ | ~~№3: `\|default(0)`~~ — **❌ СНЯТ ОКОНЧАТЕЛЬНО** | — | Причина: данные на шине есть, bridge их теряет (§5-кватер-Д). Формула не чинится |
-| **A0** | **№3: починка приёма кадра bridge** (приоритет сессии) | 🔶 средний | **Шаг 1 — правка ЛОГИРОВАНИЯ:** добавить `[RAW n] <hex>` до сканера + лог остатка буфера (§5-кватер-Д «РАЗБОР КОДА»). Бэкап `modbus_ha_bridge.py` → правка → `ha addons rebuild local_modbus-bridge` → прогон 2–3 мин → смотреть, как приходит ответ гостиной. **Шаг 2 — фикс чтения:** читать ответ по межбайтовой паузе (≥3.5 симв.), а не по `in_waiting`. **Ждёт ОК Alex** |
+| **A0** | **№3: починка приёма кадра bridge** (приоритет сессии) | 🔶 средний | **✅ Шаг 1 (правка логирования) ВЫПОЛНЕН 2026-09-14 вечер-5:** коммиты `6a8ca3f`+`ad6345a` в `~/Automation/HA-ZONT-Modbus` → Gitea, scp на t610, `ha apps rebuild` + `restart`, бэкап `.bak-prelogging-*`. Сырой лог дал механизм (§5-кватер-Ж). **➡️ Шаг 2 (фикс) — ЖДЁТ ВЫБОРА ALEX: (A) обрезать нераспознанный префикс буфера [3 строки, быстрый тест] / (B) чтение по межбайтовой паузе ≥3.5 симв. [лечит причину] / (C) ещё диагностика перед правкой** |
 | ~~B1~~ | ~~**№5 (Этап 4): ДОЛИТЬ Caddyfile**~~ — **✅ СДЕЛАН + `trusted_proxies` фикс** | — | Alex подменил файл + `docker restart caddy`. `mallexxx.duckdns.org` → 200. Затем `.storage/http` → `trusted_proxies += 192.168.2.197/32` (§5-кватер-В) |
 | **B2** | **Node-RED наружу** — выставить порт аддона и поправить Caddy | 🔶 средний | Опции `a0d7b954_nodered`: `{ "1880/tcp": 11880 }`, `host_network` убрать → рестарт → Caddy `nodered.*` → `192.168.2.176:11880` + reload. **Сначала ответить: нужен ли пустой t610-Node-RED?** (§5-кватер-В-2) |
 | **B3** | **Этап 4, остаток:** GPON-редирект → t610, ZONT MQTT → t610 | 🔴 высокий | Трогает живое → окно + согласование |
@@ -1559,7 +1675,17 @@ docker restart caddy
 **Диагностика modbus (2026-09-14 позднейшая, второй заход):** `~/tmp-t610/` — `mb_backup.sh` (бэкап опций+конфига), `mb_fix_opts.sh` (правка опций — СЛОМАЛ mbusd), `mb_rollback.sh` (откат), `mb_dump_t610.sh`, `mb_stress.sh` (30 запросов — артефакт), `mb_master_test.sh` (`ha core stop` — повис), `mb_bus_check.sh`, `mb_bus_listen.sh`, `mb_whotraffic.sh`, `mb_bus2.sh`, `mb_bridge_check.sh`, `mb_zont.sh`, `mb_zont2.sh`, `mb_zont3.sh`, `mb_zont_now.sh`, `mb_after_zont.sh`, `mb_who.sh`.
 > 🔴 **Урок по скриптам:** сырой замер шины (`cat /dev/ttyUSB*` + `nc`) **пока HA/mbusd опрашивают ту же шину — портит замер и мешает работе**. Плюс `cat /dev/ttyUSB0` при работающем `modbus-bridge` **всегда пусто** (bridge держит порт). Единственный чистый метод привязки — **физический: выдернуть шнур + `dmesg`**.
 > ⚠️ Секреты в скриптах — только через обходных путей из §8 (маскировщик ломает литералы). Здесь секретов нет, использовался готовый `/tmp/curl.auth`.
-**Диагностика modbus (2026-09-14 вечер-4, разбор кода):** `~/tmp-mbbridge/` — `modbus_ha_bridge.py` (987 стр., 40 016 б, копия с t610) и `config.template.tmpl` (156 стр.). Копирование: `scp root@192.168.2.176:/addons/modbus-bridge/modbus_ha_bridge.py ~/tmp-mbbridge/`. **Проект-репозиторий (git):** `~/Automation/HA-ZONT-Modbus` — `modbus_ha_bridge.py` (40 009 б), `config.yml`, `INFRASTRUCTURE.md`; remote **отсутствует**, untracked `nodered-flows-{backup,updated}.json` + `project_home.pdf`.
+**Диагностика modbus (2026-09-14 вечер-4, разбор кода):** `~/tmp-mbbridge/` — `modbus_ha_bridge.py` (987 стр., 40 016 б, копия с t610) и `config.template.tmpl` (156 стр.). Копирование: `scp root@192.168.2.176:/addons/modbus-bridge/modbus_ha_bridge.py ~/tmp-mbbridge/`. **Проект-репозиторий (git):** `~/Automation/HA-ZONT-Modbus` — `modbus_ha_bridge.py`, `config.yml`, `INFRASTRUCTURE.md`; remote **отсутствует**, untracked `nodered-flows-{backup,updated}.json` + `project_home.pdf`.
+
+**Правка логирования bridge (2026-09-14 вечер-5, §5-кватер-Ж):** `~/tmp-mbbridge/` — `patch_bridge_logging.py` (**патчер, 3 диагностические точки**), `before-logging-patch.py.bak` (файл до правки), `repo-modbus_ha_bridge.py.bak` + `repo-config.yml.bak` (репо до синка с продом). **Git `~/Automation/HA-ZONT-Modbus`:** репо `git_admin/HA-ZONT-Modbus` (**private**), remote `origin` = `https://git.mallexxx.duckdns.org/git_admin/HA-ZONT-Modbus.git` (чистый, без токена), креды `~/.git-credentials` (chmod 600) + `credential.helper=store`. Коммиты сессии: `7e0b281` (sync HA-конфига + flows), `6a8ca3f` (sync bridge-файлов с прод), `ad6345a` (diagnostic logging patch). Скрипт выноса токена: `~/tmp-t610/setup_gitea_creds.sh`. На t610 бэкап прода: `/addons/modbus-bridge/modbus_ha_bridge.py.bak-prelogging-20260914-155143` (40 016 б).
+
+**Деплой правки bridge (2026-09-14 вечер-5):**
+```bash
+scp ~/Automation/HA-ZONT-Modbus/modbus_ha_bridge.py root@192.168.2.176:/addons/modbus-bridge/
+ssh root@192.168.2.176 'ha apps rebuild local_modbus-bridge && ha apps restart local_modbus-bridge'
+# ⚠️ Dockerfile: COPY modbus_ha_bridge.py /app/ → БЕЗ rebuild правка не применится
+# снятие диагностики: откатить ad6345a → scp бэкап .bak-prelogging-* → rebuild → restart
+```
 
 **Бэкапы на t610:** `/config/automations.yaml.bak-*` (последний: `.bak-20260914-131541` — перед снятием `not_from`), `/config/configuration.yaml.bak-http-*`, `/config/.storage/http.bak-*`, `/addons/modbus-bridge/*.bak-hex-*`.
 
@@ -1739,6 +1865,45 @@ docker restart caddy
 
 ---
 
+### 2026-09-14 (вечер-5: правка логирования bridge ВНЕДРЕНА + НАЙДЕНА ПРИЧИНА + Gitea-remote)
+
+**Контекст:** Алекс — *«Конечно правим»* / *«Продолжай»* — санкция на Шаг 1 плана (диагностика bridge). Перед этим: *«Добавь для этих проектов remote на gitea»*, *«Flows да, pdf — нет»*, *«Не забудь сначала закоммитить текущий код если в нем есть незакоммиченые измениния. Ты же в папке проекта это делаешь?»*
+
+**А. Gitea — задача 3-гт ✅ ЗАКРЫТА (детали §5-кватер-Е):** репо `git_admin/HA-ZONT-Modbus` создан через API (**private**), remote чистый (без токена), токен → `~/.git-credentials` (chmod 600) + `credential.helper=store`, push `7e0b281`. `.gitignore` += `project_home.pdf`.
+
+**Б. Правка логирования bridge — ✅ ВЫПОЛНЕНА (детали §5-кватер-Ж):**
+
+| Шаг | Факт |
+|---|---|
+| Синк репо↔прод | коммит `6a8ca3f` (различия были только в `entity_id`) |
+| Патч | `~/tmp-mbbridge/patch_bridge_logging.py` — 3 точки: `[RAW n]`, `[BUF-LEFT n]`, `[DROP-HEAD/TAIL n]`; `py_compile` OK |
+| Коммит+push | `ad6345a` → Gitea |
+| Бэкап прода | t610 `/addons/modbus-bridge/modbus_ha_bridge.py.bak-prelogging-20260914-155143` |
+| Деплой | `scp` → 40 725 б, патч на месте |
+| Rebuild+restart | `ha apps rebuild local_modbus-bridge` (46 с) → `restart` → `started` |
+
+**В. 🔴 РЕЗУЛЬТАТ — ПРИЧИНА НАЙДЕНА ФАКТОМ (сырой лог):**
+
+| Наблюдение в логе | Смысл |
+|---|---|
+| `[RAW 1] 64` → `[BUF-LEFT 2] 00 64` → `[RAW 7] 03 00 64 00 01 cc 20` | **кадры приходят разорванными** (1+7 байт); склейка в `buf` работает для коротких |
+| `[BUF-LEFT 5] 14 01 40 55 f8` ×16 подряд | **байты-сироты копятся и НЕ удаляются** — не образуют валидный кадр по CRC → `del` не срабатывает |
+| `[BUF-LEFT 1] 00` ×20 подряд | мусорный `00` **застревает в голове буфера навсегда** |
+| запрос `01 03 00 02 00 07` есть, `Sniff: dining*` — нет | **ответ гостиной отбрасывается** из-за сдвига выравнивания |
+
+**🔴 МЕХАНИЗМ:** нераспознанные байты не чистятся (стр. 960–961) → **сдвиг выравнивания** → длинный (19 байт) ответ гостиной сканер начинает с мусорного `00` вместо `01` → CRC не сходится → отброс молча (стр. 687). **`timeout` как причина снят окончательно** (12-байтные ответы ловятся при том же `timeout: 0.05`). **Бонус: это же объясняет «замерзание» лога на 7 ч** — застрявший мусор блокирует распознавание новых кадров при `state: started`.
+
+**План фикса предложен Alex'у (выбор — за ним):** (A) обрезать нераспознанный префикс буфера [3 строки, быстрый тест]; (B) чтение по межбайтовой паузе ≥3.5 симв. [лечит причину]; (C) ещё диагностика.
+
+**Что менялось в железе:** правка кода `modbus_ha_bridge.py` на t610 + rebuild + restart аддона. **Функционального фикса пока НЕТ** — только диагностика (логика распознавания не тронута).
+
+**Не сделано (ждёт решения Alex):** сам фикс приёма кадра (Шаг 2, варианты A/B/C).
+
+> 📌 **Процессный урок (положительный):** на требование Alex «не забудь закоммитить, ты же в папке проекта?» — сначала **проверить фактом** (git-статус, remote, расхождение с продом), и только потом коммитить. Выяснилось, что `/addons/modbus-bridge/` — **не репо**, а проект-репо `~/Automation/HA-ZONT-Modbus` с **несозданным remote**. Правку делали **в репо →коммит→ деплой**, а не наоборот.
+> ⚠️ **Питфолл shell (Hermes), проявился дважды:** `TOKEN=$(... | sed -E 's|…|…|')` в inline-команде **ломается** на `|` внутри `$( )` → писать **скрипт файлом** (`write_file` → `bash file.sh`).
+
+---
+
 ### 2026-09-14 (вечер-4: разбор кода bridge + подготовка Gitea remote)
 
 **Контекст:** Alex спросил «что делаем дальше по плану» → обсудили варианты (A1/A2/A3 vs Этап 4) → Alex потребовал разобраться с датчиком гостиной: *«то есть как я понял ты нихуя не нашел?»*, *«то есть таймаут надо поднимать?»*, *«логирование правильно сделано? оно позволит идентифицировать проблему?»*. Затем: «Да. Не забудь сначала закоммитить текущий код если в нем есть незакоммиченые измениния. Ты же в папке проекта это делаешь?» → «Добавь для этих проектов remote на gitea».