[2026-09-17] eagle: family/how-to/home-automation.md family/how-to/zont-config-compiler.md family/tech/local-ustreamer-addon.md family/tech/t610-hang-investigation.md family/tech/t610-hw-metrics-addon.md family/tech/zont-config-object-types.md family/tech/zont-scenario-logic-11109.md

family/tech/local-ustreamer-addon.md

@@ -273,7 +273,11 @@ CPU: 45% io · I/O pressure some 38% / full 25.7% · load 3.26–3.63 при 2
 Swap: 518 МБ из 1 ГБ, zswap 354 МБ · journald "Under memory pressure" ×5
 MemTotal: 1 475 788 kB (1.44 ГБ)
 ```
-> ⚠️ **ОТКРЫТО:** на плате физически, по словам Alex, **4 ГБ**, а ядро видит **1.44 ГБ** (`MemTotal`). Из аддона проверить нельзя (нет доступа к `/sys/firmware/dmi`, `dmidecode`, `docker stats`). Разобраться отдельной задачей: BIOS `memory remap`, плохо вставленная планка, ограничение BIOS. Пока это не решено — хост будет свопить на HDD 5400 rpm.
+> ⚠️ **ОТКРЫТО (контекст на 2026-09-15):** на плате физически, по словам Alex, **4 ГБ**, а ядро видело **1.44 ГБ** (`MemTotal`). Из аддона проверить нельзя (нет доступа к `/sys/firmware/dmi`, `dmidecode`, `docker stats`).
+>
+> 🔄 **ОБНОВЛЕНО 2026-09-17:** на живом хосте `MemTotal` = **3 470 776 kB = 3.31 ГБ** после перезагрузки (аптайм 6 мин). То есть объём **меняется между загрузками** — 1.44 ↔ 3.31 ГБ. Это **не** «BIOS memory remap» и не «плохо вставленная планка» как отдельная поломка, а **ступенчатый отвал**: два слота → падение ступенькой. Полный разбор: **[[family/tech/t610-hang-investigation]] §3.1.0, §3.1.2, §5.1**.
+> ✅ **Мониторинг этого заведён** — `sensor.t610_ram_total` в HA + строка на диск каждые 60 с, [[family/tech/t610-hw-metrics-addon]]. Следующий отвал будет виден фактом, а не догадкой.
+> ⚠️ Хост при 1.44 ГБ свопит на HDD 5400 rpm — это остаётся верным.
 
 ---
 
@@ -330,7 +334,7 @@ done
 | `core_configurator` (File editor) | **УДАЛЁН** (`uninstall`) | веб-редактор `/config`; не используется, а **долбил HA каждые 30 с** (`GET /`, `502 Bad Gateway`) → цикл ретраев + лог на диск = лишний I/O |
 | `a0d7b954_nodered` | **остановлен** (`stop`), не удалён | жирный процесс на 1.4 ГБ RAM; для камеры не нужен. Судьба (удалить / оставить) — за Alex |
 
-**Итоговый список аддонов (7):** `core_ssh`, `core_mosquitto`, `a0d7b954_nodered` (**stopped**), `45df7312_zigbee2mqtt`, `local_mbusd`, `local_modbus-bridge`, `local_ustreamer`.
+**Итоговый список аддонов (8, на 2026-09-17):** `core_ssh`, `core_mosquitto`, `a0d7b954_nodered` (**stopped**), `45df7312_zigbee2mqtt`, `local_mbusd`, `local_modbus-bridge`, `local_ustreamer`, **`local_hw_metrics`** (метрики хоста — [[family/tech/t610-hw-metrics-addon]]).
 
 > ⚠️ **`core_configurator` пишет `GET /` каждые 30 секунд** и логирует каждый запрос — на слабом хосте это заметная постоянная нагрузка. Держать его «на всякий случай» не стоит, если файлы правятся по SSH.
 > 💡 **Диагностический признак:** аддон в состоянии `error` + `Service exited with code 256 (by signal 15)` в логе = остановлен нормально, а `error` — финальный статус. Проверять лог, а не только `state`.

family/tech/t610-hang-investigation.md

@@ -8,6 +8,9 @@ updated: 2026-09-17b
 # 🔴 t610 — зависания: состояние расследования
 
 > **Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА.** BIOS **прошит до K30 v01.20** (2026-09-17) — следующий замер памяти покажет, помогло ли.
+> ✅ **2026-09-17: следы больше не теряются** — заведён сбор метрик аддоном `local_hw_metrics`:
+> 11 датчиков в HA + строка на диск со `sync` каждые 60 с → **[[family/tech/t610-hw-metrics-addon]]**.
+> Каждый следующий инцидент оставит данные за последнюю минуту жизни хоста.
 > **Три кандидата:** (A) 🔴 **память** — стоит 4 ГБ, оба слота заняты, видно 1.44 ГБ
 > (§3.1.0) + 🔑 **UMA Frame Buffer в BIOS** как документированный механизм потери (§3.1.3)
 > + 🔑 **батарейка CMOS** (§3.1.4) · (B) деградация носителя → SQLite disk I/O (§5).
@@ -109,6 +112,21 @@ Alex перезапустил t610 вручную (сброс питанием)
 
 ### 3.1. Хост видит **1.44 ГБ**, не 3.31 ГБ — расхождение с докой
 
+> 🔄 **ПОДТВЕРЖДЕНО КОЛЕБАНИЕ ОБЪЁМА (2026-09-17, позже в тот же день).**
+> Снято с живого хоста после очередной перезагрузки (аптайм 6 мин):
+> ```
+> MemTotal:  3 470 776 kB  ← 3.31 ГБ
+> MemFree:   1 472 856 kB
+> MemAvailable: 2 582 092 kB
+> temp1_input: 60875 (60.9 °C)
+> ```
+> **То есть `MemTotal` МЕНЯЕТСЯ МЕЖДУ ЗАГРУЗКАМИ: 1.44 ГБ ↔ 3.31 ГБ.** Это ровно тот
+> «прямой признак нестабильности планки/слота», который был предсказан в **§3.1.1** ниже.
+> **Не два разных дефекта, а один: ступенчатый отвал объёма.** Подтверждает §3.1.0 и §3.1.2.
+> ✅ **Мониторинг заведён** — `sensor.t610_ram_total` + лог на диск каждые 60 с:
+> **[[family/tech/t610-hw-metrics-addon]]**. Следующий отвал будет виден фактом.
+> ⚠️ **Причину этой перезагрузки (13:05) я не выяснял** — отдельная задача.
+
 ```
 MemTotal:     1475788 kB   ← 1.44 ГБ  ← ЖИВОЙ ФАКТ 2026-09-17
 MemFree:        18620 kB   ← 18 МБ
