Установка Home Assistant Core: Полный гайд

Превращение NAS в центральный контроллер умного дома: сеть, проброс Zigbee-стика, база данных под историю и то, что стоит знать перед первым запуском.

Зачем локальный хаб вместо облачных приложений

Home Assistant в Docker объединяет устройства от Xiaomi, Tuya, Sonoff, Philips Hue и десятков других производителей в одну локальную систему автоматизации — без постоянной зависимости от внешних облаков, которые могут отключить API, поднять подписку или просто перестать существовать. Автоматизации при этом выполняются локально: включение света по датчику движения не ждёт ответа от сервера за океаном.

Core, Supervised, HAOS — и почему на NAS это Core

У Home Assistant несколько способов установки, и путаница между ними — источник половины проблем в комьюнити-форумах. Держите таблицу под рукой, прежде чем гуглить очередной аддон:

Ключевое следствие: у Core нет Add-on Store — того самого магазина дополнений с одной кнопкой установки Zigbee2MQTT, Mosquitto или ESPHome, который вы могли видеть на скриншотах Supervised-установок. На NAS все эти сервисы поднимаются как отдельные, но связанные Docker-контейнеры — это чуть больше работы на старте, зато полностью прозрачно и не требует "поддерживаемой" ОС.

Что понадобится перед стартом

• Synology NAS с Container Manager и доступом по SSH.
• Свободный USB-порт для Zigbee- или Z-Wave-координатора, если планируете локальную сеть умных устройств, а не только Wi-Fi.
• Домен или локальное DNS-имя для NAS, если планируете доступ извне через реверс-прокси.
• 20–30 минут: часть шагов (udev-правила, компаньоны) не входит в стандартные гайды и требует аккуратности.

Шаг 1 — подготовка каталогов

01Создаём структуру

mkdir -p /volume1/docker/homeassistant/config
mkdir -p /volume1/docker/mosquitto/{config,data,log}
mkdir -p /volume1/docker/zigbee2mqtt/data

Как и с другими сервисами на NAS — единственное, что нужно бэкапить для полного восстановления, это папка config: там лежат configuration.yaml, база истории, сертификаты интеграций и файл секретов.

Шаг 2 — почему сеть host, а не bridge

В отличие от Vaultwarden или Nginx Proxy Manager, для Home Assistant связка обычного bridge и проброшенных портов работает не полностью. Причина — протоколы обнаружения устройств: mDNS (Chromecast, Apple HomeKit, принтеры), SSDP/UPnP (Sonos, некоторые телевизоры и медиаплееры) и мультикаст-трафик локальной сети в целом плохо проходят через NAT контейнера.

В режиме network_mode: host контейнер разделяет сетевой стек с самим NAS, а не живёт за NAT — устройства обнаруживаются автоматически, а порт 8123 не нужно отдельно пробрасывать: он уже слушает на IP самого NAS.

Шаг 3 — docker-compose.yml построчно

02Базовый сервис Home Assistant

services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:2026.7
    restart: unless-stopped
    network_mode: host
    privileged: false
    volumes:
      - /volume1/docker/homeassistant/config:/config
      - /etc/localtime:/etc/localtime:ro
    environment:
      TZ: "Europe/Moscow"
    devices:
      - /dev/serial/by-id/usb-Silicon_Labs_Zigbee_Coordinator-if00-port0:/dev/zigbee

Фиксированный тег версии вместо stable здесь так же важен, как и в других сервисах на NAS: обновление Home Assistant — процесс с собственным чейнджлогом breaking changes, который стоит читать осознанно, а не получать при случайном рестарте контейнера.

Шаг 4 — стабильный проброс Zigbee/Z-Wave

03Почему не /dev/ttyUSB0

Путь вида /dev/ttyUSB0 назначается по порядку подключения устройств при загрузке — если после перезагрузки NAS Zigbee-стик проинициализируется вторым, а не первым, весь ваш Zigbee-сегмент дома молча отвалится, а compose-файл при этом не изменится ни на строчку.

ls -l /dev/serial/by-id/
# usb-Silicon_Labs_Zigbee_Coordinator-if00-port0 -> ../../ttyUSB0

Шаг 5 — компаньоны вместо аддонов: Zigbee2MQTT и Mosquitto

