[2026-09-14] eagle: family/how-to/t610-access.md family/plans/t610-addons-deployment.md
This commit is contained in:
Alexey Martemyanov
@@ -15,10 +15,11 @@
|
||||
> - **`area_id`** (зона устройства) — теряется → проставить заново по эталону;
|
||||
> - **ссылки на `entity_id`** в автоматизациях/дашбордах — не обновляются автоматически, даже если реестр переименован (грепать `[a-z_]+\.0x[0-9a-f]{16}` **везде**, включая `platform: state`-триггеры).
|
||||
> Подробно: [[family/plans/t610-addons-deployment]] §«ДОБАВЛЕНО В КОНЦЕ СЕССИИ».
|
||||
> 🔑 **z2m не публикует состояние пассивно** — реле остаются `unknown` до первого события. Живость проверять по **`lastSeen`** в `database.db`. После рестарта HA — физически нажать кнопки.
|
||||
> 🔑 **⚠️ `unknown` после рестарта HA ВОЗВРАЩАЕТСЯ — проверено экспериментом 2026-09-14.** Зафиксировано → `homeassistant.restart` → снято: всё, что было `on`/`off`, стало `unknown` (`office_table_light_switch`, `smart_light_office`, `heating_cable_plug`, `boiler_controller_power`). **`retain: true`, `cache_state`, `cache_state_persistent`, `cache_state_send_on_startup` в z2m стоят — но retained на топиках устройств не публикуется** (контроль: `zigbee2mqtt/bridge/state` retained **есть** → брокер умеет).
|
||||
> ✅ **РЕШЕНИЕ (применено 2026-09-14): `not_from: [unavailable, unknown]` убран из триггеров кнопок** в `automations.yaml`. Первое нажатие срабатывает, проверено на живом. Бэкап `/config/automations.yaml.bak-20260914-131541`.
|
||||
> 🔑 **Кэш состояний z2m лежит в `/homeassistant/zigbee2mqtt/state.json`** (НЕ в `/config/zigbee2mqtt` и не в `/addon_configs` — искать `find / -name state.json`). Плоский JSON `{ieee: {param: value}}`, пишется при каждом событии. Полное описание и таблица «до/после»: [[family/plans/t610-addons-deployment]] §«ДОБАВЛЕНО В КОНЦЕ СЕССИИ» ③‑бис.
|
||||
> 🔑 **z2m не публикует состояние пассивно** — реле остаются `unknown` до первого события. Живость проверять по **`lastSeen`** в `database.db`. После рестарта HA состояния **возвращаются сами через ~40–60 с** (birth-message), принудительно нажимать кнопки НЕ нужно.
|
||||
> 🔑 **⚠️ `unknown` после рестарта HA — РАЗОБРАНО И РЕШЕНО (2026-09-14).** При рестарте всё, что было `on`/`off`, становится `unknown` — но **состояния возвращаются САМИ через ~40–60 с**, без физических нажатий. Механизм: z2m слушает `homeassistant.status_topic` (`homeassistant/status`); когда HA стартует, z2m видит birth-message и **переопубликовывает состояния всех устройств**. `retain: true` + `cache_state*` для этого **НЕ нужны** (retained на топиках устройств фактически не публикуется — контроль: `zigbee2mqtt/bridge/state` retained есть, значит дело не в брокере; причины: `cache_state_send_on_startup` отдаёт состояние, пока HA ещё не подписан).
|
||||
> ✅ **РЕШЕНИЕ (применено 2026-09-14): `not_from: [unavailable, unknown]` убран из триггеров кнопок** в `automations.yaml` — иначе первое нажатие после рестарта блокировалось. Проверено на живом, оба канала. Бэкап `/config/automations.yaml.bak-20260914-131541`. Полностью: [[family/plans/t610-addons-deployment]] §«ДОБАВЛЕНО В КОНЦЕ СЕССИИ» ③‑тер.
|
||||
> ⚠️ **Окно нестабильности:** между «HA поднялся» и приходом birth-message (десятки секунд) реле = `unknown` — нажатие в это окно может не сработать.
|
||||
> 🔑 **Кэш состояний z2m лежит в `/homeassistant/zigbee2mqtt/state.json`** (НЕ в `/config/zigbee2mqtt` и не в `/addon_configs` — искать `find / -name state.json`). Плоский JSON `{ieee: {param: value}}`, пишется при каждом событии. Таблица «до/после»: [[family/plans/t610-addons-deployment]] §«ДОБАВЛЕНО В КОНЦЕ СЕССИИ» ③‑бис/③‑тер.
|
||||
|
||||
## Основное
|
||||
|
||||
@@ -245,6 +246,27 @@ ttyACM0 → /sys/devices/pci0000:00/0000:00:15.3/0000:04:00.0/usb3/3-1/3-1:1.0
|
||||
|
||||
**Различать только по `by-path`** (адрес шины) — ровно та же проблема, что была на TrueNAS, где алиасы `ttyZONT`/`ttyVent` делались udev-правилами по адресу шины ([[family/how-to/zont-modbus-bridge-udev-race-protection]]).
|
||||
|
||||
**✅ Доказано на живом t610 (2026-09-14):** в `/dev/serial/by-id/` для двух CH340 существует **ровно ОДИН симлинк** — `usb-1a86_USB_Serial-if00-port0 → ttyUSB1` (занял тот, кто зарегистрировался последним). **Ссылки на `ttyUSB0` через by-id нет вообще.** Значит by-id не просто «неоднозначен» — он физически не может адресовать второй адаптер.
|
||||
|
||||
```
|
||||
by-id:
|
||||
usb-1a86_USB_Serial-if00-port0 -> ../../ttyUSB1 ← один на два CH340
|
||||
usb-Inswift_Zigbee_ZBP-MG21_535A000001-if00 -> ../../ttyACM0
|
||||
```
|
||||
|
||||
**Проверка серийников (доказывает причину):**
|
||||
```bash
|
||||
for d in 1-3 1-4; do
|
||||
echo -n "$d serial: "; cat /sys/bus/usb/devices/$d/serial 2>/dev/null || echo '(ПУСТО)'
|
||||
done
|
||||
# 1-3 serial: (ПУСТО) ← CH340 в порту 3
|
||||
# 1-4 serial: (ПУСТО) ← CH340 в порту 4
|
||||
```
|
||||
|
||||
> 🔴 **ОПАСНОСТЬ ТИХОГО СБОЯ: перепутывание кабелей.** CH340 №1 и №2 **физически неотличимы** — одинаковые VID:PID, название, отсутствуют серийники, стоят в одном корпусе. Если переткнуть кабели местами (ZONT ← порт 4, вентиляция ← порт 3), *оба аддона поднимутся без ошибок*, но будут работать **не с теми шинами**. Внешне это никак не проявится: Modbus-трафик пойдёт в чужой порт. Диагностируется только по аномальному трафику или по отсутствию ответов устройств.
|
||||
>
|
||||
> **Правило:** перед любым перетыканием записать, какой адаптер в каком порту, и сверить с картой ниже. Проверка «кто на шине» без физического вмешательства невозможна, если шина молчит (нет эталонного трафика для сравнения).
|
||||
|
||||
**Zigbee-координатор** — единственный из трёх, у кого есть уникальный серийник (`535A000001`), поэтому его by-id стабилен и проброс по by-id безопасен.
|
||||
|
||||
### Различия by-path на t610 vs TrueNAS
|
||||
@@ -344,7 +366,7 @@ ha apps uninstall local_<slug> && ha store reload && ha apps install local_<slug
|
||||
| `database.db` | база z2m (устройства, endpoints, keys) |
|
||||
| `configuration.yaml` | конфиг z2m: `network_key`, `pan_id`, `ext_pan_id`, `channel`, `serial`, `mqtt`, **секция `devices:` с `friendly_name`** |
|
||||
| `coordinator_backup.json` | бэкап координатора |
|
||||
| `state.json` | ⚠️ **в этой папке его НЕТ.** Живой кэш состояний: **`/homeassistant/zigbee2mqtt/state.json`** (искать `find / -name state.json`) — плоский JSON `{ieee: {param: value}}`, пишется при каждом событии; z2m переопубликовывает его при старте (`cache_state_send_on_startup: true`). Содержит `state_l1`/`state_l2` (TS0002) и `state_left`/`state_right` (TS0012) — именно из него видно «запомненный на момент перезагрузки» стейт реле. |
|
||||
| `state.json` | ⚠️ **в этой папке его НЕТ.** Живой кэш состояний: **`/homeassistant/zigbee2mqtt/state.json`** (искать `find / -name state.json`) — плоский JSON `{ieee: {param: value}}`, пишется при каждом событии. Содержит `state_l1`/`state_l2` (TS0002) и `state_left`/`state_right` (TS0012) — именно из него видно «запомненный на момент перезагрузки» стейт реле. ⚠️ **Отдаётся в HA не мгновенно:** при старте HA публикуется в момент, когда HA ещё не подписан, поэтому реально состояние доходит через **birth-message** (`homeassistant/status`) — z2m видит старт HA и переопубликовывает. Задержка ~40–60 с. |
|
||||
| `log/<ts>/log.log` | логи запуска |
|
||||
|
||||
**⚠️ ПИТФОЛЛ: `database.db` — это НЕ SQLite, а JSON Lines** (по одному JSON-объекту на строку, расширение `.db` обманчиво).
|
||||
|
||||
Reference in New Issue
Block a user