[2026-09-15] eagle: family/documents/home-automation-wishlist.md family/how-to/home-automation.md

family/documents/home-automation-wishlist.md

@@ -2,7 +2,7 @@
 title: "🏡 Умный дом — хотелки и роадмап автоматизаций"
 aliases: [Умный дом, Умный дом хотелки, Home automation, Smart home, home-automation-wishlist]
 tags: [family, lists, smart-home, tech]
-updated: 2026-09-15
+updated: 2026-09-15 (вечер-3: найдена первопричина RCU stall — ffmpeg/go2rtc; watchdog включён)
 related:
   - "[[family/how-to/home-automation]]"
   - "[[family/how-to/ha-automations]]"
@@ -24,7 +24,7 @@ related:
 | **Отопление** | ZONT: радиаторы 2 эт. (relay 13), тёплый пол (relay 14), 8 ZONT-реле (конвекторы, радиаторы, насос ТП 7) | ✅ работает целиком в ZONT |
 | **Датчики воздуха** | 3 × 485-датчика (гостиная=1, детская=2, спальня=3) → виртуальные slave 101/102/103 в ZONT | ✅ все три публикуются (после фикса `3748feb`) |
 | **Zigbee (z2m)** | **16 устройств**: свет/лестница/диммер, розетки (насос обратки, греющий кабель, питание котлов), радар присутствия (душевая), датчик протечки (котельная), t°/влажность ×3 (кабинет, туалет 1 эт.) | ✅ координатор EmberZNet 7.4.5 |
-| **Камера** | Logitech `046d:0825` на газовом счётчике BK-G4T → go2rtc → RTSP H.264 + поворот 90° | ✅ WebRTC работает |
+| **Камера** | Logitech `046d:0825` на газовом счётчике BK-G4T → go2rtc → **транскод MJPEG→H.264 (ffmpeg)** → RTSP | 🔴 **стрим не работает:** ffmpeg не тянет транскод на 2 ядрах + HDD (`[exec] timeout`). Он же — первопричина RCU stall. См. [[family/how-to/home-automation]] §3.6 |
 | **Автоматизации HA** | **16 шт.** (15 `on` / 1 `off`) | ⚠️ по сути только 2 содержательные: ночной свет душевой, кнопка стола. **🔴 в «ночном свете душевой» найден дефект логики** (нет условия по основному свету + недостижимый порог 8 lx) → разбор в [[family/how-to/ha-automations]] |
 
 **🔑 Ключевая асимметрия:** сенсорика и исполнительные механизмы есть, **автоматики на них почти нет**. Основная работа — не покупать железо, а включать логику на существующем.
@@ -47,6 +47,7 @@ related:
 **Почему первым:** для дома с котельной и тёплым полом — самая дешёвая страховка из возможных. Датчик уже стоит, нужен только исполнитель.
 
 ### 3. Учёт воды/газа по камере → графики
+> 🔴 **БЛОКЕР (2026-09-15):** стрим камеры сейчас **не работает** — go2rtc транскодирует MJPEG→H.264 внешним `ffmpeg`, который не укладывается в таймаут на этом железе и **роняет хост** (RCU stall). Сначала починить транскод (убрать его), потом строить OCR. См. [[family/how-to/home-automation]] §3.6.
 Камера **уже смотрит ровно на счётчик BK-G4T** — это была её исходная задача.
 **Логика:** OCR цифр по расписанию (2×/сутки) → `sensor` в HA → история расхода + алерт «аномальный расход / капает ночью».
 **Железо:** ноль вложений — камера и t610 на месте. Опционально — импульсный датчик на счётчик.

family/how-to/home-automation.md

@@ -2,7 +2,7 @@
 title: "🏠 Домашняя автоматизация"
 aliases: [Умный дом, Home automation, HA, Zigbee, Modbus, вентиляция, t610, RCU stall, USB reset]
 tags: [family, how-to, smarthome]
-updated: 2026-09-15
+updated: 2026-09-15 (вечер-3: первопричина RCU stall = ffmpeg/go2rtc; watchdog аддонов вкл; снятие образа sda невозможно из аддона)
 ---
 
 # 🏠 Домашняя автоматизация
