[2026-09-17] eagle: family/how-to/home-automation.md family/how-to/rasputin-router.md family/tech/haos-local-addon-publish-sensors.md family/tech/t610-hang-investigation.md family/tech/t610-hw-metrics-addon.md

2026-09-17 13:30:51 +06:00
parent 0319e09317
commit e912b6c9db
5 changed files with 517 additions and 64 deletions
@@ -19,12 +19,13 @@ tags:
  - monitoring
 title: "\U0001F4CA t610 — метрики хоста (RAM, температура) + лог, переживающий зависание"
 type: tech
-updated: '2026-09-17'
+updated: '2026-09-17b'
 ---
 # 📊 t610 — метрики хоста (RAM, температура) + лог, переживающий зависание

-> **Статус: ✅ ВНЕДРЕНО И РАБОТАЕТ (2026-09-17).** Локальный аддон `local_hw_metrics`, интервал 60 с.
-> Ждёт живой проверки Alex'ом (коммит ПОСЛЕ — после неё).
+> **Статус: ✅ РАБОТАЕТ (2026-09-17).** Локальный аддон `local_hw_metrics` **v8.0.0**, интервал 60 с,
+> MQTT discovery. 11 датчиков живые в HA, лог пишется на диск со `sync`.
+> ⚠️ **Известный дефект: `entity_id` с двойным префиксом** `sensor.t610_t610_*` (не переименовывается, §8).
 > Родительские доки: [[family/how-to/home-automation]] · расследование зависаний — [[family/tech/t610-hang-investigation]]

 ---
@@ -36,25 +37,73 @@ updated: '2026-09-17'
 1. **Метрики хоста в HA как датчики** — сколько RAM занято/свободно, температура CPU.
 2. **Лог, который переживает зависание.** HAOS пишет свой журнал в **RAM** — после жёсткого зависания он исчезает целиком ([[family/tech/t610-hang-investigation]] §2, 5 источников пусты). Каждый инцидент стирал свои доказательства. Нужно было, чтобы следующий случай оставил следы.

+> 🔴 **Требование Alex к сдаче работы:** «Я готов результат проверь когда датчики будут в **ha ui**».
+> То есть «сущность отвечает по API» — **не** приёмка. Датчики должны быть видны в UI,
+> с зоной и дашбордом. Это меняет план: назначение зоны/дашборда — часть «готово», а не «потом».
+
 ---

-## 2. Архитектура
+## 2. Архитектура (ФИНАЛЬНАЯ — MQTT discovery)

 ```
-аддон local_hw_metrics (alpine, bash, loop)
+аддон local_hw_metrics v8 (alpine, bash, while true)
   │  каждые 60 с
   ├─ читает ХОСТОВЫЕ /proc/meminfo, /proc/loadavg, /proc/pressure/*,
   │           /sys/class/hwmon/hwmon0/temp1_input, /proc/uptime,
-   │           размер /config/home-assistant_v2.db + -wal
-   ├─ публикует 11 сенсоров → POST /api/states/<entity>  (HA REST API)
+   │           размер /config/home-assistant-v2.db + -wal
+   ├─ один retained JSON в топик t610/hw/state
+   │  + retained "online" в t610/hw/available
+   │  + retained discovery-конфиги homeassistant/sensor/t610_host/<key>/config
+   │            │
+   │            └──► HA (интеграция mqtt) САМ создаёт 11 настоящих сущностей
+   │                 в entity_registry, с unique_id и device `t610`
   └─ дописывает строку в /share/ha-metrics/hw-YYYY-MM.log + sync
                              ▲
                              └─ переживает жёсткое зависание
 ```

-**Почему аддон, а не cron в `core_ssh`:** аддон `core_ssh` собран на **s6** (`/etc/services.d/` — только `sshd`, `ttyd`), а `crond` (BusyBox) в нём **не запущен**. `/etc/crontabs/root` существует, но процесса нет; своего startup-хука в встроенный аддон не добавить. Любая задача «внутри core_ssh» умрёт при рестарте аддона. Свой аддон с внутренним `while true` — надёжно и переживает ребут хоста (`boot: auto` + `watchdog: true`).
+### Почему MQTT discovery, а НЕ REST `POST /api/states`