@@ -484,6 +502,7 @@ ssh root@192.168.2.176 'smartctl -t long /dev/sda'   # затем -l selftest
    `MemTotal`/`MemAvailable`/`MemFree`, load, `pressure/io`+`pressure/memory`, `k10temp`,
    размер БД+WAL, аптайм. **Это то, что даст версию к следующему зависанию** — сейчас каждый
    инцидент стирает свои следы (§2).
+   > ✅ **СДЕЛАНО 2026-09-17** — но путь другой: **`/share`**, а не `/mnt/data` (последнего на t610 **не существует**). Реализовано локальным аддоном `local_hw_metrics`: 11 датчиков в HA через `POST /api/states/` + строка в `/share/ha-metrics/hw-YYYY-MM.log` со `sync`. Список: **[[family/tech/t610-hw-metrics-addon]]**. Ложный путь `/mnt/data` исправлен (питфолл 77).
 4. **`recorder:` с `exclude`** — исключить `sensor.*_summary`, `at2_*_summary`, `update.*`,
    `button.*_identify`, `event.*`. Снижает нагрузку на БД. **Не «фикс зависания»** — отдельное улучшение.
 5. **Включить watchdog `local_ustreamer`** — единственный аддон без watchdog (§3.7 родительской доки).

family/tech/t610-hw-metrics-addon.md

