[2026-09-17] eagle: family/how-to/home-automation.md family/tech/t610-hang-investigation.md

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-17
+updated: 2026-09-17b
 ---
 
 # 🏠 Домашняя автоматизация
@@ -336,12 +336,16 @@ Z2M **остановлен** с 2026-09-15 (стик отдан ZHA), данны
 
 > 🔴🔴 **ОБНОВЛЕНО 2026-09-17 — ЦИФРЫ НЕ СХОДЯТСЯ. Живой хост отдаёт `MemTotal: 1 475 788 kB` = 1.44 ГБ.**
 > Это **НЕ** 3.31 ГБ из таблицы ниже и **не** объясняется округлением.
-> **`e820` 2026-09-17 обрывается на `0x5e7fffff` ≈ 1.48 ГБ — выше памяти физически нет.**
+> **`e820` 2026-09-17 обрывается на `0x5e7fffff` ≈ 1.48 ГБ — выше этой границы памяти нет.**
-> ⛔ Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» **снята фактом** — вырезать нечего.
+> 🔴 **Физически установлено 4 ГБ, оба слота ЗАНЯТЫ** (`DMI: Memory slots populated: 2/2`),
+> а поднимается только 1.44 ГБ. **Потеряно ~2.5 ГБ — ГЛАВНАЯ НЕРЕШЁННАЯ ПРОБЛЕМА.**
+> ⛔ Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» **снята** — масштаб не тот (iGPU берёт
+> фиксированный фреймбуфер в сотни МБ, а не 2.5 ГБ).
 > Разбор, версии и способ проверки (BIOS F10, планки по одной, контакты, memtest86+ с USB):
-> **[[family/tech/t610-hang-investigation]] §3.1, §3.1.1, §3.1.2, §5.1.**
+> **[[family/tech/t610-hang-investigation]] §3.1.0, §3.1.1, §3.1.2, §5.1.**
 > ⚠️ **ПЕРЕМЕРЯТЬ `head -3 /proc/meminfo` + `dmesg | grep e820` при КАЖДОМ разборе инцидента**,
-> не доверять записанному. `dmidecode` на t610 **НЕТ** — число планок только из BIOS setup.
+> не доверять записанному. `dmidecode` на t610 **НЕТ** — заполненность слотов даёт
+> `dmesg | grep "Memory slots"`, объём каждой планки — только BIOS setup.
 
 ```
 MemTotal:     3 470 792 kB = 3.31 ГиБ   ← столько видит ядро (замер 2026-09-15)
@@ -361,9 +365,7 @@ HA core:      ~700 МБ (лимит 3.55 ГБ)
 ```
 
 > 🔴 **ПИТФОЛЛ: НЕ читать `MemFree` как «сколько памяти всего» или «сколько занято».** `MemFree` падает при заполнении файлового кэша (Cached 2.3 ГБ) и в I/O-шторме (наблюдали `MemFree 16 МБ`). Верные метрики — **`MemTotal`** (сколько всего) и **`MemAvailable`** (сколько реально доступно).
-> 🔴 **Версия «система видит 1.44 ГБ вместо 4» — ОШИБОЧНА.** Такая цифра получалась из неверного чтения (`MemFree` в шторме / лимит контейнера), а не из реального объёма. Проверять: `head -3 /proc/meminfo`.
+> 🔴🔴 **ОТМЕНЕНО 2026-09-17.** Ранее здесь было записано: «версия „система видит 1.44 ГБ вместо 4“ — ОШИБОЧНА». **Это опровергнуто живым замером:** `MemTotal` = **1.44 ГБ**, при физически установленных 4 ГБ и **двух занятых слотах** (`DMI: Memory slots populated: 2/2`). Разница «3.31 → 1.44» **реальна** и не объясняется округлением. См. врезку выше и [[family/tech/t610-hang-investigation]] §3.1.0.
-> 🔴 **НО (2026-09-17): живой `MemTotal` = 1.44 ГБ — это УЖЕ другой разговор, не округление.**
-> `MemFree` остаётся верной метрикой «занято», но `MemTotal` надо перемерять — см. врезку выше.
 > 📌 Полный e820-маппинг: `dmesg | grep -iE "e820|BIOS-provided"`.
 
 ### 3.4. 🔴 Носитель sda — HDD, и как НЕ измерить его нагрузку