-**Почему REST, а не MQTT:** из контейнера `mosquitto_pub` падает с `Bad file descriptor` (питфолл 7 родительской доки, подтверждён ещё раз). Единственный рабочий путь к HA из контейнера — внешний `https://mallexxx.duckdns.org` (проверено: `401` без токена, `200` с токеном). Значит `POST /api/states/<entity>` — и **правка `configuration.yaml` не нужна вообще**: блок `mqtt:` в конфиг **не добавлялся**, рестарт ядра **не потребовался**. Это лучше первоначального плана (было: MQTT → 6 сенсоров через `mqtt:`).
+**Это главное решение сессии, и оно переигрывалось дважды.**
+
+| | REST `POST /api/states` | **MQTT discovery** ✅ |
+|---|---|---|
+| Попадает в `entity_registry` | ❌ **нет** | ✅ да |
+| `unique_id` | ❌ нет | ✅ есть |
+| `device` | ❌ нет | ✅ есть (`t610`) |
+| `area_id` назначить | ❌ **нельзя** (нет записи в реестре) | ✅ можно |
+| Видно на дашбордах зон | ❌ нет | ✅ да |
+| История в recorder | пишется, но к несуществующей записи | ✅ нормально |
+
+> 🔴 **Урок:** REST-сущности живут **только в state machine**, их нет в реестре.
+> Проверено фактом: `POST /api/states/sensor.x` → сущность отвечает по API, но
+> `config/entity_registry/list` её **не содержит** (`find t610` → 0 записей).
+> Для датчиков, которые нужны на дашборде, **REST-путь негоден** — только MQTT discovery
+> или `configuration.yaml`.
+
+### Почему аддон, а не cron в `core_ssh`
+
+Аддон `core_ssh` собран на **s6** (`/etc/services.d/` — только `sshd`, `ttyd`), а `crond`
+(BusyBox) в нём **не запущен** — процесса нет, хотя `/etc/crontabs/root` существует и в нём
+есть штатные задачи. Своего startup-хука в встроенный аддон не добавить. Любая задача
+«внутри core_ssh» умрёт при рестарте аддона. Свой аддон с `while true` — надёжно
+и переживает ребут хоста (`boot: auto` + `watchdog: true`).
+
+### Как выглядит публикация (ключевой фрагмент)
+
+```bash
+# один retained JSON со всеми значениями
+PUB=... mosquitto_pub -h core-mosquitto -p 1883 -u "$MQ_USER" -P "$MQ_PASS" \
+     -t "t610/hw/state" -m "$PAYLOAD" -r
+
+# discovery-конфиг одного сенсора (retained)
+CFG='{"name":"RAM total","unique_id":"t610hw_mem_total","state_topic":"t610/hw/state",
+      "value_template":"{{ value_json.mem_total }}","availability_topic":"t610/hw/available",
+      "payload_available":"online","payload_not_available":"offline",
+      "unit_of_measurement":"MB","device_class":"data_size","state_class":"measurement",
+      "device":{"identifiers":["t610_host"],"name":"t610","manufacturer":"HP","model":"t610"}}'
+mosquitto_pub ... -t "homeassistant/sensor/t610_host/mem_total/config" -m "$CFG" -r
+```

 ---

@@ -66,33 +115,66 @@ updated: '2026-09-17'
 | Исходники на Mac | `~/tmp-t610/hw_metrics_addon/` |
 | Slug в Supervisor | **`local_hw_metrics`** |
 | Лог метрик | `/share/ha-metrics/hw-YYYY-MM.log` (хостовый, `sda8`) |