@@ -0,0 +1,173 @@
+---
+aliases:
+  - t610 metrics
+  - hw_metrics addon
+  - метрики t610
+  - RAM температура датчики HA
+  - лог переживающий зависание
+created: '2026-09-17'
+namespace: family
+related:
+  - '[[family/how-to/home-automation]]'
+  - '[[family/tech/t610-hang-investigation]]'
+  - '[[family/tech/local-ustreamer-addon]]'
+tags:
+  - family
+  - tech
+  - smarthome
+  - t610
+  - monitoring
+title: "\U0001F4CA t610 — метрики хоста (RAM, температура) + лог, переживающий зависание"
+type: tech
+updated: '2026-09-17'
+---
+# 📊 t610 — метрики хоста (RAM, температура) + лог, переживающий зависание
+
+> **Статус: ✅ ВНЕДРЕНО И РАБОТАЕТ (2026-09-17).** Локальный аддон `local_hw_metrics`, интервал 60 с.
+> Ждёт живой проверки Alex'ом (коммит ПОСЛЕ — после неё).
+> Родительские доки: [[family/how-to/home-automation]] · расследование зависаний — [[family/tech/t610-hang-investigation]]
+
+---
+
+## 1. Зачем
+
+Две задачи, поставленные Alex 2026-09-17:
+
+1. **Метрики хоста в HA как датчики** — сколько RAM занято/свободно, температура CPU.
+2. **Лог, который переживает зависание.** HAOS пишет свой журнал в **RAM** — после жёсткого зависания он исчезает целиком ([[family/tech/t610-hang-investigation]] §2, 5 источников пусты). Каждый инцидент стирал свои доказательства. Нужно было, чтобы следующий случай оставил следы.
+
+---
+
+## 2. Архитектура
+
+```
+аддон local_hw_metrics (alpine, bash, loop)
+   │  каждые 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)
+   └─ дописывает строку в /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`).
+
+**Почему 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:`).
+
+---
+
+## 3. Файлы
+
+| Что | Где |
+|---|---|
+| Аддон | `/addons/hw_metrics/` на t610 — `config.yaml`, `Dockerfile`, `metrics.sh` (chmod 600) |
+| Исходники на 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) попытки, не используется |
+| Скрипт на хосте (легаси) | `/usr/local/bin/ha_hw_metrics.sh` — v2 (REST). Рабочий, но аддон его заменяет |
+
+**Версия токена:** `ha_token` лежит **в опциях аддона** (`/data/options.json` внутри контейнера), `tokenlen=183`. Env-файл `/etc/ha_hw_metrics.env` — не нужен, оставлен как след первой попытки.
+
+---
+
+## 4. Датчики (11)
+
+| 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 |
+
+⚠️ **`ram_used` = `MemTotal − MemAvailable`, НЕ `MemFree`** — питфоллы 44/45: `MemFree` падает из-за файлового кэша и врёт про «занято».
+
+> ⚠️ **Датчики из REST — `restore_state`-типа.** Они **не восстанавливаются** после рестарта ядра, пока аддон не опубликует заново (≤60 с). Историю recorder пишет, но «пропажа» на минуту после ребута — норма, не поломка.
+> ⚠️ **Зона/дашборд не назначены.** Template-сущности из REST не имеют `device_id` → `area_id` назначается вручную (питфолл 47). Не сделано.
+
+---
+
+## 5. Формат строки лога
+
+CSV, 17 полей, без заголовка:
+
+```
+ISO_UTC, MemTotal, MemAvailable, MemFree, Cached, SwapTotal, SwapFree,
+load1, load5, load15, pressure_io, pressure_mem, temp_mC, uptime_s,
+db_kB, wal_kB, RC
+```
+
+Последнее поле `RC` — код ошибки публикации: `0` = все 11 сенсоров отдались, `1` = что-то не прошло (детали в логе аддона).
+
+Объём: 1 строка ≈ 117 байт × 1440/сутки ≈ **165 КБ/мес**. За год ~2 МБ.
+
+---
+
+## 6. Команды
+
+```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}"'
+
+# лог аддона
+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'
+
+# пересборка после правки metrics.sh (ОБЯЗАТЕЛЬНА — скрипт впекается в образ)
+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'
+
+# удалить датчик (если понадобится)
+curl -s -X DELETE -H @/tmp/h1 "$B/api/states/sensor.t610_ram_used"
+```
+
+---
+
+## 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 и умирает вместе с хостом | Именно это делает лог «переживающим зависание». Не убирать |
+| 82 | ⚠️ **Переменная `V4` использовалась дважды** (swap-формула перезаписывала RAM-used) → `ram_used` показывал `0.0` | Проверять значения датчиков **против хостовых** (`head -3 /proc/meminfo`), а не только «сущность создалась» |
+
+---
+
+## 8. Что осталось
+
+- ⚠️ **Живая проверка Alex'ом** — коммит ПОСЛЕ не сделан, ждёт.
+- ⚠️ **Зона/дашборд для 11 датчиков** не назначены (`area_id` = null, питфолл 47).
+- ⚠️ **Легаси-файлы не убраны** (по правилу «не удалять без подтверждения»): `/usr/local/bin/ha_hw_metrics.sh` и `/etc/ha_hw_metrics.env` — рабочие, но аддон их заменяет. Снести по команде Alex.
+- ⚠️ **Ротация лога** — не сделана. 2 МБ/год, можно не трогать, но зафиксировать.
+
+---
+
+## 9. Связанные
+
+- [[family/how-to/home-automation]] — контур автоматизации, §3.5 (ограничения `core_ssh`), §3.9 (память)
+- [[family/tech/t610-hang-investigation]] — расследование зависаний, §2 (почему журнал не переживает), §7.3 (эта задача)
+- [[family/tech/local-ustreamer-addon]] — образец локального аддона

family/tech/zont-config-object-types.md

@@ -16,7 +16,7 @@ tags:
   - reference
 title: "\U0001F9E9 ZONT Config — типы объектов"
 type: reference
-updated: '2026-09-17b'
+updated: '2026-09-17c'
 ---
 
 # 🧩 ZONT Config — типы объектов
@@ -24,7 +24,7 @@ updated: '2026-09-17b'
 > Справочник по типам объектов конфига ZONT (первое поле в `#Z<id>=<type>,…`).
 > **Инструкция по конвертерам:** [[family/how-to/zont-config-compiler]]
 > **Источник:** код `config-to-yml.py` / `yml-to-config.py` в `/Users/admin/Automation/HA-ZONT-Modbus`; инструкция по запуску — [[family/how-to/zont-config-compiler]].
