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

family/plans/t610-home-automation.md

@@ -1,7 +1,10 @@
 ---
 updated: >-
   2026-09-14 (ночь-16: §2 — железо хоста + канон чтения температуры CPU
-  `k10temp`; питфоллы: пустой `thermal_zone`, нет бинарника `sensors`)
+  `k10temp`; питфоллы: пустой `thermal_zone`, нет бинарника `sensors`.
+  §8 — ГРАНИЦЫ ПРАВ: контейнер HA Core из аддона НЕ инспектируется
+  (docker/nsenter/Supervisor-exec 403/Core REST 401/`/sys` ro) + схема
+  вывода температуры в HA через SSH-интеграцию. §9 — вишлист + задача)
 namespace: family
 status: works
 ---
@@ -95,6 +98,8 @@ ssh root@192.168.2.176 \
 
 **Ориентиры (G-T56N, пассивное охлаждение):** 55–65 °C — норма; **70 °C** (`temp1_max`) — повод проверить обдув/пыль; 100 °C — throttling. Под нагрузкой (ffmpeg-транскод камеры, `ha apps rebuild`, опрос шины) температура растёт — замер 58 °C сделан при `load 0.2` (холостой), это **не потолок**.
 
+> 🔗 **Как вывести эту температуру датчиком в HA** (и почему `System Monitor` тут бессилен, а контейнер Core не проинспектировать) — **§8 → «Границы прав» + «Как вывести температуру CPU в HA»**.
+
 **Про SSH:** в HA OS SSH выключен по умолчанию. Включается аддоном `core_ssh` (Terminal & SSH): положить публичный ключ в `authorized_keys`. Пароля root не существует, вход только по ключу.
 
 **Откуда реально можно зайти на t610 (`192.168.2.176:22`) — проверено фактом 2026-09-14:**
