🏠 Умный дом — автоматика

Статус на 2026-09-14: домашняя автоматизация перенесена на HP t610 (HA OS). 📌 Всё про миграцию — хост, доступ, карта USB/гнёзд, аддоны, Zigbee, питфоллы, текущее состояние — в единственном документе family/plans/t610-home-automation. НЕ дублировать сюда. 📌 Этот документ — справочник по ЖЕЛЕЗУ: AT2 (параметры/PWM), карта Slave ID, регистры заслонок/реле, ZONT relays. Оборудование и адреса Modbus при миграции не меняются. Текущее состояние: unavailable в HA — 8 (было 44 → 10 → 8). Оставшиеся все известные: 7 — slave 10 (AT2 fans, блок закомментирован, задача снята Alex) + 1 — todo.shopping_list (системная). Первопричина массового отвала была в перепутанных гнёздах аддонов (mbusd↔modbus-bridge) — исправлено обменом привязок; ещё 2 (dining_summary/dining_air_summary) ожили после фикса сборки кадров bridge (коммит 3748feb). Zigbee-реле котла заведено (вечер-13): switch.boiler_controller_power → slave 104, рег. 1 (bidirectional), ✅ подтверждено Alex. Детали — ниже (карта Slave ID) и family/plans/t610-home-automation §5-кватер-И-7.

📷 Камера — ✅✅ ФИНАЛЬНАЯ СХЕМА (2026-09-14, вечер-13): USB-вебка Logitech 046d:0825 (смотрит на счётчик газа/воды BK-G4T) физически на t610, отдаёт только MJPEG. Работает через аддон a889bffc_go2rtc-hardware (в нём ffmpeg) → транскод MJPEG→H.264 отдельным ffmpeg:-источником → RTSP rtsp://192.168.2.176:8554/usb_camera_h264 → в HA Generic Camera camera.192_168_2_176 («Камера котельной», зона kotelnaia, unique_id 01M2FX50K72X2RSYY549QSG3XP, rtsp_transport: tcp). WebRTC в приложении HA работает (подтверждено Alex). 🔄 Поворот 90° добавлен (камера стоит криво): суффикс #rotate=90 в ffmpeg:-строке /config/go2rtc.yaml. Нативный параметр go2rtc (дока go2rtc.org/internal/ffmpeg/), работает при транскодинге. Поток стал 480x640. ✅ Направление подтверждено Alex: «в ту» — значение 90 верное. Бэкап /config/go2rtc.yaml.bak-rotate-20260914-202817. ❌ ОПРОВЕРГНУТО (вечер-11/13): прежние записи в этом документе — «схема camera: platform: ffmpeg (camera.usb_camera)», «СХЕМУ МЕНЯЕМ, вечер-10», «зоне назначить нельзя, нет unique_id» — устарели. YAML-ffmpeg-камера была отвергнута (Resource busy, нет unique_id), заменена на local_ustreamer (вечер-11), затем на go2rtc-hardware (вечер-13). У финальной Generic Camera unique_id ЕСТЬ, зона kotelnaia назначена. Каноны и питфоллы — family/plans/t610-home-automation §5-кватер-И-6 (КАНОН-1: синтаксис v4l2; КАНОН-2: поворот #rotate=). ⚠️ Камера = ОДИН процесс. ustreamer и go2rtc вместе → залипание USB (Failed to resubmit video URB (-1)), лечится только power-cycle. local_ustreamer → boot: manual, stopped — оставлен для отката.

