564 lines
29 KiB
Markdown
564 lines
29 KiB
Markdown
---
|
||
title: "\U0001F3E0 Умный дом — автоматика"
|
||
aliases:
|
||
- Умный дом
|
||
- Home automation
|
||
- Modbus
|
||
- home-automation
|
||
tags:
|
||
- family
|
||
- how-to
|
||
- smarthome
|
||
- modbus
|
||
updated: 2026-09-15
|
||
related:
|
||
- '[[family/how-to/router-bishkek-asus]]'
|
||
- '[[family/plans/t610-home-automation]]'
|
||
- '[[family/how-to/ha-automations]]'
|
||
- '[[family/how-to/zigbee2mqtt-t610]]'
|
||
- '[[family/how-to/truenas-access]]'
|
||
---
|
||
# 🏠 Умный дом — автоматика
|
||
> **Статус на 2026-09-14:** домашняя автоматизация **перенесена на HP t610** (HA OS).
|
||
> 📌 **Всё про миграцию** — хост, доступ, карта USB/гнёзд, аддоны, Zigbee, питфоллы, текущее состояние — **в единственном документе [[family/plans/t610-home-automation]]. НЕ дублировать сюда.**
|
||
> 📌 **Этот документ — справочник по ЖЕЛЕЗУ:** AT2 (параметры/PWM), карта Slave ID, регистры заслонок/реле, ZONT relays. Оборудование и адреса Modbus при миграции не меняются.
|
||
> 📌 **Логика HA-автоматизаций (automations.yaml), карта device_id/entity_id, дефекты** — [[family/how-to/ha-automations]].
|
||
> **Текущее состояние:** `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-сети.
|
||
>
|
||
> **🔴 КАНОН (2026-09-15): H2000 PRO — НЕ Zigbee и НЕ Modbus-датчик.** Сущности `sensor.h2000_pro_temperatura_teplogo_pola` (**82.04**), `sensor.h2000_pro_temperatura_podachi` (81.14), `sensor.h2000_pro_temperatura_ulitsa` (57.2) есть в HA, но **в z2m их нет** (`grep -c H2000 configuration.yaml` → 0) и в карте Modbus их нет. Приходят **отдельной HA-интеграцией** (`config_entry 01M2EXY2D5YJZY71VAKJTTGB16`) — это **контроллер отопления H2000-серии (ZONT)**, не датчик. **НЕ ТРОГАТЬ** (прямое требование Alex 2026-09-15). В задачах про Zigbee/тёплый пол его **не рассматривать как кандидата**. Разбор — [[family/how-to/zigbee2mqtt-t610]] §3.
|
||
>
|
||
> **⛔ ДЕКОМИССИЯ 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
|
||
|
||
```
|
||
P73 31700
|
||
P74 0
|
||
|
||
Pwm/freq
|
||
10/3.3
|
||
15/6
|
||
20/10
|
||
25/15.8
|
||
26/18.5
|
||
28/21.2
|
||
29/23.3
|
||
30/25.6
|
||
32/31.3
|
||
33/33.6
|
||
35/38
|
||
36/41.3
|
||
37/41.8
|
||
38/43.3
|
||
40/46.1
|
||
41/47.9
|
||
42/48.2
|
||
44/50
|
||
45/51.6
|
||
46/51.9
|
||
47/52.6
|
||
48/53.5
|
||
49/54.2
|
||
50/54.8
|
||
52/56.2
|
||
54/57.2
|
||
56/58.3
|
||
58/59.2
|
||
59/59.6
|
||
60/60
|
||
|
||
Hz : PWM
|
||
0 : 0
|
||
1 : 0
|
||
2 : 0
|
||
3 : 0
|
||
4 : 48
|
||
5 : 55
|
||
6 : 63
|
||
7 : 70
|
||
8 : 78
|
||
9 : 85
|
||
10 : 92
|
||
11 : 97
|
||
12 : 102
|
||
13 : 107
|
||
14 : 112
|
||
15 : 117
|
||
16 : 120
|
||
17 : 123
|
||
18 : 126
|
||
19 : 129
|
||
20 : 132
|
||
21 : 135
|
||
22 : 138
|
||
23 : 141
|
||
24 : 144
|
||
25 : 147
|
||
26 : 149
|
||
27 : 151
|
||
28 : 153
|
||
29 : 155
|
||
30 : 157
|
||
31 : 159
|
||
32 : 161
|
||
33 : 163
|
||
34 : 165
|
||
35 : 167
|
||
36 : 169
|
||
37 : 171
|
||
38 : 173
|
||
39 : 175
|
||
40 : 177
|
||
41 : 179
|
||
42 : 181
|
||
43 : 183
|
||
44 : 185
|
||
45 : 187
|
||
46 : 190
|
||
47 : 194
|
||
48 : 198
|
||
49 : 202
|
||
50 : 206
|
||
51 : 210
|
||
52 : 214
|
||
53 : 218
|
||
54 : 222
|
||
55 : 226
|
||
56 : 220
|
||
57 : 228
|
||
58 : 236
|
||
59 : 245
|
||
60 : 255
|
||
```
|
||
|
||
## Карта 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:
|
||
|
||
1. **PRG** — войти в параметры
|
||
2. Стрелками выбрать **P10** → **FUNC/DATA** → изменить на **0** → **FUNC/DATA**
|
||
3. Стрелками выбрать **P11** → **FUNC/DATA** → изменить на **0** → **FUNC/DATA**
|
||
4. **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 умеет пробрасывать все девайсы. Теперь могу просить сири сделать потеплее) Многие из вас могли не понять примерно треть написанного. И это наглядная иллюстрация нынешнего состояния умных домов и простоты их настройки.
|
||
```
|