@@ -787,7 +789,7 @@ 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
 | 41 | 🔴 **`sensor.*_summary` показывает мусор вида `1692° 780ppm`, но датчик под ним исправен** | Смотреть **сырые** `sensor.<room>_temperature`/`_co2`, не шаблонную сводку. Сводка склеивает атрибуты своим шаблоном — её кривизна не означает поломку датчика. См. §9 |
 | 42 | ⚠️ **Живой конфиг сниффа — НЕ в `/addons/modbus-bridge/config.yaml`** | `config.yaml` = только опции аддона (device/baud). Регистры и коррекции — в `data/config.template.tmpl` → `run.sh` рендерит из него `/app/config.yml` при старте |
 | 44 | 🔴 **`MemFree` читают как «сколько памяти всего/занято»** | Верные метрики: **`MemTotal`** (всего) и **`MemAvailable`** (доступно). `MemFree` падает из-за файлового кэша (Cached 2.3 ГБ) и в I/O-шторме. См. §3.9 |
-| 45 | 🔴 **«BIOS 4096 МБ → HA видит 1.44 ГБ»** — ложная тревога | Реально usable **3.31 ГБ** (минус ~800 МБ ACPI NVS/data + reserved + iGPU). Проверять `head -3 /proc/meminfo` + `dmesg \| grep e820`. См. §3.9 |
+| 45 | 🔴🔴 **«BIOS 4096 МБ → HA видит 1.44 ГБ» — БЫЛА названа «ложной тревогой», ОТМЕНЕНО 2026-09-17** | ⛔ Прежний вывод («реально usable 3.31 ГБ») **опровергнут живым замером**: ядро отдаёт `MemTotal: 1 475 788 kB` = **1.44 ГБ**, e820 обрывается на `0x5e7fffff`. При этом **физически стоит 4 ГБ, оба слота заняты** (`DMI: Memory slots populated: 2/2`). **Потеряно ~2.5 ГБ — не объяснено.** Разбор: [[family/tech/t610-hang-investigation]] §3.1.0 |
 | 46 | 🔴 **Создал сущность → «в UI её нет»** | Проверять **4** вещи: (1) `/api/states/<e>` отвечает, (2) `area_id` ≠ `null` в реестре, (3) диагностика устройства скрыта, (4) дашборды не ссылаются на мёртвые сущности. Разбор — [[family/tech/kitchen-hood-fan-template]] §6.1 |
 | 47 | 🔴 **Template-сущность из YAML не получает `area_id`** | У неё нет `device_id` → зону назначать вручную WS `config/entity_registry/update` с `area_id`. Иначе «невидима» на дашбордах зон |
 | 48 | 🔴 **`hidden_by: user` НЕ убирает сущность из storage-дашбордов и `area_entities()`** | Это два независимых механизма. Ссылки в `/config/.storage/lovelace.*` вписаны руками — править их отдельно (`jq`). Реально «выключить» — только `disabled_by` |

family/tech/t610-hang-investigation.md

@@ -7,12 +7,18 @@ updated: 2026-09-17
 
 # 🔴 t610 — зависания: состояние расследования
 
-> **Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА. Главный кандидат — деградация носителя (§5).**
+> **Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА.**
+> **Два кандидата:** (A) 🔴 **память** — стоит 4 ГБ, оба слота заняты, видно 1.44 ГБ
+> (§3.1.0) · (B) деградация носителя → SQLite disk I/O (§5).
 > Сессия 2026-09-17. Ниже — что проверено фактом, что опровергнуто, и что осталось.
 > Родительская дока: [[family/how-to/home-automation]] · §3.1 (RCU stall, закрыто), §3.5 (ограничения аддона), §3.9 (память).
 >
-> ⚡ **Читать в этом порядке:** §1 факты момента смерти → §2 логи недоступны → §4 что опровергнуто
+> ⚡ **Читать в этом порядке:** §1.0 формулировка задачи → §1 факты момента смерти →
-> (**не повторять**) → §5 главный кандидат + как проверить → §7 предложение (ждёт апрува).
+> §2 логи недоступны → §3.1.0 главный факт про память → §4 что опровергнуто
+> (**не повторять**) → §5 кандидаты + как проверить → §7 предложение (ждёт апрува).
+>
+> 🔴 **Alex прямо указал:** разгадка, скорее всего, **в памяти**, а логи ничего не дадут
+> (их и нет — §2). Приоритет проверок: **BIOS/планки (§5.1)** наравне с SMART (§5.2).
 
 ---
 
