Home Assistant на сервере: частые ошибки и решения

MAATRIX

Home Assistant на microSD-карте Raspberry Pi рано или поздно приводит к битой файловой системе и слетевшей автоматизации в самый неподходящий момент. Перенос на нормальный сервер — VPS или выделенный — решает проблему с надёжностью хранения, но открывает новый набор граблей: сеть в контейнере, доступ к USB-периферии, разрастающаяся база recorder и обновления, которые иногда ломают интеграции. Ниже — конкретные причины и решения для каждой из них, без универсальных советов «перезагрузите».

Как выбрать способ установки на сервере

На выделенном или виртуальном сервере доступны три реалистичных варианта установки, и путаница между ними — источник половины проблем в этой статье.

• Home Assistant Container — просто Docker-контейнер homeassistant/home-assistant, без надстройки Supervisor. Максимально гибко ложится на любой сервер, но аддоны (готовые пакеты вроде Zigbee2MQTT, ESPHome, Node-RED) придётся разворачивать отдельными контейнерами вручную.
• Home Assistant Supervised — полноценная система с магазином аддонов, но официально поддерживается только на Debian/Ubuntu без другого Docker-стека на машине. На сервере, где уже крутятся другие сервисы, это создаёт конфликт: Supervisor хочет управлять Docker сам.
• Home Assistant OS в виртуальной машине — отдельная ОС под KVM/Proxmox. Самый «чистый» вариант с полным набором функций, но требует гипервизора, а не голого Docker-хоста.

Для сервера в аренде разумный компромисс — Container-вариант через docker compose, а аддоны поднимать как соседние сервисы в том же docker-compose.yml:

services:
  homeassistant:
    image: homeassistant/home-assistant:2026.8
    container_name: homeassistant
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro
    environment:
      - TZ=Europe/Moscow

Частая ошибка — попытка поставить Supervised поверх сервера, где уже стоит Portainer или другой стек контейнеров: установочный скрипт падает на проверке окружения или ломает существующий Docker daemon. Если нужны официальные аддоны — проще выделить под HA отдельную VM с Home Assistant OS, а не тащить Supervised на общий хост.

Сеть и обнаружение устройств

Самая частая жалоба новичков на сервере: «HA не видит мои Wi-Fi лампы и колонки, хотя на Raspberry Pi всё находилось само». Причина почти всегда одна — контейнер в режиме bridge, а не host.

Home Assistant активно использует mDNS/SSDP для автообнаружения (Chromecast, HomeKit-устройства, некоторые Wi-Fi-розетки). В bridge-сети контейнер сидит за NAT докера, широковещательные пакеты mDNS туда просто не долетают. Решение — network_mode: host в docker-compose, как в примере выше. Минус: контейнер занимает порты напрямую на хосте, поэтому порт 8123 должен быть свободен, а если на сервере уже висит nginx на 80/443 — конфликтов с HA не будет, порты разные.

Второй частый случай — сервер физически удалён от умных устройств (это нормально для VPS в дата-центре, а не дома). Тогда автообнаружение по определению работать не будет: устройства находятся в другой L2-сети. Здесь два честных варианта:

• держать HA локально (мини-ПК или NUC дома), а на арендованном сервере — только резервную копию, VPN-шлюз и внешний доступ;
• использовать сетевые Zigbee/Wi-Fi-мосты, которые общаются с HA по IP, а не по локальному broadcast (об этом — в следующем разделе).

USB-контроллеры и сетевые Zigbee-координаторы

Если координатор Zigbee или Z-Wave — это USB-стик (SkyConnect, ConBee II, Sonoff Zigbee 3.0 Dongle), он физически должен быть воткнут в машину, где крутится Home Assistant. На арендованном VPS в другом городе это невозможно в принципе — нет физического порта. Вариантов решения два:

1. USB-over-IP или ser2net — если сервер физически рядом (например, вы поставили мини-сервер дома или в стойке колокейшна), можно пробросить стик через usbip или через ser2net, который отдаёт последовательный порт по TCP. HA/Zigbee2MQTT подключается к нему как к socket://ip:port вместо /dev/ttyUSB0.
2. Сетевой Zigbee-координатор — устройства вроде ZigStar LAN или SLZB-06 изначально работают по Ethernet/Wi-Fi и отдают Zigbee-стек по TCP. Это заметно надёжнее самодельного проброса USB и не привязывает координатор к конкретному хосту.

Пример конфигурации Zigbee2MQTT для сетевого координатора вместо локального USB:

serial:
  port: tcp://192.168.1.50:6638
  adapter: ember

Если стик всё же локальный (сервер стоит физически у вас), для Docker-контейнера его нужно пробросить явно:

