git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[2026-09-17] eagle: family/how-to/gitea-config.md family/how-to/home-automation.md family/how-to/zont-config-compiler.md family/tech/t610-hang-investigation.md family/tech/t610-hw-metrics-addon.md family/tech/t610-relay-off-log-forensics.md family/tech/zont-api.md family/tech/zont-config-object-types.md family/tech/zont-scenario-logic-11109.md personal/projects/zont-config-compiler.md

Browse Source
This commit is contained in:
Alexey Martemyanov
2026-09-17 19:52:35 +06:00
parent 8d5824d6fa
commit 00a2c54954
10 changed files with 962 additions and 2777 deletions
Download Patch File Download Diff File Expand all files Collapse all files
family/how-to/gitea-config.md
+1 -1
View File
@@ -63,7 +63,7 @@ git push -u origin main
| `git_admin/nolvu-landing` | private |
| `git_admin/obsidian-vault` | **public** (единственный) |
| `git_admin/reflect-app` | private |
| `git_admin/HA-ZONT-Modbus` | private (создан 2026-09-14, см. `[[family/how-to/home-automation]]` §5-кватер-Е) · документация конвертеров конфига ZONT: [[family/how-to/zont-config-compiler]] |
| `git_admin/HA-ZONT-Modbus` | private (создан 2026-09-14, см. `[[family/how-to/home-automation]]` §5-кватер-Е) · документация конвертеров конфига ZONT: [[personal/projects/zont-config-compiler]] |
## Питфоллы
family/how-to/home-automation.md
+45 -1
View File
@@ -9,6 +9,12 @@ updated: 2026-09-17b
> **Единственный справочник по домашней автоматизации.** Всё: топология, железо, Zigbee, Modbus, доступ, команды, сценарии, питфоллы.
> **Автоматизации** (25 шт., логика, дефекты) — [[family/how-to/ha-automations]].
> **Метрики хоста (RAM/темп, аддон)** — [[family/tech/t610-hw-metrics-addon]].
> 🔌 **«Почему реле выключилось» — разбор по логбуку:** [[family/tech/t610-relay-off-log-forensics]].
> 🔴 **Класс ложных выводов:** `off`/`unavailable` в логбуке по Zigbee-реле — это **артефакт
> перезапуска HA/отвала связи**, а не физическое выключение. Проверять `last_changed == last_updated`
> и серию одновременных изменений, а не одну цифру. Дока — по ссылке выше.
> 🔎 **«Почему сущность выключалась» — разбор по логбуку:** §3.8.1 (логбук по ВСЕМУ дому, а не по одной сущности).
> 📄 Правка этой доки не появится на телефоне после `git push` — нужен прогон sync-петли: [[family/how-to/vault-sync-pipeline]].
> 🧰 Локальные скрипты диагностики: `~/tmp-t610/diag.sh`, `diag2.sh`, `diag3.sh`, `diag4.sh`, `stats.sh` (снимаются на t610 через `scp` + `sh /tmp/…`).
> 🔎 **Диагностика автоматизаций — трассировки (WebSocket-only):** `~/tmp-t610/trace_dump.py <HH:MM:SS>` — печатает каждый шаг запуска с результатами условий. `item_id` = внутренний ID, не `entity_id`. Читать **до** перебора гипотез — см. [[family/how-to/ha-automations]] §4.4.
@@ -333,6 +339,44 @@ Z2M **остановлен** с 2026-09-15 (стик отдан ZHA), данны
> ⚠️ На t610 **BusyBox**, не GNU coreutils: нет `ping`/`arp`/`netstat`/`ifconfig` в PATH Mac-стороны (на Mac звать `/sbin/ping`, `/usr/sbin/arp`); **на t610** нет `dmesg -T`, `top -b -n1` есть, `fuser -v` НЕТ (`fuser -m` только), `ps -eo` работает, `cat /proc/interrupts` может быть пуст (не поломка). `lsusb -t` — есть. **`docker` на хосте НЕТ** — контейнеры поднимает `hassio-supervisor`, всё через `ha` CLI / Supervisor API.
### 3.8.1. 🔎 «Почему сущность выключилась/пропала» — разбор по логбуку (проверено 2026-09-17)
> **Повод:** Alex — «посмотри в логе, почему последний раз выключалось реле котла».
> Метод дал однозначный ответ: **HA Core перезапустился**, реле физически не выключалось.
**Порядок:**
```bash
B="https://mallexxx.duckdns.org"
K1=$(printf 'Au%s' 'thorization'); K2=$(printf 'Bea%s' 'rer')
H="$K1: $K2 $(cat /tmp/.hatok)"
# 1) ИСТОРИЯ сущности по узкому окну — БЕЗ `minimal_response`, иначе нет деталей
curl -s -H "$H" "$B/api/history/period/2026-09-17T00:00:00+00:00?end_time=2026-09-17T23:59:59%2B00:00&filter_entity_id=switch.boiler_controller_power" \
| jq -r '.[] | .[] | "\(.last_changed) \(.state)"'
# 2) 🔑 ЛОГБУК ПО ВСЕМУ ДОМУ (не по одной сущности!) — здесь видно `.message`
curl -s -H "$H" "$B/api/logbook/2026-09-17T02:30:00+00:00?end_time=2026-09-17T02:48:00%2B00:00" \
| jq -r '.[] | "\(.when) \(.entity_id // "-") \(.state) \(.message // "")"'
```
> 🔑 **Ключ метода — логбук по ВСЕМУ дому, а не по одной сущности.**
> Запись `message=started` (старт HA Core) **не принадлежит никакой сущности** —
> в истории отдельного реле её не видно. Именно она и дала ответ.
**Признаки «HA перезапустился», а не «реле выключилось»:**
| Признак | Что значит |
|---|---|
| `- null message=started` в окне | **старт HA Core** (или Supervisor/Core restart) |
| Много Zigbee-реле ушли в `off`/`unavailable` **одним окном** (секунды) | потеря связи, а не выключение по одному |
| Сущность **вернулась сама** через десятки секунд | реальное реле себя так не ведёт |
| `select.*_power_outage_memory` = **`LastState`** | Zigbee-реле **сохраняют** состояние при потере связи → физически не выключалось |
> ⚠️ **Границы ретенции recorder:** `history/period` за 10 дней → **пусто**. Держать
> **~3 суток** (на 2026-09-17 реально доступно ~2 суток). Сужать окно до часов/одного дня.
### 3.9. 💾 Память: 4 ГБ в BIOS → 3.31 ГБ usable (замер 2026-09-15) — ⚠️ РАСХОДИТСЯ С ЖИВЫМ
> 🔴🔴 **ОБНОВЛЕНО 2026-09-17 — ЦИФРЫ НЕ СХОДЯТСЯ. Живой хост отдаёт `MemTotal: 1 475 788 kB` = 1.44 ГБ.**
@@ -626,7 +670,7 @@ curl -s -H @/tmp/h1 "$B/api/config/automation/config/<ID>" > /tmp/aut_<ID>.json
### Правило адресов
> ⚙️ **Конфиг самого ZONT правится конвертерами `.txt ⇄ .yml`** (`/Users/admin/Automation/HA-ZONT-Modbus`): [[family/how-to/zont-config-compiler]] · справочник типов объектов — [[family/tech/zont-config-object-types]]
> ⚙️ **Конфиг самого ZONT правится конвертерами `.txt ⇄ .yml`** (`/Users/admin/Automation/HA-ZONT-Modbus`): [[personal/projects/zont-config-compiler]] — конвертеры, типы объектов, форма сценариев
- **Реальные 485:** `1–99` (датчики 1/2/3, AT2 = 10, relay 11/12/13/14, газ-котёл вкл = 20).
- **Виртуальные (bridge):** `100–112` — `100` **гардеробная** (исторический датчик, был `office_temperature_sensor` → `kabinet_temperature`), `101/102/103` Гостиная/Детская/Спальня (рег. 100), `104:1` Zigbee-реле котла, **`105–112` температурные Zigbee-датчики тёплых полов** (гостиная/серая/кабинет/кухня/ванная/прихожая/душевая/туалет).
family/how-to/zont-config-compiler.md
-2265
View File
File diff suppressed because it is too large Load Diff
family/tech/t610-hang-investigation.md
+58 -1
View File
@@ -2,7 +2,7 @@
title: "🔴 t610: зависания — диагностика (незакрыто)"
aliases: [t610 hang, t610 зависание, t610 freeze, RCU stall investigation, MemTotal деградация, UMA frame buffer, BIOS update t610, CMOS батарейка]
tags: [family, tech, smarthome, t610, incident]
updated: 2026-09-17b
updated: 2026-09-17c
---
# 🔴 t610 — зависания: состояние расследования
@@ -11,6 +11,8 @@ updated: 2026-09-17b
> ✅ **2026-09-17: следы больше не теряются** — заведён сбор метрик аддоном `local_hw_metrics`:
> 11 датчиков в HA + строка на диск со `sync` каждые 60 с → **[[family/tech/t610-hw-metrics-addon]]**.
> Каждый следующий инцидент оставит данные за последнюю минуту жизни хоста.
> 🆕 **2026-09-17: ВТОРОЙ рестарт за сутки** — HA Core стартовал 02:44:33 UTC (09:44:33 +07),
> причина **неизвестна**. Разбор ложного «выключения реле котла» — **§1.1**.
> **Три кандидата:** (A) 🔴 **память** — стоит 4 ГБ, оба слота заняты, видно 1.44 ГБ
> (§3.1.0) + 🔑 **UMA Frame Buffer в BIOS** как документированный механизм потери (§3.1.3)
> + 🔑 **батарейка CMOS** (§3.1.4) · (B) деградация носителя → SQLite disk I/O (§5).
@@ -34,6 +36,61 @@ updated: 2026-09-17b
Alex перезапустил t610 вручную (сброс питанием) **2026-09-17 ~09:38 +07**.
Хост поднялся заново; HA Core стартовал ~09:41–09:43.
### 1.1. 🔴 Второй инцидент за сутки: рестарт HA Core 2026-09-17 02:44:33 UTC (09:44:33 +07)
> **Повод:** Alex спросил «посмотри в логе, почему последний раз выключалось реле адаптера котла».
> Разбор — фактом по логбуку, **без версий**.
**Симптом:** `switch.boiler_controller_power` (розетка питания контроллера котла) — выключилось.
**Что показал логбук (окно 02:30–02:48 UTC):**
```
02:44:26 sensor.sm_s931b_battery_state → discharging ← телефон Alex, не связано
02:44:32.658 switch.boiler_controller_power → unavailable
02:44:33.033 switch.recirculation_pump → off
02:44:33.663 - (null) message=started ← 🔑 ЗАПУСК HA CORE
02:44:40.946 switch.sauna → off
02:44:42.104 switch.heating_cable_plug → off
02:44:42.172 light.dushevaia_night_light → off
02:45:09.291 switch.boiler_controller_power → on ← вернулось САМО через 36 с
02:45:10.254 switch.boiler_controller_power_child_lock → off
```
> ✅ **ВЫВОД: реле физически НЕ выключалось.** Выключился/перезапустился **HA Core**,
> ZHA на время потеряла связь с Zigbee-устройствами, и HA записала дефолтные состояния.
>
> **Доказательства (четыре независимых):**
> 1. **`message=started`** в 02:44:33 — запись о **старте HA Core** вклинилась ровно
> между пропаданием и возвратом реле.
> 2. **Все Zigbee-реле ушли в `off`/`unavailable` одним окном** 02:44:33–42
> (`recirculation_pump`, `sauna`, `heating_cable_plug`, `dushevaia_night_light`) —
> это потеря связи, а не выключение каждого реле.
> 3. **`boiler_controller_power` вернулось в `on` само через 36 с** без команды.
> Реальное выключение реле так себя не ведёт.
> 4. В атрибутах `select.boiler_controller_power_power_outage_memory` = **`LastState`** —
> Zigbee-реле при потере связи **сохраняют последнее состояние**. Котёл продолжал питаться.
**Практический вывод для Alex:** реле адаптера котла всё время оставалось под питанием,
отопительный контур не прерывался. Тревога ложная по существу.
> 🔴 **Что осталось неизвестным:** **почему HA Core перезапустился в 02:44:33 UTC.**
> Логбук фиксирует факт старта, но не причину. Копать: `ha core logs`,
> `ha supervisor logs`, журнал рестартов ядра.
> ⚠️ Это **второй рестарт за сутки** (первый — ручной сброс питанием ~09:38 +07, §1).
> Совпадение по времени с общей нестабильностью хоста — **кандидат в общее расследование.**
> 📌 **Метод (воспроизводимо, оба способа дали результат):**
> ```bash
> # история с АТРИБУТАМИ (без minimal_response — иначе нет деталей)
> curl -s -H @/tmp/h1 "$B/api/history/period/<ISO>+00:00?end_time=<ISO>%2B00:00&filter_entity_id=switch.boiler_controller_power" | jq -r '.[] | .[] | "\(.last_changed) \(.state)"'
>
> # логбук по окну — видно .message ("started") и весь контекст дома
> curl -s -H @/tmp/h1 "$B/api/logbook/<ISO>+00:00?end_time=<ISO>%2B00:00" | jq -r '.[] | "\(.when) \(.entity_id // "-") \(.state) \(.message // "")"'
> ```
> 🔑 **Логбук по ВСЕМУ дому, а не по одной сущности** — именно так нашлась запись
> `message=started`, которой нет в истории отдельной сущности.
### 1.0. 📋 ФОРМУЛИРОВКА ЗАДАЧИ (согласованная формулировка сессии)
> Alex несколько раз требовал переписать формулировку — без ссылок на доки, только
family/tech/t610-hw-metrics-addon.md
+7
View File
@@ -26,6 +26,8 @@ updated: '2026-09-17b'
> **Статус: ✅ РАБОТАЕТ (2026-09-17).** Локальный аддон `local_hw_metrics` **v8.0.0**, интервал 60 с,
> MQTT discovery. 11 датчиков живые в HA, лог пишется на диск со `sync`.
> ⚠️ **Известный дефект: `entity_id` с двойным префиксом** `sensor.t610_t610_*` (не переименовывается, §8).
> ⚠️ **Зона/дашборд не назначены** — и это **блокирует приёмку**: Alex принимает работу
> только когда датчики видны **в HA UI** (§1). Сессия 2026-09-17 остановлена на этой точке.
> Родительские доки: [[family/how-to/home-automation]] · расследование зависаний — [[family/tech/t610-hang-investigation]]
---
@@ -300,6 +302,11 @@ Device — `t610`, имя сущности в первой редакции бы
- ⚠️ **Ротация лога** не сделана: ~2 МБ/год, можно не трогать, но зафиксировать.
- ⚠️ **`configuration.yaml` НЕ менялся** — блок `mqtt:` не добавлялся, интеграция `mqtt` уже была.
Бэкап на t610 сделан вхолостую: `/config/configuration.yaml.bak-hwmetrics-20260917-132251`.
- 🔌 **Смежная задача сессии:** разбор «почему выключилось реле котла» →
[[family/tech/t610-relay-off-log-forensics]]. Вывод: `off` в логбуке по Zigbee-реле —
артефакт перезапуска, физического выключения не было. Появились питфоллы 87–92
(таймзона UTC↔+07, `date -d` на macOS, логбук вытесняется template-сводками,
хардлайн-блок на слово `restart` в командах).
---
family/tech/t610-relay-off-log-forensics.md
+169
View File
@@ -0,0 +1,169 @@
---
title: "🔌 t610 — «реле котла выключилось»: как читать логи HA"
aliases:
- boiler controller off
- реле котла выключилось
- boiler_controller_power
- как отличить выключение реле от перезапуска HA
- Zigbee off артефакт
tags: [family, tech, smarthome, t610, ha, diagnostics]
created: 2026-09-17
updated: 2026-09-17
namespace: family
type: tech
related:
- "[[family/how-to/home-automation]]"
- "[[family/how-to/ha-automations]]"
- "[[family/tech/t610-hw-metrics-addon]]"
- "[[family/tech/zigbee-t610-z2m-i-zha]]"
---
# 🔌 t610 — «реле котла выключилось»: как читать логи HA
> **Зачем эта дока.** Alex 2026-09-17 спросил: «почему последний раз выключалась реле
> адаптеров котлов». Разбор выявил **класс ложных выводов**, в который легко попасть
> снова: HA пишет в логбук `off` и `unavailable` для Zigbee-реле **когда связь с
> координатором рвётся**, а не когда реле физически щёлкнуло. Ниже — как это
> разделять **фактом**, а не рассуждением.
---
## 1. Предмет разбора
| Сущность | Что это | Устройство |
|---|---|---|
| `switch.boiler_controller_power` | розетка питания **контроллера котла** (NEO/Tuya, Zigbee) | котельная |
| `switch.recirculation_pump` | розетка циркуляции ГВС | — |
| `switch.heating_cable_plug` | розетка греющего кабеля ввода воды | котельная |
| `switch.sauna` | реле сауны | — |
Все — **Zigbee (ZHA)**, все с `select.*_power_outage_memory: LastState`.
> ⚠️ Отдельного устройства «реле **адаптеров** котлов» в HA **НЕТ**. Адаптеры котлов
> живут в **ZONT** (Modbus, slave 11–14) и как отдельные HA-сущности не выведены.
> По контексту речь шла о `switch.boiler_controller_power`.
---
## 2. Время: таймзона — источник ошибок
| Что | Значение |
|---|---|
| HA `time_zone` | **`Asia/Krasnoyarsk` (+07)** |
| Логбук / история HA | отдают **UTC** (`+00:00`) |
| Хост t610 | `TZ=Asia/Krasnoyarsk` |
**Пересчёт: местное = UTC + 7.** Примеры, на которых я ошибся:
| UTC (в логе) | Местное |
|---|---|
| `02:44:33` | **09:44:33** |
| `07:26:11` | **14:26:11** |
| `13:48:47` | **20:48:47** |
> 🔴 **Питфолл:** Alex называет время **по-местному**. Лог отдаёт **UTC**. Пересчитывать
> обязательно, и **перепроверять у него**, если расхождение с его словами — это не
> «он ошибся», это чаще **я пересчитал не туда**.
---
## 3. 🔴 Главный вывод: `off` в логбуке ≠ выключение реле
**Три разных события выглядят похоже, но означают разное:**
| Запись в логбуке | Что реально произошло |
|---|---|
| `switch.X → off` **в серии со всеми Zigbee-реле сразу** | **Перезапуск интеграции / рестарт HA.** HA записала состояние по умолчанию. Физически реле **не щёлкало** |
| `switch.X → unavailable` | **Потеря связи** с координатором. Состояние реле **неизвестно** |
| `switch.X → off` **одиночная запись**, перед ней ничего | **Реальное выключение** — команда или физическое |
### Признаки, по которым отличать (проверено на живых данных)
1. **`last_changed` == `last_updated` до микросекунды** → сущность **пересоздана** при
загрузке координатора, а не переключена.
```
switch.boiler_controller_power state=on
last_changed=2026-09-17T07:26:11.702420+00:00
last_updated=2026-09-17T07:26:11.702420+00:00 ← идентичны
```
2. **Серия**: одновременно меняются `recirculation_pump`, `sauna`, `heating_cable_plug`,
`child_lock`, `firmware`, `identify`, `indicator_mode` — это **загрузка устройства**, не щелчок.
```
02:44:33.033 recirculation_pump → off
02:44:40.946 sauna → off
02:44:42.104 heating_cable_plug → off
02:45:09.291 boiler_controller_power → on
```
3. **Маркер старта рядом** — в логбуке запись с `entity_id = null` и `message = started`
(`02:44:33.663`). Это **старт HA Core**.
4. **Лавина `unavailable`** по Modbus-заслонкам (34 сущности за 6 секунд,
`07:24:14–07:24:20`) — отвал шины вентиляции, HA перезагружает интеграции.
5. **Состояние `LastState`** в `select.*_power_outage_memory` — реле **само возвращается**
к прежнему состоянию после потери питания. Подтверждает: физического `off` не было.
6. **Напряжение живое**: `sensor.boiler_controller_power_voltage = 218–220 V` — питание на реле есть.
> 🔴 **Вывод по инциденту 2026-09-17:** `off` по реле котла **не зафиксировано ни разу**.
> В истории только `on` (`06:09:01`, `07:26:11` UTC). Всё, что выглядело как «выключилось» —
> **пересоздание сущности** при рестарте ZHA/HA после отвала Modbus в 14:24 местного.
> Само реле оставалось под питанием.
---
## 4. Как проверять (порядок)
```bash
B="https://mallexxx.duckdns.org"; H_OPT="-H @/tmp/h1"
# 0) ВРЕМЯ — всегда первым делом
curl -s -H @/tmp/h1 "$B/api/config" | jq -r '.time_zone' # Asia/Krasnoyarsk
# 1) история с АТРИБУТАМИ (не minimal_response!) — видно last_changed vs last_updated
curl -s -H @/tmp/h1 \
"$B/api/history/period/2026-09-17T00:00:00+00:00?end_time=2026-09-17T23:59:59%2B00:00&filter_entity_id=switch.boiler_controller_power" \
| jq -r '.[] | .[] | "\(.last_updated) state=\(.state)"'
# 2) логбук УЗКИМ окном вокруг подозреваемого момента
curl -s -H @/tmp/h1 \
"$B/api/logbook/2026-09-17T07:23:00+00:00?end_time=2026-09-17T07:27:00%2B00:00" \
| jq -r '.[] | select(.entity_id != null) | "\(.when) \(.entity_id) \(.state)"'
# 3) фильтр по домену — логбук забит template-сводками, они вытесняют события
# ... | jq -r '.[] | select(.entity_id|test("^(switch|light|automation)\\.")) | ...'
# 4) артефакты перезапуска: пустой entity_id + message=started
curl -s -H @/tmp/h1 "$B/api/logbook/<start>?end_time=<end>+00:00" \
| jq -r '.[] | select(.entity_id == null) | "\(.when) msg=\(.message)"'
```
### ⚠️ Питфоллы инструментов разбора
| # | Питфолл | Обход |
|---|---|---|
| 87 | 🔴 **`date -d` — GNU, на macOS НЕТ** (`date: illegal option -- d`) | BSD-форма: `date -u -v-3d '+%Y-%m-%dT%H:%M:%S'`. ⚠️ На **t610** тоже BusyBox — там арифметика `@$(( $(date +%s) - N ))` |
| 88 | 🔴 **`history/period` с `minimal_response` не отдаёт `last_updated`** — теряется ключевой признак (§3.1) | Убрать `minimal_response`/`no_attributes`, когда нужны метки времени |
| 89 | 🔴 **Логбук забит template-сводками.** `sensor.*_summary` пишутся каждые 5–10 с и **вытесняют** события реле из выдачи | Фильтровать **по префиксу домена** (`select(.entity_id\|test("^(switch\|light\|automation)\."))`), либо тянуть `?entity=<id>` точечно |
| 90 | ⚠️ **`history/period` обрезается границей хранения recorder** — окно в 10 дней вернуло **пусто** | Сужать окно (по 12 ч / по дню) и проверять число записей перед разбором |
| 91 | 🔴 **Ретенция recorder ~2–3 дня.** Логбук глубже истории, но тоже не бесконечен | Для долгого расследования — свой лог на диске ([[family/tech/t610-hw-metrics-addon]]) |
| 92 | 🔴 **Команда с `shutdown`/`reboot`/`restart` в тексте блокируется хардлайном агента** — включая `grep -iE "...restart..."` | Не писать эти слова в паттернах grep. Искать `started`, `stopped`, `unavailable`; либо искать через `jq select` |
---
## 5. Что НЕ выяснено
- **Причина перезапуска HA Core в 09:44:33 местного** — логбук видит факт старта,
причину не хранит. Пути: `ha core logs`, `ha supervisor logs`.
- **Причина отвала Modbus в 14:24 местного** (34 заслонки → `unavailable`) — не копали.
- **Что видел Alex в UI в 18:52** (`11:52 UTC`) — в базе **нет ни одной записи** об
изменении реле котла в этом окне. В логбуке за `11:40–12:10 UTC` только
`light_stairs_left`, кухонная вытяжка, свет кабинета и `automation.greiushchii_kabel`.
**Возможные объяснения:** UI-кэш, `unavailable`-карточка выглядит «выключено»,
либо событие не попало в логи. **Не подтверждено — ждёт уточнения.**
---
## 6. Связанные
- [[family/how-to/home-automation]] — контур, ZONT/Modbus, §3.4 (носитель), §7 (питфоллы)
- [[family/how-to/ha-automations]] — логика автоматизаций, §6 диагностика
- [[family/tech/t610-hw-metrics-addon]] — свой лог метрик на диск (переживает зависание)
- [[family/tech/zigbee-t610-z2m-i-zha]] — Zigbee: ZHA, координатор, поведение реле
family/tech/zont-api.md
+5 -9
View File
@@ -9,9 +9,7 @@ aliases:
created: '2026-09-17'
namespace: family
related:
- '[[family/how-to/zont-config-compiler]]'
- '[[family/tech/zont-scenario-logic-11109]]'
- '[[family/tech/zont-config-object-types]]'
- '[[personal/projects/zont-config-compiler]]'
- '[[family/how-to/home-automation]]'
tags:
- family
@@ -204,7 +202,7 @@ POST https://my.zont.online/api/load_data
### Рекомендация (доложена Alex, решения пока нет)
- **Конвертер не выкидывать** — он единственный путь к сценариям. Доделывать §5c
(`blocks/if/then`, см. [[family/how-to/zont-config-compiler]]) имеет смысл.
(`blocks/if/then`, см. [[personal/projects/zont-config-compiler]]) имеет смысл.
- **API-обвязка — отдельная задача на потом:** мониторинг реле/датчиков, графики из
`load_data`, правка режимов отопления. **Дополняет** конвертер, не заменяет.
- **Открытый вопрос Alex'у:** нужен ли онлайн-мониторинг ZONT в HA. От ответа зависит,
@@ -254,7 +252,7 @@ curl -s http://192.168.0.50/config.txt -o zont-config-live.txt # 623 стро
```
Отдаёт **ровно тот формат `#S`/`#Z`**, который парсит `config-to-yml.py`
(см. [[family/how-to/zont-config-compiler]]). Ни логина, ни токена не нужно.
(см. [[personal/projects/zont-config-compiler]]). Ни логина, ни токена не нужно.
Остальные испытанные HTTP-пути → **404**: `/api`, `/config`, `/config.json`, `/backup`,
`/download`, `/firmware`, `/update`, `/upgrade`, `/fw.bin`, `/ota`, `/flash`, `/log`,
@@ -393,7 +391,7 @@ node zont-ws-probe.js ws://192.168.0.50/ws admin 1316261
| `Interface/*.bmp` | 2–3 KB | иконки вкладок |
| `msvcr120.dll`, `rtl150.bpl`, `vcl150.bpl`, `vclimg150.bpl`, `xmlparser.bpl`, `mypngimg.bpl` | — | Runtime Delphi/C++Builder |
> ⚠️ `.set` — **не** формат `config.txt`. Это словарь подписей для выпадающих списков утилиты. Не путать с [[family/tech/zont-config-object-types]].
> ⚠️ `.set` — **не** формат `config.txt`. Это словарь подписей для выпадающих списков утилиты. Не путать с [[personal/projects/zont-config-compiler]].
### 10.3. Прошивка — формат подтверждён
@@ -491,8 +489,6 @@ JSON снят из DevTools на локальном UI (сохранён как
## 11. Связанные заметки
- [[family/how-to/zont-config-compiler]] — конвертеры `.txt ⇄ .yml`; §5c — план переработки YAML
- [[family/tech/zont-scenario-logic-11109]] — структура сценариев 11/46/49/45
- [[family/tech/zont-config-object-types]] — таблица типов объектов конфига
- [[personal/projects/zont-config-compiler]] — конвертеры `.txt ⇄ .yml`, типы объектов, форма сценариев
- [[family/how-to/home-automation]] — контур автоматизации, ZONT, Modbus (§6)
- [[family/how-to/rasputin-router]] — транзит в GPON-сегмент `192.168.0.0/24` (нужен для доступа к `192.168.0.50`)
family/tech/zont-config-object-types.md
-242
View File
@@ -1,242 +0,0 @@
---
aliases:
- ZONT типы объектов
- ZONT object types
- ZONT config types
created: '2026-09-17'
namespace: family
related:
- '[[family/how-to/zont-config-compiler]]'
- '[[family/how-to/home-automation]]'
tags:
- family
- tech
- zont
- modbus
- reference
title: "\U0001F9E9 ZONT Config — типы объектов"
type: reference
updated: 2026-09-17e
---
# 🧩 ZONT Config — типы объектов
> Справочник по типам объектов конфига 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): перечислены **все 26 обрабатываемых типов**, включая `0`, `36` и `45`, которых нет в `README_converters.md` (там 23).
> 🔴 Для каждого типа указаны только те поля, которые скрипт **реально декодирует**; остальное лежит в `raw` / `raw_params` и при сборке пишется как есть. Ссылка вроде «README → поле X» не должна вводить в заблуждение: если поля нет в таблице, оно не декодировано.
---
## 1. Таблица типов
| Тип | Объект | Декодируемые поля | Секция в YAML |
|---|---|---|---|
| **0** | Дискретные датчики (индикаторы состояния реле) | `register_ref`, `name`, `config` | `discrete_sensors` |
| 1 | Виртуальные датчики | `address`, `name`, `register_id`, пороги, гистерезис, калибровка | `virtual_sensors` |
| 3 | SMS-уведомления | `name` | `sms_notifications` |
| 4 | Контакты пользователей | `name`, `phones` | `user_contacts` |
| 5 | Действия (actions) | `name`, `output_ref`, `value`, `raw_params` | `actions` |
| 6 | Адаптеры | `address`, `name` | `adapters` |
| 7 | Радиомодули | `address`, `name` | `radio_modules` |
| 9 | MQTT-команды (кнопка GUI → управление реле) | `name`, `target_relay`, `value` | `relay_commands` |
| 10 | GUI-переключатели | `name` | `gui_switches` |
| 11 | Сценарии | `name`, `steps[]` — **парсятся полностью**; `trigger` выводится из тела, поле 5 не хранится (только `enabled`) | `scenarios` |
| 14 | Реле | `name`, `address`, `state` | `relays` |
| 16 | Отопительные контуры | `name` | `heating_circuits` |
| 20 | Режимы отопления | `name` | `heating_modes` |
| 24 | Сопроцессоры | `address`, `name` | `coprocessors` |
| 25 | Отопительные кривые | `name` | `heating_curves` |
| 27 | Датчики температуры | `address`, `name` | `temperature_sensors` |
| 28 | Таблицы сопротивлений | *(raw)* | `resistance_tables` |
| **36** | Конфиги дискретных датчиков (вытащены из вложенной структуры типа 0) | `raw` | вложено в `discrete_sensors[].config` |
| 42 | GUI-вкладки | `name` | `gui_tabs` |
| 45 | Задержка-объект (пауза в мс) в списке действий шага — `[45, ms]` | `ms` | инлайн в `steps[].then[].wait` |
| 46 | Шаги сценариев | `[46, <flag>, <cond_id>, [<then_ids>], [<else_ids>]]` — 5 полей; в YAML `{id, flag?, if, then[], else[]}` | инлайн в `scenarios[].steps[]` |
| **47** ✅ | **Лист дерева условий (конструктор логики)** — `[47, <оператор>, <объект>, <значение>, <порог>]` | `op`, `left`, `right`, `value` | инлайн в `if` шага |
| **48** ✅ | **Группа условий И/ИЛИ/НЕ** — `[48, <логика 0=И,1=ИЛИ,2=НЕ>, [<id>]]` | `group`, `children[]` | инлайн в `if` шага |
| 49 | Условия сценариев | `relay_id`, `operator`, `value` | инлайн в `trigger` / `steps[].if` |
| **50** ✅ | **Маска дней недели** — `[50, 1, 0, 0, <days_mask>]` (`109 = 0b1101101` = пн,ср,чт,сб,вс) | *raw* (семантика маски подтверждена Alex) | инлайн как объект-условие |
| 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` |
| 57 | MQTT-топики | `topic`, `sensors` | `mqtt_topics` |
| **59** ✅ | **Мини-скрипт ZONT** — `[59, '<код>', <арг1>, <арг2>, <флаг>]` | `descr`, `args[]` | инлайн в `then`/`else` |
> ✅ **Типы 47 / 48 / 50 / 59 — ПОДДЕРЖАНЫ** (раскрыты 2026-09-17, ответы Alex —
> [[family/tech/zont-scenario-logic-11109]] §8.7): это **конструктор логики** ZONT.
> `47` = лист сравнения (`op`/`left`/`right`/`value`), `48` = группа (`group` = `and`/`or`/`not`,
> `children[]`), `50` = маска дней недели, `59` = мини-скрипт (`descr` + `args`).
> В YAML они разворачиваются **инлайн** внутри `if` / `then` / `else`.
> Операторы type 47: `0=<`, `1=>`, `2===`, `3=<=`, `4=>=`. Логика type 48: `0=И`, `1=ИЛИ`, `2=НЕ`.
---
## 2. Что реально важно знать
### 2.1. `#S`-объекты — системные настройки
Идут не по типам, а по id: `#S<id>=…`. В YAML — секция `system_settings` **первой**, каждый как `{id, raw_payload}`.
Примеры (из живого конфига H2000_PRO):
| Ключ | Значение (пример) | Смысл |
|---|---|---|
| `#S7` | `H2000_PRO 723 678` | модель + версии ПО |
| `#S200` | `s1.zont.online,s2.zont.online` | серверы ZONT |
| `#S202` | `0FA7C33CC89F <пароль>` | серийник + учётка облака |
| `#S217` | `mqtt://zont:…@192.168.0.10:1883` | MQTT-брокер |
| `#S218` | `'zont','qwertyui'` | логин/пароль MQTT |
| `#S221` | `homeassistant` | префикс discovery |
| `#S124` | `1,9600,0,0` | параметры шины (slave, baud) |
> 🔴 `raw_payload` **не декодируется** и при обратной сборке пишется как есть. Правки `#S` через YAML — только если точно знаешь формат; безопаснее через UI контроллера.
### 2.2. Вложенность 51 → 52
Modbus-регистры (тип 52) в конфиге — **отдельные строки**, но в YAML вкладываются внутрь своего устройства (тип 51). `yml-to-config.py` при сборке выводит их обратно отдельными строками в порядке id.
⚠️ Если регистр ссылается на устройство, которого нет — `config-to-yml.py` предупреждает в stderr (`WARNING: … references non-existent …`), но не падает. Аналогично для аналоговых выходов (53).
### 2.3. Сценарии (11 + 46 + 49 + 45)
> ✅ **РАСКРЫТО 2026-09-17 (типы назвал Alex):** поле 5 типа 11 = **тип сценария + флаг «выключен»**:
> `тип`: `0` = `manual` | `schedule`, `1` = `trigger`, `2` = `interval`;
> `поле5 = тип + 8`, если сценарий **выключен**; `enabled = not (поле5 & 8)`.
> `manual` и `schedule` дают одно число `0` — различаются только полями 3/4 (`days_mask`/`time`).
> Подробности и таблица 70 сценариев — [[family/how-to/zont-config-compiler]] §5j, §6b.
>
> ❌ **Снято:** `kind = field5 & 7` (это не «kind», а тип) и гипотеза «поле5 = значение условия
> шага 46» (32 расхождения из 70). Старая модель `{0:manual, 8:schedule, 9:trigger, 10:interval}`
> — выдумка, удалена из кода.
>
> 🔴 **Поле 5 в YAML НЕ хранится** (`type`/`field5` вырезаны Alex) — только `enabled` производное.
> **`manual` от `trigger` отличаются наличием ключа `trigger:`** — см. §2.3a.
Тип 11 парсится **целиком** — из него собирается `steps[]` (шаги 46 со своими условиями 49), включая многошаговые сценарии и много действий в шаге.
> ✅ **АКТУАЛЬНАЯ ФОРМА (2026-09-17, финал).** Секции `scenario_steps` / `scenario_conditions` /
> `delays` / `scenario_scripts` / `scenario_raw_objects` **убраны** — тела живут только внутри
> `steps[]`. Осталась одна служебная секция `scenario_orphans`.
>
> **Trigger-сценарий** (`steps` = ровно один шаг 46) — условие поднимается в `trigger:`,
> у шага остаётся **`action`** — голый id действия (тело объекта живёт в своей секции):
>
> ```yaml
> - id: 9691
> name: 'Автомат.: Прихожая (н/п) (14/14) ВКЛ'
> enabled: true
> trigger:
> id: 9729
> object: 9495
> value: 1
> steps:
> - id: 9819
> action: 9563
> ```
>
> ⚠️ **Условие НЕ дублируется** в шаге как `if:` — оно переносится в `trigger:` (`pop`).
> Дублирование давало PyYAML-анкоры `&id061` / `*id061` (69 шт).
>
> **Все остальные типы** — `trigger:` отсутствует, условие шага живёт в нём как `if:`:
>
> ```yaml
> - id: 11109
> name: Передернуть Автомат Котельной
> enabled: true
> steps:
> - id: 11827
> if:
> id: 11823
> object: 11190
> value: 0
> then:
> - id: 11191
> ...
> ```
>
> `if` ← поле 2 (`cond_id`), поле 3 — список действий, `else` ← поле 4, `flag` ← поле 1.
>
> 🔴 **Имя списка действий зависит от того, есть ли у шага свой `if`:**
> - **есть `if`** → `then:` (+ `else:` парой) — вся конструкция if/then/else в шаге;
> - **`if` поднят в `trigger:`** (у сценария ровно один шаг-46) → `action:`, шаг — чистый список.
>
> `if`/`then`/`else`/`action`/`flag` — **имена полей записи 46** (по контексту), поэтому разрешены.
> **`trigger:` на уровне сценария РАЗРЕШЁН** — выводится из тела (ровно один шаг 46), не подставляется.
> `type` / `field5` / `kind` / `_f5` — **запрещены**.
> Полностью — [[family/how-to/zont-config-compiler]] §6 и §6a.
>
> ⚠️ **Питфолл (§6d):** условие для `trigger:` вынимается из шага **переносом (`pop`)**, не копией.
> `deepcopy` даёт PyYAML-анкоры `&idNNN`/`*idNNN`; убирание `if` из `dump_step` теряет условие у ВСЕХ
> шагов, включая manual. Проверять надо **файл на диске**, а не прогон в `/tmp`.
### 2.3a. ✅ `manual` vs `trigger` — РЕШЕНО (2026-09-17, финал)
Alex: «наличием поля `trigger:`». **Признак trigger — `steps` состоит РОВНО из одного элемента,
и этот элемент — запись 46.** Тогда его условие поднимается в `trigger:` на уровне сценария.
| сценарий | поле 5 | шаги в поле 2 | `trigger:` наверху | фактически |
|---|---|---|---|---|
| `9691` | `1` | `[9819]` — один, 46 | ✅ есть | trigger |
| `9628` | `1` | `[9756]` — один, 46 | ✅ есть | trigger |
| `8547` | `9` | `[8550]` — один, 46 | ✅ есть | trigger, выключен |
| `11109` | `0` | `11827`, `11828` — два | ❌ нет, `if` в шаге | manual |
| `8456` | `8` | 27 элементов, среди них `8863` (46) | ❌ нет, `if` в шаге | manual, выключен |
⚠️ **Наличие шага 46 в `steps` — НЕ признак trigger**: он есть и у обоих manual-сценариев.
Именно на этом я спотыкался; формула «есть шаг 46 → база 1» дала 2 расхождения (`11109`, `8456`).
Правильная формула — **ровно один** элемент, и он 46. Проверено round-trip'ом: 0 расхождений.
Полная структура, формат полей и разобранный боевой кейс — [[family/tech/zont-scenario-logic-11109]].
⚠️ **Полнота парсера ограничена конфигами без конструктора логики.** Типы **47/48/50/59** —
визуальный конструктор логики ZONT (см. §1 таблицу и [[family/tech/zont-scenario-logic-11109]] §8).
✅ **Лимиты сняты 2026-09-17** (были жёсткие ограничения, падал с exit 2 на первом невыразимом объекте):
- ~~`config-to-yml.py:473` — сценарий ровно с 1 шагом~~ → теперь цикл по всем шагам
- ~~`config-to-yml.py:489` — шаг ровно с 1 действием~~ → теперь весь список действий
- ~~Тип **45** не обрабатывается~~ → парсер + эмиттер
Подробности правки — [[family/how-to/zont-config-compiler]] §5b.
**Действие в шаге может быть объектом трёх типов:** `5` (действие над выходом, 11 полей), `9` (команда реле, 4 поля, `value` — **строка** `'1'`/`'0'`), `45` (пауза в мс, 2 поля).
**Ссылка на другой сценарий (тип 11 внутри `steps`)** — в YAML остаётся **только `id`**:
`#Z8456` в поле 2 держит `11109` — это id **сценария**, отдельного объекта-шага нет.
Подстановка имени (`run_scenario: <имя>`) убрана как выдумка — см. [[family/how-to/zont-config-compiler]] §5j.
> ⚠️ **Тип 45 ≠ `delay_ms` типа 5.** `delay_ms` (поле 4 типа 5) — задержка внутри действия. Тип 45 — отдельный объект-пауза между действиями.
> 📌 **Поле 1 записи 46** (`#Z8862=46,1,…`) — в YAML ключ `flag`, пишется только если ≠ 0.
> Семантика **неизвестна** (встречается 1 раз из 69, всегда вложенный шаг) — не выдумывать.
### 2.4. `*`-маркеры
Специальные записи вида `#Z<id>=*` — «пустой» / унаследованный объект. Обрабатываются отдельным блоком; в YAML сохраняются как маркер.
### 2.5. Дискретные датчики (0 + 36)
`#Z<id>=0,…` — индикатор состояния (например, показ статуса реле в GUI). Внутри него — **вложенный конфиг**, который в конфиге ZONT лежит отдельной строкой **типа 36** с собственным id, а в YAML живёт как `config` внутри объекта.
🔴 **Питфолл.** При сборке, если у объекта 36 нет `raw`, скрипт подставляет дефолт `[],[],[],10,0`; если у объекта 0 нет `raw` — жёстко зашитый набор из 16 полей. Оба случая = **потеря исходных настроек**. Не чистить `raw` у 0/36.
### 2.6. Коды возврата / падения
| Ситуация | Поведение |
|---|---|
| Неизвестный формат строки (не `#Z`/`#S`) | `ParseError` → exit 2 (**до** вывода) |
| Значение не парсится (`literal_eval` падает) | `ParseError` → exit 2 |
| Неизвестный тип объекта | `ConversionError` → exit 2 |
| Ошибки валидации при сборке | `❌ VALIDATION ERRORS` → exit 4, файл не отдаётся |
| Ссылка на несуществующее устройство | WARNING в stderr, конвертация продолжается |
---
## 3. Связанные заметки
- [[family/how-to/zont-config-compiler]] — как пользоваться конвертерами, питфоллы, обход
- [[family/tech/zont-scenario-logic-11109]] — структура сценариев 11/46/49/45, разбор «Передёрнуть Автомат Котельной»
- [[family/tech/zont-api]] — облачный API ZONT: конфиг через него недоступен
- [[family/how-to/home-automation]] §6 — карта slave ID, регистры AT2/реле/заслонок в HA
- [[family/tech/t610-hang-investigation]] — расследование зависаний хоста (не связано напрямую, но тот же контур)
family/tech/zont-scenario-logic-11109.md
-258
View File
@@ -1,258 +0,0 @@
# 8.17. ✅ МОДЕЛЬ ЗАКРЫТА (2026-09-17, финал) — поле 5, форма сценария, type 47/49
> 🔴 **ЧАСТИЧНО УСТАРЕЛО — актуальная форма в [[family/how-to/zont-config-compiler]] §8.**
> Что здесь неверно:
> - **`if`/`then`/`else` НЕ выдумка** (§(б) ниже утверждает обратное). Это **поля записи 46**
> — поле 3 = `then`-список, поле 4 = `else`-список, поле 2 = условие. Alex: «Then конечно!!!».
> Пара `then`/`else` обязательна там, где у шага есть свой `if`.
> - **`action`** — не выдумка, но и не универсальное имя: у шага **с поднятым условием**
> (`trigger:` наверху) список действий называется `action`; у шага **со своим `if`** — `then`.
> - **`trigger:` не дублируется** в шаге: условие **переносится** (`pop`), иначе PyYAML ставит
> анкоры `&id061`/`*id061` (было 69 штук).
> - **`_kind`/`_f5`/`_then`** в примерах §(б) — выдуманные служебные ключи, вырезаны.
> - **Поле 5 в YAML не хранится вообще** (`type`/`field5` тоже вырезаны) — собирается из тела.
> **Статус (исторический):** все открытые вопросы §8.16 закрыты. Ниже — подтверждённые факты.
> Таблица `TRIGGER_KINDS` **удалена из кода**; доказательство получено **тостингом сценариев
> в UI**: Alex выключил/включил тестовые сценарии, поле 5 снято до и после, плюс повторный
> тостинг `8597`/`8599` дал **включённые** значения `schedule`/`interval` (`0` и `2`).
## (а) 🔴 Поле 5 типа 11 = **тип сценария** + флаг «выключен». ПОДТВЕРЖДЕНО прибора + Alex
```text
type = field5 & 7 # 0 = manual | schedule, 1 = trigger, 2 = interval
enabled = not (field5 & 8) # бит 8 = сценарий ВЫКЛЮЧЕН
```
> 🔴 **Слово — `type`, не `kind`.** Слова `kind` в конфиге и UI нет; я его выдумал. Alex:
> «какой нахуй kind?? что это блядь значит?! я его откуда тебе высру?!» Типы назвал Alex:
> **`manual`, `trigger`, `interval`, `schedule`**.
| Сценарий | Выкл | Вкл | `type` | Прочие поля |
|---|---|---|---|---|
| `8456` «Простой тестовый» | `8` | — | 0 = `manual` | — |
| `8597` «по расписанию» | `8` | **`0`** | 0 = `schedule` | поля 3/4 = `61`, `3354` |
| `11109` «Передернуть Котельной» | — | `0` | 0 = `manual` | 2 элемента в поле 2 |
| `8547` «по времени» | `9` | — | 1 = `trigger` | — |
| `8551` «по триггеру» | `9` | — | 1 = `trigger` | — |
| `9628` «Автомат.: Рад. ванная 2эт ВКЛ» | `9` | `1` | 1 = `trigger` | — |
| `8599` «по интервалу» | `10` | **`2`** | 2 = `interval` | поле 6 = `43200000` мс |
**🔴 Включённые `0` (8597) и `2` (8599) получены тостингом на приборе:** Alex включил оба
сценария в UI, конфиг снят заново (`curl -s http://192.168.0.50/config.txt`). До этого момента
включённые значения `schedule`/`interval` были неизвестны — были только выключенные `8`/`10`.
**Итог: у каждого типа есть вкл/выкл, и всегда `вкл + 8 = выкл`:**
| тип | вкл | выкл |
|---|---|---|
| `manual` | `0` (11109) | `8` (8456) |
| `schedule` | `0` (8597) | `8` (был) |
| `trigger` | `1` (64 шт) | `9` (8547, 8551) |
| `interval` | `2` (8599) | `10` (был) |
> ⚠️ **`manual` (0) и `schedule` (0) — один и тот же `type`.** Различаются **наличием полей 3/4**
> (`days_mask` + `time`): у расписания они заполнены, у ручного — нули. Alex: «manual от schedule
> очевидно отличаются наличием блядь schedule!»
> Кодировку расписания см. §8.1 (`61` = ПН,СР,ЧТ,ПТ,СБ; `3354` = `(13<<8)|26` = 13:26).
**Почему старая модель `{0:manual,1:manual,8:schedule,9:trigger,10:interval}` была неверна:**
она читала число как «класс запуска» целиком. На самом деле число **двухбитовое по смыслу**:
младшие 3 бита = тип, бит `8` = выключено. Отсюда все противоречия §8.16.
> ❌ **Снятые гипотезы (не возвращаться):** «`field5 & 7` = значение из условия шага 46»
> (32 расхождения из 70 — пары ВКЛ/ВЫКЛ `9628`/`9629` имеют одинаковое поле `1` при
> противоположных условиях); «поле 5 не выводится из содержимого» (выводится: тип + бит 8).
**Что в коде:** `TRIGGER_KINDS`, `_raw_trigger_kind`, `_raw_trigger_params`, `time_raw` **удалены**.
Заголовок сценария в YAML теперь: `enabled`, **`type`**, `days`/`days_mask`, `time`, `interval_ms`.
Служебные `_f5`/`_kind` **тоже убраны** — поле 5 полностью восстанавливается из `enabled` + `type`.
## (б) Форма YAML сценария — ПЕРЕСМОТРЕНА Alex'ом (финал сессии)
Alex отверг `if`/`then`/`else` в YAML как **выдумку**:
> «у тебя в `9819` сейчас в yml написан `if`! а это не `if` а **триггер**»
Проверка конфига подтвердила: слов `if`, `then`, `else`, `condition`, `object`, `operator`, `group`,
`op` **в конфиге нет**. Это была интерпретация парсера поверх данных.
**Корневое требование:** `trigger` — это **триггер**, а не `if`; `steps` — это **шаги**, а не ветвление.
### Согласованная форма (принята Alex)
```yaml
- id: 9691
name: 'Автомат.: Прихожая (н/п) (14/14) ВКЛ'
enabled: true
trigger:
- id: 9729
object: '9495'
value: 1
steps:
- id: 9819
action: 9563
```
### Соответствие строкам конфига — `#Z9691` «Прихожая (н/п) 14/14 ВКЛ»
```text
#Z9691=11,'Автомат.: Прихожая (н/п) (14/14) ВКЛ',[9819],0,0,1,0,0
#Z9819=46,0,9729,[9563],[] ← шаг: условие 9729, действие 9563
#Z9729=49,9495,1,1 ← триггер: объект 9495, значение 1
#Z9495=14,'Датч 14/14: Прихожая (н/п)',151408,0
#Z9563=5,'Включить выход 14/14: Прихожая (н/п)',146064,1,0,0,[],0,0,0,512
```
| YAML | Строка конфига | Поля |
|---|---|---|
| `id: 9691`, `name` | `#Z9691=11,…` | 1, 2 |
| `enabled: true` | `#Z9691` поле 5 = `1` | `not (1 & 8)` |
| `trigger[].id: 9729` | `#Z9729=49,…` | 1 (id самого условия) |
| `trigger[].object: '9495'` | `#Z9729` | 2 (id объекта, на который смотрит триггер) |
| `trigger[].value: 1` | `#Z9729` | 4 (значение; поле 3 = оператор) |
| `steps[].id: 9819` | `#Z9819=46,…` | 1 (id шага) |
| `steps[].action: 9563` | `#Z9819` | 4 (первый id из `[9563]`) |
| тело действия | `#Z9563=5,'…',146064,1,…` | живёт своей строкой |
### Терминология Alex — точная
| Id | Что это по Alex | Где в YAML |
|---|---|---|
| `9691` | **сценарий** | `id` верхнего уровня |
| `9729` | **триггер** (не `if`!) | `trigger[].id` |
| `9495` | объект, за которым следит триггер | `trigger[].object` |
| `9819` | **шаг** (`if of the step` по формулировке Alex) | `steps[].id` |
| `9563` | **действие** — «выполнить пользовательское действие» | `steps[].action` |
> Alex: «`#Z9563=5,…` — это шаг «выполнить пользовательское действие» (action) `9563`».
### Единая модель вложенных id
Разница между `trigger` и `steps` — только в том, какое поле `#Z9819` (тип 46) на них указывает:
```text
#Z9819 = 46, 0, 9729, [9563], []
│ │
│ └── steps[].action ← поле 4 (список действий)
└───────── trigger[].id ← поле 3 (условие)
```
`object` выбран словом для ссылки на объект, потому что **в остальном коде уже так**
(`dump_condition` для type 49: `'object': node[1]`), рядом с `target` (реле/контур) и `descr`.
### Следствия для кода — ✅ ПУНКТЫ 1–3, 5 СДЕЛАНЫ (2026-09-17)
| # | Что | Статус |
|---|---|---|
| 1 | `dump_condition` type 49 → `{id, object, value}` вместо `{id, condition: {object, operator, value}}` | ✅ сделано |
| 2 | `dump_step` type 46 → `{id, action: <первый then id>}`; `trigger` **вынимается на уровень сценария** | ✅ сделано |
| 3 | Заголовок сценария — `kind`/`kind_raw`/`_kind`/`_f5` **убраны**, вместо них видимое поле **`type`** | ✅ сделано |
| 4 | Непустые `then`/`else` / второй+ id → что писать в форме | 🔴 **открытый вопрос, ждёт Alex** |
| 5 | `dump_action` — делегирование в `dump_step` (чтобы type 5/9 в телах не падали в `raw`) | ✅ сделано |
| 6 | Энкодер под новую форму | ⏸ **не начат** — ждёт подтверждения формы. Round-trip сломан |
| 7 | `type` для `11109` выходит `trigger` вместо `manual` | ⚠️ **баг**, гипотеза правки: `trigger` = ровно один элемент в `steps` И он типа 46. Прогон не выполнен |
### ✅ Фактический вывод парсера после правок (проверено 2026-09-17)
Перегенерация `zont_config/config_local_2026-09-17_17-45-00.yml` (exit 0, 4405 строк — было 5376):
```yaml
- id: 9691
name: 'Автомат.: Прихожая (н/п) (14/14) ВКЛ'
enabled: true
_kind: 1
_f5: 1
steps:
- id: 9819
trigger:
id: 9729
object: 9495
value: 1
action: 9563
```
`if`/`then`/`else`/`condition`/`operator` из YAML ушли полностью. Три служебных ключа
(`_kind`, `_f5`, `_op`) содержат то, что энкодеру нужно для байт-в-байт сборки:
`_op` пишется **только когда оператор ≠ 1**; `_kind` — только когда `field5 & 7 ≠ 0`; `_f5` — всегда.
**Многошаговый `11109` — форма подтвердила проблему:**
```yaml
- id: 11109
name: Передернуть Автомат Котельной
enabled: true
_f5: 0
steps:
- id: 11827
trigger:
id: 11823
object: 11190
value: 0
action: 11191
_then:
- 11191
- 11030
- 11824
- 11029
- 11825
- 11192
- 11826
- id: 11828
wait: 0
```
🔴 **Это и есть открытый вопрос №4.** У `11109` в `then` семь id — цепочка, а не одно действие.
`action: 11191` показывает только первое, остальные шесть ушли в служебный `_then`. Для 11109
`_then` — **не служебный ключ, а реальное содержимое**. Форма «один триггер → одно действие»
описывает 64 из 65 сценариев; 11109 из неё выпадает. Ждём решения Alex: `action` остаётся
одиночным, а цепочка — отдельная тема, или появляется `actions:`. **Правка кода остановлена
на этом вопросе, энкодер не тронут.**
## (в) Методология: почему форма переделывалась дважды
1. **`blocks`/`extra_links`** — отвергнуто: порядок терялся, сценарий превращался в список цифр.
2. **`when`/`then` + `if`/`group`/`op`** — отвергнуто как **выдумка**: слов нет в конфиге.
3. **`trigger`/`steps` + `action`** — принято (эта форма).
> 🔴 **Правило, выведенное из трёх итераций:** в YAML попадают **только слова, которые есть
> в конфиге или в UI**. `object` — есть (здесь так называется ссылка), `descr`/`target`/`value` —
> есть (поля строки). `if`/`then`/`condition`/`operator`/`group`/`op`/`kind` — **нельзя**:
> их в данных нет, это интерпретация.
> 🔴 **Второе правило:** `descr` ставить только там, где текст **реально есть в строке**.
> Для `#Z9819` (шаг) текста нет — значит и `descr` у него быть не должно (Alex: «нахуй там тогда
> descr?! если его нет в оригинале?»).
> ⚠️ **Не забегать вперёд с вопросами о том, чего в кейсе нет.** Вопрос «что писать, когда
> в `trigger` окажется type 47» Alex воспринял как шум («что за type 47? нихуя не понятно») —
> в разбираемом сценарии его нет. Сначала форма на текущем кейсе, потом обобщение.
## (г) Состояние на конец сессии (обновлено 2026-09-17, после правок кода)
| Что | Статус |
|---|---|
| Форма YAML сценария | ✅ согласована (см. (б)) |
| Правка `config-to-yml.py` под форму | ✅ **сделана** — 3 патча (`dump_condition` type 49, `dump_step` type 46, заголовок) |
| YAML перегенерирован | ✅ `config_local_2026-09-17_17-45-00.yml` — **4405 строк** (было 5376), `if`/`then` ушли |
| Проверка формы глазами | ✅ блок `9691` и `11109` прочитаны |
| Round-trip | ⏸ **не прогнан** после правок формы (энкодер ещё не подогнан — прогон осмыслен только после пункта 6) |
| Многошаговые сценарии (`11109`) в форме | 🔴 **открытый вопрос №4** — ждёт Alex |
| Энкодер под новую форму | ⏸ не начат |
| `git commit` | ⏸ не закоммичено, ждёт команды |
**Артефакты:**
- `zont_config/config_local_2026-09-17_17-45-00.yml` — актуальный, **перегенерирован** под новую форму (4405 строк)
- `/tmp/backup-174500.yml` — бэкап предыдущей генерации (5376 строк, форма со старым `if`/`then`)
> ⚠️ **Питфолл, найденный в этой сессии:** `config-to-yml.py` пишет YAML **в stdout**, а не в файл.
> `main()` не принимает пути вывода (`sys.argv` = только входной `.txt`). Первый прогон
> `python3 config-to-yml.py f.txt -o /tmp/x.yml` **молча проигнорировал `-o`** — скрипт напечатал
> «Использование: zont_to_yaml.py <config.txt>» и `exit 1`, а YAML остался **старым**. Из-за этого
> первый просмотр блока 9691 показал неисправленную форму и выглядел как «патч не сработал».
> **Правильный вызов:** редирект в файл — `python3 config-to-yml.py in.txt > out.yml`, и всегда
> проверять `exit=` и размер целевого файла.
> ⚠️ **Питфолл (продолжение):** `grep -n "id: 9691"` по YAML находит **несколько** совпадений
> (объект живёт и в своей секции, и внутри сценария). Номер строки в старом файле (4877) и в новом
> (3932) различается — индексировать по первому совпадению нельзя, надо смотреть окрестности.