@@ -21,6 +27,44 @@ updated: 2026-09-17
 Alex перезапустил t610 вручную (сброс питанием) **2026-09-17 ~09:38 +07**.
 Хост поднялся заново; HA Core стартовал ~09:41–09:43.
 
+### 1.0. 📋 ФОРМУЛИРОВКА ЗАДАЧИ (согласованная формулировка сессии)
+
+> Alex несколько раз требовал переписать формулировку — без ссылок на доки, только
+> описание проблемы и симптомов. Ниже — финальный вариант. **Держать его в голове
+> при любой новой сессии по этой теме.**
+
+**Задача:** HP t610 работает как хост Home Assistant OS. Периодически зависает
+насмерть — хост перестаёт отвечать, помогает только отключение питания.
+
+**Оборудование:**
+- HP t610 (тонкий клиент), AMD G-T56N, 2 ядра
+- Память: **4 ГБ**, два слота SO-DIMM, **оба заняты**
+- Носитель: HDD WDC WD2500BEVT, 250 ГБ, 5400 rpm
+- ОС: Home Assistant OS 18.2, HA Core 2026.9.2
+- USB: Zigbee-стик, два CH340 (шина вентиляции, шина ZONT), веб-камера
+- Аддонов 7, из них запущены 5
+
+**Симптомы:**
+1. Хост перестаёт отвечать по сети и в вебе. Помогает только отключение питания.
+2. Перед зависанием **журнал обрывается** — последняя запись в БД 07:29, активность SQLite 07:31.
+3. База **не закрывается чисто** — при старте сообщение, что корректное завершение SQLite не подтверждено.
+4. **Логов прошлой загрузки не существует** — HAOS пишет журнал в RAM, после зависания он теряется целиком.
+5. **Память деградировала.** Раньше система видела **3.31 ГБ**, сейчас **1.44 ГБ**. Потеря **~1.9 ГБ**. Когда — неизвестно.
+6. При этом ядро сообщает, что **заняты оба слота**, и физически стоит 4 ГБ — то есть планки на месте, но поднимаются не полностью.
+7. Карта памяти от BIOS обрывается на 1.44 ГБ — выше этой границы памяти нет.
+8. Свободной памяти почти нет: 16–18 МБ при ~1 ГБ в файловом кэше. Swap 1 ГБ не используется.
+9. Зависания повторяются.
+
+**Что неизвестно:**
+- Когда и почему пропали 1.9 ГБ — планка деградировала, отходит контакт, несовместима, BIOS не поднимает.
+- Связана ли потеря памяти с зависаниями, или это два независимых дефекта.
+- Что именно приводит к зависанию.
+
+**Ограничение диагностики:** после зависания следов не остаётся — журнал в RAM, метрик
+на момент смерти нет. Каждый следующий случай стирает свои доказательства.
+
+---
+
 **Факты о моменте смерти (из читаемого после ребута):**
 
 | Наблюдение | Значение | Откуда |
@@ -88,11 +132,13 @@ BIOS-e820: [mem 0x000000005e7f4000-0x000000005e7fffff] usable   ← ПОСЛЕД
 > **Верхняя граница памяти = `0x5e7fffff` ≈ 1.48 ГБ. Выше — ничего.**
 >
 > **Что это доказывает:** если бы стояла планка 2 ГБ и её часть забирал iGPU/UMA,
-> e820 уходил бы за `0x80000000` (2 ГБ). Он обрывается ровно на 1.48 ГБ →
+> e820 уходил бы за `0x80000000` (2 ГБ). Он обрывается ровно на 1.48 ГБ → BIOS
-> **сейчас видна одна планка ~1.44 ГБ**, и никакой «вырезанной области» нет.
+> **отдаёт ядру только 1.48 ГБ**, хотя физически стоит 4 ГБ (§3.1.0).
 >
 > ⛔ **Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» — ОКОНЧАТЕЛЬНО СНЯТА** (см. §4).
 > Резерв ACPI NVS/data + reserved ≈ 30–40 МБ — это **норма**, не потеря.
+> ⚠️ **Но и «UMA вырезал 2.5 ГБ» — тоже не проходит:** iGPU у G-T56N берёт
+> фиксированный фреймбуфер (сотни МБ), а не 2.5 ГБ. Масштаб не тот.
 >
 > 🔑 **Следствие:** в BIOS на старте отдаётся 1.44 ГБ. Если после очередного
 > холодного сброса `MemTotal` изменится — это прямое доказательство нестабильности планки/слота.