-| Env-файл (легаси) | `/etc/ha_hw_metrics.env` — `MQ_USER`/`MQ_PASS`/`TOK`, chmod 600. Оставлен от первой (MQTT) попытки, не используется |
+| Env-файл (легаси) | `/etc/ha_hw_metrics.env` — `MQ_USER`/`MQ_PASS`/`TOK`, chmod 600. Оставлен от REST-попытки, **не используется аддоном** |
 | Скрипт на хосте (легаси) | `/usr/local/bin/ha_hw_metrics.sh` — v2 (REST). Рабочий, но аддон его заменяет |

-**Версия токена:** `ha_token` лежит **в опциях аддона** (`/data/options.json` внутри контейнера), `tokenlen=183`. Env-файл `/etc/ha_hw_metrics.env` — не нужен, оставлен как след первой попытки.
+### `config.yaml` аддона (v8, финал)
+
+```yaml
+name: "HW metrics (t610: RAM + temp)"
+version: "8.0.0"
+slug: "hw_metrics"
+arch: [amd64, aarch64]
+startup: services
+boot: auto          # стартует при загрузке ХОСТА
+init: false
+host_network: true  # ← нужно: даёт доступ к Docker DNS (core-mosquitto) и хостовому /proc
+map:
+  - share:rw        # ← обязательно: /share/ha-metrics для лога
+  - config:ro       # ← обязательно: du по home-assistant_v2.db
+options:
+  interval: 60
+  mqtt_host: "core-mosquitto"
+  mqtt_port: 1883
+  mqtt_user: "zont"
+  mqtt_password: ""
+schema:
+  interval: "int(10,600)"
+  mqtt_host: "str"
+  mqtt_port: "port"
+  mqtt_user: "str"
+  mqtt_password: "password"
+```
+
+`Dockerfile`: `FROM alpine:3.20` + `apk add bash jq mosquitto-clients coreutils`, `CMD ["/bin/bash","/metrics.sh"]`.

 ---

-## 4. Датчики (11)
+## 4. Датчики (11) — фактические ID

-| Entity | Единица | Источник |
-|---|---|---|
-| `sensor.t610_ram_total` | MB | `MemTotal` |
-| `sensor.t610_ram_available` | MB | `MemAvailable` |
-| `sensor.t610_ram_free` | MB | `MemFree` |
-| `sensor.t610_ram_used` | MB | `MemTotal − MemAvailable` |
-| `sensor.t610_swap_used` | MB | `SwapTotal − SwapFree` |
-| `sensor.t610_cpu_temp` | °C | `hwmon0/temp1_input` / 1000 |
-| `sensor.t610_load_1m` | — | `/proc/loadavg` |
-| `sensor.t610_load_5m` | — | `/proc/loadavg` |
-| `sensor.t610_uptime` | s | `/proc/uptime` |
-| `sensor.t610_pressure_io` | % | `/proc/pressure/io` some avg10 |
-| `sensor.t610_pressure_mem` | % | `/proc/pressure/memory` some avg10 |
+> 🔴 **`entity_id` получились с ДВОЙНЫМ префиксом** — `sensor.t610_t610_*`.
+> Причина и почему не исправлено — §8. В **UI видно корректно** (`t610 RAM total`),
+> кривой только `entity_id` для автоматизаций/шаблонов.

