Home Assistant в Docker на домашнем сервере объединяет устройства разных брендов в единый умный дом

Готовые наборы умного дома от крупных вендоров хороши ровно до момента, когда в квартиру попадает устройство другого бренда. Термостат общается с фирменным облаком, датчики живут в собственном приложении, а свет не реагирует на движение, зафиксированное чужим сенсором. Home Assistant предлагает другой маршрут: открытая платформа поднимается на своём сервере в Docker, поддерживает несколько тысяч типов устройств и обходится без обязательных облаков и подписок. Дальше показан рабочий путь от чистого Linux-сервера до автоматизаций, которые реально экономят и электроэнергию, и нервы.

Открытая платформа и её отличие от коробочных комплектов

Проект развивается с 2013 года, основал его Паулюс Схоутсен, платформа написана на Python и распространяется по лицензии Apache 2.0. С 2024 года разработка идёт под зонтом некоммерческого фонда Open Home Foundation, поэтому поглощение проекта корпорацией маловероятно. Версии нумеруются годом и месяцем, например 2025.1, свежий релиз выходит ежемесячно. Каталог интеграций давно перевалил за две тысячи записей: розетки и лампы, шторы, котлы, роботы-пылесосы, солнечные инверторы, датчики протечки и качества воздуха.

Ключевая разница с коробочным набором в том, что платформа не привязана к бренду устройства. Сенсор одной фирмы, реле второй и камера третьей попадают в общее пространство состояний и в один сценарий. Производитель закроет облако или сменит API? Устройство чаще всего продолжит работать, потому что локальные интеграции держат связь напрямую по домашней сети. Отсюда практический выигрыш: команды выполняются за десятки миллисекунд, история показаний не утекает на чужие серверы, за функциональность не нужно платить каждый месяц.

Интерфейс собирается из карточек: живые плитки состояния, графики, камеры, план квартиры. Работает мобильное приложение с уведомлениями и виджетами, открывается доступ из браузера. Всё дальнейшее исходит из того, что сервер уже видит домашнюю сеть.

Подготовка сервера и выбор варианта установки

Платформа ставится тремя способами: готовым образом Home Assistant OS, вариантом Supervised с полной надстройкой и контейнером Home Assistant Container. Для отдельного или уже работающего сервера интересен третий путь: минимум обвязки, любой дистрибутив с Docker, простое соседство с другими службами. Плата за гибкость: в контейнерной версии нет каталога дополнений, поэтому брокер сообщений, Zigbee-шлюз и база данных запускаются соседними контейнерами в том же compose-файле.

Минимум для плавной работы: 2 ГБ памяти, два ядра, 16 ГБ диска. Для большой сети датчиков и записи видео лучше сразу 4 ГБ памяти и SSD. Операционная система подойдёт привычная: Debian, Ubuntu, AlmaLinux, даже LXC-контейнер на Proxmox.

Базовый compose.yaml принимает такой вид:

services:
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /opt/ha/config:/config
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
    restart: unless-stopped
    stop_grace_period: 60s
    privileged: true
    network_mode: host

Каждая строка несёт смысл. Режим host нужен для автоматического обнаружения устройств: платформа слушает групповые рассылки mDNS на UDP-порту 5353 и SSDP на 1900, а NAT-сеть Docker-моста такие пакеты не пропускает. Привилегии дают доступ к DBus и Bluetooth-адаптеру; если Bluetooth не нужен, строку убирают. Параметр stop_grace_period отводит процессу шестьдесят секунд на корректное завершение, чтобы база успела сбросить буферы на диск. Это верхний предел, а не обязательная пауза: контейнер уходит сразу после выхода. В командной строке то же самое задаёт флаг --stop-timeout 60.

Развернуть всё на чистом сервере можно за шесть шагов:

1. Установить Docker Engine и плагин compose, проверить версию командой docker --version;
2. Создать каталог /opt/ha/config и сохранить в него compose.yaml;
3. Запустить docker compose up -d и дождаться загрузки образа объёмом около 1 ГБ;
4. Открыть в браузере страницу платформы на порту 8123 и пройти онбординг;
5. При уже подключённых радиомодулях добавить их в блок devices compose-файла;
6. Убедиться, что после перезагрузки хоста платформа поднимается сама, командой docker compose ps.