@@ -104,7 +150,42 @@ ssh root@192.168.2.176 'dmesg | grep -iE "BIOS-provided|e820.*usable"'
 ```
 
 > ⚠️ **`dmidecode` на t610 НЕТ** (и `/sys/firmware/dmi/entries/17-*/raw` пуст) —
-> число планок этим путём не получить. Смотреть в **BIOS setup** (см. §5.1).
+> число планок и объём **каждой** этим путём не получить. Смотреть в **BIOS setup** (см. §5.1).
+
+### 3.1.0. 🔴 ГЛАВНЫЙ ФАКТ: оба слота ЗАНЯТЫ, а видно 1.44 ГБ — это НЕОБЪЯСНИМО
+
+Снято с живого хоста 2026-09-17 (только чтение):
+
+```
+[    0.000000] DMI: Memory slots populated: 2/2
+```
+
+> 🔴 **Ядро само сообщает: слотов 2, заняты ОБА.**
+>
+> Alex подтвердил: **физически установлено 4 ГБ.**
+>
+> Отсюда прямое противоречие, которое и есть суть проблемы:
+>
+> | Вводная | Значение |
+> |---|---|
+> | Физически установлено | **4 ГБ** (2 планки, оба слота заняты) |
+> | Видит ядро (`MemTotal`) | **1.44 ГБ** |
+> | Верх e820 | `0x5e7fffff` ≈ 1.48 ГБ |
+> | **ПОТЕРЯНО** | **~2.5 ГБ** |
+>
+> **Объём памяти не изменился физически — изменилось то, сколько из неё BIOS/ядро
+> поднимают.** Раньше система видела **3.31 ГБ**, теперь **1.44 ГБ** (§3.9 родительской доки).
+>
+> **Это и есть главная нерешённая проблема.** Не «сколько планок стоит» (ответ: две, обе
+> на месте), а **почему с 4 ГБ поднимается только 1.44**.
+>
+> ⛔ Версия «планка вынута» — **снята** (`2/2` из ядра).
+> ⛔ Версия «планки по 1 ГБ + 512 МБ, так и было» — **снята** (Alex: памяти 4 ГБ).
+
+**Что это меняет:** режим отказа — не «планка отвалилась и исчезла», а
+**одна/обе планки не поднимаются полностью либо недетектируются BIOS'ом**:
+контакт, несовместимость (x4 SDRAM), деградация модуля, сбой инициализации памяти в BIOS.
+Проверка — §5.1, **BIOS setup обязателен** (он покажет объём **каждого** слота).
 
 ### 3.1.2. 🧩 ЖЕЛЕЗО: HP t610 — 2 слота SO-DIMM, max 4 ГБ (сервис-мануал HP)
 
@@ -197,6 +278,8 @@ kids_summary / dining_summary / dining_air_summary / bedroom_summary
 | «Логи есть, надо просто посмотреть внимательнее» | Их **нет** физически (§2). Проверено 5 источников |
 | 🔴 «Бэкап-джоб (tar `home-assistant_v2.db`) вешает хост» | Alex: «такая операция по факту ничего не может убить». `tar czf` 77 МБ = секунды чтения + секунды gzip. Докин RCU stall (§3.6 родительской доки) был **непрерывным ffmpeg-ретранскодом**, а не разовой архивацией. **Разница принципиальная** |
 | ⚠️ Уточнение по бэкапу | `tar` собирается **НА t610** (`tar czf -` по ssh, stdout → `> OUT` уже на TrueNAS). Значит нагрузка — чтение + gzip **на слабом хосте**. Это уточнение, **не** причина |
+| «Планка вынута / одна из планок исчезла» | ⛔ **Снято фактом:** `DMI: Memory slots populated: 2/2` — оба слота заняты (§3.1.0) |
+| «Так всегда и было — планки по 1 ГБ + 512 МБ» | ⛔ **Снято:** Alex подтвердил 4 ГБ физически; раньше ядро видело 3.31 ГБ |
 
 > 📌 **Урок метода (для будущих сессий):** я трижды подряд выдал «версию», построенную
 > на одной цифре без проверки смежных фактов (template-сенсоры → swap/cache → UMA →
@@ -242,10 +325,16 @@ sqlalchemy.exc.InvalidRequestError: This session is in 'prepared' state
 
 ### 5.1. Как проверить память (BIOS + планки)
 
-1. **BIOS setup: `F10` при старте** → `System Information` / `Memory` — **точный объём и число планок**.
+> 🔑 **Точка входа — BIOS setup.** Он единственный покажет **объём КАЖДОГО слота**
-   Это ответ на «сколько ставит BIOS». Разводит «планка отваливается» от «дока устарела».
+> (`dmidecode` на t610 нет, §3.1.1). Разводит: одна планка не поднимается полностью,
+> обе частично, или сбой инициализации.
+
+1. **BIOS setup: `F10` при старте** → `System Information` / `Memory` — **точный объём и объём каждого слота**.
+   ⚠️ Ключевой вопрос: BIOS видит **4 ГБ** (значит теряется на этапе ядра/ACPI) или
+   тоже **1.44 ГБ** (значит BIOS сам не поднимает планки). **Ответ разводит два разных диагноза.**
 2. **`MemTotal` после холодного сброса** — если меняется между загрузками → планка/слот нестабильны (§3.1.1).
 3. **Планки по одной** — вынуть вторую, стартовать с первой, затем наоборот.
+   Смотреть, какой объём поднимает каждая **в одиночку**.
 4. **Контакты** — вынуть, протереть ластиком (HP: золочение обязательно; окисление — штатный отказ).
 5. **memtest86+** (`memtest.org`) — грузится с USB, понимает legacy BIOS **и** UEFI.
    ⚠️ **MemTest86 v11.7 (memtest86.com) — только UEFI**, на t610 **не загрузится**;
@@ -255,6 +344,8 @@ sqlalchemy.exc.InvalidRequestError: This session is in 'prepared' state
    один раз при загрузке через BIOS и не пересчитывается. «Дропнула память» на практике
    означает **зависла**, а не потеряла. Режим отказа — **нестабильная планка**: иногда
    не определяется с первого раза, иногда ребут, иногда зависон под нагрузкой.
+7. ⚠️ **Проверить thermal pad** — HP требует его на SO-DIMM в модели t610 (не PLUS).
+   Перегрев модуля — возможный спутник деградации.
 
 ### 5.2. Как проверить носитель (первый приоритет)
 
@@ -325,7 +416,7 @@ ssh root@192.168.2.176 'smartctl -t long /dev/sda'   # затем -l selftest
 | 55 | ⚠️ **`MemTotal` может расходиться с докой** — живой факт `1.44 ГБ` против зафиксированных `3.31 ГБ` (§3.9 родительской доки) | Всегда перемерять `head -3 /proc/meminfo` + e820 при разборе инцидента, не полагаться на записанное |
 | 56 | 🔴 **`http://192.168.2.176:8123` из LAN → `curl` exit 7, хоть хост жив** | Единственный путь к API — `https://mallexxx.duckdns.org`. Совпадает с питфоллом 1 |
 | 57 | ⚠️ **После холодного старта ZHA догружается**: часть сущностей минуты висит `unavailable` | Не спешить с выводом «устройства отвалились» — перемерить через 2–3 мин. Первый снимок дал 75 сущностей, полный — 310 |