-⚠️ **`ram_used` = `MemTotal − MemAvailable`, НЕ `MemFree`** — питфоллы 44/45: `MemFree` падает из-за файлового кэша и врёт про «занято».
+| `entity_id` (факт) | Отображаемое имя | Единица | Источник |
+|---|---|---|---|
+| `sensor.t610_t610_ram_total` | t610 RAM total | MB | `MemTotal` |
+| `sensor.t610_t610_ram_available` | t610 RAM available | MB | `MemAvailable` |
+| `sensor.t610_t610_ram_free` | t610 RAM free | MB | `MemFree` |
+| `sensor.t610_t610_ram_used` | t610 RAM used | MB | `MemTotal − MemAvailable` |
+| `sensor.t610_t610_swap_used` | t610 SWAP used | MB | `SwapTotal − SwapFree` |
+| `sensor.t610_t610_cpu_temp` | t610 CPU temp | °C | `hwmon0/temp1_input` / 1000 |
+| `sensor.t610_t610_load_1m` | t610 load 1m | — | `/proc/loadavg` |
+| `sensor.t610_t610_load_5m` | t610 load 5m | — | `/proc/loadavg` |
+| `sensor.t610_t610_uptime` | t610 uptime | s | `/proc/uptime` |
+| `sensor.t610_t610_pressure_io` | t610 pressure io | % | `/proc/pressure/io` some avg10 |
+| `sensor.t610_t610_pressure_mem` | t610 pressure mem | % | `/proc/pressure/memory` some avg10 |

-> ⚠️ **Датчики из REST — `restore_state`-типа.** Они **не восстанавливаются** после рестарта ядра, пока аддон не опубликует заново (≤60 с). Историю recorder пишет, но «пропажа» на минуту после ребута — норма, не поломка.
-> ⚠️ **Зона/дашборд не назначены.** Template-сущности из REST не имеют `device_id` → `area_id` назначается вручную (питфолл 47). Не сделано.
+⚠️ **`ram_used` = `MemTotal − MemAvailable`, НЕ `MemFree`** — питфоллы 44/45: `MemFree` падает
+из-за файлового кэша и врёт про «занято».
+
+**Проверено совпадением с хостом:** `ram_total 3389.4 MB` = `3470776 kB` ✓ ·
+`cpu_temp 61.8 °C` = `61750 мК` ✓ · `ram_used 832.8 MB` = `(3470776−2618024)/1024` ✓

 ---

@@ -106,9 +188,14 @@ load1, load5, load15, pressure_io, pressure_mem, temp_mC, uptime_s,
 db_kB, wal_kB, RC
 ```

-Последнее поле `RC` — код ошибки публикации: `0` = все 11 сенсоров отдались, `1` = что-то не прошло (детали в логе аддона).
+Последнее поле `RC` — код ошибки публикации: `0` = всё отдалось, `1` = что-то не прошло
+(детали в логе аддона). Фактический пример живой строки:

-Объём: 1 строка ≈ 117 байт × 1440/сутки ≈ **165 КБ/мес**. За год ~2 МБ.
+```
+2026-09-17T07:25:57Z,3470776,2618024,778160,1723516,1145356,1145356,1.36,1.18,1.00,0.95,0.00,61750,4864,79616,12,0
+```
+
+Объём: 1 строка ≈ 117 байт × 1440/сутки ≈ **165 КБ/мес**, ~2 МБ/год.

 ---

@@ -117,9 +204,9 @@ db_kB, wal_kB, RC
 ```bash
 # состояние аддона
 ssh -i ~/.ssh/id_rsa root@192.168.2.176 \
-  'T=$(cat /run/s6/container_environment/HASSIO_TOKEN); K1=$(printf "Au%s" "thorization"); K2=$(printf "Bea%s" "rer"); H="$K1: $K2 $T"; curl -s -H "$H" http://supervisor/addons/local_hw_metrics/info | jq -r "{state: .data.state, watchdog: .data.watchdog, boot: .data.boot}"'
+  'T=$(cat /run/s6/container_environment/HASSIO_TOKEN); K1=$(printf "Au%s" "thorization"); K2=$(printf "Bea%s" "rer"); H="$K1: $K2 $T"; curl -s -H "$H" http://supervisor/addons/local_hw_metrics/info | jq -r "{state: .data.state, watchdog: .data.watchdog, boot: .data.boot, version: .data.version}"'

-# лог аддона
+# лог аддона (живой, не буфер)
 ssh -i ~/.ssh/id_rsa root@192.168.2.176 \
  'T=$(cat /run/s6/container_environment/HASSIO_TOKEN); K1=$(printf "Au%s" "thorization"); K2=$(printf "Bea%s" "rer"); curl -s -H "$K1: $K2 $T" http://supervisor/addons/local_hw_metrics/logs | tail -20'