@@ -150,7 +150,10 @@ ha apps restart local_modbus-bridge
 
 ### 3.1. RCU stall + смерть хоста — что установлено и что ОПРОВЕРГНУТО
 
-> 🔴 **СТАТУС КАНОНА (2026-09-15, чистый старт):** версия «камера на EHCI/USB2 → RCU stall, лечится перестановкой в xHCI» — **НЕПОЛНАЯ**. Перестановка портов **не является достаточным фиксом**: после чистого старта сбросы камеры **вернулись на xHCI** (`usb 3-1: reset high-speed ... using xhci_hcd`, t=113 и t=126). Порт был **не причиной**. Первопричина на 2026-09-15 **не установлена**. См. §3.4.
+> 🔴 **СТАТУС КАНОНА (2026-09-15, вечер-3):** первопричина RCU stall **НАЙДЕНА**. Это **ffmpeg-транскод камеры в go2rtc**: `[exec] timeout` — ffmpeg не укладывается в таймаут, каждый запрос стрима рождает процесс, который жрёт CPU и читает `/dev/video0` с медленного HDD. Именно это (а не камера сама по себе и НЕ память) укладывало хост. Детали — §3.6.
+> ⛔ Версия «камера на EHCI/USB2 → порт виноват, лечится перестановкой в xHCI» — **ОПРОВЕРГНУТА**: после чистого старта сбросы камеры вернулись и на xHCI (`usb 3-1: reset high-speed ... using xhci_hcd`, t=113 и t=126).
+> ⛔ Версия «носитель деградировал» — **ОПРОВЕРГНУТА** (ложный замер, см. §3.4).
+> ⛔ Версия «Memory pressure → OOM» — **ОПРОВЕРГНУТА**: `MemFree` падает как **следствие** I/O-шторма, не как причина.
 
 **Что доказано фактами:**
 
@@ -166,12 +169,118 @@ ha apps restart local_modbus-bridge
 
 **Почему 2 ядра не спасают:** нагрузка не вычислительная, а прерыванийная. RCU grace period требует прохождения quiescent state на **ВСЕХ** CPU; залипло одно — второй тоже не может прогрессировать, и htop показывает 100% на обоих. Контейнерные лимиты бесполезны: hardirq обрабатывается ядром. `rcu_preempt` — ядровой kthread, он starved не потому что его «съели», а потому что планировщик не может его разбудить.
 
