--- title: "\U0001F3E0 Умный дом — автоматика" aliases: - Умный дом - Home automation - Modbus - home-automation tags: - family - how-to - smarthome - modbus updated: 2026-09-14 related: - '[[family/how-to/router-bishkek-asus]]' - '[[family/plans/t610-home-automation]]' - '[[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 при миграции не меняются. > **Текущее состояние:** `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 ``` 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 ` обрезает вывод до 100 строк и отдаёт СТАРЫЙ буфер** (видели записи 13:10 при текущем времени 20:10) — живой лог через CLI **не получить**. Обход — API: `GET http://192.168.2.176:80/api/hassio/addons/local_modbus-bridge/logs`, заголовок `Authorization: Bearer `; ответ — **голая строка** в `.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 -> ` + ответ на 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 умеет пробрасывать все девайсы. Теперь могу просить сири сделать потеплее) Многие из вас могли не понять примерно треть написанного. И это наглядная иллюстрация нынешнего состояния умных домов и простоты их настройки. ```