Раз Core лишён Add-on Store, связку для Zigbee поднимаем вручную: брокер MQTT и Zigbee2MQTT как обычные сервисы того же compose-проекта, использующие тот же координатор:

  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mosquitto
    restart: unless-stopped
    network_mode: host
    volumes:
      - /volume1/docker/mosquitto/config:/mosquitto/config
      - /volume1/docker/mosquitto/data:/mosquitto/data
      - /volume1/docker/mosquitto/log:/mosquitto/log

  zigbee2mqtt:
    image: koenkk/zigbee2mqtt:latest
    container_name: zigbee2mqtt
    restart: unless-stopped
    network_mode: host
    depends_on:
      - mosquitto
    volumes:
      - /volume1/docker/zigbee2mqtt/data:/app/data
      - /run/udev:/run/udev:ro
    devices:
      - /dev/serial/by-id/usb-Silicon_Labs_Zigbee_Coordinator-if00-port0:/dev/zigbee
    environment:
      TZ: "Europe/Moscow"

После первого запуска Zigbee2MQTT в его веб-интерфейсе на порту 8080 нужно указать адрес брокера (mqtt://localhost:1883) — а в Home Assistant интеграция MQTT подхватит устройства автоматически через автообнаружение (MQTT discovery), без единой ручной записи в configuration.yaml.

Шаг 6 — HTTPS через реверс-прокси

Home Assistant проверяет, что запрос пришёл от доверенного прокси, прежде чем доверять заголовкам X-Forwarded-For — без этого либо ничего не работает через HTTPS, либо в логах сыпется предупреждение о недоверенном источнике. Добавьте в configuration.yaml:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - 192.168.1.0/24

В Nginx Proxy Manager (или другом реверс-прокси) хост указывает на IP_NAS:8123, с обязательной поддержкой WebSocket — Lovelace держит соединение открытым для мгновенного обновления состояний устройств.

База данных: когда SQLite уже мало

По умолчанию Home Assistant пишет историю состояний в SQLite прямо внутри config. Для пары десятков устройств этого достаточно годами, но при сотне с лишним сенсоров и коротком интервале опроса файл базы начинает пухнуть, а Lovelace-графики — тормозить при открытии истории за месяц.

recorder:
  purge_keep_days: 10
  commit_interval: 5
  exclude:
    domains:
      - automation
      - updater

Исключение шумных доменов вроде automation из записи в recorder часто сокращает размер базы заметнее, чем любые настройки хранения — статусы автоматизаций меняются постоянно, но почти никогда не нужны в истории.

Бэкапы без Supervisor

Кнопки "Создать снапшот" из Supervised-версии здесь нет — бэкап делается на уровне файловой системы NAS. Простой скрипт для планировщика задач Synology:

#!/bin/bash
STAMP=$(date +%Y%m%d-%H%M)
DEST=/volume1/docker/homeassistant/backups
mkdir -p "$DEST"
tar --exclude='config/home-assistant_v2.db-wal' \
    -czf "$DEST/ha-config-$STAMP.tar.gz" \
    -C /volume1/docker/homeassistant config
find "$DEST" -name "ha-config-*.tar.gz" -mtime +14 -delete

Перед архивированием остановите контейнер (или хотя бы дождитесь паузы в записи) — SQLite так же чувствителен к копированию "на горячую", как и база Vaultwarden из отдельной статьи об этом.

Безопасность

• Двухфакторная аутентификация для собственной учётной записи Home Assistant — включается в профиле пользователя, поддерживает TOTP.
• Не открывайте порт 8123 напрямую в интернет через проброс на роутере — только через реверс-прокси с HTTPS, как в шаге 6.
• trusted_networks для локальной подсети, если хотите вход без пароля с доверенных устройств дома, но обязательно с отдельной аутентификацией для доступа снаружи.
• Отдельный VLAN для IoT-устройств, если роутер это поддерживает — компрометация дешёвой умной лампочки не должна давать доступ к остальной сети.

Частые проблемы

Если после всех шагов Zigbee-сеть держится стабильно между перезагрузками, а Lovelace открывается по HTTPS без предупреждений в логах — дальше это уже вопрос автоматизаций, а не инфраструктуры.