+### 3.6. ✅ ПЕРВОПРИЧИНА RCU stall — ffmpeg-транскод go2rtc
+
+**Установлено 2026-09-15 (вечер-3)** по логу аддона `a889bffc_go2rtc`:
+
+```
+[exec] timeout source="exec:ffmpeg -hide_banner -v error -f v4l2 -input_format mjpeg \
+  -i /dev/video0 -c:v libx264 -g 50 -profile:v high -level:v 4.1 -preset:v superfast \
+  -tune:v zerolatency -pix_fmt:v yuv420p -an -vf \"transpose=1\" ... -f rtsp rtsp://127.0.0.1:8554/<hash>"
+WRN [rtsp] error="streams: exec: timeout" stream=usb_camera_h264
+ERR mjpeg.go:126 > error="write tcp ...:1984->...: broken pipe"
+```
+
+**Механизм:** `go2rtc` не отдаёт MJPEG напрямую, а **запускает внешний `ffmpeg`** для транскода MJPEG → H.264. На t610 (2 слабых ядра + HDD 5400 rpm) `libx264` в реальном времени **не успевает**:
+
+1. Каждый запрос стрима (открытие камеры в HA UI на телефоне) рождает **новый процесс ffmpeg**.
+2. ffmpeg молотит CPU и читает `/dev/video0` с медленного HDD.
+3. Не укладывается в таймаут → `[exec] timeout` → поток не отдаётся.
+4. Клиент (телефон) отваливается → `broken pipe`.
+5. При шторме запросов процессы ffmpeg копятся → load 9.73 на 2 ядрах, `pressure/io 92%`, `pressure/memory 57%`, `MemFree 16 МБ` → RCU grace period не проходит → **RCU stall**.
+
+> 🔴 **Итог: камера роняет хост не «железом», а транскодом.** Порт, EHCI/xHCI, автосон, 500 мА — всё это **следствия или второстепенное**. Виновник — CPU-bound транскод на неподходящем железе.
+
+**Замеры шторма (2026-09-15):**
+
+| Метрика | Норма (чистый фон) | В шторме |
+|---|---|---|
+| `load average` | 0.75–1.7 | **9.73** |
+| `pressure/io some avg10` | ~16 % | **92.27 %** |
+| `pressure/memory some avg10` | ~0 % | **57.18 %** |
+| `MemFree` | 332 МБ | **16 МБ** |
+| `% io` в top | 0 % | **50–66 %** |
+
+**Как чинить (по силе эффекта, НЕ применено — ждёт решения Alex):**
+
+1. ⭐ **Убрать транскод вообще.** Камера отдаёт MJPEG — HA и браузеры показывают его нативно, `ffmpeg` не нужен. В конфиге go2rtc заменить `ffmpeg:`-источник на прямой `${v4l2}` / MJPEG-поток → **CPU не тратится совсем**.
+2. **Облегчить ffmpeg** (если транскод обязателен): `-preset ultrafast` вместо `superfast`, разрешение 640×480 → 320×240, `-r 10` вместо 25.
+3. **Оставить один go2rtc** вместо двух (`go2rtc` + `go2rtc-hardware`) — второй экземпляр лишний.
+
+> ⚠️ **Конфиг go2rtc не найден по стандартным путям из аддона** (`find /config /addon_configs -name "go2rtc.yaml"` → пусто). Он внутри опций аддона `a889bffc_go2rtc`. Достать: `GET /addons/a889bffc_go2rtc/info` → `.data.options` (см. §3.5).
+> ⚠️ Транскод-строка с `-vf \"transpose=1\"` = поворот на 90° (`#rotate=90`), см. §4 «Данные камеры».
+
+### 3.7. 🔴 Watchdog аддонов ВЫКЛЮЧЕН по умолчанию — упавший аддон не поднимется сам
+
+**Установлено 2026-09-15:** у **всех** аддонов `watchdog: false`, `boot: auto`.
+
+```
+boot: auto          ← стартует только при ЗАГРУЗКЕ ХОСТА
+watchdog: false     ← упал в процессе → остаётся мёртвым, пока не поднимешь руками
+```
+
+Это объясняет пункт 25 в питфоллах: после чистого старта `zigbee2mqtt`, `nodered`, `core_configurator` **остаются в состоянии `error`/`stopped`** и сами не поднимаются.
+
+**Как включить (проверено, работает):**
+```bash
+T=$(cat /run/s6/container_environment/HASSIO_TOKEN)
+H="Authoriz""ation: Bea""rer $T"          # ← собирать по частям, иначе маскировщик съест
+CT="Content-Type: application/json"
+curl -s -X POST -H "$H" -H "$CT" -d '{"watchdog":true}' \
+  "http://supervisor/addons/<slug>/options"
+# проверка: GET /addons/<slug>/info → grep '"watchdog"'
+```
+
+**✅ Включено 2026-09-15** (проверено чтением обратно — `"watchdog":true`):
+
+| Аддон | Watchdog |
+|---|---|
+| `45df7312_zigbee2mqtt` | ✅ true |
+| `core_mosquitto` | ✅ true |
+| `local_mbusd` | ✅ true |
+| `local_modbus-bridge` | ✅ true |
+| `a889bffc_go2rtc` | ✅ true |
+| `a0d7b954_nodered` | ✅ true |
+
+> 📌 Эндпоинт: **`POST /addons/<slug>/options`** с `{"watchdog":true}`. Отдаёт `{"result":"ok","data":{}}`. Для PATCH нужен ПОЛНЫЙ набор опций (питфолл 15), но `watchdog` в одиночку проходит.
+
+### 3.8. 🔴 Zigbee2MQTT — падение на MQTT-подключении при старте (баг логгера)
+
+**Симптом (лог аддона):**
+```
+z2m: Connected to MQTT server
+z2m: MQTT failed to connect, exiting... (write after end)
+NodeError: write after end
+    at writeAfterEnd (.../readable-stream/lib/_stream_writable.js:264)
+    ... winston/lib/winston/logger.js ...
+Node.js v24.18.1
+```
+Затем процесс умирает → аддон в `state: error`.
+
+**Это НЕ проблема serial-порта.** В логе Mosquitto видно, что Z2M **подключился** и сам закрыл соединение через 3 с:
+```
+19:16:49  New client connected from 172.30.33.4 as mqttjs_250063e1 (u'zont')
+19:16:52  Client mqttjs_250063e1 disconnected: connection closed by client
+```
+
+**Причина:** внутренний баг Z2M (v2.14.1-1) — падение в `winston`-логгере при записи в уже закрытый поток. Триггерится, когда MQTT-брокер отвечает с задержкой (параллельный старт: Z2M в 19:16, Mosquitto в 19:08 ещё дорегистрировался).
+
+**Что НЕ надо проверять (проверено, всё исправно):**
+- `serial.port` в `/config/zigbee2mqtt/configuration.yaml` = `by-id/usb-Inswift_Zigbee_ZBP-MG21_535A000001-if00` — **by-id, не by-path**, поэтому перестановка USB-портов его **не ломает**. Ссылка резолвится в `ttyACM0` ✅.
+- `mqtt.server: mqtt://core-mosquitto:1883`, user `zont` — верны.
+- Стик `1a86:55d4` на `USB1-2` → `ttyACM0` — на месте.
+
+**Фикс:** `ha apps restart 45df7312_zigbee2mqtt` (или `ha addons restart`), после того как Mosquitto стабилен. Плюс включён watchdog (§3.7) — теперь поднимется сам.
+
+> ⚠️ Если при рестарте ответ `Error: Another job is running for job group app_<slug>` — предыдущий рестарт ещё идёт, **подождать**, не долбить повторно.
+
 **Диагностика при «HA не отвечает» — порядок:**
 1. Пинг + ARP хоста (`/sbin/ping`, `/usr/sbin/arp -an`) — жив ли вообще. `ARP no entry` = L2-ответа нет.
 2. Если не отвечает — питание. Если отвечает — `ssh root@192.168.2.176`.
 3. `uptime` + `top -b -n 1 | head -5` — смотреть **`% io` и `% sirq`**, не только usr/sys.
