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/rasputin-router.md family/how-to/zont-config-compiler.md family/tech/zont-api.md

Browse Source
This commit is contained in:
Alexey Martemyanov
2026-09-17 13:41:01 +06:00
parent e912b6c9db
commit 21fa0d5f9e
3 changed files with 295 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
family/how-to/rasputin-router.md
+59 -9
View File
@@ -545,20 +545,54 @@ default via 192.168.2.2 dev eth0 proto static src 192.168.2.157
То есть Rasputin получает адрес `192.168.2.157` **от роутера `192.168.2.2`** и выходит в интернет через него, а `192.168.2.2` — через GPON `192.168.0.1`. Топология запроса подтверждена: `rasputin → 192.168.2.2 → 192.168.0.1 (GPON) → 192.168.0.50`.
### План ремонта (НЕ применён, ждёт апрува)
### ✅ ЧТО СДЕЛАНО (2026-09-17) — правило `ip rule` добавлено и работает
Применено и **проверено Alex руками** (80 порт на `192.168.0.50` открылся):
```sh
# 1. ip rule — расширить bypass на GPON-сегмент
# на живом роутере
ip rule add to 192.168.0.0/24 lookup main priority 100
# 2. та же строка в /etc/rc.local — иначе умрёт после ребута
# 3. firewall: Allow-upstream-LAN dest_ip += 192.168.0.0/24, добавить proto icmp
# 4. проверить, что masq зоны wan покрывает 192.168.0.0/24 (иначе ответ не вернётся)
# и то же записано в /etc/rc.local (чтобы выжило ребут)
```
Бэкап до правки: `/etc/rc.local.bak.20260917-132639`
Правила после правки (две строки priority 100 — это нормально):
```text
100: from all to 192.168.2.0/24 lookup main
100: from all to 192.168.0.0/24 lookup main
101: from all iif br-lan lookup vpn
```
> 🔴 **Правка файлов на роутере — через скачивание → локальную правку → заливку.**
> `sed -i` по живому конфигу **запрещён** (и был заблокирован в этой сессии).
> Порядок: `scp` вниз → `patch` локально → `scp` наверх → `cat` для проверки.
### ⚠️ Что ОСТАЛОСЬ не сделано (осознанно, по объёму команды «ip rule»)
Alex дал команду только на `ip rule`. Следующие два пункта **не трогались**:
1. **NAT/masq для `192.168.0.0/24`** — нет. Пакет уходит с source `192.168.6.x`.
Проверка показала, что 80 порт всё равно отвечает (GPON, судя по всему, маршрутизирует
обратно), поэтому это **не блокер**, но и не гарантия.
2. **ICMP** — `Allow-upstream-LAN` в nft по-прежнему только `tcp`+`udp`, без `icmp`.
Значит **пинг из LAN в `192.168.0.0/24` не работает до сих пор**, хотя TCP/UDP проходит.
Не путать «не пингуется» с «не работает».
### План ремонта (исходный, для истории)
```sh
# 1. ip rule — расширить bypass на GPON-сегмент ← СДЕЛАНО
ip rule add to 192.168.0.0/24 lookup main priority 100
# 2. та же строка в /etc/rc.local ← СДЕЛАНО
# 3. firewall: Allow-upstream-LAN dest_ip += 192.168.0.0/24, добавить proto icmp ← НЕ сделано
# 4. проверить, что masq зоны wan покрывает 192.168.0.0/24 ← НЕ сделано
```
Порядок работ по боевому конфигу: коммит ДО → правка → заливка → проверка Алекса руками → коммит ПОСЛЕ.
Три причины: (1) `ip rule 100` покрывает только `192.168.2.0/24` — трафик на `192.168.0.0/24` не матчится и уходит в `table vpn`/`tun0` вместо WAN; (2) нет NAT/masq для GPON-сегмента — пакет уходит с source `192.168.6.x`, ответ не может вернуться; (3) `Allow-upstream-LAN` создан только для `tcp`+`udp`, **без `icmp`** — ICMP из LAN падает в KillSwitch, и роутер сам отдаёт `Destination Port Unreachable`. Поэтому **пинг не индикатор**: для `192.168.0.0/24` он врёт так же, как для `192.168.2.0/24`. Проверять только тем каналом, которым будете работать (SSH/TCP), напр. `nc -zv 192.168.0.50 80` или `ssh -o BatchMode=yes`.
## Downstream LAN Access
```text
@@ -765,6 +799,10 @@ Firewall backup from Cloudflare direct-bypass change:
/etc/config/firewall.bak.20260714-195530
```
Роутинг через туннель (`tunvpn`) — 2026-07-14.
Firewall/Cloudflare bypass — 2026-07-14.
GPON-транзит (`ip rule` на `192.168.0.0/24`) — 2026-09-17.
Rollback example:
```sh
@@ -783,6 +821,18 @@ uci commit dhcp
/etc/init.d/dnsmasq restart
```
Rollback GPON-транзита (2026-09-17):
```sh
# живая система
ip rule del to 192.168.0.0/24 lookup main priority 100
# постоянство
cp /etc/rc.local.bak.20260917-132639 /etc/rc.local
```
> ⚠️ Правки `/etc/rc.local` на роутере делать **только** через `scp`-вниз → `patch` локально →
> `scp`-наверх. `sed -i` по живому конфигу запрещён.
## Notes And Pitfalls
- The Cloudflare bypass depends on Mac `cloudflared` using QUIC. If the Mac falls back to HTTP/2/TCP/443, the router exception will not match.
@@ -792,8 +842,8 @@ uci commit dhcp
- The firewall allow alone would not be sufficient, because policy routing rule `101` sends LAN ingress to `table vpn`. The direct `ip rule`s at priorities `98` and `99` must remain before priority `101`.
- Rule order in `forward_lan` matters: Cloudflare direct allow must stay above `KillSwitch`.
- `eth0` is the **active** WAN as of 2026-09-17 (`192.168.2.157/24`, gw `192.168.2.2`); `usb0` is idle. At the 2026-07-22 capture this was inverted (`eth0` down, `usb0` carrying the default route). Do not trust the old banner — re-read `ip route` before assuming which WAN is live.
- 🔴 **Транзит из LAN `192.168.6.0/24` в GPON-сегмент `192.168.0.0/24` НЕ работает (2026-09-17).** Причин три: `ip rule 100` не покрывает `192.168.0.0/24`; нет NAT/masq для этого направления; ICMP не разрешён в `Allow-upstream-LAN`. План ремонта — в одноимённом разделе. **Пока не применён.**
- 🔴 **ICMP не является индикатором доступности `192.168.0.0/24` — и подавно.** `Allow-upstream-LAN` создан только для `tcp`+`udp`, поэтому эхо-запросы из LAN падают в `KillSwitch` и роутер отвечает `Destination Port Unreachable` от себя. Проверять TCP-портом (`nc -zv 192.168.0.50 80`) или SSH.
- 🔴 **Транзит из LAN `192.168.6.0/24` в GPON-сегмент `192.168.0.0/24` — ЧАСТИЧНО ПОЧИНЕН (2026-09-17).** `ip rule` добавлено (живая система + `/etc/rc.local`), Alex проверил 80 порт на `192.168.0.50` — работает. Было три причины: `ip rule 100` не покрывал `192.168.0.0/24` (✅ исправлено); нет NAT/masq для этого направления (❌ не сделано, не блокер); ICMP не разрешён в `Allow-upstream-LAN` (❌ не сделано). Подробности — в разделе «Транзит Rasputin → 192.168.0.0/24».
- 🔴 **ICMP по-прежнему не индикатор доступности `192.168.0.0/24`.** `Allow-upstream-LAN` создан только для `tcp`+`udp`, поэтому эхо-запросы из LAN падают в `KillSwitch` и роутер отвечает `Destination Port Unreachable` от себя. **Пинг в GPON-сегмент не работает даже после починки `ip rule`** — TCP/UDP при этом проходит. Проверять TCP-портом (`nc -zv 192.168.0.50 80`) или SSH.
- Различай два похожих симптома: `Destination Port Unreachable` **от роутера `192.168.6.1`** = локальное отбивание ICMP/firewall-ом, а не закрытый порт на хосте. Признак живости — ответ на TCP/SSH, а не текст ICMP-ошибки.
- 🔴 **Ping from Mac to an unreachable `192.168.2.x` host returns `Destination Port Unreachable` from `rasputin.lan (192.168.6.1)`, NOT a plain timeout.** This is the router rejecting the attempt — it does **not** mean the host is up with a closed port. Use `arp (incomplete)` + `100% packet loss` as the liveness signal. Confirmed 2026-09-15 (see the dedicated section above).
- Liveness of `192.168.2.0/24` hosts is best verified with the channel you intend to work through: key-based SSH (`ssh -o BatchMode=yes root@192.168.2.176 'uptime'`). Ping and web ports can mislead; an answered SSH session cannot.
family/how-to/zont-config-compiler.md
+100 -1
View File
@@ -36,6 +36,7 @@ updated: '2026-09-17g'
| **Конфиги** | `zont_config/` — свежие · `zont_config/archive/` — историчные |
| **Типы объектов** | [[family/tech/zont-config-object-types]] |
| **ZONT в общем контуре** | [[family/how-to/home-automation]] §6 |
| **Снять живой конфиг с прибора** | 🔴 `curl -s http://192.168.0.50/config.txt` — **без авторизации**, формат ровно как у парсера. См. [[family/tech/zont-api]] §6bis |
---
@@ -214,6 +215,8 @@ cd /Users/admin/Automation/HA-ZONT-Modbus
# 1. Снять текущий конфиг с контроллера → в zont_config/
# имя файла: config_<SN>_<SN>_<YYYY-MM-DD_HH-MM-SS>.txt
# ✅ Напрямую с контроллера, без авторизации (см. §5g):
curl -s http://192.168.0.50/config.txt -o zont_config/config_$(date +%Y-%m-%d_%H-%M-%S).txt
# 2. TXT → YAML
python3 config-to-yml.py zont_config/config_XXXX.txt > /tmp/zont.yml
@@ -306,7 +309,7 @@ diff A.txt B.txt # пусто = round-trip чистый
| 5 | Неизвестный тип объекта → exit 2, файл не создаётся | Смотреть stderr — там причина |
| 6 | `validate_config()` → exit 4 | Печатает `❌ VALIDATION ERRORS` + список причин; файл намеренно **не выдан** (вывод пустой) |
| 7 | Регистр без своего устройства / аналоговый выход с битой ссылкой | WARNING в stderr, конвертация продолжается — проверить ссылки вручную |
| 8 | Загрузка конфига в контроллер — **руками**, скрипты только конвертируют | Конвертер не имеет доступа к ZONT |
| 8 | Загрузка конфига в контроллер — **руками**, скрипты только конвертируют | Конвертер не имеет доступа к ZONT. ⚠️ **Снятие конфига — уже не ручное:** `http://192.168.0.50/config.txt` отдаёт весь конфиг без авторизации (§5g) |
| 9 | `INFRASTRUCTURE.md`, `docker-compose.yml`, `docker run.txt` в проекте — **исторический TrueNAS-стек** | Актуальный контур — [[family/how-to/home-automation]]. Не искать `modbus-bridge`/`mbusd` на NAS |
| 10 | Дополнительных зависимостей нет | Только `pyyaml` — `jsonschema`/`ruamel` не нужны |
| 11 | ✅ **ИСПРАВЛЕНО 2026-09-17** — Сценарий с >1 шагом падал (exit 2) | `config-to-yml.py` теперь цикл по всем шагам; `yml-to-config.py` пишет все `step_ids` |
@@ -498,6 +501,102 @@ scenarios:
---
## 5g. 🔴 Локальный эндпоинт контроллера: `http://192.168.0.50/config.txt`
**Факт (Alex, 2026-09-17):** контроллер отдаёт **весь конфиг** по HTTP **без авторизации**.
```
http://192.168.0.50/config.txt
```
| | |
|---|---|
| **Что отдаёт** | весь конфиг — тот же формат `#Z…` / `#S…`, что и файл из облака |
| **Авторизация** | **не требуется** |
| **Адрес** | `192.168.0.50` — локальный IP контроллера |
**Что это меняет:** снятие конфига с контроллера перестаёт быть ручной операцией через облако/UI —
его можно тянуть напрямую curl'ом из локальной сети.
```bash
# снять конфиг напрямую с контроллера
curl -s http://192.168.0.50/config.txt -o zont_config/config_$(date +%Y-%m-%d_%H-%M-%S).txt
```
> ⚠️ **Не проверено:** кодировка ответа (ожидается windows-1251, как в облачных выгрузках) и коды
> ответа при недоступности. Проверить `file`/`iconv` перед тем, как полагаться на байтовую идентичность.
>
> ⚠️ **Запись через этот эндпоинт не подтверждена.** Известно только чтение. Загрузка конфига в
> контроллер — по-прежнему руками (см. §5b питфолл 8). Не предполагать наличие POST.
---
## 5h. 🌐 API ZONT — что доступно (исследовано 2026-09-17)
Доки скачаны в проект: `zont_api_docs/` (`zont_api_docs.html` 250 KB, `zont_api_docs.txt`,
`convert.py` — воспроизводимая HTML→text сборка).
**Источник:** https://zont-online.ru/api/docs/
### 🔴 Главный вывод: конфиг через API недоступен
Публичное API — это **состояния и история**, не конфигурация.
- Слово `scenario` в доке — **0 вхождений**. `relay` — 1.
- Ни одного метода для типов `11 / 14 / 46 / 49` (сценарии, реле, шаги, условия).
- `z3k_config` (где живут Z-объекты) упоминается **только как ссылка на ID** в `load_data`.
Метода для работы с ним **нет**.
**Следствие:** конвертер `.txt ⇄ .yml` — **единственный** путь правки сценариев и реле.
Переписать управление на API нельзя, переписывать нечего.
### Все методы API (11 шт.)
| Метод | Что делает | Конфиг? |
|---|---|---|
| `devices` | читает устройства + настройки (`load_io: true` → ещё и состояния) | чтение |
| `update_device` | **меняет настройки** — термостат, режимы отопления, расписание, доверенные номера, баланс SIM, OpenTherm, `custom_controls` | ⚠️ узко |
| `set_io_port` | управления состоянием: `guard-state`, `siren`, `engine-block`, `webasto` | — |
| `send_custom_command` | послать пользовательскую команду по `command_id` (ZTC/Mega SX) | — |
| `load_data` | **история** за период: `temperature`, `events`, `z3k_*` (Delta-time Array) | — |
| `raw_events` | история событий | — |
| `temperature` / `thermostat_work` | показания датчиков / работа термостата | — |
| `custom_controls` | история пользовательских статусов | — |
| `ztc_state` | питание, GSM, Wi-Fi | — |
| `generate_archive` / `download_generated_archive` | выгрузка архива | — |
**Наш H-2000 PRO** из `update_device` получает только **отопление**: `thermostat_mode`,
`thermostat_mode_temps`, `thermostat_ext_mode`, `thermostat_ext_modes_config`, `tempschedule`,
`thermometers`, `ot_*` (OpenTherm).
### Аутентификация
1. `get_authtoken` (POST, с login/password) → `token`
2. Дальше — заголовок `X-ZONT-Token: <token>` (или Basic)
3. Обязательный заголовок `X-ZONT-Client: <email>`
4. На **403** — токен отозван, получать заново
Базовый URL: `https://my.zont.online/api/<метод>`
**Легковесный вариант:** https://my.zont.online/api/widget/v3
### Что это значит практически
| Задача | Как решать |
|---|---|
| Править сценарии, реле, датчики | **только конвертер** (типы 11/14/46/49) |
| Снять конфиг | `http://192.168.0.50/config.txt` без авторизации (§5g) |
| Залить конфиг | руками (UI/облако) — API записи конфига нет |
| Смотреть состояния реле/датчиков онлайн | `devices?load_io=true` — **можно** |
| История температур/событий | `load_data` — **можно** |
| Менять режимы отопления | `update_device` — **можно** |
**Рекомендация:** конвертер не выкидывать — он единственный путь к сценариям. API-обвязка
(мониторинг состояний + история + режимы отопления) — **отдельная задача**, которая
**дополняет** конвертер, а не заменяет его.
---
## 6. Состояние проекта (проверено 2026-09-17, вечер)
✅ **Конвертеры закоммичены — `199f2b1`.** Рабочее дерево чистое (после этого коммита).