services:
  zigbee2mqtt:
    image: koenkk/zigbee2mqtt
    devices:
      - /dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus-if00-port0:/dev/ttyUSB0
    group_add:
      - dialout

Частая ошибка — указывать /dev/ttyUSB0 напрямую вместо пути by-id. После перезагрузки сервера или переподключения кабеля номер ttyUSB0/ttyUSB1 может смениться местами с другим устройством, и Zigbee-сеть «пропадает» без видимой причины. by-id привязан к серийнику устройства и не съезжает.

База данных recorder: разрастание и миграция на PostgreSQL

По умолчанию Home Assistant пишет историю состояний и событий в SQLite-файл home-assistant_v2.db. На активной установке с полусотней датчиков этот файл легко разрастается до нескольких гигабайт за пару месяцев, а .storage начинает тормозить UI и автоматизации — recorder блокирует запись на время долгих SELECT-запросов дашборда истории.

Первое, что стоит сделать на любом сервере — ограничить глубину хранения и исключить шумные сущности из recorder:

recorder:
  purge_keep_days: 10
  commit_interval: 5
  exclude:
    domains:
      - automation
      - update
    entities:
      - sensor.uptime
      - sensor.date_time

Если датчиков много (ZigBee-сеть на 60+ устройств, погодные интеграции с ежеминутным опросом), SQLite начинает упираться в производительность диска даже на SSD. Правильный шаг — вынести recorder в отдельный PostgreSQL-контейнер:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: homeassistant
      POSTGRES_USER: hass
      POSTGRES_PASSWORD: change_me
    volumes:
      - ./pgdata:/var/lib/postgresql/data

recorder:
  db_url: postgresql://hass:change_me@postgres/homeassistant

Перед переключением обязательно сделайте бэкап home-assistant_v2.db — миграцию история назад SQLite не переносит, начнётся с чистого листа в новой БД. На сервере это не проблема: место и ресурсы под отдельный контейнер БД есть, в отличие от Raspberry Pi, где PostgreSQL на карте памяти сам по себе создаёт узкое место.

Бэкапы и безопасные обновления

Home Assistant обновляется часто, и не каждый релиз проходит без сюрпризов — интеграции у сторонних разработчиков (HACS) иногда ломаются раньше, чем core успевает подстроиться. На сервере с полноценным диском это лечится нормальным бэкапом, а не надеждой на удачу.

Встроенные снапшоты (Settings → System → Backups) работают, но хранить их стоит не рядом с самим HA — если упадёт диск, снапшот упадёт вместе с ним. Простой вариант для сервера — выгружать архив конфигурации по cron на отдельный volume или в объектное хранилище:

#!/bin/bash
# /opt/scripts/ha-backup.sh
DATE=$(date +%F)
docker exec homeassistant python3 -m homeassistant.backup_restore --backup
rsync -a /opt/homeassistant/config/backups/ /mnt/backup-disk/ha/$DATE/
find /mnt/backup-disk/ha/ -mtime +14 -exec rm -rf {} \;

Перед обновлением на мажорную версию (например, с 2026.7 на 2026.8) стоит на минуту остановить автообновление и проверить changelog на breaking changes — HA сам пишет их прямо в release notes. Правило, которое экономит вечера: обновляться не в день релиза, а через 3-5 дней, когда сообщество уже отловило типовые баги в HACS-интеграциях.

Если через docker compose — обновление сводится к смене тега образа и пересборке:

docker compose pull homeassistant
docker compose up -d homeassistant

Откат при поломке — вернуть предыдущий тег в compose-файле и восстановить конфиг из бэкапа, сделанного перед обновлением. Держать хотя бы 2-3 последних рабочих снапшота — обязательный минимум, а не опция.

Удалённый доступ без облака производителя

Одна из причин переезжать на собственный сервер — не платить за Nabu Casa Cloud и не зависеть от чужой инфраструктуры для входа в свой собственный дом. На арендованном сервере это решается стандартным связкой reverse proxy + SSL, без прокидывания HA напрямую в интернет через голый порт 8123.

Пример через Caddy с автоматическим SSL:

ha.example.com {
    reverse_proxy localhost:8123
}

В configuration.yaml Home Assistant нужно явно разрешить прокси, иначе он будет считать все запросы подозрительными и ронять сессии:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - ::1

Для доступа без открытого наружу порта вообще (что безопаснее, если сервер держит и другие сервисы) — поднять WireGuard между сервером и телефоном/ноутбуком и ходить в HA по внутреннему IP. Это чуть менее удобно, чем прямая ссылка из любой сети, зато полностью убирает HA из списка публично сканируемых целей. О самой настройке туннеля подробно — в статье про установку WireGuard на VPS; для быстрого личного доступа без ручной настройки клиентов подойдёт и связка через Tailscale или ZeroTier.

Частые вопросы