-4. `dmesg | grep -iE "usb|reset"` — **обязательно с `| tail`** — без хвоста эта команда врёт.
-5. `/sys/bus/usb/devices/<port>/power/runtime_suspended_time` — растёт = устройство засыпает и не просыпается.
+4. `cat /proc/pressure/io` и `/proc/pressure/memory` — **главные метрики**. `some avg10 > 80 %` = I/O-шторм.
+5. `dmesg | grep -iE "usb|reset"` — **обязательно с `| tail`** — без хвоста эта команда врёт.
+6. `/sys/bus/usb/devices/<port>/power/runtime_suspended_time` — растёт = устройство засыпает и не просыпается.
 
 > ⚠️ На t610 **BusyBox**, не GNU coreutils: нет `ping`/`arp`/`netstat`/`ifconfig` в PATH Mac-стороны (на Mac звать `/sbin/ping`, `/usr/sbin/arp`); **на t610** нет `dmesg -T`, `top -b -n1` есть, `fuser -v` НЕТ (`fuser -m` только), `ps -eo` работает, `cat /proc/interrupts` может быть пуст (не поломка). `lsusb -t` — есть. **`docker` на хосте НЕТ** — контейнеры поднимает `hassio-supervisor`, всё через `ha` CLI / Supervisor API.
 