-| 58 | 🔴 **`dmidecode` на t610 НЕТ**, `/sys/firmware/dmi/entries/17-*/raw` пуст | Число/объём планок — только **BIOS setup** (F10). `MemTotal` + e820 дают объём, но не число планок |
+| 58 | 🔴 **`dmidecode` на t610 НЕТ**, `/sys/firmware/dmi/entries/17-*/raw` пуст | Число планок — **`dmesg \| grep "Memory slots"`** → `DMI: Memory slots populated: 2/2` (⚠️ даёт **только заполненность**, не объём). Объём каждой планки — только **BIOS setup** (F10). `MemTotal` + e820 дают суммарный объём |
 | 59 | 🔴 **`dmesg` на t610 требует `\| tail`** — без хвоста врёт (питфолл 5 родительской доки, подтверждён) | Всегда `dmesg \| grep … \| tail` |
 | 60 | 🔴 **Порядок расследования: ФАКТЫ → версия, а не версия → проверка** | Три подряд опровергнутые «версии» (§4) съели сессию. Сначала e820/BIOS/SMART/метрики, потом формулировка |
 | 61 | ⚠️ **Симптом-матч с форума ≠ доказательство** | Тред `1025213` совпал по версии стека и симптомам, но это **кандидат**, не причина. Закрывать только фактом по §5.2 |