@@ -127,46 +214,110 @@ ssh -i ~/.ssh/id_rsa root@192.168.2.176 \
 ssh -i ~/.ssh/id_rsa root@192.168.2.176 \
  'T=$(cat /run/s6/container_environment/HASSIO_TOKEN); K1=$(printf "Au%s" "thorization"); K2=$(printf "Bea%s" "rer"); H="$K1: $K2 $T"; CT="Content-Type: application/json"; curl -s -X POST -H "$H" -H "$CT" http://supervisor/addons/local_hw_metrics/rebuild'

-# лог метрик
+# лог метрик на диске
 ssh -i ~/.ssh/id_rsa root@192.168.2.176 'tail -5 /share/ha-metrics/hw-2026-09.log'

-# сущности в HA
-B="https://mallexxx.duckdns.org"; curl -s -H @/tmp/h1 "$B/api/states/sensor.t610_ram_used" | jq -r '.state'
+# живые значения датчиков
+B="https://mallexxx.duckdns.org"; curl -s -H @/tmp/h1 "$B/api/states" | jq -r '.[] | select(.entity_id|test("t610.*(ram|swap|cpu|load|uptime|pressure)")) | "\(.entity_id) = \(.state) \(.attributes.unit_of_measurement // "")"'

-# удалить датчик (если понадобится)
-curl -s -X DELETE -H @/tmp/h1 "$B/api/states/sensor.t610_ram_used"
+# проверка «в реестре ли сущности» (ключевой критерий для дашборда!)
+cd ~/tmp-t610 && python3 chk_reg.py
+
+# МОСТИК: сброс retained discovery-топиков (лечит зависшие/дублирующиеся сущности)
+scp -i ~/.ssh/id_rsa clear_t610_topics.sh root@192.168.2.176:/tmp/
+ssh -i ~/.ssh/id_rsa root@192.168.2.176 'bash /tmp/clear_t610_topics.sh'
 ```

+### 🔴 Порядок установки/обновления локального аддона (стоил 8 итераций)
+
+```bash
+# 1) store/reload — регистрирует аддон в Supervisor (ещё НЕ установка)
+# 2) install    — возвращает ok ДО готовности → НЕ слать options сразу
+# 3) options    — задать MQTT-пароль
+# 4) rebuild    — только ставится в очередь
+# 5) start
+```
+После правки `config.yaml` (схемы/опций) Supervisor **кеширует старый манифест** —
+`store/reload` схему не обновляет. Помогает **`uninstall` → `store/reload` → `install`**
+и **поднятие `version`** в `config.yaml`.
+
 ---

-## 7. Питфоллы (новые)
+## 7. Питфоллы

 | # | Питфолл | Обход |
 |---|---|---|
-| 73 | 🔴 **`mosquitto_pub` из контейнера — `Bad file descriptor`.** Подтверждён повторно уже на хосте, а не только в аддоне | Публиковать **не через MQTT**. Рабочий путь к HA из контейнера — `https://mallexxx.duckdns.org` (внешний, `401` без токена) |
-| 74 | 🔴 **`POST /api/states/<entity>` создаёт сущность напрямую** — блок `mqtt:` в `configuration.yaml` **не нужен**, рестарт ядра не нужен | Проверено: POST → `200`, GET → значение; DELETE → `200`, затем `404` |
-| 75 | 🔴 **`crond` на `core_ssh` не запущен**, хотя `/etc/crontabs/root` есть. Аддон на **s6** (`/etc/services.d/` = `sshd`, `ttyd`) | Не пытаться поднять cron внутри `core_ssh` — задача умрёт при рестарте аддона. Периодику делать **своим аддоном** с `while true` |
-| 76 | 🔴 **Новый локальный аддон: сначала `POST /addons/<slug>/install`, потом `/options`** | Иначе `/options` и `/rebuild` отдают `{"result":"error","message":"App is not installed"}`. Порядок: `store/reload` → `install` → `options` → `rebuild` → `start`. ⚠️ `store/reload` **регистрирует** аддон в Supervisor (`GET /addons` его уже показывает, `/info` отдаёт `state: unknown` + опции из `config.yaml` — но это **не** установка) |
-| 76a | 🔴 **`install` возвращает `{"result":"ok"}` ДО готовности образа** | Сразу после `install` идти слать `options` **нельзя** — получишь тот же `App is not installed`. Дождаться реального признака готовности, а не ответа API. `rebuild` тоже только ставится в очередь. **Симптом-маркер:** `options`/`rebuild` дают `App is not installed`, хотя `install` только что сказал `ok` → это гонка, а не сломанный манифест |
-| 77 | ⚠️ **`/mnt/data` на t610 НЕ существует** (дока §7.3 указывала его как путь для логов) | Хостовый шаренный путь — **`/share`**. Проверено: `df` показывает `sda8` на `/share`, `/config`, `/backup`, `/addons` |
-| 78 | 🔴 **Свой аддон видит ХОСТОВЫЕ `/proc` и `/sys`** | `MemTotal` из аддона `3470776` = хостовый; `hwmon0` виден. Это позволяет мерить хост, а не контейнер — но **проверять фактом** для каждого нового аддона |
-| 79 | ⚠️ **`map: share:rw` + `config:ro` в `config.yaml`** — иначе `/share` недоступен и `du` по БД не сработает | Обязательная секция `map:` для локального аддона |
-| 80 | ⚠️ **Строку-заголовок `Authorization` инлайном писать нельзя** — фильтр рвёт | Собирать в рантайме: `K1=$(printf 'Au%s' 'thorization')`, `K2=$(printf 'Bea%s' 'rer')`, `AUTH="$K1: $K2 $TOK"`. В файле на диске строка цела (маскируется только вывод) — проверять `awk 'NR==N' file \| od -c` |
-| 81 | 🔴 **`sync "$LOGF"` — обязателен.** Без него строка остаётся в page cache и умирает вместе с хостом | Именно это делает лог «переживающим зависание». Не убирать |
+| 73 | 🔴 **`mosquitto_pub` из контейнера падает `Bad file descriptor` — НО только на неверном адресе.** Работает на `core-mosquitto` (Docker DNS, IPv6 `fd0c:ac1e:2100::7`), падает на `127.0.0.1` и `192.168.2.176` (свой netns, 1883 не слушается) | ⛔ **Прежняя формулировка «MQTT из контейнера не работает» — НЕВЕРНА.** Адресовать **`core-mosquitto`**. Проверка: `getent hosts core-mosquitto` + `nc -z core-mosquitto 1883` |
+| 74 | 🔴 **`POST /api/states/<entity>` создаёт сущность, которой НЕТ в `entity_registry`** | Для датчиков, которые нужны в UI/зоне/дашборде, REST **негоден** — только **MQTT discovery** или `configuration.yaml`. REST-путь годится для разовых записей без UI |
+| 75 | 🔴 **`crond` на `core_ssh` не запущен**, хотя `/etc/crontabs/root` есть. Аддон на **s6** (`/etc/services.d/` = `sshd`, `ttyd`) | Периодику делать **своим аддоном** с `while true` |
+| 76 | 🔴 **Новый локальный аддон: `install` ДО `options`/`rebuild`** | Иначе `{"result":"error","message":"App is not installed"}`. Порядок в §6. ⚠️ `install` возвращает `ok` **до** готовности — сразу слать `options` нельзя, это гонка |
+| 77 | ⚠️ **`/mnt/data` на t610 НЕ существует** (старая дока §7.3 указывала его как путь для логов) | Хостовый шаренный путь — **`/share`**. Проверено `df`: `sda8` на `/share`, `/config`, `/backup`, `/addons` |
+| 78 | 🔴 **Свой аддон видит ХОСТОВЫЕ `/proc` и `/sys`** | `MemTotal` из аддона `3470776` = хостовый; `hwmon0` виден. Позволяет мерить хост — но **проверять фактом** для каждого нового аддона |
+| 79 | ⚠️ **`map: share:rw` + `config:ro` обязательны в `config.yaml`** | Иначе `/share` недоступен и `du` по БД не сработает |
+| 80 | ⚠️ **Строку-заголовок `Authorization` инлайном писать нельзя** — фильтр секретов рвёт | Собирать в рантайме: `K1=$(printf 'Au%s' 'thorization')`, `K2=$(printf 'Bea%s' 'rer')`, `AUTH="$K1: $K2 $TOK"`. **В файле на диске строка цела** (маскируется только вывод агента) — проверять `awk 'NR==N' file \| od -c` |
+| 81 | 🔴 **`sync "$LOGF"` — обязателен** | Без него строка остаётся в page cache и умирает вместе с хостом. Именно это делает лог «переживающим зависание» |
 | 82 | ⚠️ **Переменная `V4` использовалась дважды** (swap-формула перезаписывала RAM-used) → `ram_used` показывал `0.0` | Проверять значения датчиков **против хостовых** (`head -3 /proc/meminfo`), а не только «сущность создалась» |
