Files

T

Alexey Martemyanov 9ce79baab4 [2026-09-14] eagle: family/how-to/t610-access.md family/plans/home-automation-migration-t610.md family/plans/t610-addons-deployment.md

2026-09-14 10:02:52 +06:00

37 KiB

Raw Blame History

title, status, tags, created, updated, related

title

status

t610 — развёртывание через HA-аддоны

Статус (2026-09-14): Этап 1 ✅. Этап 2 ✅ ПОЛНОСТЬЮ (все 3 USB подключены, привязка by-path + uart: true, z2m работает — 16 устройств, mbusd работает — порт 502, modbus-bridge работает — MQTT + HA-опрос, в HA добавлена MQTT-интеграция). Этап 3 🔄 В РАБОТЕ — разведка выполнена, решения приняты (БД с нуля, реестры заменить, HACS на согласовании, Zigbee-имена чистить), ждём ответа Alex по 3 вопросам (HACS / схема имён / порядок). Родительский план: family/plans/home-automation-migration-t610 (Шаг 3 в нём заменяется на этот документ). Доступ к хосту, CLI и питфоллы: family/how-to/t610-access.

Ключевые решения (кратко, для быстрого входа в контекст)

Решение	Что выбрано	Почему
Формат развёртывания сервисов	HA-аддоны (не docker-compose)	из SSH-аддона host docker не виден; аддоны штатны и снимают udev-гонку
Источник z2m	community-repo `zigbee2mqtt/hassio-zigbee2mqtt`	в официальном сторе z2m нет
mbusd / modbus-bridge	local add-ons (`/addons/...`)	кастомный код, в сторе нет
Привязка CH340 (2 одинаковых адаптера)	`/dev/serial/by-path/...`	by-id у обоих идентичен (нет серийников)
Как аддон видит serial	флаг `uart: true` в манифесте аддона	даёт доступ ко всем serial (by-id + by-path) автоматически; `devices:` не нужен
udev-алиасы `ttyZONT`/`ttyVent`	отменены	на HA OS невозможны (SSH-аддон = Alpine-контейнер); by-path функционально эквивалентен
Доступ к хостовому шеллу	не нужен	debug-SSH 22222 включается только флешкой; всё делается через Supervisor API

Контекст: почему аддоны, а не docker-compose 1:1

Изначально в родительском плане (Шаг 3, Вариант B) предполагалось перенести docker-compose.yml с TrueNAS 1:1. При проверке живого t610 выяснилось:

HA OS 18.2 внутри использует host docker 29.6.2 (overlayfs, journald) — docker есть, ha docker info подтверждает.
Но из SSH-аддона docker CLI не виден — аддон живёт в своём контейнере. Доступ к host docker только через Supervisor (ha docker) или через Portainer-аддон.
Поэтому штатный и наименее хрупкий путь — аддоны.

Решение Alex (2026-09-13): «Делай всё аддонами».

Состав аддонов

Сервис	Slug	Источник	Статус
Mosquitto broker (MQTT)	`core_mosquitto`	Official (core)	✅ установлен, `started` (1883/1884)
Node-RED	`a0d7b954_nodered`	Community	✅ установлен, `started` (1880)
Advanced SSH & Web Terminal	`a0d7b954_ssh`	Community	✅ есть в сторе (запасной путь)
Terminal & SSH	`core_ssh`	Official	✅ установлен и работает
Samba share (для доступа к файлам)	`core_samba`	Official	⏸️ установлен, `stopped` (нужен `password`)
File editor	`core_configurator`	Official	✅ установлен, `started`
Zigbee2MQTT	`45df7312_zigbee2mqtt`	Community repo	✅ установлен, работает — 16 устройств
mbusd	`local_mbusd`	Local add-on (`/addons/mbusd`)	✅ установлен, работает — порт 502
modbus-bridge	`local_modbus-bridge`	Local add-on (`/addons/modbus-bridge`)	✅ установлен, работает — MQTT + HA-опрос
MQTT-интеграция в HA	`mqtt`	Config entry	✅ добавлена 2026-09-14 (была ОТСУТСТВОВАЛА → 22 сущности; стало 104, 69 Zigbee)

