diff --git a/family/documents/home-automation-wishlist.md b/family/documents/home-automation-wishlist.md index 4b0db096..d8cc6975 100644 --- a/family/documents/home-automation-wishlist.md +++ b/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 на месте. Опционально — импульсный датчик на счётчик. diff --git a/family/how-to/home-automation.md b/family/how-to/home-automation.md index 42a06706..ccb9accb 100644 --- a/family/how-to/home-automation.md +++ b/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/" +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//options" +# проверка: GET /addons//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//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_` — предыдущий рестарт ещё идёт, **подождать**, не долбить повторно. + **Диагностика при «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//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//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 ` работает) | -| 25 | После чистого старта **три аддона не поднимаются сами**: `zigbee2mqtt`, `nodered`, `core_configurator` | Проверять скан статусов после каждого ребута, поднимать руками | +| 25 | После чистого старта **три аддона не поднимаются сами**: `zigbee2mqtt`, `nodered`, `core_configurator` | Причина — **`watchdog: false` у всех аддонов** (§3.7). Включить watchdog через `POST /addons//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_` | Предыдущий рестарт ещё идёт — подождать, не долбить повторно | +| 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 есть) или собирать заголовок по частям.