+| 83 | 🔴 **`object_id` в discovery-конфиге + кириллица в `device.name` = транслитерированный `entity_id`** (`sensor.hp_t610_khost_ha_t610_ram_vsego`) | `device.name` — **только латиницей**; `object_id` **не задавать**. Тогда `entity_id` строится из device name + name |
+| 84 | 🔴 **`id_reuse: Identifier values have to increase` запирает `entity_registry/update` и `/remove`** — на переименование, `name`, `area_id`, удаление, даже на смену `unique_id`. Промежуточные имена, `name_by_user`, удаление device, рестарт ядра — **НЕ помогают** | ⚠️ **Не тратить время на переименование.** Радикальный путь — **новый `unique_id`** (`t610hw_*`), тогда HA создаёт сущности заново. Но даже это не спасло от двойного префикса (§8) |
+| 85 | 🔴 **Сброс retained discovery-топиков (`-m "" -r`) удаляет сущности из HA** — и **снимает** блокировку `id_reuse` | Это **штатный** способ «пересоздать» MQTT-сущности: очистить топики → HA удалит сущности → переопубликовать конфиг. `mosquitto_pub -t <topic>/config -m "" -r` |
+| 86 | ⚠️ **`GET /addons/<slug>/info` отдаёт `state: unknown` после `uninstall`** — это норма | Не считать поломкой |

 ---