Первый запуск, онбординг и наведение порядка в сенсорах

Первый экран встречает мастер онбординга: создание учётной записи администратора, название дома, часовой пояс, единицы измерения. Через несколько минут платформа сама перечисляет найденное в сети: роутер, телевизор, розетки с локальным API, медиаплееры. Каждое устройство превращается в сущность с идентификатором вида sensor.bedroom_temperature, и дальше автоматизации оперируют именно ими.

Конфигурация ведётся в двух режимах. Простой путь: панели веб-интерфейса, где устройства и правила добавляются мышью. Гибкий путь: файл configuration.yaml в каталоге /config, где объявляются интеграции, зоны, пользовательские датчики. Перед применением изменений работает проверка конфигурации, а сломанную настройку лечит безопасный режим загрузки. Разделы конфигурации перезагружаются без рестарта всей платформы, поэтому правка правил не прерывает сбор показаний с датчиков. Времени экономят и заготовки автоматизаций под названием blueprint, где достаточно подставить свои устройства в готовый шаблон.

Если страница не открывается сразу, первую подсказку даёт команда docker logs -f homeassistant: при первом старте база создаётся несколько минут, и интерфейс появляется не мгновенно. Отдельные значения собираются во вспомогательные сущности: input_number держит желаемую температуру, input_select хранит список режимов, а датчики-шаблоны вычисляют производные величины вроде средней температуры по этажу. Такой слой абстракции избавляет от правки десятков правил при замене одного прибора: меняется только источник, правила трогать не нужно. Зоны и комнаты упорядочивают хаос: каждая сущность получает комнату, а ярлыки группируют оборудование по сценариям, например "отопление осенью". Группы позволяют управлять десятью лампами одной командой, а фильтры на панели показывают только нужный этаж или крыло.

Радиомодули Zigbee и Z-Wave в контейнере

Для датчиков без проводов нужен USB-стик: Home Assistant Connect ZBT-1 на радиочипе EFR32MG21 (до 2024 года продавался под именем SkyConnect) или Sonoff ZBDongle-E на CC2652P. Устройство пробрасывается в контейнер строкой devices со значением /dev/ttyUSB0:/dev/ttyUSB0, а пользователю на хосте нужны права группы dialout, иначе файл девайса окажется недоступен.

Дальше развилка. Встроенная интеграция ZHA работает сразу и закрывает базовый сценарий. Отдельный контейнер Zigbee2MQTT мощнее: поддерживает более четырёх тысяч моделей, позволяет переименовывать устройства, калибровать показания, настраивать автовосстановление связи. Он публикует показания в MQTT, откуда платформа их забирает. Сеть Zigbee живёт на частоте 2,4 ГГц, каждый прибор с питанием от розетки становится ретранслятором и расширяет покрытие, поэтому план расстановки повторителей важнее мощности самого стика. Канал подбирают под Wi-Fi: номера 15, 20 или 25 реже пересекаются с занятыми каналами Wi-Fi.

Z-Wave подключается парой Z-Wave JS UI и штатной интеграции Z-Wave: отдельный контейнер держит стик и веб-панель, платформа ходит к нему по WebSocket. Частота зависит от региона: 868,42 МГц в Европе, 908,42 МГц в Северной Америке, и стик покупают под свой регион. Для обеих технологий типовая скорость последовательного порта 115200 бод, а USB-удлинитель на полметра от корпуса сервера заметно снижает помехи от блоков питания. Оба радиоканала любят порядок в прошивках: перед обновлением координатора Zigbee делают резервную копию сетевых настроек, иначе после сбоя придётся заново подключать десятки устройств. Механизм копии сети есть и в ZHA, и в Zigbee2MQTT, занимает он секунды и лежит рядом с конфигурацией.

Интеграции по сети от MQTT до Matter

MQTT это шина для самодельных и нестандартных датчиков. Брокер работает соседним контейнером, сенсоры публикуют показания в топики, платформа подписывается на маску вроде home/+/temperature. Живость канала проверяется с хоста одной командой:

mosquitto_pub -h 127.0.0.1 -t "home/office/temp" -m "22.4"

Проект ESPHome превращает YAML-описание в прошивку для плат ESP32 и ESP8266: датчик температуры, счётчик воды или реле описываются десятком строк, прошивка собирается и заливается по воздуху. Bluetooth-датчики температуры и влажности ловятся напрямую, а в большом доме роль повторителей берут ESP32 в роли Bluetooth-ретранслятора.

Новые протоколы тоже на месте: платформа работает контроллером Matter, а для устройств на Thread нужен граничный маршрутизатор, роль которого может взять ZBT-1 в режиме Thread. Проводные системы подключаются по KNX и Modbus, локальный JSON-API розеток Shelly отдаёт состояние без облака, а для части устройств Tuya удаётся получить локальный ключ и уйти от фирменного приложения целиком.

Автоматизации, сценарии и учёт электроэнергии

Логика платформы строится на связке "триггер, условие, действие". Пример: температура в комнате опустилась ниже 20 °C и окно закрыто, конвектор включается; окно открылось, нагрев прекращается немедленно. Сценарий "Вечер" одним касанием приглушает свет, закрывает шторы и включает увлажнитель. Правила пишутся в интерфейсе или в YAML, а отлаживаются через журнал срабатываний с метками времени.

Панель энергии заслуживает отдельного абзаца. Интеграция собирает расход с розеток и реле с измерением, задаётся цена киловатт-часа, отдельно добавляются солнечная генерация и возврат в сеть. Платформа рисует графики по часам и месяцам, считает долю самопотребления и подсказывает, какие приборы расходуют больше всего. Долгосрочная статистика хранит почасовые агрегаты отдельно от мгновенных значений, поэтому график за год строится без задержек. Правило с шаблоном умеет сравнивать не только пороги, но и динамику: если расход за час превысил средний за тот же час прошлой недели в два раза, приложение получит предупреждение ещё до платёжки. Уведомления приходят в мобильное приложение: рост расхода ночью или отключение холодильника от розетки замечаются за минуты.

База данных, резервные копии и обслуживание

Служба recorder пишет состояния в SQLite, файл home-assistant_v2.db в каталоге /config. По умолчанию журнал хранит десять дней (параметр purge_keep_days), а при сотнях сущностей база вырастает на гигабайты в месяц и замедляет графики. Лечение: отдельный контейнер MariaDB и строка db_url в конфигурации. Шаблон сервиса:

  mariadb:
    image: mariadb:11
    restart: unless-stopped
    ports:
      - "127.0.0.1:3306:3306"
    environment:
      MARIADB_DATABASE: homeassistant
      MARIADB_USER: ha
      MARIADB_PASSWORD: change-me-long
    volumes:
      - /opt/ha/mariadb:/var/lib/mysql

Строка подключения для рекордера выглядит так: mysql://ha:change-me-long@127.0.0.1:3306/homeassistant?charset=utf8mb4. Полезно исключить из журнала сущности без ценности: солнце, погоду, частые опросы. Это уменьшает объём базы в разы без потери истории по приборам.

Резервные копии решаются штатно: с релиза 2024.4 интеграция Backup работает и в контейнерной установке, складывает tar-архив в /config/backups, расписание задаётся в настройках. Готовый архив уезжает на NAS по rsync или в облачное хранилище через rclone. Разворачивание копии проверяют хотя бы раз в полгода, архив без проверки это иллюзия защиты. Конфигурация в git-репозитории превращает эксперименты в обратимые: любое изменение откатывается. Обновление платформы занимает минуты: docker compose pull, затем docker compose up -d, перед этим полезно просмотреть примечания к релизу, а перед крупными обновлениями сохранять полный архив. Откат описывается сменой тега stable на конкретный номер версии.

Home Assistant в Docker не требует серверной стойки и дорогих контроллеров: недорогой мини-ПК, пара стиков и свободный вечер дают систему, которая переживает сбои облаков производителей и продолжает работать, даже когда домашний интернет временно лежит. Такая автономность объясняет, почему self-hosted платформы вытесняют коробочные наборы в домах, где устройства считают своими, а не одолженными.