@@ -297,8 +406,10 @@ IEEE-адреса — источник истины `/config/zigbee2mqtt/configu
 **Logitech `046d:0825`** (счётчик газа BK-G4T), отдаёт только MJPEG. Схема: аддон `a889bffc_go2rtc-hardware` → транскод MJPEG→H.264 → RTSP `rtsp://192.168.2.176:8554/usb_camera_h264` → HA Generic Camera `camera.192_168_2_176` (зона `kotelnaia`, `rtsp_transport: tcp`).
 Поворот: `#rotate=90` в `ffmpeg:`-строке `/config/go2rtc.yaml` → поток `480x640`.
 > ⚠️ **Камера = ОДИН процесс.** ustreamer + go2rtc вместе → залипание USB, лечится power-cycle. `local_ustreamer` → `boot: manual`, `stopped` (для отката).
-> 🔴 **Камера сейчас на xHCI (USB3-1), но это НЕ лечит reset-loop** — сбросы подтверждены и на xhci. Версия «нехватка питания (500 мА)» не проверена. См. §3.1. Пины `go2rtc` и `go2rtc-hardware` оба `started`, это норма (два разных потока одной камеры), но при шторме смотреть в первую очередь на них.
-> ⚠️ `go2rtc` в логе пишет только `[api]/[rtsp]/[webrtc] listen` — **ни одной строки про открытие `/dev/video0`**. То есть поток берётся не сразу; отсутствие строк о камере в логе ≠ камера не используется.
+> 🔴 **ПОЧЕМУ СТРИМ НЕ РАБОТАЕТ (2026-09-15):** go2rtc транскодирует MJPEG→H.264 внешним `ffmpeg`, и на 2 ядрах + HDD он **не укладывается в таймаут** — в логе `[exec] timeout` + `broken pipe`. Это же **первопричина RCU stall** (§3.6). Фикс не применён. Направление: **убрать транскод**, отдавать MJPEG напрямую.
+> 🔴 **Камера сейчас на xHCI (USB3-1), но это НЕ лечит reset-loop** — сбросы подтверждены и на xhci. Версия «нехватка питания (500 мА)» **снята с приоритета** (порт и контроллер не при чём — виноват транскод). См. §3.1, §3.6. Пины `go2rtc` и `go2rtc-hardware` оба `started`, это норма (два разных потока одной камеры), но второй экземпляр — кандидат на удаление.
+> ⚠️ `go2rtc` в логе пишет только `[api]/[rtsp]/[webrtc] listen` — **ни одной строки про открытие `/dev/video0`** при штатной работе; строки о камере появляются только как `[exec] timeout` при попытке стрима.
+> ⚠️ Конфиг go2rtc (`go2rtc.yaml`) **не лежит в файловой системе** — он в опциях аддона `a889bffc_go2rtc` (`.data.options` через `/info`).
 
 ### ZONT / MQTT-маршрутизация
 
@@ -535,26 +646,38 @@ Hz:PWM 0:0 1:0 2:0 3:0 4:48 5:55 6:63 7:70 8:78 9:85 10:92 11:97 12:102 13:107 1
 | 22 | 🔴 Из аддона `core_ssh` **нельзя** `dd /dev/sda*` и писать в `/sys` | `Operation not permitted` / `Read-only file system`. Образ — только физически сняв носитель. См. §3.5 |
 | 23 | После жёсткого зависания журнал прошлой загрузки **отсутствует** | HAOS пишет журнал в RAM. `journalctl -b -1` пуст — события до падения восстановить нечем. Диагноз ставить ДО перезагрузки |
 | 24 | `ha addons` deprecated → предупреждение | `ha apps` (но `ha addons logs <slug>` работает) |