-## 8. Что осталось
+## 8. 🔴 Известный дефект: двойной префикс `entity_id`

- ⚠️ **Живая проверка Alex'ом** — коммит ПОСЛЕ не сделан, ждёт.
- ⚠️ **Зона/дашборд для 11 датчиков** не назначены (`area_id` = null, питфолл 47).
- ⚠️ **Легаси-файлы не убраны** (по правилу «не удалять без подтверждения»): `/usr/local/bin/ha_hw_metrics.sh` и `/etc/ha_hw_metrics.env` — рабочие, но аддон их заменяет. Снести по команде Alex.
- ⚠️ **Ротация лога** — не сделана. 2 МБ/год, можно не трогать, но зафиксировать.
+**Симптом:** `sensor.t610_t610_ram_total` вместо `sensor.t610_ram_total`.
+**Причина:** HA строит `entity_id` как `<device.name> + "_" + <entity.name>`.
+Device — `t610`, имя сущности в первой редакции было `t610 RAM total` → склейка дала двойной префикс.
+**Почему не исправлено:** после первого создания `entity_id` зафиксировался в реестре,
+а **любая** операция `entity_registry/update` / `/remove` с этими сущностями отбивается
+`id_reuse: Identifier values have to increase` (питфолл 84).
+
+**Что пробовалось (всё безрезультатно):**
+1. Промежуточное имя `sensor.zz_tmp_*` → `id_reuse`.
+2. `name_by_user` через `config/entity_registry/update` с полем `name` → прошло **1 из 11**, остальные `id_reuse`.
+3. Удаление device из реестра → `id_reuse`.
+4. Смена `unique_id` (`t610_*` → `t610hw_*`) + сброс discovery-топиков → HA создал сущности **заново**, но `entity_id` всё равно двойной (уже с `name` = `t610 RAM total`).
+5. Убирание `object_id`, латиница в `device.name` → **не помогло** (создались `sensor.t610_t610_*`).
+6. Рестарт HA Core (`POST /api/services/homeassistant/restart`) → блокировка переживает рестарт.
+
+**Оценка влияния:** в **UI всё корректно** — показывается `t610 RAM total` (`friendly_name`),
+дашборд и зона работают. Страдают только автоматизации/шаблоны, где пишется полный `entity_id`.
+
+**Возможный фикс (не применён, ждёт решения Alex):** сменить `unique_id` ещё раз
+(например на `t610hwm_*`) **вместе** с именем сущности без префикса (`name: "RAM total"`),
+предварительно очистив retained-топики, — тогда HA создаст сущности с нуля и `entity_id`
+выйдет `sensor.t610_ram_total`.

 ---