Про Zigbee2MQTT

В официальном сторе z2m нет (есть только deCONZ core_deconz и core_silabs_multiprotocol). Варианты:

A. Community-репозиторий z2m — у сообщества есть репо (https://github.com/zigbee2mqtt/hassio-zigbee2mqtt), добавляется как app repository, дальше штатная установка.
B. Local add-on — свой Dockerfile в /addons/zigbee2mqtt.

Решение: A (community repo) — меньше ручной работы, поддерживается сообществом, обновления через UI. ✅ Реализовано 2026-09-14.

Про mbusd и modbus-bridge

В сторе нет и быть не может (кастомный код). Только local add-ons:

/addons/mbusd/          → Dockerfile + config
/addons/modbus-bridge/  → Dockerfile + modbus_ha_bridge.py + config.yml

Local add-ons требуют Advanced Mode в профиле HA (Settings → Apps появляются только с ним) + репозиторий «Local apps» уже подключён (проверено: addons_repositories содержит Local apps).

✅ USB-устройства подключены (2026-09-14) — блокер снят

Все 3 устройства воткнуты и видны (карта by-id/by-path: family/how-to/t610-access §USB).

/dev/ttyUSB0 → CH340 #1  by-path: pci-0000:00:12.0-usb-0:3:1.0-port0  (порт 3)  → ZONT / modbus-bridge
/dev/ttyUSB1 → CH340 #2  by-path: pci-0000:00:12.0-usb-0:4:1.0-port0  (порт 4)  → Vent / mbusd
/dev/ttyACM0 → Zigbee Inswift ZBP-MG21  by-id: usb-Inswift_Zigbee_ZBP-MG21_535A000001-if00

⚠️ Два CH340 неразличимы по by-id (у обоих 1a86:7523, serial отсутствует) → привязка только по by-path / адресу шины.

🔑 РЕШЕНИЕ: привязка по `by-path` вместо udev-алиасов

Проверено на живом t610 (2026-09-14): udev-алиасы (ttyZONT/ttyVent) на HA OS не нужны и сделать их «как на TrueNAS» нельзя — SSH-аддон это Alpine-контейнер, у него нет /etc/udev/rules.d и нет udevadm. Хостовый доступ = только debug-SSH 22222, который на t610 выключен и включается лишь флешкой с ключом в разделе CONFIG (по сети — никак: ha host без ssh-команд, Supervisor API /host/services/ssh → 403, роль аддона manager).

Рабочая схема — штатный механизм Supervisor: uart: true.

В config.yaml (или config.json) аддона флаг uart: true даёт контейнеру доступ ко всем serial-устройствам хоста — вместе с симлинками /dev/serial/by-id/ и /dev/serial/by-path/.
Подтверждено: core_ssh имеет uart: true → из него виден весь /dev/serial/by-path/. z2m-аддон тоже имеет uart: true.
devices: в конфиг аддона прописывать НЕ надо — при uart: true проброс serial автоматический.

Как прописывать путь в конфиге сервиса:

# zigbee2mqtt (Settings → Apps → Zigbee2MQTT → Configuration → serial)
serial:
  adapter: ember
  port: /dev/serial/by-path/pci-0000:04:00.0-usb-0:1:1.0   # Zigbee — by-id тоже ок (уникальный серийник)

Для mbusd / modbus-bridge (local add-ons) — в их config.yaml/опциях указывать by-path:

ZONT  → /dev/serial/by-path/pci-0000:00:12.0-usb-0:3:1.0-port0
Vent  → /dev/serial/by-path/pci-0000:00:12.0-usb-0:4:1.0-port0

Это функциональный аналог udev-алиасов с TrueNAS: имя не «прыгает» при перезагрузке, привязка к физическому порту. Разница только в том, что вместо ttyZONT пишется полный by-path.

⚠️ by-path привязан к физическому порту. CH340 #1 обязан остаться в порту 3, CH340 #2 — в порту 4. Если поменять — пути поедут. Порты зафиксированы (проверено).

✅ z2m на t610 — ВЫПОЛНЕНО (2026-09-14)

Что сделано:

Бэкап с TrueNAS → Mac ~/tmp-t610/z2m-backup-20260914/ (database.db, configuration.yaml, state.json, coordinator_backup.json). Источник на TrueNAS: /mnt/RED_2TB/docker/zigbee2mqtt/.
Установлен аддон 45df7312_zigbee2mqtt v2.14.1-1 (community repo). Манифест содержит uart: true → доступ ко всем serial, devices: не нужен.
Mosquitto: добавлен логин zont (тот же пароль, что на TrueNAS) через Supervisor API → POST /addons/core_mosquitto/options → ha apps restart core_mosquitto. Нужен, чтобы HA-интеграция и ZONT продолжили работать по старым креденшелам.
Опции z2m (Supervisor API POST /addons/45df7312_zigbee2mqtt/options):

serial: { "port": "/dev/serial/by-id/usb-Inswift_Zigbee_ZBP-MG21_535A000001-if00",
          "adapter": "ember", "baudrate": 115200, "rtscts": false }
mqtt:   { "server": "mqtt://core-mosquitto:1883", "user": "zont", "password": "<как на TrueNAS>" }

База перенесена 1:1. ⚠️ data_path аддона = /config/zigbee2mqtt — внутри HA-конфига, НЕ /addon_configs/.... Создана /config/zigbee2mqtt/, залиты database.db + configuration.yaml (тот же network_key/pan_id/ext_pan_id/channel: 11, но serial → by-id, MQTT → core-mosquitto).
ha apps start 45df7312_zigbee2mqtt → работает.

Лог подтверждает успех (/config/zigbee2mqtt/log/<ts>/log.log):

zh:ember: [INIT TC] Adapter network matches config.
z2m: Coordinator firmware: EmberZNet 7.4.5 [GA], EZSP 13
z2m: Currently 16 devices are joined.
z2m: Connected to MQTT server

✅ 16 устройств на месте, переспаривание НЕ потребовалось. (Tuya: модули реле, диммеры, розетки, датчики t°/влажности, протечки, радар присутствия, светильник.)

Питфоллы z2m-переноса:

Пароль MQTT содержит $ (mqtt1z3$) → при передаче через sed/интерполяцию в шелле ломается экранирование, скрипт падает с unmatched '|'. Надёжный путь: файл configuration.yaml готовить локально, заливать копированием файла, значения с $ не подставлять в bash-строки. Для Supervisor API — JSON собирать через jq, а не конкатенацией.
Supervisor API требует полный набор опций (схема валидирует все ключи) — брать текущие и менять нужное.
Пароль в выводе ha/API маскируется как *** — это нормально, значение применяется.
uart: true = автоматический проброс всех serial (by-id + by-path). devices: в конфиг аддона прописывать не надо.
В SSH-аддоне нет python3, и он неустойчив к сложному экранированию строк — готовые конфиги заливать файлом, а не генерировать на хосте.

План по шагам

Этап 1 — базовые аддона (не требуют USB) — ✅ ВЫПОЛНЕНО 2026-09-13

Advanced Mode — не понадобился для CLI (всё сделано через ha apps), понадобится позже для local add-ons
Mosquitto broker (core_mosquitto v7.1.1) — установлен, started, порты 1883 (MQTT) + 1884 (WS) открыты, discovery отправлен в HA автоматически
Node-RED (a0d7b954_nodered v22.0.6) — установлен, started, порт 1880 открыт, уже подключился к HA (Connected to http://supervisor/core)
Samba share (core_samba) — установлен, но stopped: требует задать password (по умолчанию null) → логин homeassistant. Задать в UI: Settings → Apps → Samba → Configuration
File editor (core_configurator) — установлен, started
Репозиторий Zigbee2MQTT добавлен: ha store add https://github.com/zigbee2mqtt/hassio-zigbee2mqtt → появился как Home Assistant App: Zigbee2MQTT (slug 45df7312)
✅ HA MQTT-интеграция на core-mosquitto — ДОБАВЛЕНА 2026-09-14 (её не было → z2m/bridge не создавали сущности). Сущностей: 22 → 104 (69 Zigbee). Рецепт — §«HA MQTT-интеграция» ниже.

Питфоллы, выявленные при установке:

ha apps НЕ имеет команды для изменения опций (только install/start/stop/restart/logs/info/update/uninstall). Настройка опций — только через UI или Supervisor API (POST http://supervisor/addons/<slug>/options).
Node-RED по умолчанию ssl: true → падает при старте без сертификата (init-nginx: command exited 1, state: error). Фикс: ssl: false через API (см. ниже).
API требует полный набор опций (схема валидирует все ключи) — нельзя послать только {"ssl": false}, будет Missing option 'certfile'. Надо взять текущие опции и поменять нужное.
В SSH-аддоне нет python3 (только bash/curl/jq/ha). Скрипты для t610 писать на bash+jq.
ha store add <url> (не ha store repositories add).

Рабочий рецепт смены опций аддона (bash+jq через SSH-аддон):

SLUG="a0d7b954_nodered"
API="http://supervisor/addons/${SLUG}"
AUTH=*** Bearer ${SUPERVISOR_TOKEN}"
curl -s -H "${AUTH}" "${API}/info" | jq '.data.options | .ssl = false' > /tmp/o.json
jq -n --slurpfile o /tmp/o.json '{options: $o[0]}' > /tmp/post.json
curl -s -X POST -H "${AUTH}" -H "Content-Type: application/json" -d @/tmp/post.json "${API}/options"
ha apps restart "$SLUG"

⚠️ Если строка AUTH= выглядит искажённой — это артефакт маскировки секретов при записи доки. В живом скрипте: AUTH=*** Bearer ${SUPERVISOR_TOKEN}". Рабочие скрипты лежат на Mac в ~/tmp-t610/*.sh. Скрипты лежат локально: ~/tmp-t610/nr_set_ssl.sh.

Этап 2 — USB-устройства — ✅ ВЫПОЛНЕНО 2026-09-14

Alex втыкает 3 USB в t610 — ВЫПОЛНЕНО 2026-09-14. Порты зафиксированы: CH340 #1 → USB1 порт 3, CH340 #2 → USB1 порт 4, Zigbee → USB3 порт 1. Устройства из портов не вынимать!
Пути определены (ls /dev/serial/by-id/, by-path, sysfs) — подробная карта: family/how-to/t610-access §USB
Карта составлена: ttyUSB0 = CH340 #1 (ZONT), ttyUSB1 = CH340 #2 (Vent), ttyACM0 = Zigbee
СПОСОБ ПРИВЯЗКИ РЕШЁН 2026-09-14 — привязка по by-path, никаких udev-алиасов. Механизм: флаг uart: true в манифесте аддона даёт доступ ко всем serial включая /dev/serial/by-path/ (проверено на живом t610: core_ssh uart:true видит все by-path; z2m тоже uart:true). devices: прописывать не надо. Подробности: family/how-to/t610-access §USB. Блокер снят.
✅ z2m-аддон УСТАНОВЛЕН И РАБОТАЕТ (2026-09-14) — аддон 45df7312_zigbee2mqtt v2.14.1-1, serial по by-id, база перенесена 1:1, 16 устройств на месте, переспаривание не потребовалось. Подробности — §«z2m на t610 (ВЫПОЛНЕНО)» выше.
✅ mbusd local add-on СОБРАН И РАБОТАЕТ (2026-09-14) — slug local_mbusd, порт 502 открыт (проверено nc с Mac), устройство by-path CH340 #2 (порт 4). Подробности — §«Local add-ons mbusd / modbus-bridge» ниже.
✅ modbus-bridge local add-on РАБОТАЕТ (2026-09-14) — slug local_modbus-bridge, устройство by-path CH340 #1 (порт 3), конфиг валиден, MQTT подключён, 13 discovery-сообщений, HA-опрос работает (HA poll -> sensor..._temperature = 73.454). Плюс в HA добавлена MQTT-интеграция (её НЕ БЫЛО) — см. §«HA MQTT-интеграция» ниже.

✅ HA MQTT-интеграция + `ha.url` для modbus-bridge (2026-09-14)

Симптомы по цепочке: HTTP 401 при ha.url = http://supervisor/core → HTTP 404 при http://192.168.2.176:80 → в HA всего 22 сущности, Zigbee нет.

Причины (по порядку):

http://supervisor/core НЕ принимает пользовательский long-lived token — эндпоинт рассчитан на внутренний SUPERVISOR_TOKEN. С пользовательским токеном → 401. ✅ Правильный адрес: http://192.168.2.176:80 (прямой HA Core). Проверено curl'ом из аддона: supervisor/core → 401, 192.168.2.176:80 → 200.
404 — не из-за адреса, а из-за отсутствия MQTT-интеграции в HA: discovery-сообщения z2m/bridge не превращались в сущности (было 22 системные сущности).
После добавления MQTT-интеграции → сущностей 104 (69 Zigbee), опрос пошёл, 404 исчез.

Рецепт добавления MQTT-интеграции (Config Entry Flow API):

T=<long-lived token>
BASE="http://192.168.2.176/api/config/config_entries/flow"
FID=$(curl -s -X POST -H "Authorization: Bearer $T" -H "Content-Type: application/json" \
  -d '{"handler":"mqtt","show_advanced_options":false}' "$BASE" | jq -r .flow_id)
curl -s -X POST -H "Authorization: Bearer $T" -H "Content-Type: application/json" \
  -d '{"next_step_id":"addon"}' "$BASE/$FID"     # → "type":"create_entry" = готово

Проверка: jq -r '.data.entries[].domain' /config/.storage/core.config_entries | grep mqtt → mqtt. Скрипт: ~/tmp-t610/setup_mqtt_integration.sh.

⚠️ ПИТФОЛЛ: токен маскируется при подстановке в bash-переменную

Любая подстановка токена в echo/sed/переменную окружения давала в опциях заглушку <len 13> вместо токена.
Рабочий способ: записать токен в файл → scp на t610 (/tmp/ha_token.txt) → читать на месте TOK=$(tr -d '\n\r' < /tmp/ha_token.txt) → подавать через jq --arg t "$TOK". Не интерполировать в строки.
Проверка токена: curl -o /dev/null -w '%{http_code}' -H "Authorization: Bearer $T" http://192.168.2.176/api/ → 200 ок, 401 — токен от другого пользователя.
⚠️ Ложный след (не повторять): гипотеза «iss в JWT должен равняться core.uuid» — НЕВЕРНА. У рабочего токена iss=e75d1d6f..., core.uuid=d3b24dad... — не совпадают, и это норма. Единственный надёжный тест — HTTP-код на /api/.
Скрипты: ~/tmp-t610/{apply_token2.sh,setup_mqtt_integration.sh,verify_token.sh}, токен: ~/tmp-t610/ha_token.txt.

✅ Local add-ons mbusd / modbus-bridge — ВЫПОЛНЕНО (2026-09-14)

Структура (на t610, /addons/):

/addons/mbusd/            Dockerfile, config.yaml, run.sh
/addons/modbus-bridge/    Dockerfile, config.yaml, run.sh,
                          modbus_ha_bridge.py, data/config.template.tmpl

Локальные аддоны видны Supervisor как local_mbusd и local_modbus-bridge (repo local = «Local apps»).

mbusd (local_mbusd):

База: готовый образ 3cky/mbusd:latest (как на TrueNAS), НЕ сборка из исходников. В манифесте uart: true, порт 502/tcp.
run.sh генерирует /etc/mbusd/mbusd.conf из опций (/data/options.json через jq) и запускает mbusd -d -L - -c.
Опции: device = /dev/serial/by-path/pci-0000:00:12.0-usb-0:4:1.0-port0, speed 9600, mode 8n1, trx_control addc.
✅ Порт 502 слушается (nc -z 192.168.2.176 502 → OK).

modbus-bridge (local_modbus-bridge):

База: python:3.11-alpine + pyserial paho-mqtt py3-yaml py3-requests; uart: true, host_network: true.
run.sh: из /data/options.json берёт device/baudrate/ha_token/mqtt_user/mqtt_password, генерирует runtime /app/config.yml из шаблона (ha.url → http://192.168.2.176:80, mqtt.broker → core-mosquitto), экспортит env HA_TOKEN/MQTT_USER/MQTT_PASS и запускает modbus_ha_bridge.py.
Опции: device = /dev/serial/by-path/pci-0000:00:12.0-usb-0:3:1.0-port0, baudrate 9600, ha_token (183 симв.), mqtt_user = zont, mqtt_password.
✅ Конфиг валиден, serial открыт, sniffer работает, MQTT подключён, HA-опрос = 73.454 без ошибок.
⚠️ ha.url ОБЯЗАН быть http://192.168.2.176:80 — НЕ http://supervisor/core (тот требует SUPERVISOR_TOKEN и даёт 401 с пользовательским токеном).

Питфоллы local add-ons (HA OS 18.2) — важные:

${BUILD_FROM} в Dockerfile пустой, если нет build.yaml с базовыми образами по arch. Решения: (a) добавить build.yaml c build_from: {amd64: ..., aarch64: ...}, либо (b) взять готовый образ напрямую (FROM 3cky/mbusd:latest) — тогда build.yaml не нужен.
Supervisor парсит все *.yml/*.yaml в папке аддона РЕКУРСИВНО как манифесты → служебный шаблон конфига (config.template.yml) вызывает Invalid app config!. Фикс: переименовать в .tmpl (не .yml).
ENTRYPOINT базового образа перебивает CMD — контейнер запускал mbusd напрямую, минуя /run.sh → can't read config file /etc/mbusd.conf. Фикс: в Dockerfile ENTRYPOINT [] + CMD ["/bin/bash","/run.sh"].
После правки Dockerfile/манифеста нужен ha apps uninstall <slug> → ha store reload → ha apps install (обновление образа не подхватывается само).
Пакета mbusd в репозиториях Alpine НЕТ (apk add mbusd → no such package) — только готовый образ или сборка из исходников.
Сборка локальных аддонов идёт через docker buildx на хосте, занимает несколько минут, требует интернета (pull базового образа).

Рабочий рецепт диагностики сборки: ha apps install <slug> → при ошибке ha supervisor logs | tail -60 (там полный вывод docker build).

Этап 3 — перенос HA-конфига — 🔄 В РАБОТЕ (разведка 2026-09-14, решения приняты)

Решения Alex (2026-09-14):

История БД (home-assistant_v2.db, 142 МБ) — НЕ переносить, начинаем с нуля.
Реестры .storage — ЗАМЕНИТЬ (вариант B: взять реестры TrueNAS целиком, а не сливать). Zigbee-сущности пересоздадутся z2m автоматически по database.db + discovery. Минус: переименования entity_id, сделанные в UI на TrueNAS, потеряются.
HACS и custom_components — на согласование (см. §«Инвентарь custom_components»).
Zigbee generic-имена — привести к единому виду, пока реестр чистый (см. §«Zigbee friendly_name»).

Разведано: что на TrueNAS (`/mnt/RED_2TB/docker/ha/`)

Файл/папка	Размер	Решение
`configuration.yaml`	29 954 б (~30КБ)	✅ переносить + правка `modbus.host`
`automations.yaml`	7 045 б	✅ переносить
`scripts.yaml`	30 728 б	✅ переносить
`secrets.yaml`	161 б	✅ переносить
`scenes.yaml`	0 б	пусто, можно не тащить
`www/card-mod.js`	99 373 б	✅ переносить (на него ссылается `lovelace_resources`)
`www/floorplan/floor1_ha.svg`, `floor2_ha.svg`	131КБ + 198КБ	✅ переносить (нужны для дашборда `home_plan`)
`blueprints/`	3 файла, все штатные homeassistant	❌ не переносить (дефолтные)
`home-assistant_v2.db`	142 МБ (+`-wal` 1.9МБ)	❌ не переносить (решение: с нуля)
`home-assistant_v2.db.corrupt.2026-04-30*`	152 МБ	❌ не переносить
`.storage/`	35 файлов	⚠️ переносить выборочно — деление ниже
`custom_components/`	`hacs`, `localtuya`, `tuya_local`	⚠️ по инвентарю ниже

Версии совпадают: .HA_VERSION на TrueNAS и на t610 = 2026.9 (t610: 2026.9.2) → миграция реестров допустима.

`.storage` — что НЕЛЬЗЯ перезаписывать

⚠️ Копировать .storage/ целиком НЕЛЬЗЯ — там смешаны системные файлы t610 и контентные TrueNAS:

❌ НЕ трогать (идентичность/система t610): core.uuid (подменит instance_id), auth, auth_provider.homeassistant (сломает логин ha_admin), http, http.auth, onboarding, core.config, homeassistant.exposed_entities, core.config_entries (там уже правильная MQTT-интеграция t610).

✅ Переносить (контент):

core.entity_registry — КРИТИЧНО (без него entity_id не совпадут с configuration.yaml)
core.device_registry, core.area_registry, core.floor_registry, core.restore_state
lovelace.home_plan (+ .bak, .bak2), lovelace_dashboards, lovelace_resources
hacs.* (если HACS переносим), person, zone

Инвентарь `custom_components` (на согласование)

Компонент	Версия	Config entry	Решение
`localtuya`	5.2.3	✅ есть (Tuya-облако: client_id/secret, devices, region, user_id)	✅ переносить обязательно
`hacs`	2.0.5	✅ есть, но репозиториев НЕТ (`hacs.repositories` пуст)	⚠️ на согласование
`tuya_local`	2026.7.2	❌ нет	❌ не переносить

localtuya ставился вручную (не через HACS — репо HACS пусто). Он реально используется → перенос обязателен, иначе потеряются Tuya-устройства.

Порядок работ Этапа 3 (важно — не перепутать)

Бэкап текущего /config t610 → Mac (~/tmp-t610/config-t610-backup-<дата>/)
Бэкап нужного с TrueNAS → Mac
ha core stop (иначе HA перезапишет .storage при выходе)
Перенести реестры .storage (замена, выборочно по списку выше)
Перенести configuration.yaml + правка modbus.host → 127.0.0.1
Перенести automations.yaml, scripts.yaml, secrets.yaml, www/
Перенести custom_components/ (по согласованию)
Старт HA, проверка: конфиг валиден, сущности на месте, автоматизации, дашборд home_plan
ТОЛЬКО ПОСЛЕ этого — правка friendly_name в z2m + чистка entity_id в HA

⚠️ Порядок шагов 4 → 9 критичен: если переименовать z2m до переноса реестров, работа пропадёт (HA перезапишет реестр).

✅ Zigbee `friendly_name` — корень generic-имён (разведка 2026-09-14)

Найден корень: в z2m ВСЕ 16 устройств имеют friendly_name = свой hex-адрес (0xa4c13862d39377e6 и т.д.). Это состояние приехало с TrueNAS — HA их так не называл.

Проверено в /config/zigbee2mqtt/configuration.yaml (секция devices:) — у всех 16 friendly_name: '<hex>'.
В core.entity_registry на TrueNAS: entity_id вида sensor.0xa4c13862d39377e6_temperature, но original_name/name уже человеческие («Температура», «Влажность»).
Отдельная категория — вообще без имени: switch.0xa4c138f8da8bc478 (original_name пусто), switch.0xcc86ecfffe1347fd, switch.0x84fd27fffed9e137, update.0xa4c138f8da8bc478, light.0xa4c13882a4b42db0.

Корневой механизм: entity_id в HA формируется при первом появлении сущности и от friendly_name z2m. Уже созданные entity_id в реестре НЕ переименовываются автоматически при смене friendly_name. Поэтому нужны две операции: (а) friendly_name в z2m, (б) переименование entity_id в core.entity_registry HA.

Модели (из database.db, JSON-lines — НЕ sqlite): modelID пуст, но manufName даёт модель Tuya: _TZ3000_akqdg6g7, _TZ3000_gjnozsaz, _TZ3000_3a9beq8a, _TZ3000_hy6ncvmw, _TZE200_crq3r3la, _TZ3000_0e6uvexf, _TZ3000_5gey1ohx, _TZ3000_odzoiovu, _TZ3000_kvwrdf47, _TZ3210_nhqka112, _TZ3000_kccru4oi, _TZ3000_ooc8illt, _TZE204_qasjif9e, Zbeacon (протечка).

📌 Питфолл: база z2m database.db — это JSON Lines (объект на строку), НЕ SQLite. sqlite3 database.db → file is not a database. Читать: jq -r 'select(.type!="Coordinator") | [.ieeeAddr,.type,.manufName] | @tsv' z2m-live.db. Также в SSH-аддоне нет sqlite3 — базу копировать на Mac (scp → /Users/admin/tmp-t610/z2m-live.db).

Предлагаемая схема имён (на согласование с Alex): room_device в латинице snake_case (напр. dining_co2, kids_motion, bedroom_temp) — кириллица в entity_id нежелательна. Ждём подтверждения схемы от Alex перед переименованием.

Этап 4 — проверка и отключение TrueNAS

Чек-лист из родительского плана §6
Caddy upstream → t610; GPON-редирект → t610
Остановить + отключить автозапуск на TrueNAS (§7)

Отличия от родительского плана (что меняется)

Было (родительский план)	Стало (этот план)
docker-compose 1:1 на HA OS	HA-аддоны
udev-алиасы `99-tty-alias.rules` на t610	не нужно — аддоны с `uart: true` видят `/dev/serial/by-path/...` и `/dev/serial/by-id/...` автоматически; в конфиге сервиса указывается by-path
Скрипт ожидания tty + systemd	не нужно — Supervisor сам ждёт устройство при старте аддона
Ручной `docker compose up`	`ha apps start <slug>` / UI
Пути `/mnt/data/...`	`/addon_configs/<slug>/` и `/share`, `/config`
Хостовый SSH (как на TrueNAS)	недоступен — SSH-аддон = Alpine-контейнер; debug-SSH 22222 только через флешку `CONFIG`. Привязка serial решается штатным `uart: true`, хостовый шелл не нужен

✅ Плюс: проблема udev-гонки на t610 снимается — Supervisor управляет зависимостями и пробросом устройств. Это была самая опасная часть старого плана.

Открытые вопросы

✅ РЕШЕНО 2026-09-14 — способ привязки CH340 в аддонах: привязка по /dev/serial/by-path/...; механизм Supervisor — флаг uart: true в манифесте аддона (доступ ко всем serial автоматически, devices: не нужен). Проверено на живом t610. Детали: family/how-to/t610-access §USB.
✅ РЕШЕНО 2026-09-14 — куда переносить данные z2m: data_path аддона = /config/zigbee2mqtt (внутри HA-конфига), НЕ /addon_configs/. Туда залиты database.db и configuration.yaml.
✅ Проверено 2026-09-14 — совместимость community-repo z2m с HA OS 18.2 / Core 2026.9.2: работает (v2.14.1-1, координатор EmberZNet 7.4.5, 16 устройств).
✅ РЕШЕНО 2026-09-14 — uart: true для local add-ons: подтверждено на mbusd/modbus-bridge — в их манифестах uart: true, by-path виден, устройства открываются (mbusd порт 502, bridge sniffer на шине ZONT). Тот же механизм, что у z2m и core_ssh.
✅ РЕШЕНО 2026-09-14 — modbus-bridge ha_token/mqtt_password: вписаны, MQTT + HA-опрос работают. Ключевой момент — ha.url = http://192.168.2.176:80 (не supervisor/core), + в HA добавлена MQTT-интеграция. Этап 2 закрыт полностью.
Камера (§8 родительского плана) — не аддон, разбираться отдельно

Связанные заметки

family/plans/home-automation-migration-t610 — родительский план
family/how-to/home-automation — карта slave ID, ZONT, регистры
family/how-to/t610-access — доступ к хосту, CLI, карта USB, питфоллы
family/how-to/zont-modbus-bridge-udev-race-protection — старая проблема гонки udev (на аддонах неактуальна)
family/how-to/truenas-infrastructure — текущий docker-стек TrueNAS

37 KiB Raw Blame History Unescape Escape