> ⚠️ **ПЕРЕНОС ИДЁТ (начат 2026-09-12):** весь стек домашней автоматизации (HA, zigbee2mqtt, nodered, mosquitto, mbusd, modbus-bridge) переносится с TrueNAS на **HP t610** (HA OS). План со всеми путями/шагами и прогрессом: [[family/plans/home-automation-migration-t610]], детали развёртывания: [[family/plans/t610-addons-deployment]].
>
> **Статус на 2026-09-14 (Этап 2 закрыт):** ✅ на t610 работают HA Core, mosquitto (логин `zont`), Node-RED, **zigbee2mqtt (16 Zigbee-устройств, база перенесена 1:1)**, **mbusd (порт 502, шина вентиляции)**, **modbus-bridge (снифф 485-датчиков + MQTT + HA-опрос)** и **MQTT-интеграция в HA** (её не было → z2m/bridge не создавали сущности; стало 104 сущности / 69 Zigbee). ⏳ Осталось: Этап 3 — перенос HA-конфига (`configuration.yaml`, `.storage/core.entity_registry` и т.д.), затем Этап 4 — переключение трафика. **ZONT ещё НЕ перенаправлен** на MQTT t610 — редирект GPON-роутера и `modbus.host` в HA-конфиге пока смотрят на TrueNAS. Подробности: [[family/plans/t610-addons-deployment]].
> **Статус на 2026-09-14:** домашняя автоматизация **перенесена на HP t610** (HA OS). Всё про перенос, доступ к хосту, карту USB/Zigbee/аддоны, питфоллы и текущее состояние — в едином документе [[family/plans/t610-home-automation]]. **ZONT ещё НЕ перенаправлен** на MQTT t610 — редирект GPON-роутера пока смотрит на TrueNAS.
>
> Карты Slave ID и регистров ниже **остаются в силе** — оборудование и адреса Modbus не меняются.
@@ -513,4 +521,4 @@ P77 = 54321
```
Четыре способа управления тёплым полом. Термостаты я взял на али, от не очень понятного производителя, но дёшево и с вайфаем. Родное для него приложение Smart Life сразу увидело все три термостата и данные бодро пошли на китайские сервера Tuya. В качестве основного средства автоматизации и управления умным домом я выбрал опенсорсный сервер Home Assistant. Есть интеграции под все на свете, выглядит не убого и шустро работает на запылившемся на полке микрокомпьютере raspberry pi 3. Сперва я завёл интеграцию через официальный плагин от Tuya, зарегистрировавшись на их сайте IoT разработчиков и получив нужные ключи api. Теперь данные через китайские сервера шли на мой локальный. Но оказалось, что их api не умело все возможности моего термостата. Например он умеет показывать температуру воздуха и температуру самого пола. А через сервер приходила только температура воздуха. При этом родное приложение Smart Life умело все. Огорчившись, я нашёл неофициальную интеграцию Tuya девайсов для Home Assistant. Она умеет работать с данными девайсами локально, в обход китайских серверов. Но не поддерживает термостаты как класс. Поэтому я нашёл форк с поддержкой термостатов, сделал свой форк, дописал туда несколько строк на питоне для корректной работы именно моей модели, заодно сделал пул реквест и наконец-то заимел полнофункциональный термостат на своём локальном сервере. Ну а самим девайсам запретил ходить во внешний мир на роутере. И вишенкой на торте является интеграция с Apple HomeKit, куда Home Assistant умеет пробрасывать все девайсы. Теперь могу просить сири сделать потеплее) Многие из вас могли не понять примерно треть написанного. И это наглядная иллюстрация нынешнего состояния умных домов и простоты их настройки.
> ⚠️ **ОШИБКА В ПРЕДЫДУЩЕЙ РЕДАКЦИИ — ИСПРАВЛЕНО 2026-09-14 (поздняя сессия).** Ранее здесь было записано «блокер аппаратный: шина не подключена, работа за Alex». **ЭТО НЕВЕРНО — шина вентиляции РАБОТАЕТ.** Прямая проверка Modbus-запросами (регистры **из конфига HA**, не reg 0!) дала живые ответы: `slave 11 reg 5 → OK data=640001`, `slave 11 reg 8 → OK`, `slave 12 reg 1 → OK data=640001`, `slave 10 → OK` (значение 100), `slave 2 → OK`, `slave 3 → OK`, `slave 20 → OK`. Ответы **нестабильны** (то `OK`, то `EXC 0x0B`) — вероятная причина: короткий `timeout` mbusd (1000 мс) + `retries 3`, тогда как реле-модули заслонок отвечают медленно. **Что осталось выяснить:** почему HA не получает эти данные, хотя снаружи они есть (смотреть лог `homeassistant.components.modbus` в HA, а не mbusd). См. §«Диагностика шины вентиляции (mbusd)».
> 🔑 **CH340 привязывать ТОЛЬКО по `by-path`.** Доказано: у двух CH340 нет серийников → в `/dev/serial/by-id/` для них **один общий симлинк** (ведёт на `ttyUSB1`, на `ttyUSB0` ссылки нет). 🔴 Перепутывание кабелей CH340 #1/#2 **не даст ошибки** — аддоны поднимутся, но будут работать не с теми шинами. См. §«ГЛАВНЫЙ ПИТФОЛЛ».
>
> 🔑 **Ключевой вывод:** HA связывает сущности по **`unique_id`**, а не по `entity_id`. Смена `friendly_name` в z2m **сохраняет человеческие `entity_id`** — дублей нет.
> 🔑 **При переносе HA между инстансами теряются ВСЕ инстанс-локальные привязки** (устройства ре-регистрируются):
> - **`device_id`** — новый у каждого устройства → перемапить в `automations.yaml`/`scripts.yaml` по `identifiers` (`zigbee2mqtt_<ieee>`);
> - **ссылки на `entity_id`** в автоматизациях/дашбордах — не обновляются автоматически, даже если реестр переименован (грепать `[a-z_]+\.0x[0-9a-f]{16}` **везде**, включая `platform: state`-триггеры).
> Подробно: [[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]] §«ДОБАВЛЕНО В КОНЦЕ СЕССИИ» ③‑бис/③‑тер.
| Сеть | 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)
**Единственный штатный способ:** флешка (FAT32, метка тома **`CONFIG`**) с файлом `authorized_keys` (публичный ключ) в корне → воткнуть в t610 → перезагрузка/ожидание → порт 22222 открывается.
> 📌 **На практике хостовый SSH на t610 не нужен:** задача алиасов serial решается штатным механизмом Supervisor — флагом `uart: true` (см. §USB → «РЕШЕНИЕ»). Хостовый шелл потребовался бы только для кастомных udev-правил, а они не требуются.
## Ограничения SSH-аддона (что доступно из шелла)
Внутри аддона `core_ssh`**НЕТ**`docker` CLI и **НЕТ**`python3`.
**Как управлять 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 <slug> # детали аддона (в т.ч. options, схема)
ha apps install <slug> # установить
ha apps start|stop|restart <slug>
ha apps logs <slug> # логи аддона
ha store add <url> # добавить репозиторий аддонов
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-путь и прочитать атрибуты
# топология USB (какое устройство на каком контроллере/порту)
lsusb
lsusb -t
# быстрый срез всех tty + их sysfs
for d in ttyUSB0 ttyUSB1 ttyACM0;doecho"$d -> $(readlink -f /sys/class/tty/$d/device)";done
```
> 📌 **Питфолл:** у двух CH340 (`1a86:7523`) поля `serial`/`manufacturer` **пустые** → их `by-id` совпадает. Различать только по `by-path` (адрес шины). Подробнее — §USB.
### Смена опций аддона через Supervisor API
API доступен из аддона (`SUPERVISOR_TOKEN` уже в окружении):
> ⚠️ **ПРИМЕЧАНИЕ (2026-09-14):** в некоторых скриптах этой доки переменная токена при записи через инструменты выглядит как `AUTH="...***..."` — это артефакт маскировки секретов, а не рабочий код. В живом скрипте должно быть `AUTH="Authorization: Bearer ${SUPERVISOR_TOKEN}"`. Если строку с `AUTH` съело при редактировании — перезаписать файл целиком (см. `~/tmp-t610/*.sh` на Mac, они рабочие).
> ⚠️ API требует **полный** набор опций — схема валидирует все ключи. Посылать только изменённое нельзя: вернёт `Missing option '<key>'`. Берём текущие опции и меняем нужное.
### Long-lived token HA и обращение к API из аддонов (важно, 2026-09-14)
**⚠️ ПИТФОЛЛ 1 — токен маскируется в bash.** Если подставлять токен через переменную окружения / `echo` / `sed`, в итоговый JSON/опции попадает **заглушка** (наблюдалось `<len 13>` вместо реальных 183 символов). **Рабочий способ:** записать токен в **файл** → скопировать файлом на t610 → читать на месте:
```bash
TOK=$(tr -d '\n\r' < /tmp/ha_token.txt)
jq --arg t "$TOK"'.ha_token = $t' input.json > out.json
```
**⚠️ ПИТФОЛЛ 1б — маскировка СЪЕДАЕТ КАВЫЧКУ в скрипте.** Если в тексте bash-скрипта стоит литерал `Authorization: Bearer $TOK`, инструмент записи подменяет его заглушкой и **теряет закрывающую кавычку** → при запуске: `unexpected EOF while looking for matching '"'`. **Обход — собирать заголовок без литерала рядом с переменной:**
**⚠️ ПИТФОЛЛ 1в — круглые скобки `()` в строках `echo` внутри bash-скрипта** → `syntax error near unexpected token '('`. Не писать `(…)` в `echo "текст (пояснение)"`. То же для апострофов внутри одинарных кавычек.
**⚠️ ПИТФОЛЛ 1г — `jq '…\(…)'` инлайн в bash-скрипте ломается** → `syntax error near unexpected token ')'` / `unexpected EOF`. `jq`-выражения с интерполяцией (`"\(.state)\t\(.entity_id)"`) и вложенными кавычками писать **в отдельный файл**`q_*.jq` и вызывать `jq -rf q_x.jq`. Это самый устойчивый способ (проверено).
**⚠️ ПИТФОЛЛ 1д — сборка curl-заголовка с токеном.** Самый надёжный обход маскировки — файл-конфиг curl:
```bash
printf'header="Authorization: Bearer *** > /tmp/curl.auth # токен из файла, БЕЗ литерала в скрипте
Так в тексте скрипта токена нет → маскировщик не портит строку.
**⚠️ ПИТФОЛЛ 2 — адрес для аддона.** Внутри аддона `http://supervisor/core` требует **внутренний**`SUPERVISOR_TOKEN`, а пользовательский long-lived token там даёт **401**. Для обращения к HA Core из аддона использовать **прямой адрес**:
```
http://192.168.2.176:80 ✅ работает с пользовательским токеном (200)
http://supervisor/core ❌ 401 с пользовательским токеном
```
Это ровно то, что нужно modbus-bridge в его `ha.url` (см. [[family/plans/t610-addons-deployment]]).
`host_network: true` в манифесте аддона не обязателен для этого, но не мешает — `192.168.2.176` достижим и без него.
**⚠️ ЛОЖНЫЙ СЛЕД (не повторять):** гипотеза «`iss` в JWT должен совпадать с `core.uuid` HA» — **НЕВЕРНА**. У рабочего токена `iss` и `core.uuid` не совпадают (проверено: `iss=e75d1d6f…`, `core.uuid=d3b24dad…`), и это норма. Единственный надёжный критерий — HTTP-код на `/api/`.
### Добавление интеграции MQTT в HA (Config Entry Flow API)
Если в HA **нет MQTT-интеграции**, discovery-сообщения z2m/bridge уходят в mosquitto и **висят** — сущности не создаются (симптом: `404` при обращении к сущности; в HA только системные ~22 сущности).
| `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`)
> 📌 Диск был взят из TrueNAS (бывший системный диск с Windows 7) — образ HA OS записан через `dd` с Mac. Подробности в [[family/plans/home-automation-migration-t610]] Шаг 1.
→ **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]]).
**✅ Доказано на живом 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
> 🔴 **ОПАСНОСТЬ ТИХОГО СБОЯ: перепутывание кабелей.** CH340 №1 и №2 **физически неотличимы** — одинаковые VID:PID, название, отсутствуют серийники, стоят в одном корпусе. Если переткнуть кабели местами (ZONT ← порт 4, вентиляция ← порт 3), *оба аддона поднимутся без ошибок*, но будут работать **не с теми шинами**. Внешне это никак не проявится: Modbus-трафик пойдёт в чужой порт. Диагностируется только по аномальному трафику или по отсутствию ответов устройств.
>
> **Правило:** перед любым перетыканием записать, какой адаптер в каком порту, и сверить с картой ниже. Проверка «кто на шине» без физического вмешательства невозможна, если шина молчит (нет эталонного трафика для сравнения).
**Zigbee-координатор** — единственный из трёх, у кого есть уникальный серийник (`535A000001`), поэтому его by-id стабилен и проброс по by-id безопасен.
- 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 не нужны.
> 🔴 **ВНИМАНИЕ: предыдущая версия этого раздела была ОШИБОЧНОЙ.** Два ложных вывода, оба опровергнуты:
> 1. ~~«проблема аппаратная, линии A/B не подключены / шина обесточена, работа за Alex»~~ → **НЕВЕРНО. Шина работает, устройства отвечают.**
> 2. ~~«в логе mbusd только `conn_open/close` → запросы до порта не доходят»~~ → **НЕВЕРНО. Эти `conn_open` от `192.168.2.157` — МОИ СОБСТВЕННЫЕ запросы: Mac сидит за роутером, и через NAT все запросы к `192.168.2.176:502` выглядят как трафик от `.157` (роутер «Rasputin», eth0 `192.168.2.157`). Никакого «постороннего клиента, который жрёт слоты mbusd» не существует.**
### Как проверять шину ПРАВИЛЬНО
**Ключевая ошибка:** слать Modbus-запрос на **reg 0**. В конфиге HA заслонки читаются с **reg 5, 7, 8** (и т.д.), а не с 0. У молчащего устройства ответа не будет ни на одном регистре, у живого — ответ по своим регистрам. **Сначала смотреть адреса в конфиге:**
**Вывод:** шина вентиляции **живая**, mbusd **работает**, заслонки (11, 12) **отвечают**. Ответы **нестабильны** — один и тот же slave на reg 5 отвечает, на reg 7 нет.
**Гипотеза причины нестабильности:**`timeout = 1000 мс` в mbusd слишком короткий — реле-модули заслонок отвечают медленнее, mbusd не дожидается и отдаёт `0x0B` (`GATEWAY TARGET DEVICE FAILED TO RESPOND`). **Что делать:** поднять `timeout` до 3000 мс, `retries` снизить до 1, перезапустить `local_mbusd`, проверить, уйдут ли `unavailable` из HA.
**Что остаётся невыясненным:** почему HA видит `unavailable`, если снаружи данные приходят (44 `unavailable`: ~32 заслонки `intake_damper_*`/`exhaust_damper_*` + вентиляторы `fan_3_*`/`fan_at2_*`). **Смотреть нужно лог HA** (`homeassistant.components.modbus`, `pymodbus`), а НЕ лог mbusd — mbusd как транспорт исправен.
### Актуальные проблемы (не путать с «аппаратным блокером»)
| Порт слушается | `nc -z 192.168.2.176 502` | ✅ открыт |
| Устройство | `ha apps info local_mbusd \| grep -A8 'options:'` | `by-path ...0:4:1.0-port0` (CH340 #2, порт 4) ✅ |
| Параметры | там же | speed 9600, mode 8n1, **timeout 1000** ⚠️, retries 3, trx `addc` |
| Шина отвечает | Python-запрос на reg из конфига HA | ✅ **ДА** (см. таблицу выше) |
> ⚠️ **Не путать при диагностике:** раньше бытовало мнение «в логе mbusd `conn_open/close` от `.157` = посторонний клиент забивает слоты». **Это ложный след.** `.157` — это eth0 роутера Rasputin, через который идёт весь трафик из локалки 192.168.2.x; источник — сам Mac. Источник в логе mbusd — всегда адрес того, кто реально открывает TCP-соединение. ⚠️ **Также:** `nc` на OpenWrt (busybox) не поддерживает `-z` — для проверок портов с роутеров использовать `curl`/`wget`.
>
> ℹ️ **Конфиг HA modbus:** `configuration.yaml` → `modbus: [{name: rtu_bus, type: tcp, host: 192.168.2.176, port: 502}]`. Slave 10 (AT2 fans) **закомментирован** в конфиге с пометкой «not responding on vent bus» — чтобы не блокировать опрос заслонок. После починки шины — раскомментировать.
build.yaml ← ТОЛЬКО если базовый образ задаётся через ${BUILD_FROM} (см. питфолл 1)
```
**Жизненный цикл:**
```bash
ha store reload # Supervisor подхватывает /addons/* → local_<slug> в сторе
ha apps install local_<slug> # собирает образ (docker buildx) и ставит
ha apps start local_<slug>
ha apps logs local_<slug>
# при правке Dockerfile/манифеста:
ha apps uninstall local_<slug> && ha store reload && ha apps install local_<slug>
```
Настройка опций после установки — через UI или Supervisor API (`POST http://supervisor/addons/<slug>/options`, полный набор опций).
Диагностика провала сборки: **`ha supervisor logs | tail -60`** — там полный вывод docker build.
**⚠️ Питфоллы (все ловились на живом t610):**
1.**`${BUILD_FROM}` пустой** → `base name (${BUILD_FROM}) should not be blank`. Либо добавить `build.yaml` c `build_from: {amd64: <image>, aarch64: <image>}`, либо **взять готовый образ напрямую** (`FROM 3cky/mbusd:latest`) — тогда `build.yaml` не нужен.
2.**Supervisor рекурсивно парсит ВСЕ `*.yml`/`*.yaml` в папке аддона** как манифесты → служебный шаблон конфига даёт `Invalid app config!` и ломает загрузку. Фикс: держать шаблон с расширением **`.tmpl`** (например `data/config.template.tmpl`), переименовывать в `.yml` только внутри контейнера при сборке.
4.**Пакета может не быть в репозиториях Alpine** (`apk add mbusd` → `no such package`) — тогда только готовый образ из Docker Hub или сборка из исходников.
5.**Сборка идёт через `docker buildx` на хосте**, тянет базовый образ из интернета, занимает несколько минут.
6.**`uart: true`** в манифесте обязателен для доступа к `/dev/serial/by-path/…` (иначе аддон не увидит CH340/Zigbee). Для modbus-bridge дополнительно `host_network: true`.
7.В HA UI local add-ons требуют **Advanced Mode** в профиле (Settings → Apps).
8.**⚠️ Правка файлов аддона (`data/*.tmpl`, `*.py`) НЕ применяется без rebuild.** `run.sh` генерирует runtime-конфиг из копии **внутри образа** (`Dockerfile`: `COPY data/config.template.tmpl /app/config.template.yml`). После правки исходников обязателен **`ha addons rebuild local_modbus-bridge`** — иначе работает старая версия из образа и правки «не видно». Симптом ошибки: `ha addons rebuild <slug>` (команда долгая, ~1 мин).
> 📌 Из SSH-аддона `/addons/` **виден** (это `/addons/modbus-bridge`, без префикса `local_`); изначально казалось, что нет — проверять именно `/addons/<имя-папки>`.
> 📌 `<slug>` в URL аддона = `local_<имя папки>`. Опции из UI кладутся в `/data/options.json` внутри контейнера — читать через `jq`.
> 📌 z2m: `data_path` = **`/config/zigbee2mqtt`** (внутри HA-конфига, НЕ `/addon_configs/`). Там `database.db`, `configuration.yaml`, `coordinator_backup.json`, `log/`. Данные перенесены 1:1 с TrueNAS — подробности и питфоллы: [[family/plans/t610-addons-deployment]] §«z2m на t610 (ВЫПОЛНЕНО)».
> 📌 В HA 2026.x аддоны в UI называются **Settings → Apps** (не «Add-ons»). Пункта «Add-ons» в меню больше нет.
## Работа с данными z2m на t610 (2026-09-14)
**Файлы в `/config/zigbee2mqtt/`:**
| Файл | Что это |
|---|---|
| `database.db` | база z2m (устройства, endpoints, keys) |
| `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` обманчиво).
-`sqlite3 database.db "SELECT ..."` → **`Error: in prepare, file is not a database (26)`** — не тратить на это время.
- Читать через `jq` построчно (каждый объект = устройство):
-В SSH-аддоне **нет `sqlite3`** — базу копировать на Mac (`scp`) и разбирать там.
> 📌 **`modelID` в `database.db` пустой** (не заполнился при переносе базы 1:1), но `manufName` даёт модель Tuya — по ней определяется тип устройства.
> ⚠️ **Расхождение имён: HA vs z2m (главный вывод 2026-09-14, УТОЧНЁН).** Человеческие имена в z2m на TrueNAS **были** (`Насос обратки`, `Kitchen hood`, `Sauna`…), но на t610 они превратились в hex — z2m при старте дописал секцию `devices:` с `friendly_name` = IEEE (файл заливался без этой секции). В HA при этом `entity_id` остались человеческими — они правились вручную.
> | HA `entity_id` | ✅ человеческий (`switch.sauna`) | ✅ **сохранился из реестра** |
> | HA `original_name` | «Температура» (имя параметра) | то же |
>
> **Чтобы починить:** прописать `friendly_name` в z2m (= префикс существующих `entity_id`), перезапустить z2m. ⚠️ **`entity_id` при этом НЕ изменятся** — HA связывает сущности по `unique_id` (`<ieee>_<param>_zigbee2mqtt`), который не меняется. Дублей не возникает, автоматизации не ломаются. Полная таблица имён: [[family/plans/t610-addons-deployment]] §«КРИТИЧЕСКОЕ ОТКРЫТИЕ».
### Спаривание нового Zigbee-устройства (permit_join через MQTT, 2026-09-14)
В z2m-конфиге **`permit_join` не задан** → окно спаривания закрыто по умолчанию. Открывается штатно через MQTT-запрос (без UI):
```bash
# пароль MQTT берём из опций аддона БЕЗ интерполяции в строку ($ в пароле ломает bash)
ha apps info 45df7312_zigbee2mqtt --raw-json | jq -r '.data.options.mqtt.password' > /tmp/mqtt_pw.z2m
> ⚠️ **ЛИМИТ ОКНА СПАРИВАНИЯ = 254 секунды.** `"time": 300` → `error: Cannot permit join for more than 254 seconds`. Ставить **≤250**.
> ⚠️ **Спаривание через MQTT-запрос требует запуска ИЗНУТРИ контейнера аддона** (там есть `mosquitto_pub` и доступ к `core-mosquitto`). Если запускать через `ssh root@t610 'mosquitto_pub …'`, переменные окружения не пробрасываются — подставлять значения **локально в строку команды** (`. mqtt.env` → `CMD="mosquitto_pub … '$MQTT_USER' -P '$MQTT_PASS' …"` → `ssh … "$CMD"`), иначе `Connection Refused: not authorised`.
**Переименование устройства после спаривания (обязательный шаг):**
⚠️ **HA успевает создать сущности под hex-именем раньше, чем rename применяется** → после rename всё равно нужно чистить hex-`entity_id` в `core.entity_registry` (HA stop → jq → HA start). Подробно: [[family/plans/t610-addons-deployment]] §«Новое устройство: boiler_controller_power».
**Зона для нового устройства** ставится в **`core.device_registry`** (поле `area_id`), НЕ в `core.entity_registry`. Найти устройство по `identifiers`: `jq -r '.data.devices[] | select((.identifiers|tostring)|test("<ieee_без_0x>")) | [.id,.name,.area_id] | @tsv' /config/.storage/core.device_registry`.
- **`mosquitto_pub/sub` в аддоне НЕ поддерживают `--pwfile`** (`Error: Unknown option '--pwfile'`) — только `-u`/`-P`. Передавать пароль через переменную, прочитанную из файла (`$(cat)`), а не интерполировать в команду.
- **`ha apps logs <slug>` тяжёлый** — не ставить его в цикл ожидания (команда «висит» минутами). Ждать завершения интервью лучше через `database.db`/`state.json`, а не грепая логи в `while`.
> ✅ **Новое устройство 2026-09-14:** `0xa4c138eb6fbe9d19` — **NEO NAS-WR01B, Smart plug with electrical measurements** (розетка с измерением P/V/I/E), `powerSource: Mains (single phase)`. Заменяет прежний **Tuya Smart Plug** («Ввод воды греющий кабель») — Alex поменял его на Zigbee-розетку. `Successfully configured '0xa4c138eb6fbe9d19' (definition v0.0.1)`, discovery ушёл, сущности создались.
> ✅ **Новое устройство 2026-09-14 (поздняя сессия):** `0xa4c1381694217e10` → **`boiler_controller_power`** — **TS011F** (Tuya Smart Plug с измерениями), `manufName _TZ3000_gjnozsaz`, **Router / Mains**, зона **Котельная**. Питание контроллеров котлов. 13 сущностей переименованы из hex → `switch.boiler_controller_power` и т.д. **Итого в z2m 15 устройств.** Рецепт — §«Спаривание нового Zigbee-устройства» выше + [[family/plans/t610-addons-deployment]] §«Новое устройство: boiler_controller_power».
### Удаление мёртвого/ненужного устройств из z2m (2026-09-14)
Признак мёртвого: `state: unavailable`, в `state.json` записи нет, `lastSeen` в `database.db` — давно. Проверка:
`state.json` читать по пути **`/homeassistant/zigbee2mqtt/state.json`** (не `/config/zigbee2mqtt/`).
```bash
jq -r --arg i "0xcc86ecfffe1347fd"'select(.ieeeAddr==$i) | {ieeeAddr,lastSeen,interviewCompleted}' /config/zigbee2mqtt/database.db
**z2m сам** убирает устройство из `database.db` И из секции `devices:``configuration.yaml`. Проверка: `jq -r 'select(.type!="Coordinator") | .ieeeAddr' database.db | wc -l`.
### Перенос HA-конфига с TrueNAS на t610 (Этап 3, 2026-09-14)
**⚠️ НЕ переносить** (локальное для t610): `core.uuid` (подменит `instance_id`), `auth`, `auth_provider.homeassistant`, `http`, `http.auth`, `onboarding`, `core.config`, **`core.config_entries`** (⚠️ иначе потеряется настроенная MQTT-интеграция!), `core.analytics`, `frontend.*`, `hacs.*`, `repairs.*`.
**Процедура:**
```bash
# 1) бэкапы (Mac): tar -czf на t610 в /tmp + scp; с TrueNAS аналогично
# 2) стоп HA
ha core stop # проверить: curl http://192.168.2.176/ → 000
# 3) залить .storage реестры (cp), затем конфиги, затем www/
# 4) проверить: ha core check # пусто = ошибок нет
# 5) старт
ha core start # curl http://192.168.2.176/ → 200
```
**Проверка результата:**`jq '.data.entities|length' core.entity_registry` (на TrueNAS было 410), `jq '.data.areas|length' core.area_registry` (11), `jq -r '.data.entries[].domain' core.config_entries | grep mqtt` (должен остаться `mqtt`).
> ⚠️ **`lovelace.home_plan` ссылается на сущности по именам** — если дашборд ссылается на старую Tuya-розетку (`switch.vvod_vody_greiushchii_kabel`), заменить в файле на новую (`switch.heating_cable_plug`) **до** залива.
**Питфолл: `tar` не читает `auth`/`http`/`auth_provider`** (права `0600`, владелец root) — это норма, и они не нужны. Не считать ошибкой.
### Итог миграции (факты после запуска, 2026-09-14)
- API `200`, **248 сущностей**, 11 зон, MQTT-интеграция цела, ошибок в `home-assistant.log` нет.
- **`unknown` — норма середины работы:** z2m ещё публикует в hex-топики; сущности, питаемые от z2m, данных не получают. Работают modbus (заслонки), `sensor.dining_*`/`kids_*`/`bedroom_*` (sniffer), `shower_2_presence_sensor_*`, `light_sensor_stairs_*`. Лечится сменой `friendly_name` в z2m.
- **Сущности связаны по `unique_id`** (`<ieee>_<param>_zigbee2mqtt`) → смена `friendly_name` сохраняет `entity_id`, дублей нет.
## HA-конфиг: что где лежит (TrueNAS → t610, разведка 2026-09-14)
-`custom_components/` — `hacs` (2.0.5, **репо пусто → НЕ переносим**), `localtuya` (5.2.3, ~~используется~~ → **ОТКАЗ 2026-09-14**: Tuya-розетка заменена на Zigbee, компонент не нужен), `tuya_local` (2026.7.2, не используется)
-`home-assistant_v2.db` — 142 МБ, **не переносится** (решение: история с нуля)
**Решение по custom_components (2026-09-14, подтверждено Alex):**
| Компонент | Решение | Почему |
|---|---|---|
| `hacs` | ❌ не переносить | репозиториев в HACS ноль, нагрузки не несёт |
| `localtuya` | ❌ не переносить | обслуживал 1 Tuya-розетку («Ввод воды греющий кабель», IP 192.168.2.194); розетка заменена на Zigbee-розетку NEO NAS-WR01B (`0xa4c138eb6fbe9d19`) |
| `tuya_local` | ❌ не переносить | config entry отсутствовал → не использовался |
Итог: **`custom_components/` вообще не переносим.** В `configuration.yaml` убрать строку `localtuya: debug` (была единственной отсылкой к компоненту).
> 📌 **Как узнать, используется ли интеграция:** `jq -r '.data.entries[].domain' core.config_entries` — если домена нет, компонент не подключён. Наличие папки в `custom_components/` ≠ использование.
**⚠️ `.storage/` НЕ копировать целиком** — смешаны системные файлы t610 и контентные TrueNAS:
**Порядок критичен:** сначала реестры, **потом** (после старта HA) правка `friendly_name` в z2m и `entity_id` в HA. Переименование до переноса реестров пропадёт — HA перезапишет реестр.
### 🔴 Питфоллы переноса HA-конфига между инстансами (2026-09-14, дорого выучено)
**1. `device_id` НЕ переносятся.**`device_id` — UUID, генерируемый HA при регистрации устройства **в конкретном инстансе**. Даже с перенесённым `core.device_registry` MQTT-интеграция на новом хосте регистрирует устройства заново → выдаёт **новые**`device_id`.
**Следствие:** все автоматизации/скрипты с device-триггерами (в UI это почти все) падают с `Unknown device '<uuid>'` и получают `unavailable`.
**Лечение:** перемапить `device_id` в `automations.yaml`/`scripts.yaml` по `identifiers` (`[["mqtt","zigbee2mqtt_<ieee>"]]`):
⚠️ `entity_id` и `unique_id` — переносятся; `area_id`/`floor_id` — переносятся (задаются в реестре); `device_id` — **НЕТ**.
**2. `core.config_entries` нужен, если есть виртуальные сущности.**`switch_as_x`, `template`, helper'ы ссылаются на entry в `core.config_entries`. Не перенесёшь → сущности-сироты `unavailable`.
⚠️ **Конфликт:** на новом хосте `core.config_entries` свой (там свежая MQTT-интеграция). Если перенести целиком — потеряешь локальные интеграции; если не перенести — потеряешь `switch_as_x`/helpers. **Решение:** не переносить целиком, а **точечно добавить** нужные entry (мы так добавили 4 `switch_as_x`).
**3. HA не переименовывает `entity_id` при смене `friendly_name`.** Связь — по `unique_id` (у z2m `<ieee>_<param>_zigbee2mqtt`, не меняется). Смена `friendly_name` меняет MQTT-топики и `default_entity_id` в discovery, но `entity_id` в реестре остаётся старым → переименовывать вручную (`jq` по `core.entity_registry`).
**4. `switch_as_x` с hex-ссылкой.** Восстановленные entry могут ссылаться на старое hex-имя (`switch.0x84...`) → обязательно поправить `options.entity_id` на новое человеческое имя.
**Общий вывод для будущих переносов HA:** либо переносить конфиг+реестры **вместе с `core.config_entries`**, либо после переноса делать **два фикса**: (а) перемап `device_id`, (б) добор виртуальных entry. Иначе половина автоматизаций будет `unavailable`.
**5. hex-`entity_id` в `automations.yaml`/`scripts.yaml` — вторая поломка того же класса (открыта 2026-09-14).**
При переименовании реестра (`hex → человеческие entity_id`) **ссылки внутри `automations.yaml` НЕ обновляются**. После переименования реестра в автоматизациях остаются старые hex-имена (`light.0xa4c13882a4b42db0`, `switch.0xa4c13873b5c1575b`) — HA их не находит.
**Вывод: при переносе чистить ОБА вида ссылок — и `device_id`, и hex-`entity_id`.** Иначе автоматизация «чинится» наполовину.
**Систематическая проверка (перед заливкой):** собрать множество `device_id` из `automations.yaml`/`scripts.yaml` регексом `device_id:\s*([0-9a-f]{32})`, а hex-`entity_id` — `[a-z_]+\.0x[0-9a-f]{16}`; каждое сверить с реестром t610.
**6. `sudo` на TrueNAS не нужен для чтения реестров HA.**`/mnt/RED_2TB/docker/ha/.storage/*` — права 644, owner root → **читаются напрямую** (`scp truenas_admin@...:/mnt/.../core.device_registry .`). `sudo cat` падает с`a terminal is required to read the password` — sudo не требуется.
**7. ⚠️ `not_from: [unknown]` в триггерах кнопок — ломает первое нажатие после рестарта HA (открыта и закрыта 2026-09-14).**
Защита задумана верно: при старте HA состояние = `unknown`, затем устройство присылает реальный стейт — без защиты это выглядело бы как «переключение» и свет щёлкал бы сам. **Но стояла слишком широко** — блокировала и первое НАСТОЯЩЕЕ нажатие.
```yaml
trigger:
- platform:state
entity_id:switch.office_table_light_switch_l1
not_from:[unavailable, unknown] # ← убрать: блокирует первое нажатие
```
**Лечение:** убрать `not_from` из триггеров кнопок в `automations.yaml` (правится локально → `scp` → HA restart). Альтернатива — оставить защиту, но сузить (напр. `not_from: [unavailable]` только).
⚠️ **Питфолл-близнец: `mosquitto_sub -R` (retained-only) в аддоне ВРЁТ** — с ним вывод пустой даже там, где retained есть. Надёжный способ проверить retained — подписаться и смотреть, что прилетает **СРАЗУ** при подписке (retained мгновенно, живой трафик — только по событию).
**Общий вывод для будущих переносов HA:** либо переносить конфиг+реестры **вместе с `core.config_entries`**, либо после переноса делать **два фикса**: (а) перемап `device_id`, (б) добор виртуальных entry. Иначе половина автоматизаций будет `unavailable`.
### 🔍 Где искать человеческие имена устройств (важный урок 2026-09-14)
**В реестрах HA имён устройств НЕТ.** Проверено на TrueNAS: `core.entity_registry` содержит `original_name` = имя **параметра** («Температура», «Влага», «Занятость»), а не устройства; `name`/`name_by_user` — `null`. Все 16 датчиков t° называются «Температура» → **по `original_name` устройство не определить.**
**Три места, где реально лежат имена:**
1.**z2m** → `/config/zigbee2mqtt/configuration.yaml` → секция `devices:` → `friendly_name`. ✅ На TrueNAS там были человеческие имена (`Насос обратки`, `Kitchen hood`, `Sauna`, `Dimmer bed`...).
2.**HA `core.device_registry`** → `data.devices[].name`, связь через `identifiers: [["mqtt","zigbee2mqtt_0x…"]]`:
3.**Дашборд `lovelace.home_plan`** → `entity` в `picture-elements` — **самый надёжный** источник рабочей схемы имён (`switch.sauna`, `light.smart_light_office_left`, `binary_sensor.shower_2_presence_sensor_presence`...).
**Питфолл поиска по автоматизациям:** триггеры часто ссылаются на **`device_id`**, а не `entity_id`:
```yaml
triggers:
- type:battery_level
device_id:52266a1b4a9d301f0da0dfa6f97c4ea2 # ← имени нет
```
Поэтому `grep` по `entity_id` даёт пусто. Искать надо по `device_id` → `core.device_registry` → `identifiers` → IEEE.
**⚠️ Питфолл при переносе z2m:** если залить `configuration.yaml`**без секции `devices:`**, z2m при старте сам создаст её и пропишет `friendly_name` = IEEE для каждого устройства → hex-имена. Это и случилось на t610 2026-09-14 (человеческие имена с TrueNAS были потеряны). **Проверять секцию `devices:` сразу после переноса.**
> 📌 Полезно: имя устройства в z2m ≠ `entity_id` в HA. `entity_id` формируется при **первом появлении** сущности в HA и **не меняется** при смене `friendly_name`. Чтобы переименовать — нужно менять `entity_id` в `core.entity_registry` (или удалить сущность и дать создать заново).
**Полезные команды разведки конфига (из SSH-аддона на t610):**
```bash
ls -la /config/ # состав HA-конфига
ls /config/.storage/ | wc -l # число файлов реестра
jq -r '.data.entities | length' /config/.storage/core.entity_registry # число сущностей
cat /config/.HA_VERSION # версия HA
```
На TrueNAS аналогично, путь `/mnt/RED_2TB/docker/ha/` (читать под `truenas_admin`).
> 📌 **Как узнать, используется ли интеграция:** `jq -r '.data.entries[].domain' core.config_entries` — если домена нет, компонент не подключён (напр. `tuya_local` стоял в файлах, но config entry отсутствовал → не использовался).
## Связанные заметки
- [[family/plans/home-automation-migration-t610]] — план миграции (родительский)
- TrueNAS ≈ RPi4 по многопотоку (2 ядра против 4), но **вдвое выше в single-thread**. Сервисы HA/Node-RED/БД single-thread-зависимы → здесь TrueNAS выигрывает.
- **HP t610 — вдвое слабее обоих** (2011, Bobcat-ядро). Единственный плюс — x86-64, официальные образы встают без возни с ARM.
- 📌 **2026-09-12: t610 назначен хостом для переноса домашней автоматизации**(HA OS + zigbee2mqtt/mosquitto/nodered/mbusd/modbus-bridge). План: [[family/plans/home-automation-migration-t610]]. RAM 4 ГБ и HDD признаны достаточными (замер нагрузки не требуется).
- 📌 **2026-09-12: t610 назначен хостом домашней автоматизации.**Перенос **выполнен 2026-09-14** — см. [[family/plans/t610-home-automation]]. RAM 4 ГБ и HDD достаточны.
- **Jellyfin-транскод не тянет никто** из трёх (iGPU HD2500 у G2020 без современного кодека; RPi4/t610 — нет аппаратного пути).
> ⚠️ **ПЕРЕНОС НАЧАТ (2026-09-12):** вся домашняя автоматизация (HA, zigbee2mqtt, nodered, mosquitto, mbusd, modbus-bridge + камера) переносится с TrueNAS на **HP t610** (HA OS). Причина: TrueNAS на пределе RAM (17/21 ГБ). План и прогресс: [[family/plans/home-automation-migration-t610]]. Образ HA OS 18.2 скачан; запись на диск ждёт подтверждения. **TrueNAS-стек пока работает как есть — ничего не отключено.**
> ✅ **ДОМАШНЯЯ АВТОМАТИЗАЦИЯ ПЕРЕНЕСЕНА НА HP t610 (2026-09-14).** HA, zigbee2mqtt, mosquitto, mbusd, modbus-bridge переехали на **t610** (HA OS, `192.168.2.176`). Единый документ по t610 — [[family/plans/t610-home-automation]]. **TrueNAS-стек автоматизации пока работает как есть — не отключён** (отключение = Этап 4). Причина переноса: TrueNAS на пределе RAM (17/21 ГБ).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Alexey Martemyanov