-> ✅ Таблица сверена с кодом (2026-09-17): перечислены **все 25 обрабатываемых типов**, включая `0` и `36`, которых нет в `README_converters.md` (там 23).
+> ✅ Таблица сверена с кодом (2026-09-17): перечислены **все 26 обрабатываемых типов**, включая `0`, `36` и `45`, которых нет в `README_converters.md` (там 23).
 > 🔴 Для каждого типа указаны только те поля, которые скрипт **реально декодирует**; остальное лежит в `raw` / `raw_params` и при сборке пишется как есть. Ссылка вроде «README → поле X» не должна вводить в заблуждение: если поля нет в таблице, оно не декодировано.
 
 ---
@@ -52,9 +52,9 @@ updated: '2026-09-17b'
 | 28 | Таблицы сопротивлений | *(raw)* | `resistance_tables` |
 | **36** | Конфиги дискретных датчиков (вытащены из вложенной структуры типа 0) | `raw` | вложено в `discrete_sensors[].config` |
 | 42 | GUI-вкладки | `name` | `gui_tabs` |
-| **45** | 🔴 **Задержка-объект (пауза в мс) в списке действий шага** — `[45, ms]`. **Конвертером НЕ поддержан** | *ничего — объекта нет в YAML* | **нет секции** — теряется |
-| 46 | Шаги сценариев | `[46, prio, cond_id, [action_ids], []]` — 5 полей | внутри `scenarios` |
-| 49 | Условия сценариев | *(raw; помечаются как уже разобранные)* | внутри `scenarios` |
+| **45** | Задержка-объект (пауза в мс) в списке действий шага — `[45, ms]` | `ms` | `delays` |
+| 46 | Шаги сценариев | `[46, prio, cond_id, [action_ids], []]` — 5 полей | `scenario_steps` |
+| 49 | Условия сценариев | `relay_id`, `operator`, `value` | `scenario_conditions` |
 | 51 | Modbus-устройства | `slave_id`, `name`, `poll_interval`, `timeout`, `registers`, `raw_params` | `modbus_devices` |
 | 52 | Modbus-регистры | `name`, `register`, `bit_width`, `repeat_period`, `num_vars`, `raw_params` | **вложены в своё устройство 51** |
 | 53 | Аналоговые выходы | `name`, `min`, `max`, `value`, `offset`, `scale`, `flags`, `address` | `analog_outputs` |