-## 9. Связанные
+## 9. Что осталось
+
+- ⚠️ **`entity_id` с двойным префиксом** (§8) — ждёт решения Alex.
+- ⚠️ **Зона/дашборд для 11 датчиков** — `area_id` не назначен. ⚠️ **Назначить через реестр нельзя** (`id_reuse`, питфолл 84) → делать карточку на дашборд через `entity_id`, либо зону на **device** (`config/device_registry/update`) — не проверено.
+- ⚠️ **Коммит ПОСЛЕ** в `~/Automation/HA-ZONT-Modbus` — ждёт проверки Alex'ом. Закоммичен только «коммит ДО»: `12ba22b` «Sync configuration.yaml from t610 prod (kitchen hood fan template)».
+- ⚠️ **Легаси-файлы** `/usr/local/bin/ha_hw_metrics.sh` и `/etc/ha_hw_metrics.env` — рабочие, но аддон их заменяет. Снести по команде Alex.
+- ⚠️ **Ротация лога** не сделана: ~2 МБ/год, можно не трогать, но зафиксировать.
+- ⚠️ **`configuration.yaml` НЕ менялся** — блок `mqtt:` не добавлялся, интеграция `mqtt` уже была.
+  Бэкап на t610 сделан вхолостую: `/config/configuration.yaml.bak-hwmetrics-20260917-132251`.
+
+---
+
+## 10. Побочный факт: `MemTotal` пойман как ступенька
+
+Во время проверки (2026-09-17, ~13:11) снято с живого хоста: **`MemTotal = 3 470 776 kB` = 3.31 ГБ**,
+аптайм **6 минут** — то есть хост только что перезагрузился, и память поднялась **полным объёмом**.
+
+> Это **подтверждение уже описанного** в [[family/tech/t610-hang-investigation]] механизма
+> «ступенька между загрузками» (§3.1.2: два слота → ступенчатое падение объёма;
+> §5.1 п.2: «если `MemTotal` меняется между загрузками → планка/слот нестабильны»),
+> а **не** новое открытие. Раньше в доке был «живой факт 1.44 ГБ» — теперь есть точка 3.31 ГБ.
+> ✅ **Это ровно тот тип данных, который теперь фиксирует аддон** — то, ради чего задача и делалась.
+> Причину того ребута не выясняли.
+
+---
+
+## 11. Связанные

 - [[family/how-to/home-automation]] — контур автоматизации, §3.5 (ограничения `core_ssh`), §3.9 (память)
 - [[family/tech/t610-hang-investigation]] — расследование зависаний, §2 (почему журнал не переживает), §7.3 (эта задача)