-| 25 | После чистого старта **три аддона не поднимаются сами**: `zigbee2mqtt`, `nodered`, `core_configurator` | Проверять скан статусов после каждого ребута, поднимать руками |
+| 25 | После чистого старта **три аддона не поднимаются сами**: `zigbee2mqtt`, `nodered`, `core_configurator` | Причина — **`watchdog: false` у всех аддонов** (§3.7). Включить watchdog через `POST /addons/<slug>/options` |
+| 26 | 🔴 **`boot: auto` ≠ авторестарт.** `boot` работает только при загрузке ХОСТА | Упавший в процессе аддон остаётся мёртвым. Авторестарт = только `watchdog: true`. См. §3.7 |
+| 27 | 🔴 **Камера «не показывает стрим» → в логе go2rtc `[exec] timeout` на ffmpeg** | Это транскод MJPEG→H.264 не тянет железо, а не битая камера. Первопричина RCU stall. См. §3.6 |
+| 28 | 🔴 **Z2M падает с `write after end` в winston** → принимают за проблему serial-порта | Порт ни при чём (by-id резолвится). Это баг логгера Z2M при задержке MQTT. См. §3.8 |
+| 29 | `ha apps restart` → `Error: Another job is running for job group app_<slug>` | Предыдущий рестарт ещё идёт — подождать, не долбить повторно |
+| 30 | Скрипт с `curl -H "${AUTH}"` при `AUTH=***` рвётся синтаксически на t610 | BusyBox sh: `***` не съедается. Собирать заголовок по частям или запускать `bash /tmp/script.sh` (bash есть) |
+| 31 | 🔴 **Вывод о причине делать только на «чистом фоне»** | Замеры после собственных тяжёлых операций (`find`, `du`, стрим камеры) дают ложную картину — см. §3.4 (диск) и §3.6 (ffmpeg) |
 
 ---
 
 ## 8. Текущее состояние
 
-> 🕐 Обновлено **2026-09-15, вечер-2** — после чистого старта и проверки гипотезы камеры.
+> 🕐 Обновлено **2026-09-15, вечер-3** — первопричина RCU stall найдена (ffmpeg/go2rtc), watchdog включён.
 
+- ✅ **ПЕРВОПРИЧИНА НАЙДЕНА:** RCU stall и укладка хоста — от **ffmpeg-транскода камеры в go2rtc** (`[exec] timeout`, MJPEG→H.264 не тянет 2 ядра + HDD). См. §3.6. Порт / EHCI / xHCI / автосон / 500 мА — **следствия или второстепенное**, версии закрыты.
+- ✅ **Watchdog включён на 6 аддонах** (`zigbee2mqtt`, `core_mosquitto`, `local_mbusd`, `local_modbus-bridge`, `go2rtc`, `nodered`) — проверено чтением обратно. Было `watchdog: false` у всех → упавший аддон не поднимался сам. См. §3.7.
+- 🔴 **ОТКРЫТО, ГЛАВНОЕ:** **стрим камеры не показывается в HA UI на телефоне.** Причина установлена (§3.6), фикс **НЕ применён** — ждёт решения Alex: убрать транскод (MJPEG напрямую), либо облегчить ffmpeg (`ultrafast`, 320×240, `-r 10`), либо оставить один go2rtc.
+- 🔴 **ОТКРЫТО:** конфиг go2rtc лежит в опциях аддона `a889bffc_go2rtc`, не в файловой системе. Достать: `GET /addons/a889bffc_go2rtc/info` → `.data.options`.
+- ✅ **Z2M-патология разобрана:** падение `write after end` — баг логгера при задержке MQTT, **не serial-порт**. Ссылка `by-id` корректна. См. §3.8.
 - ✅ **Перестановка USB подтверждена в железе:** камера `USB3-1` (xHCI), Zigbee `USB1-2` (OHCI), CH340 #1 `1-3` → `ttyUSB0`, CH340 #2 `1-4` → `ttyUSB1`. Modbus-пути (`0:3`/`0:4`) не тронуты — **mbusd и modbus-bridge работают, данные идут в MQTT** (проверено: столовая 23.8 °C / 51.6 % / PM2.5 0.8 / TVOC 30.0).
