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

family/plans/t610-home-automation.md

@@ -43,7 +43,7 @@
 
 | Что | Состояние |
 |---|---|
-| **10 сущностей `unavailable`** (было 44) | **✅ ОСНОВНОЕ РЕШЕНО 2026-09-14 (финал): аддоны стояли на перепутанных гнёздах — поменяны местами → ушли ВСЕ 32 заслонки** (см. §5 «✅✅ РЕШЕНИЕ»). Рабочая привязка: `mbusd` = гнездо 3 (вентиляция), `modbus-bridge` = гнездо 4 (**ZONT 485**). **Остались 10** (не наши задачи, отдельные известные вещи — см. §9): `switch.fan_3_high/medium/low` + `sensor.fan_at2_*` (slave 10 закомментирован в `configuration.yaml`) + `sensor.dining_summary`/`dining_air_summary` (нужен `\|default(0)`) + `todo.shopping_list` (системная) |
+| **10 сущностей `unavailable`** (было 44) | **✅ ОСНОВНОЕ РЕШЕНО 2026-09-14 (финал): аддоны стояли на перепутанных гнёздах — поменяны местами → ушли ВСЕ 32 заслонки** (см. §5 «✅✅ РЕШЕНИЕ»). Рабочая привязка: `mbusd` = гнездо 3 (вентиляция), `modbus-bridge` = гнездо 4 (**ZONT 485**). **Остались 10:** 7 — `switch.fan_3_high/medium/low` + `sensor.fan_at2_*` (slave 10 закомментирован в `configuration.yaml`, задача СНЯТА Alex'ом — не поломка); **2 — `sensor.dining_summary`/`dining_air_summary` (причина НЕ `\|default(0)`, а отсутствие MQTT-данных `modbus/sensors/dining/*` — см. §5-тер)**; 1 — `todo.shopping_list` (системная) |
 | ~~`verify` как причина~~ | **ОПРОВЕРГНУТО как причина:** при верной привязке шин заслонки ожили при том же `verify` (`state_on:1`/`state_off:0`). Причина была в перепутанных шинах, не в `verify` |
 | **`sensor.fan_at2_*` / `switch.fan_3_*` — сироты** | В `configuration.yaml` **весь блок slave 10 (AT2 fans) закомментирован** → эти сущности физически не могут получать данные. Не задача — просто известный факт состояния конфига |
 | `switch.sauna` = `unknown` | Розетка физически отключена (`lastSeen` 8+ ч) — не баг |
@@ -549,7 +549,7 @@ Raw RTU: 14 01 00 00 00 01 FF 0F
 |---|---|
 | `switch.fan_3_high/medium/low` | slave 10 — блок закомментирован в `configuration.yaml` (факт состояния, не задача) |
 | `sensor.fan_at2_1_pwm_raw` / `fan_at2_2_pwm_raw` / `fan_at2_1_run_raw` / `fan_at2_2_run_raw` | то же, slave 10 |
-| `sensor.dining_summary` / `sensor.dining_air_summary` | template-сенсоры, нужен `\|default(0)` (косметика, задача №3) |
+| `sensor.dining_summary` / `sensor.dining_air_summary` | **❌ причина НЕ в `\|default(0)`** (опровергнуто 2026-09-14 15:39, см. §5-тер): ZONT **не публикует** `modbus/sensors/dining/*` — 8 датчиков столовой пусты. Открытый вопрос к Alex: датчик есть физически? |
 | `todo.shopping_list` | системная, не наша |
 
 **Как делался обмен (рецепт):**
@@ -587,6 +587,84 @@ ch341 1-4 → ttyUSB1   (гнездо 4 = вентиляция)  ← ОШИБК
 
 ---
 
+## 5-тер. 🔬 Датчики столовой: `dining_summary` `unavailable` — причина НЕ в формуле (2026-09-14 15:39)
+
+**Сессия диагностики, только чтение. Задача от Alex: «почему что-то недоступно, что ты собрался менять».**
+
+### ❌ ПРЕЖНЯЯ (опровергнутая) формулировка
+
+Док в §9 задача 3 говорил: «`sensor.*_summary` — добавить `\|default(0)` в template-сенсоры (косметика, самоизлечится)». **Это НЕВЕРНО в двух местах:**
+1. **Не «все `*_summary`»** — `kids_summary` и `bedroom_summary` **работают** (`25° 384ppm` / `25° 411ppm`). Ломаются только 2: `dining_summary`, `dining_air_summary`.
+2. **Не «нет `default`»** — это следствие, а не причина. Причина — **нет самих данных**.
+
+### ✅ ФАКТ (проверено живьём)
+
+**Шаг 1 — состояния датчиков (`/api/states`):**
+
+| Сущность | Состояние |
+|---|---|
+| `sensor.dining_temperature_2` | `unknown` |
+| `sensor.dining_co2` | `unknown` |
+| `sensor.dining_tvoc` | `unknown` |
+| `sensor.dining_pm10` | `unknown` |
+| `sensor.dining_humidity` / `_pm2_5` / `_formaldehyde` | `unknown` |
+| `sensor.kids_temperature` / `kids_co2` | `25.2` / `384.8` → `kids_summary` = `25° 384ppm` ✅ |
+| `sensor.bedroom_temperature` / `bedroom_co2` | `25.07` / `411.4` → `bedroom_summary` = `25° 411ppm` ✅ |
+
+**Шаг 2 — что это за сущности (реестр HA):** `sensor.dining_*` → `platform: mqtt` → `device_id: d4878565d104ef5c09c2d38961521b84` → в `core.device_registry` `identifiers = [["mqtt","modbus_dining_sensor"]]`. То есть это **виртуальные датчики, которые создаёт `modbus-bridge`** через MQTT discovery (НЕ Zigbee, НЕ HA).
+
+**Шаг 3 — что реально публикуется в MQTT (подписка `mosquitto_sub -t 'modbus/#'`):**
+```
+modbus/sensors/kids/temperature      25.2
+modbus/sensors/kids/co2              381.38
+modbus/sensors/kids/humidity         39.2
+modbus/sensors/bedroom/temperature   25.07
+modbus/sensors/bedroom/co2           409.85
+modbus/sensors/bedroom/humidity      36.0
+```
+🔴 **`modbus/sensors/dining/*` — НЕТ НИ ОДНОГО СООБЩЕНИЯ.** ZONT не опрашивает датчик столовой (или его нет на 485-шине).
+
+### 🧩 Формула (для полноты — `configuration.yaml` строки 1116–1121)
+
+```yaml
+- name: dining_summary
+  state: "{{ states('sensor.dining_temperature_2')|round(0)|int }}° {{ states('sensor.dining_co2')|int }}ppm"
+- name: dining_air_summary
+  state: "{{ states('sensor.dining_tvoc')|int }}tvoc {{ states('sensor.dining_pm10')|int }}pm"
+- name: kids_summary      # ← эта РАБОТАЕТ
+  state: "{{ states('sensor.kids_temperature')|round(0)|int }}° {{ states('sensor.kids_co2')|int }}ppm"
+```
+
+**Это НЕ «средние»** (агент ошибочно так назвал — исправлено). Это **склейка строки** для плашки на дашборде: температура + CO2 через пробел.
+
+**Механика падения:** `int`/`round` не умеют превратить строку `unknown` в число → рендер template падает → **вся** сущность становится `unavailable` (а не `unknown`). У детей/спальни датчики отдают числа → формула собирается.
+
+### 🔴 ПОЧЕМУ ФИКС ФОРМУЛОЙ — ВРАНЬЁ
+
+Если вписать `\|default(0)`, сводка выдаст **`0° 0ppm`** — то есть на дашборде появится «ложный ноль» вместо честного «нет данных». **Alex'у нужен факт, а не зелёная плашка.** Правка кода **не делается** до ответа на вопрос ниже.
+
+### ❓ ОТКРЫТЫЙ ВОПРОС К ALEX (блокирует решение)
+
+**Есть ли датчик температуры/CO2 в столовой физически** (тот, что ZONT должен видеть на 485-шине)?
+
+| Ответ | Что делать |
+|---|---|
+| **Да, есть** | Чинить ZONT: почему не опрашивает датчик (не зарегистрирован в ZONT / обрыв / датчик сдох). Проверить по карте: **Гостиная = slave 1, Детская = 2, Спальня = 3** ([[family/how-to/home-automation]]) — «столовая» в ZONT может называться «Гостиная» или это отдельный слейв |
+| **Нет** | 8 сущностей `sensor.dining_*` — **мусор с TrueNAS**. Чистить из `core.entity_registry` (при остановленном HA, бэкап реестра), а не «чинить» формулой |
+
+> 📌 **Метод (переиспользуемый) — как отвечать на «почему сущность недоступна»:**
+> 1. `/api/states` → какие сущности `unavailable`/`unknown`.
+> 2. `core.entity_registry` → `platform` + `device_id` (откуда сущность).
+> 3. `core.device_registry` → `identifiers` (какое устройство/интеграция).
+> 4. Если `mqtt` + `modbus_*_sensor` → подписка `mosquitto_sub -t 'modbus/#'` → **есть ли данные вообще**.
+> 5. Только после этого решать: чинить источник / чистить мусор / править формулу. **Формула — последнее, что проверять, а не первое.**
+
+**Пароль для `mosquitto_sub`:** `ha apps info 45df7312_zigbee2mqtt --raw-json | jq -r '.data.options.mqtt.password'`, `-u zont`. В SSH-аддоне есть `mosquitto_sub`; `-R` (retained) **врёт** (§6), смотреть что прилетает сразу при подписке.
+
+**Ничего не менялось — только чтение.**
+
+---
+
 ## 6. Zigbee (z2m)
 
 ### Данные и файлы
@@ -861,7 +939,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.*_summary` — добавить `\|default(0)` в template-сенсоры (косметика, самоизлечится) | — |
+| 3 | **`sensor.dining_summary` / `dining_air_summary`** — ❌ **ПРЕЖНЯЯ ФОРМУЛИРОВКА ОПРОВЕРГНУТА 2026-09-14 15:39.** Это **НЕ** `\|default(0)`. Причина: 8 сущностей `sensor.dining_*` (`_co2`, `_temperature_2`, `_humidity`, `_tvoc`, `_pm10`, `_pm2_5`, `_formaldehyde`) сидят на MQTT, но **ZONT не публикует `modbus/sensors/dining/*` ВООБЩЕ** (проверено подпиской на MQTT живьём: в трафике только `kids/*` и `bedroom/*`). `int`/`round` на `unknown` → сводка `unavailable`. **Фикс формулой = враньё** (`0° 0ppm`). **Открытый вопрос к Alex: датчик в столовой есть физически?** Если нет — 8 сущностей мусор с TrueNAS, чистить реестр. Если да — чинить ZONT (регистрация/обрыв датчика). Кода не менять до ответа (§5-тер) | — |
 | 4 | **Камера** — найти образ/папку, поднять на t610, поправить upstream в Caddy | отдельно |
 | 5 | **Этап 4:** Caddy upstream → t610, GPON-редирект → t610, перенаправить ZONT на MQTT t610 | — |
 | 6 | Остановить + отключить автозапуск сервисов на TrueNAS (не удалять — откат) | — |
@@ -876,7 +954,7 @@ curl -s -X POST -H "$HDR" -H "Content-Type: application/json" \
 
 **✅ Закрыто / установлено в этой сессии (2026-09-14, вечерняя верификация 15:33):**
 - **Регресс-проверка после обмена гнёзд — ПРОЙДЕНА (только чтение, ничего не менялось).** Оба аддона `started`, привязки совпадают с финалом (`mbusd`→`usb-0:3`, `bridge`→`usb-0:4`), сниффинг живой (slave 1/2/3/14/20/101/103, CRC OK), MQTT публикуется. Срочный пункт «гнездо 4 отключено» — **закрыт**.
-- **Осталось 10 `unavailable` — все известные и объяснённые** (slave 10 закомментирован — задача снята; `*_summary` без `\|default(0)`; `todo.shopping_list` системная; `switch.sauna` — розетка обесточена). Ничего нового не сломалось.
+- **Осталось 10 `unavailable` — все известные и объяснённые.** Пересчёт 2026-09-14 15:39: **7** — slave 10 (AT2 fans) закомментирован, задача снята — не поломка; **2** — `dining_summary`/`dining_air_summary` (причина: ZONT не публикует `modbus/sensors/dining/*`, НЕ `\|default(0)` — см. §5-тер); **1** — `todo.shopping_list` системная. `switch.sauna` — розетка обесточена. Ничего нового не сломалось.
 - **⚠️ Новое наблюдение:** лог `modbus-bridge` не писался ~7 ч (последняя строка `08:32:58` при времени `15:33`) при `state: started`; `ha apps restart local_modbus-bridge` оживил. **Причина НЕ установлена — теорий не строить, проверять фактом.** Приём «restart для оживления bridge» задокументирован в §1.
 - **Деталь привязки:** `by-path` `usb-0:3`/`usb-0:4` **нестабильны по tty-номеру** (`usb-0:4`→`ttyUSB1`, `usb-0:3`→`ttyUSB0` на момент проверки). Работать **только по by-path**, tty-номера не запоминать (§3).
 
@@ -899,9 +977,11 @@ curl -s -X POST -H "$HDR" -H "Content-Type: application/json" \
 
 **Вариант A — безопасный заход (рекомендован агентом):**
 
+> ⚠️ **ОБНОВЛЕНО 2026-09-14 15:39:** шаг **A1 (`|default(0)`) СНЯТ** — его посылка опровергнута (см. §9 задача 3 и §5-тер): `dining_summary` падает не из-за отсутствия `default`, а потому что **ZONT не публикует `modbus/sensors/dining/*`**. Фикс формулой дал бы `0° 0ppm` = враньё на дашборде. **Ждём ответ Alex: датчик в столовой физически есть?**
+
 | Шаг | Задача | Риск | Действие |
 |---|---|---|---|
-| A1 | **№3**: `\|default(0)` в template-сенсоры `*_summary` | ✅ низкий | Бэкап `configuration.yaml` → правка (`round(0)` получает `unknown`) → `ha core check` → `ha core restart`. Гасит 4 ERROR'а, оживляет `sensor.bedroom_summary`/`kids_summary`/`dining_summary`/`dining_air_summary`. Откат = один файл |
+| ~~A1~~ | ~~№3: `\|default(0)` в template-сенсоры~~ — **❌ СНЯТ, посылка опровергнута** | — | См. §5-тер. Вместо правки кода — вопрос Alex про физику + (если датчика нет) чистка 8 сущностей из реестра |
 | A2 | **№7**: Static IP для t610 | ✅ низкий | На роутере `192.168.2.2` (SSH root) привязать MAC `9c:8e:99:ef:3f:c5` → `192.168.2.176`. Сервисы не трогаются |
 | A3 | **№8**: Бэкап конфигов t610 | ✅ низкий | `tar` конфигов t610 → Mac + TrueNAS + коммит в Gitea `git.mallexxx.duckdns.org` |