@@ -90,14 +90,16 @@ Modbus-регистры (тип 52) в конфиге — **отдельные
 
 ### 2.3. Сценарии (11 + 46 + 49 + 45)
 
-Тип 11 парсится **целиком** — `when` (условия) и `do` (действия) собираются в человекочитаемый вид, включая шаги (46) и условия (49). Сами 46/49 при разборе помечаются как «уже вложенные» — в YAML отдельными секциями их нет.
+Тип 11 парсится **целиком** — из него собирается `steps[]` (шаги 46 со своими условиями 49), включая многошаговые сценарии и много действий в шаге. Шаги и условия выводятся отдельными секциями YAML `scenario_steps` / `scenario_conditions`, задержки — `delays`.
 
 Полная структура, формат полей и разобранный боевой кейс — [[family/tech/zont-scenario-logic-11109]].
 
-🔴 **Жёсткие лимиты конвертера (найдено 2026-09-17)** — падение с exit 2 на первом же невыразимом объекте:
-- `config-to-yml.py:473` — сценарий ровно с **1 шагом** (`len(steps) == 1`). 2-й шаг = падение.
-- `config-to-yml.py:489` — шаг ровно с **1 действием** (`len(actions) == 1`). 2+ действий = падение.
-- Тип **45** не обрабатывается вообще → объект молча теряется при round-trip.
+✅ **Лимиты сняты 2026-09-17** (были жёсткие ограничения, падал с exit 2 на первом невыразимом объекте):
+- ~~`config-to-yml.py:473` — сценарий ровно с 1 шагом~~ → теперь цикл по всем шагам
+- ~~`config-to-yml.py:489` — шаг ровно с 1 действием~~ → теперь весь список действий
+- ~~Тип **45** не обрабатывается~~ → парсер + эмиттер, секция `delays`
+
+Подробности правки — [[family/how-to/zont-config-compiler]] §5b.
 
 **Действие в шаге может быть объектом трёх типов:** `5` (действие над выходом, 11 полей), `9` (команда реле, 4 поля, `value` — **строка** `'1'`/`'0'`), `45` (пауза в мс, 2 поля).
 

family/tech/zont-scenario-logic-11109.md

@@ -135,8 +135,19 @@ updated: '2026-09-17'
 
 ---
 
-## 5. Связанные заметки
+## 5. Статус разбора конвертером
 
-- [[family/how-to/zont-config-compiler]] — конвертеры `.txt ⇄ .yml`, план доработки под 2 шага и тип 45
+| Что | Статус |
+|---|---|
+| Многошаговый сценарий (`[11827,11828]`) | ✅ разбирается с 2026-09-17 |
+| 7 действий в шаге `11827` | ✅ разбирается с 2026-09-17 |
+| Тип 45 (4 объекта) | ✅ парсер + эмиттер, секция YAML `delays` |
+| Сценарий `enabled=0` | ℹ️ факт, не баг конвертера — решается на этапе 2 (правка YAML) |
+
+---
+
+## 6. Связанные заметки
+
+- [[family/how-to/zont-config-compiler]] — конвертеры `.txt ⇄ .yml`; 2 шага и тип 45 **поддержаны с 2026-09-17** (§5b)
 - [[family/tech/zont-config-object-types]] — полная таблица типов объектов и `#S`-настройки
 - [[family/how-to/home-automation]] — контур автоматизации, ZONT, Modbus slave ID и регистры