# HP t610 — хост домашней автоматизации (HA OS) > Хост, на который переносится домашняя автоматизация с TrueNAS. > План переноса: [[family/plans/home-automation-migration-t610]] > Развёртывание сервисов: [[family/plans/t610-addons-deployment]] ## Основное | Параметр | Значение | |----------|----------| | Железо | HP t610 (AMD T56N 2×@1.65 ГГц, 4 ГБ DDR3, HDD WD2500BEVT 250 ГБ) | | ОС | Home Assistant OS 18.2 (generic-x86-64) | | HA Core | 2026.9.2 | | Supervisor | 2026.09.0 | | **IP** | **192.168.2.176** (DHCP-имя `homeassistant`, MAC `9c:8e:99:ef:3f:c5`) | | **Web UI** | **`http://192.168.2.176`** — ⚠️ **порт 80, не 8123!** | | SSH | `ssh -i ~/.ssh/id_rsa root@192.168.2.176` (через аддон Terminal & SSH) | | Сеть | 192.168.2.0/24, статический IP пока не закреплён на роутере | > ⚠️ **HA слушает порт 80, а не 8123.** Порт 8123 на t610 **закрыт**. Веб-морда открывается по `http://192.168.2.176` без указания порта. Проверено 2026-09-13 (curl вернул HTTP 200 и страницу Home Assistant). > 📌 **Первая установка HA OS ставит HA «с нуля»** — конфиги переносятся вручную (см. план миграции §5.6), НЕ через бэкап-снапшот. ## Подключение ```bash # HA UI (порт 80!) http://192.168.2.176 # SSH — только после установки аддона Terminal & SSH (core_ssh) ssh -i ~/.ssh/id_rsa root@192.168.2.176 ``` **Важно про SSH:** в HA OS SSH **выключен по умолчанию** — порты 22 и 22222 дают `Connection refused`. Включается **только через аддон** `core_ssh` (Terminal & SSH): Settings → Apps → Terminal & SSH → Install → положить свой публичный ключ в `authorized_keys` → Start. Пароля root для SSH не существует — вход только по ключу. > ⚠️ **Порт 22222 (debug SSH) на t610 закрыт** — debug-доступ не включён. Рабочий путь — аддон. ### Хостовый SSH (debug-SSH 22222) — как и зачем Порт **22222** даёт root-шелл **самого хоста HA OS** (не контейнера) — там есть `/etc/udev/rules.d`, `udevadm`, systemd. Это аналог того доступа, что был на TrueNAS. **Но включить его по сети НЕЛЬЗЯ** (проверено 2026-09-14): - `ha host` — ssh-команд нет (только reboot/shutdown/disks/options/logs) - Supervisor API `/host/services/ssh` → **403 Forbidden** (роль аддона `core_ssh` = `manager`, нужен `admin`) - `ha os import` — только импорт конфигов с флешки **Единственный штатный способ:** флешка (FAT32, метка тома **`CONFIG`**) с файлом `authorized_keys` (публичный ключ) в корне → воткнуть в t610 → перезагрузка/ожидание → порт 22222 открывается. > 📌 **На практике хостовый SSH на t610 не нужен:** задача алиасов serial решается штатным механизмом Supervisor — флагом `uart: true` (см. §USB → «РЕШЕНИЕ»). Хостовый шелл потребовался бы только для кастомных udev-правил, а они не требуются. ## Ограничения SSH-аддона (что доступно из шелла) Внутри аддона `core_ssh` **НЕТ** `docker` CLI и **НЕТ** `python3`. Есть: `bash`, `curl`, `jq`, `ha` (HA CLI), `ssh`, `ls`, `cat`. **Как управлять docker:** только через Supervisor — `ha docker info` (сам docker на хосте есть, v29.6.2, overlayfs/journald), но из аддона он не виден, т.к. аддон живёт в своём контейнере. Полноценный docker-compose на HA OS — нештатный путь; сервисы ставим **аддонами** (см. [[family/plans/t610-addons-deployment]]). **Скрипты для t610 писать на bash + jq**, не на python3. ## HA CLI (`ha`) — полезные команды ```bash ha info # общая информация ha core info # состояние HA Core ha supervisor info # список аддонов и репозиториев ha apps # список установленных аддонов + состояние ha apps info # детали аддона (в т.ч. options, схема) ha apps install # установить ha apps start|stop|restart ha apps logs # логи аддона ha store add # добавить репозиторий аддонов ha hardware info # железо + USB-устройства (tty, serial) ha host info # диск, версия OS, features ``` > ⚠️ `ha apps` **не умеет менять опции** (нет команды `options`). Настройка — через UI или Supervisor API (см. ниже). ### Диагностика USB/serial из аддона (udevadm НЕТ) В SSH-аддоне **нет `udevadm`** (`udevadm info` вернёт пусто / command not found). Атрибуты USB-устройств читать напрямую из **sysfs**: ```bash # все serial-симлинки (по id и по адресу шины) ls -la /dev/serial/by-id/ /dev/serial/by-path/ # для конкретного tty — найти sysfs-путь и прочитать атрибуты P=$(readlink -f /sys/class/tty/ttyUSB0/device) # базовый sysfs-путь for f in idVendor idProduct serial product manufacturer; do v=$(cat "${P%/*}/$f" 2>/dev/null); [ -n "$v" ] && echo "$f = $v" done # топология USB (какое устройство на каком контроллере/порту) lsusb lsusb -t # быстрый срез всех tty + их sysfs for d in ttyUSB0 ttyUSB1 ttyACM0; do echo "$d -> $(readlink -f /sys/class/tty/$d/device)"; done ``` > 📌 **Питфолл:** у двух CH340 (`1a86:7523`) поля `serial`/`manufacturer` **пустые** → их `by-id` совпадает. Различать только по `by-path` (адрес шины). Подробнее — §USB. ### Смена опций аддона через Supervisor API API доступен из аддона (`SUPERVISOR_TOKEN` уже в окружении): ```bash SLUG="a0d7b954_nodered" API="http://supervisor/addons/${SLUG}" AUTH="Authorization: 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" ``` > ⚠️ API требует **полный** набор опций — схема валидирует все ключи. Посылать только изменённое нельзя: вернёт `Missing option ''`. Берём текущие опции и меняем нужное. ## Доступ к роутерам (диагностика сети t610) t610 в сети `192.168.2.0/24`. Роутеры для проверки: | Роутер | Доступ | Особенность | |--------|--------|-------------| | `192.168.2.2` (OpenWrt, основной) | SSH root, пароль `1316261` | DHCP-аренды: `cat /tmp/dhcp.leases` | | `192.168.6.1` («Rasputin», OpenWrt aarch64) | SSH root | имеет eth0 `192.168.2.157/24` → видит сеть 192.168.2.x | > ⚠️ **ПИТФОЛЛ: `nc` на OpenWrt (busybox) НЕ поддерживает флаг `-z`.** `nc -z host port` молча печатает usage и возвращает неверный результат → ложный вывод «порт закрыт». Для проверки портов с OpenWrt использовать `curl -s -o /dev/null -w '%{http_code}'` или `wget`. Проверка портов с Mac через `nc -z` работает нормально. ## Диск и железо (проверено 2026-09-13, `ha host info`) | Параметр | Значение | |----------|----------| | Диск | WD2500BEVT (WD-WX31A60P2258), 228.5 ГБ | | Занято | 5 ГБ | | Свободно | 214.2 ГБ | | Docker (host) | 29.6.2, storage overlayfs, logging journald | | OS | `haos:18.2`, generic-x86-64, production | > 📌 Диск был взят из TrueNAS (бывший системный диск с Windows 7) — образ HA OS записан через `dd` с Mac. Подробности в [[family/plans/home-automation-migration-t610]] Шаг 1. ## USB-устройства (подключены 2026-09-14, карта зафиксирована) **Все 3 устройства физически подключены к t610** (проверено 2026-09-14). | Устройство | by-id | **by-path (фиксированная привязка)** | tty | Физический порт | |-----------|-------|--------------------------------------|-----|-----------------| | CH340 #1 | `usb-1a86_USB_Serial-if00-port0` | `pci-0000:00:12.0-usb-0:3:1.0-port0` | `/dev/ttyUSB0` | USB1 порт 3 (OHCI `pci-0000:00:12.0`) | | CH340 #2 | `usb-1a86_USB_Serial-if00-port0` ⚠️ **тот же** | `pci-0000:00:12.0-usb-0:4:1.0-port0` | `/dev/ttyUSB1` | USB1 порт 4 | | Zigbee Inswift ZBP-MG21 | `usb-Inswift_Zigbee_ZBP-MG21_535A000001-if00` | `pci-0000:04:00.0-usb-0:1:1.0` | `/dev/ttyACM0` | USB3 порт 1 (xhci `pci-0000:04:00.0`) | Sysfs-пути: ``` ttyUSB0 → /sys/devices/pci0000:00/0000:00:12.0/usb1/1-3/1-3:1.0/ttyUSB0 ttyUSB1 → /sys/devices/pci0000:00/0000:00:12.0/usb1/1-4/1-4:1.0/ttyUSB1 ttyACM0 → /sys/devices/pci0000:00/0000:00:15.3/0000:04:00.0/usb3/3-1/3-1:1.0 ``` ### ⚠️ ГЛАВНЫЙ ПИТФОЛЛ: два CH340 неразличимы по by-id Оба CH340 — `1a86:7523`, **`serial = `, `manufacturer = `, `product = "USB Serial"`** (одинаковые). → **by-id у обоих идентичен** (`usb-1a86_USB_Serial-if00-port0`). Проброс по by-id в аддонах **сломается** — оба аддона получат одно и то же устройство. **Различать только по `by-path`** (адрес шины) — ровно та же проблема, что была на TrueNAS, где алиасы `ttyZONT`/`ttyVent` делались udev-правилами по адресу шины ([[family/how-to/zont-modbus-bridge-udev-race-protection]]). **Zigbee-координатор** — единственный из трёх, у кого есть уникальный серийник (`535A000001`), поэтому его by-id стабилен и проброс по by-id безопасен. ### Различия by-path на t610 vs TrueNAS - TrueNAS: `KERNELS=="?-1.5"` / `"?-1.6"` (другая топология USB). - t610: путь `pci-0000:00:12.0-usb-0:3` и `...-0:4` — **порт 3 и порт 4** на одном OHCI-контроллере. Т.е. udev-правило на t610: `KERNELS=="1-3"` и `KERNELS=="1-4"`. ### 🔑 РЕШЕНИЕ: привязка по `by-path` (udev-алиасы на HA OS не нужны) **Как на TrueNAS — нельзя.** Там был хостовый шелл TrueNAS → `/etc/udev/rules.d/99-tty-alias.rules`. На t610 SSH-аддон = **Alpine-контейнер**: нет `/etc/udev/rules.d`, нет `udevadm`. Хостовый доступ = только **debug-SSH 22222**, но он **выключен** и включается **только флешкой** (`authorized_keys` в разделе с меткой `CONFIG`); по сети — никак: - `ha host` — ssh-команд нет - Supervisor API `/host/services/ssh` → **403 Forbidden** (аддон `core_ssh` имеет роль `manager`, нужен `admin`) - `ha os import` — только импорт конфигов с флешки **Рабочая схема — штатный `uart: true`:** - Флаг **`uart: true`** в манифесте аддона даёт контейнеру доступ ко **всем** serial-устройствам хоста, включая симлинки `/dev/serial/by-id/` **и** `/dev/serial/by-path/`. - Проверено на живом t610: `core_ssh` имеет `uart: true` → его `/dev/serial/by-path/` содержит все пути (таблица выше). z2m-аддон тоже `uart: true`. - **`devices:` прописывать не нужно** — проброс автоматический. **Что писать в конфигах сервисов:** ``` Zigbee (z2m): serial.port = /dev/serial/by-id/usb-Inswift_Zigbee_ZBP-MG21_535A000001-if00 (или by-path pci-0000:04:00.0-usb-0:1:1.0) ZONT (modbus-bridge): /dev/serial/by-path/pci-0000:00:12.0-usb-0:3:1.0-port0 (CH340 #1, порт 3) Вентиляция (mbusd): /dev/serial/by-path/pci-0000:00:12.0-usb-0:4:1.0-port0 (CH340 #2, порт 4) ``` Функциональный аналог TrueNAS-алиасов: имя не «прыгает» при перезагрузке. Отличие — вместо `ttyZONT` пишется полный by-path. > ⚠️ **by-path привязан к физическому порту** — CH340 #1 держать в порту 3, CH340 #2 в порту 4. Порты зафиксированы. > ✅ **Плюс аддонов:** старая проблема гонки udev ([[family/how-to/zont-modbus-bridge-udev-race-protection]]) на t610 **неактуальна** — Supervisor сам ждёт устройство при старте аддона, скрипты ожидания tty не нужны. ## Установленные аддоны (на 2026-09-13) | Аддон | Slug | Версия | Состояние | Порты | |-------|------|--------|-----------|-------| | Terminal & SSH | `core_ssh` | 10.4.0 | ✅ started | 22 | | Mosquitto broker | `core_mosquitto` | 7.1.1 | ✅ started | 1883 (MQTT), 1884 (WS) | | Node-RED | `a0d7b954_nodered` | 22.0.6 | ✅ started | 1880 | | File editor | `core_configurator` | — | ✅ started | web UI | | Samba share | `core_samba` | — | ⏸️ stopped (нужен пароль) | — | Дополнительно подключён репозиторий **Zigbee2MQTT** (`45df7312`, `Home Assistant App: Zigbee2MQTT`). > 📌 В HA 2026.x аддоны в UI называются **Settings → Apps** (не «Add-ons»). Пункта «Add-ons» в меню больше нет. ## Связанные заметки - [[family/plans/home-automation-migration-t610]] — план миграции (родительский) - [[family/plans/t610-addons-deployment]] — развёртывание аддонов - [[family/how-to/home-automation]] — карта slave ID, ZONT, регистры - [[family/how-to/truenas-access]] — доступ к TrueNAS - [[family/how-to/zont-modbus-bridge-udev-race-protection]] — гонка udev (на t610 неактуальна)