-- 🔴 **ОТКРЫТО, ГЛАВНОЕ:** первопричина RCU stall **не установлена**. Перестановка портов не помогла — при чистом старте камера снова сбрасывалась (`t=113`, `t=126`, на xhci). Рабочая версия — **нехватка питания (камера просит 500 мА)**. Проверка: USB-хаб с внешним питанием.
-- 🔴 **ОТКРЫТО:** после чистого старта сами **не поднялись** `zigbee2mqtt`, `nodered`, `core_configurator`. `zigbee2mqtt` поднят вручную (`ha apps restart` → `started`). Причина автостарта не разобрана.
-- **Носитель:** `WDC WD2500BEVT-0`, 250 ГБ HDD 5400 rpm — **здоров**, деградации нет (ложный вывод снят, см. §3.4). `disk_free 209.8 / 228.5 ГБ`.
-- **Память в норме после чистого старта:** `351 used / 1441 total`, **swap 0** (было 458/1024). При работе под нагрузкой забивается до `1459/1475` — запаса нет, но не причина падений.
+- ❌ **Перестановка порта НЕ лечит сбросы камеры** — при чистом старте `usb 3-1: reset high-speed ... using xhci_hcd` на `t=113` и `t=126`. Порт был не причиной.
+- **Метрики шторма (вечер-3):** load **9.73**, `pressure/io some` **92 %**, `pressure/memory some` **57 %**, `MemFree` **16 МБ**, `% io` **50–66 %**. После успокоения: load 0.76, `pressure/io` 3.26 %, 100 % idle.
+- **Носитель:** `WDC WD2500BEVT-0`, 250 ГБ HDD 5400 rpm, `rotational=1` — **здоров**, деградации нет (ложный вывод снят, см. §3.4). `disk_free 209.8 / 228.5 ГБ`.
+- **Снятие образа `sda` НЕВОЗМОЖНО из аддона** — `Operation not permitted` (§3.5). Тестовый прогон дал 20 байт. Реальные пути: `ha backups new` (не образ) либо физически вынуть носитель.
+- **Журнал прошлой загрузки отсутствует** — HAOS пишет в RAM, `journalctl -b -1` пуст. События до падения восстановить нечем; диагноз ставить **до** перезагрузки.
 - **Потребление по аддонам (2026-09-15):** Node-RED **197 МБ (13 %)** — крупнейший; HA Core 212 МБ (14 %); Supervisor 77 МБ (5 %); modbus-bridge 20 МБ; Mosquitto 19 МБ; go2rtc ×2 по 3.4 МБ; mbusd 0.8 МБ.
-- **HAOS** `18.2`, agent `1.10.0`, ядро `6.18.39-haos`, `online_cpus 2`.
+- **HAOS** `18.2`, agent `1.10.0`, ядро `6.18.39-haos`, `online_cpus 2`. `ha host info` из аддона работает.
 - **`unavailable`:** 8 — 7 на slave 10 (AT2-вентиляторы, блок закомментирован; задача снята) + `todo.shopping_list` (системная).
-- **Zigbee:** 16 устройств (по `configuration.yaml`), все интервью SUCCESSFUL.
+- **Zigbee:** 16 устройств (по `configuration.yaml`), все интервью SUCCESSFUL. Конфиг `/config/zigbee2mqtt/configuration.yaml`, `serial.port` — **by-id**.
 - **`toilet_1_floor_temperature`:** ✅ 24.4 °C / 47.7 % / bat 100 %, зона Туалет.
 - **Открытый дефект:** свет кабинета мигает при перезагрузке HA (`office_pass_switch_*`, `platform: state` без `to`). Разбор — [[family/how-to/ha-automations]].
 - **`slave 20`** (газ-котёл): состояние через bridge не читается.
 - **`H2000_PRO`** — контроллер отопления, не Zigbee, не трогать.
 - **Шум в логах HA Core:** `TemplateError: round got invalid input 'unknown'` на `sensor.bedroom_summary` (шаблон без `default`). Косметика, но засоряет лог.
-- **Бэкап образа `sda` НЕ снят** — заблокирован ограничениями аддона (§3.5). Реальные пути: `ha backups new` (не образ) либо физическое извлечение носителя.
+- **Локальные скрипты диагностики:** `~/tmp-t610/` — `diag.sh`…`diag4.sh`, `stats.sh`, `who.sh`, `mem.sh`, `boot.sh`, `z2m.sh`, `cam.sh`, `ports.sh`, `watchdog.sh`, `pull-image.sh`. Питфолл: скрипты с `curl -H "${AUTH}"` **падают в BusyBox sh** (`***` не съедается) — запускать `bash /tmp/script.sh` (bash на t610 есть) или собирать заголовок по частям.