@@ -1960,6 +1965,41 @@ ha apps restart "$SLUG"
 > ⚠️ API требует **полный** набор опций — схема валидирует все ключи. Посылать только изменённое нельзя (`Missing option '<key>'`). Берём текущие, меняем нужное.
 > ⚠️ `SUPERVISOR_TOKEN` — **встроенная переменная окружения аддона** (подставляется Supervisor'ом автоматически). В доку она пишется через `printf`-обход, потому что маскировщик секретов при записи ломает литерал заголовка с Bearer. Рабочие скрипты — `~/tmp-t610/*.sh`.
 
+### 🚧 Границы прав: НЕЛЬЗЯ заглянуть в контейнер HA Core из аддона (проверено фактом 2026-09-14, ночь-16)
+
+**Задача, с которой это выяснено:** завести `sensor` температуры CPU в HA. Возник вопрос — «продёрнуть `hwmon` в контейнер Core или завести алиас на `thermal_zone`». Обе идеи упираются в одно: **у нас нет никакой ручки внутрь контейнера Core**. Проверены ВСЕ пути — все закрыты:
+
+| Путь | Результат | Причина |
+|---|---|---|
+| `docker ps` / `docker exec` из аддона | ❌ **`docker недоступен`** | Docker-сокет в аддоны HA OS не проброшен |
+| PID namespace хоста | ❌ **изолирован** | `ls -la /proc/1/ns/pid` == `ls -la /proc/self/ns/pid` → **тот же ns, но это ns САМОГО АДДОНА**, не хоста. `ps` показывает только **16** процессов (s6/sshd/ttyd). Процесса `hass`/`python3` в `/proc` **нет вообще** |
+| `nsenter` / host `init` | ❌ | PID 1 внутри аддона = `s6-svscan` **аддона**, не хостовый init |
+| Supervisor API exec | ❌ **`403 Forbidden`** | API **не даёт произвольный shell** (by-design, не дыра). Есть только `/host/info`, `/host/services`, `/addons/<slug>/*` |
+| `GET http://supervisor/core/api/config` (REST API Core) | ❌ **`401`** | **супервизорный токен не годится как токен Core** |
+| хостовый root на диске | ❌ | в аддон **не проброшен**: `/mnt` и `/host` **пусты** |
+| запись в `/sys` | ❌ | смонтирован **`ro,nosuid,nodev,noexec`** (`touch` → `Read-only file system`); опции монтирования менять нечем |
+
+> 🔴 **ВЫВОД В КАНОН: контейнер HA Core из аддона не инспектируется.** Ни `docker`, ни `nsenter`, ни Supervisor API, ни запись в `/sys`. **Не искать повторно** — границы прав аддона, а не недостаток прав root: аддон работает как `uid=0`, `CapEff=00000000a80425fb`, но этого мало. Всё, что нужно узнать про Core — только через **его REST API по пользовательскому long-lived токену** (`http://192.168.2.176:80/api/…`) или через **UI**.
+
+> ✅ **НО ГЛАВНОЕ, ЧТО ВЫЯСНИЛОСЬ: `/sys/class/hwmon/hwmon0` уже виден внутри АДДОНА `core_ssh`** — `name` = `k10temp`, `temp1_input` читается насквозь (`57875`). Т.е. **`hwmon` пробрасывать не надо — он уже проброшен**, потому что `/sys` монтируется в контейнеры из **одного источника** (`sysfs` ядра хоста; в Core и в аддоне — один и тот же `ro,relatime`).
+> 🔴 **Почему идея «алиас на `thermal_zone`» невозможна принципиально:** `thermal_zone0` на этом хосте **не создан ядром вовсе** (пусто и в аддоне, и на хосте). Симлинк не создаёт файл — он на него **указывает**; занять имя нечем, а `/sys` **read-only**. Создать «зону» из userspace нельзя.
+> 📌 **Следствие для автоматизации:** HA `System Monitor` читает температуру **только из `/sys/class/thermal/thermal_zone0/temp`** → на t610 он её **не покажет никогда** (зоны нет). Даёт только load/RAM/диск (через `/proc`, а он читается). Для температуры — **SSH-путь** (см. ниже), где `cat` исполняется на удалённой стороне и Core вообще не нужен доступ к `/sys`.
+
+### 🌡 Как всё-таки вывести температуру CPU в HA (рекомендованная схема)
+
+```
+t610 k10temp ──> sshd (аддон core_ssh) ──> HA SSH-интеграция ──> sensor.t610_cpu_temperature
+```
+
+**Почему это работает независимо от границ прав:** команда `cat /sys/class/hwmon/hwmon0/temp1_input` исполняется **на удалённой стороне** (в sshd t610, где `hwmon0` точно виден), а Core получает **готовое число по TCP**. Core не нужен доступ к `/sys` — поэтому тупики из таблицы выше **не блокируют** решение.
+
+- Значение приходит в **миллиградусах** (`57875`) → делить на 1000 в `value_template` сенсора.
+- Обновление раз в **60 с** (температура инерционна).
+- Алерт: automation `> 70 °C` (`temp1_max`) → пуш.
+
+> ⚠️ **Осталось непроверенным (ручки нет):** видит ли `hwmon0` **сам Core** (а не аддон). Косвенно — да (общий источник `/sys`), но **проверить нельзя** ни SSH, ни API (403/401). **Проверяется только через UI: Settings → System → Hardware** (виден ли `k10temp`). **На выбор способа не влияет** — SSH-сенсор работает при любом ответе.
+> ❌ **Отвергнутые варианты (не повторять):** ① `System Monitor` — темпы нет (нет `thermal_zone`); ② `command_line` сенсор с `cat /sys/...` — Core не видит хостовый `hwmon`; ③ **файл-мостик** в `/config` (внешний обновлятор пишет `temp`, сенсор читает) — технически возможно (`/config` аддона == `/homeassistant` Core), но **костыль**: протухание без `unique_id`/статуса online, против канона «канон > костыли».
+
 ### Long-lived token HA
 
 **Создать:** `http://192.168.2.176` → профиль → **Security** → **Long-lived access tokens** → Create.
@@ -2036,6 +2076,13 @@ curl -s -X POST -H "$HDR" -H "Content-Type: application/json" \
 
 ## 9. Что осталось
 
+**⏳ В РАБОТЕ / ЖДЁТ КОМАНДЫ ALEX (2026-09-14, ночь-16):**
+
+| Задача | Состояние | Что дальше |
+|---|---|---|
+| **Температура CPU t610 → датчик в HA** | 🔶 **ПЛАН СОГЛАСОВАН, ЖДЁТ «делай».** Разбор путей закончен: тупики зафиксированы в §8 («Границы прав»), рекомендованная схема — там же. Сенсор **ещё НЕ создан**. | ① проверить TCP из Core → sshd; ② бэкап `configuration.yaml`; ③ завести `sensor.t610_cpu_temperature` (HA SSH-интеграция, `value_template` /1000) + automation `>70 °C`; ④ записать канон. **Альтернатива без правок на t610:** cron Hermes — молчит, пока норма; пишет в Zulip при `>70 °C` |
+| **Вишлист автоматизаций** | ✅ **ЗАФИКСИРОВАН 2026-09-14:** [[family/documents/home-automation-wishlist]] — 8 направлений + 5 устройств + порядок `1 → 2 → 4 → 5 → 3 → 6`. **Ничего не реализовано.** | Ждём выбора Alex, какие направления брать в работу |
+
 | # | Задача | Кто |
 |---|---|---|
 | ~~1~~ | ~~Фикс 44 `unavailable`~~ — **✅ РЕШЕНО 2026-09-14 (финал): причина — перепутанные гнёзда аддонов. Обмен привязок → `unavailable` 44→10.** Все вложенные гипотезы (опции mbusd, `timeout`, «два мастера», `verify`, шторм коннектов) — **опровергнуты**. См. §5 «✅✅ РЕШЕНИЕ». | — |