diff --git a/family/plans/t610-home-automation.md b/family/plans/t610-home-automation.md index 60d77ddc..0dd8804e 100644 --- a/family/plans/t610-home-automation.md +++ b/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 ''`). Берём текущие, меняем нужное. > ⚠️ `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//*` | +| `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 «✅✅ РЕШЕНИЕ». | — |