✅ ZONT MQTT — ПЕРЕНАПРАВЛЕН 2026-09-14: на роутере 192.168.2.2 (OpenWrt) DNAT-правила redirect[0] (name MQTT) и rule[3] (name allow-1883) переключены dest_ip 192.168.2.197 → 192.168.2.176. ZONT теперь пишет в mosquitto-аддон на t610 (живой поток modbus/sensors/kids/*, bedroom/*). В настройках ZONT ничего не менялось — адрес mqtt://zont:…@192.168.0.10:1883 остался тот же (192.168.0.10 = wan-интерфейс самого роутера 192.168.2.2). Бэкап правил: /root/firewall.bak-20260914-092555. Детали и откат — family/plans/t610-home-automation §5-кватер-Д. Также /etc/config/dhcp: list address '/mallexxx.duckdns.org/192.168.0.10' — внутренний DNS-пин для ZONT-сети.

⛔ ДЕКОМИССИЯ TrueNAS-СТЕКА (2026-09-14, ночь): старый стек автоматизации на TrueNAS погашен — homeassistant, mbusd, mosquitto, nodered, zigbee2mqtt, modbus-bridge, ser2net (docker stop + --restart=no, НЕ удалены). Контейнеров на TrueNAS в этой схеме больше нет — весь домашний контур живёт на t610 (192.168.2.176). USB-адаптеры CH340 физически на t610 → на TrueNAS узлов /dev/ttyVent//dev/ttyZONT не существует. Полный разбор — family/plans/t610-home-automation §5-кватер-Л, канон-блок — family/how-to/truenas-infrastructure.

🔌 ZONT 485 сидит на гнезде 4 (/dev/serial/by-path/pci-0000:00:12.0-usb-0:4:1.0-port0), вентиляция — гнездо 3. modbus-bridge (аддон на t610) сниффит ZONT-шину и публикует в MQTT топики modbus/sensors/<комната>/<параметр>. Публикуются kids, bedroom И dining.

✅ dining/* — ПОЧИНЕН 2026-09-14 (коммит 3748feb). Настоящая причина: баг сборки RTU-кадров в modbus_ha_bridge.py — ответы рвались (ser.read(ser.in_waiting or 1) + короткий таймаут), байты-сироты копились в голове буфера → сдвиг выравнивания → 19-байтный кадр гостиной не сходился по CRC и молча отбрасывался (12-байтные kids/bedroom проскакивали). Фикс по канону libmodbus/pymodbus: T3.5-разграничение (пауза ≥ 3.5 символа = конец кадра; при 9600 бод = 4.01 мс) + сброс битого буфера (buf = b"", аналог resetFrame). Итог: 7/7 полей dining публикуются, unavailable 10→8. Диагностика MODBUS_DEBUG_RAW снята. ❌ ОПРОВЕРГНУТЫЕ версии (не повторять): ① «нужен |default(0)» — не причина; ② «ZONT не публикует / датчик отвечает 0» — датчик исправен, ответ 19 б на шине есть, CRC валиден; ③ «bridge отдаёт ZONT'у 0, потому что не снифит гостиную» — неверно: снифит, но терял кадр из-за бага сборки; ④ «поднять таймаут» — против факта: 12-байтные ответы ловились тем же чтением. Детали разбора — family/plans/t610-home-automation §5-кватер-З и Modbus/RTU_Framing_Source_Analysis.

AT2 — калибровка PWM

Карта Slave ID — датчики и реле

📐 Правило распределения адресов (зафиксировано 2026-09-14):

Реальные 485-устройства: 1–99 (датчики 1/2/3, AT2 = 10, relay-модули 11/12/13/14, газ-котёл вкл = 20).

Виртуальные (bridge-подстановка): 100–247 — 100 Tuya Zigbee датчик, 101/102/103 датчики Гостиная/Детская/Спальня (рег. 100), 101:1 Socket 1, 104:1 Zigbee-реле котла switch.boiler_controller_power (bidirectional, ✅ работает с 2026-09-14 вечер-13, подтверждено Alex).

✅ Свободно: 105 и выше (полностью — 105–247); у 100/102/103 свободны только регистры ≠ 100. 104:1 занято (реле котла), регистры 104:2+ свободны.

Занятость проверять ВСЕГДА по двум источникам: эта карта + реальный /addons/modbus-bridge/data/config.template.tmpl на t610. Расхождение — признак правки мимо доки.

Механика маппинга «modbus-регистр ↔ HA-сущность» (образец для нового реле/розетки) — в шапке modbus_ha_bridge.py (стр. 80–104) и config.template.yml (стр. 118–131): блок с source: ha + entity_id (чтение) и action: ha + ha_entity_id + ha_service_on/off (запись). Правка только конфига-шаблона (data/config.template.tmpl) — код менять не нужно. После правки обязателен ha apps rebuild local_modbus-bridge (шаблон впекается в образ!), затем ha apps restart. Рабочий образец-эталон — блок реле котла в §5-кватер-И-7 доки family/plans/t610-home-automation.

value_map при write: bridge берёт value_map.get(reg_val, 1 if reg_val else 0), поэтому для чужих кодов (напр. ZONT пишет 0x0100/0x0200) маппить явно: {0: 0, 1: 1, 256: 0, 512: 1}. Механика: 0x06 (write reg) и 0x05 (write coil, 0xFF00=ON) → switch.turn_on/off; 0x03 (read) → значение из HA-поллера.

🔧 Диагностика bridge — рабочие приёмы (2026-09-14)

⚠️ ha apps logs <slug> обрезает вывод до 100 строк и отдаёт СТАРЫЙ буфер (видели записи 13:10 при текущем времени 20:10) — живой лог через CLI не получить. Обход — API: GET http://192.168.2.176:80/api/hassio/addons/local_modbus-bridge/logs, заголовок Authorization: Bearer <token>; ответ — голая строка в .data (не JSON-объект).

Замерший лог ≠ мёртвый bridge. Доказательство живости — подписка на MQTT с Mac: mosquitto_sub -h 192.168.2.176 -u zont -P '<пароль>' -t 'modbus/#' -v. Идёт поток → bridge работает. (Пароль mosquitto не совпадает с тем, что лежит в опциях аддона modbus-bridge — брать рабочий из ~/tmp-t610/apply_token2.sh.)

⚠️ Секрет-маскировщик Hermes подменяет $VAR и $(cat file) на *** при write_file → собирать заголовок в файл: printf 'Authorization: %s %s' 'Bearer' "$(cat /tmp/.hatok)" > /tmp/h1, затем curl -H @/tmp/h1. (Общий питфолл агента, не bridge-специфичный.)

Команды с rm в SSH через Hermes требуют approval и могут истечь → в диагностике rm избегать.

Порядок безопасной верификации нового маппинга: пересобрать → state: started → MQTT-поток идёт → в живом логе (через API) строка HA poll -> <entity> + ответ на read нужного slave/регистра.

Датчики
Гостиная - 1 (modbus bridge virt. sensor - 101)
Детская - 2 (modbus bridge virt. sensor - 102)
Спальня - 3 (modbus bridge virt. sensor - 103)

Tuya Zigbee thermal Sensor - 100

Vent control - 10 (0A)
Газ котёл вкл - 20 (14)   ⚠️ см. [[family/plans/t610-home-automation]] §5-кватер-П-7: в логе modbus-bridge ответы slave 20 помечены `[DROP-TAIL]`/`[BUF-LEFT]` и НЕ парсятся (баг сборки кадров) → состояние по bridge не читается. Прямой `nc`-запрос на 502 даёт `OK`, но это другой путь.

Заслонки:
Relay module - 11 (0B): reg 2-17, on: 256, off: 512

Спальня
Закрыто (Синий): 1
30% (Красный): 2
60% (Жёлтый): 3
Открыто (Коричневый): 4

Гостиная правый:
5: Закрыто, -6(вытяж), 7: 66%, 8: Открыто 
Гостиная левый:
9: Закрыто, -10(вытяж), 11: 66%, 12: Открыто
Детская: 
13 Закрыто ... 16: Открыто

Кухня отток: 6: откр, 10: закр

Relay module - 12 (0C)
Кабинет:
1: Закрыто ... 4: Открыто
Север:
5: Закрыто ... 8: Открыто

Вытяж Ванная: 9: откр, 10: закр
Вытяж Кабинет: 11: откр, 12: закр
Вытяж Туалет 1: 13: откр, 14: закр
Вытяж Душевая 2: 15: откр, 16: закр

Relay module - 13 (0D) (ZONT)
Радиаторы 2эт:
9: ванная
10(н/п): коридор
11(н/п): северная
12: детская левый
13: детская правый
14(н/п): гостевая
15: спальня левый
16: спальня правый
регистры записи из зонт reg+1! 256 - on, 512 - off
чтение статусов 1-8, 9-16 возвр. 1 или 0

Заслонки пластиковые: время открытия/закрытия ~3.5-3.8

Relay module 14 (0E)
Тёплый пол (ZONT)
[1: Лест.коридор - н.п.]
2: Гостиная ближний
[3: Столовая - н.п.] 
4: Кухня
[5: Туалет 1 - н.п.]
6: Ванная 2
7: Душевая 2
8: Гардеробная 
13: Гостиная дальний
[14: Прихожая - н.п.]
15: Кабинет правый
16: Кабинет левый
регистры записи из зонт reg+1! 256 - on, 512 - off
чтение статусов 1-8, 9-16 возвр. 1 или 0

ZONT relays
1: Конвектор кухня
2: Конвектор терраса
3: Конвектор гостиная средний 
4: Конвектор гостиная левый
[5: Радиатор лестница - н.п.]
6: Радиатор кабинет
7: Насос тёплые полы
[8: Конвектор котельная - н.п.]

ℹ️ Про «виртуальные sensor 101/102/103» — механика (уточнено 2026-09-14): 101/102/103 — это виртуальные Modbus-slaves, которые аддон modbus-bridge подставляет на шине: реальные 485-датчики Гостиная=1, Детская=2, Спальня=3 сниффятся, и их значения выдаются ZONT'у как датчики 101/102/103 (регистр 100). ZONT (Modbus master) опрашивает их как внешние датчики. 🔑 Уточнение (по логу, см. family/plans/t610-home-automation §5-кватер-Д): bridge работает двусторонне — он и публикует в MQTT, и отвечает ZONT'у под адресами 101/102/103. В логе видно: Slave: 101 → sniff:dining_temperature, Slave: 102 → sniff:kids_temperature, Slave: 103 → sniff:bedroom_temperature. ❌ ОПРОВЕРГНУТО (2026-09-14): прежняя запись «по гостиной bridge отдаёт 0, потому что датчик не снифится» — неверна. Реальная причина была в баге сборки RTU-кадров (см. блок выше): 19-байтный кадр гостиной рвался и отбрасывался. После фикса 3748feb все три комнаты публикуются. Если modbus-bridge не запущен/не слушает шину → ZONT показывает эти датчики «недоступные». На TrueNAS известная первопричина была гонка docker/udev после рестарта (см. [[family/how-to/zont-modbus-bridge-udev-race-protection]]); на t610 неактуально — Supervisor сам ждёт устройство.

Карта регистров контроллера вентиляторов

(home assistant = reg - 1)

Slave id 10 (0A)
AT2-1
Run (Relay 5, orange) - 28 (ha: 27) (D10): 0 - ON, 1 - OFF
PWM (brown) - 13 (ha: 12) (D6)

AT2-2
Run (Relay 4, green) - 22 (ha: 21) (D4): 0 - ON, 1 - OFF
PWM (blue) - 12 (ha: 11) (D5)

set_percentage:
  - service: modbus.write_register
    data:
      hub: rtu
      slave: 10
      address: 12
      value: "{{ (percentage * 255 / 100) | int }}"
  - service: modbus.write_register
    data:
      hub: rtu
      slave: 10
      address: 13
      value: 1

Vent 3
Relay 1 (Вент 3 белый) - 25 (ha: 24) (D7)
Relay 2 (Вент 4 белый) - 26 (ha: 25) (D8)
Relay 3 (Вент 4 синий) - 21 (ha: 20) (D3)

40001 : Slave ID   (1..247)   R/W   EEPROM

PWM 0..255
40011 : D3   R/W   EEPROM
40012 : D5   R/W   EEPROM
40013 : D6   R/W   EEPROM
40014 : D9   R/W   EEPROM
40015 : D10  R/W   EEPROM
40016 : D11  R/W   EEPROM

DIGITAL 0/1
40021 : D2   R/W   EEPROM
40022 : D3   R/W   EEPROM
40023 : D4   R/W   EEPROM
40024 : D5   R/W   EEPROM
40025 : D6   R/W   EEPROM
40026 : D7   R/W   EEPROM
40027 : D8   R/W   EEPROM
40028 : D9   R/W   EEPROM
40029 : D10  R/W   EEPROM
40030 : D11  R/W   EEPROM
40031 : D12  R/W   EEPROM
40032 : D13  R/W   EEPROM


0    : Slave ID   (1..247)   R/W   EEPROM

PWM 0..255
10   : D3   R/W   EEPROM
11   : D5   R/W   EEPROM
12   : D6   R/W   EEPROM
13   : D9   R/W   EEPROM
14   : D10  R/W   EEPROM
15   : D11  R/W   EEPROM

DIGITAL 0/1
20   : D2   R/W   EEPROM
21   : D3   R/W   EEPROM
22   : D4   R/W   EEPROM
23   : D5   R/W   EEPROM
24   : D6   R/W   EEPROM
25   : D7   R/W   EEPROM
26   : D8   R/W   EEPROM
27   : D9   R/W   EEPROM
28   : D10  R/W   EEPROM
29   : D11  R/W   EEPROM
30   : D12  R/W   EEPROM
31   : D13  R/W   EEPROM

Ручное управление AT2

Когда автоматика сломалась и нужно перевести вентиляторы на ручное управление прямо с панели AT2:

PRG — войти в параметры
Стрелками выбрать P10 → FUNC/DATA → изменить на 0 → FUNC/DATA
Стрелками выбрать P11 → FUNC/DATA → изменить на 0 → FUNC/DATA
PRG — выйти

P10 = 0 — частота с панели (потенциометр)
P11 = 0 — пуск/стоп с панели

Чтобы вернуть на внешнее управление через Arduino/Node-RED:

P10 = 2, P11 = 2, P50 = 5 (см. секцию ниже)

Контроллер AT2 — параметры

Как задавать параметры

1. PRG – войти в параметры.


2. Стрелками выбрать номер параметра.


3. FUNC/DATA – открыть параметр.


4. Стрелками изменить значение.


5. FUNC/DATA – сохранить.


6. PRG – выйти.




---

Что выставить для управления Arduino (0–5 В + RUN через X1)

1) Источник частоты — внешний аналог

P10 = 2


2) Источник RUN/STOP — внешние входы

P11 = 2


3) Назначение X1 как RUN (вперёд)

P50 = 5


4) Калибровка входа 0–5 В

P74 = 2096   (минимум, 0 В)

P73 = 15720  (максимум, 5 В)


(Если нужно точнее — потом подстроишь)

5) Максимальная рабочая частота (если нужно 50 Гц)

P06 = 50


Да, есть ещё несколько коротких и реально важных моментов, которые стоит учесть, чтобы всё работало корректно и безопасно. Тоже без простыней.


---

1) Выбор режима остановки

Параметр:

P12 — режим остановки
Рекомендовано:

P12 = 1 (плавное торможение / deceleration stop)


Если оставить “0” (инерционная остановка), мотор будет раскручиваться сам по себе при STOP.


---

2) Время разгона и торможения

Если Arduino будет резко менять напряжение 0–5 В, а инвертор сможет резко менять частоту — нагрузка может дёрнуться.

Параметры:

P34 — ускорение

P42 — торможение


Рекомендовано для мягкой работы:

P34 = 20–50

P42 = 20–50


(значения = Гц/сек)


---

3) Логика входов X1–X6 — активны «на землю»

На стр. 3 инструкции написано:

> Short port Xn and COM, input effective



То есть вход активируется замыканием на COM.
Это важно при подключении оптопары — выход PC817 должен замыкать X1 → COM.


---

4) Выходы SP1 и SP2 — open collector

Можно использовать для:

получение сигнала RUN

сигнал ошибки

сигнал «достигнута частота»


Выбирается параметрами P58 / P60.
Например:

P58 = 3 → SP1 выдаёт fault indication (авария)


Полезно при интеграции с Arduino.


---

5) Верхний предел частоты

Параметр:

P06 — максимальная рабочая частота (default 65 Гц)


Если не хочешь случайно подать 5 В и получить перегруз:

→ поставь P06 = 50 (или твою номинальную частоту).


---

6) Источник отображаемой величины

Параметр:

P62


Если хочешь видеть на дисплее выходную частоту, а не заданную:

P62 = 1


Если хочешь видеть температуру радиатора — P62 = 4.


---

7) Режим питания 5V/10V OUT

На схеме есть вывод 5V/10V power output.

Это питание для внешних потенциометров.
Не путать с аналоговым входом.

Твой Arduino должен давать своё напряжение на VI1, НЕ на этот 5/10V OUT.


---

8) Ограничения тока (опционально)

Если двигатель маленький, можно ограничить ток:

P78–P85 — защитные лимиты
Обычно трогать не нужно.



---

9) Параметры сброса

Полный сброс параметров:

P77 = 54321


На случай, если что-то настроится неправильно.


---

Если хочешь, могу собрать короткую финальную таблицу всех параметров, которые ты реально используешь, чтобы не искать по PDF.

Xiaomi / Tuya — локальный сервер

Четыре способа управления тёплым полом. Термостаты я взял на али, от не очень понятного производителя, но дёшево и с вайфаем. Родное для него приложение Smart Life сразу увидело все три термостата и данные бодро пошли на китайские сервера Tuya. В качестве основного средства автоматизации и управления умным домом я выбрал опенсорсный сервер Home Assistant. Есть интеграции под все на свете, выглядит не убого и шустро работает на запылившемся на полке микрокомпьютере raspberry pi 3. Сперва я завёл интеграцию через официальный плагин от Tuya, зарегистрировавшись на их сайте IoT разработчиков и получив нужные ключи api. Теперь данные через китайские сервера шли на мой локальный. Но оказалось, что их api не умело все возможности моего термостата. Например он умеет показывать температуру воздуха и температуру самого пола. А через сервер приходила только температура воздуха. При этом родное приложение Smart Life умело все. Огорчившись, я нашёл неофициальную интеграцию Tuya девайсов для Home Assistant. Она умеет работать с данными девайсами локально, в обход китайских серверов. Но не поддерживает термостаты как класс. Поэтому я нашёл форк с поддержкой термостатов, сделал свой форк, дописал туда несколько строк на питоне для корректной работы именно моей модели, заодно сделал пул реквест и наконец-то заимел полнофункциональный термостат на своём локальном сервере. Ну а самим девайсам запретил ходить во внешний мир на роутере. И вишенкой на торте является интеграция с Apple HomeKit, куда Home Assistant умеет пробрасывать все девайсы. Теперь могу просить сири сделать потеплее) Многие из вас могли не понять примерно треть написанного. И это наглядная иллюстрация нынешнего состояния умных домов и простоты их настройки.

28 KiB Raw Blame History Unescape Escape