Home Assistant или openHAB: что выгоднее и когда

MAATRIX

Рано или поздно каждый, кто собирает умный дом на собственном сервере, упирается в один и тот же выбор: Home Assistant или openHAB. Оба бесплатны, оба open source, оба умеют почти всё — и именно поэтому выбрать по описанию с официального сайта невозможно. Разница вылезает только в реальной эксплуатации: сколько займёт вечеров на первую настройку, что будет с автоматизациями через полгода и не откажется ли система работать после очередного обновления. Ниже — сравнение без религиозного фанатизма в обе стороны, с конкретикой по железу, протоколам и сценариям, когда один продукт объективно выгоднее другого.

Архитектура: чем принципиально отличаются подходы

Home Assistant (HA) — это Python-приложение с очень плотной интеграцией всего со всем. У него нет чёткой границы между «ядром» и «плагинами»: интеграции подключаются через YAML или UI, состояние всех сущностей крутится в едином event bus, а Home Assistant OS (тот самый образ для Raspberry Pi или VM) добавляет ещё и supervisor с системой аддонов — готовые Docker-контейнеры для Zigbee2MQTT, Node-RED, ESPHome, баз данных и так далее. Философия HA — «работает из коробки, конфигурируется через UI, YAML для тех, кто хочет тонко настроить».

openHAB написан на Java и построен вокруг OSGi-модулей — это более классическая enterprise-архитектура, знакомая тем, кто работал с Java-серверами приложений. У openHAB жёстче разделены слои: Items (абстрактные объекты дома — «свет в кухне»), Things (физические устройства и их конкретные каналы), Bindings (драйверы протоколов), Rules (логика). Это многословнее, чем у HA, зато прозрачнее в больших инсталляциях: видно, какая сущность к какому физическому каналу привязана, и это не «размазано» по интеграциям.

Практический вывод: HA быстрее даёт результат, openHAB даёт более предсказуемую и документируемую структуру, если у вас десятки комнат и сотни устройств.

Установка и первый запуск: у кого ниже порог входа

На VPS оба ставятся без проблем, разница — в том, сколько шагов до «увидел интерфейс».

Home Assistant Container (не HAOS, а именно контейнерная версия — она разумный выбор для VPS без встроенных аддонов):

mkdir -p ~/homeassistant
docker run -d \
  --name homeassistant \
  --restart=unless-stopped \
  --network=host \
  -v ~/homeassistant:/config \
  -e TZ=Europe/Moscow \
  ghcr.io/home-assistant/home-assistant:stable

Через 30–60 секунд интерфейс доступен на порту 8123, мастер настройки создаёт первого пользователя и предлагает найти устройства в локальной сети автоматически. Подробный пошаговый разбор для Ubuntu 24.04 и docker-compose с примерами описан в статье про установку Home Assistant на VPS.

openHAB:

docker run -d \
  --name openhab \
  --restart=unless-stopped \
  --net=host \
  -v ~/openhab/addons:/openhab/addons \
  -v ~/openhab/conf:/openhab/conf \
  -v ~/openhab/userdata:/openhab/userdata \
  -e TZ=Europe/Moscow \
  -e USER_ID=9001 -e GROUP_ID=9001 \
  openhab/openhab:4.2

Веб-интерфейс поднимается на порту 8080, но дальше начинается принципиальная разница: openHAB после первого запуска почти пуст. Нужно вручную (или через Paper UI / поиск в маркетплейсе) добавить биндинги под ваши протоколы — Zigbee, Z-Wave, MQTT, Zwave-JS, KNX и так далее, — потом создать Things, потом привязать к ним Items. Это не сложно технически, но требует понимания структуры, которое у HA скрыто за автоматическим обнаружением. Если раньше не работали с openHAB, закладывайте на первичную настройку в 2–3 раза больше времени, чем на HA — не потому что openHAB хуже, а потому что он ничего не угадывает за вас.

Поддержка устройств и протоколов

По количеству интеграций Home Assistant формально впереди — в реестре тысячи с лишним записей, от облачных API вроде Yandex Smart Home и Xiaomi Cloud до локальных протоколов. Но важнее качество: у HA огромное коммьюнити пишет кастомные интеграции через HACS (Home Assistant Community Store) — не всё из этого поддерживается официально, часть держится на одном разработчике-энтузиасте, и это создаёт риск: обновление сломало что-то в ядре — кастомная интеграция может отвалиться до тех пор, пока автор не пофиксит.

У openHAB биндингов меньше, но они в среднем более formal — проходят ревью перед попаданием в основной репозиторий, документация к каждому биндингу единообразна (список Thing types, каналов, конфигурационных параметров). Для «энтерпрайзных» протоколов вроде KNX, Modbus, BACnet, LCN — то есть систем, которые встречаются в частных домах с профессиональной проводкой, а не только в квартирах с готовыми Zigbee-датчиками, — openHAB исторически сильнее и стабильнее.

Оба одинаково хорошо работают с Zigbee и Z-Wave через отдельные шлюзы: Zigbee2MQTT + MQTT-брокер (Mosquitto) как прослойка — универсальный вариант для обеих систем, подробности — в статье про установку Zigbee2MQTT на VPS. Если у вас смешанный парк устройств (несколько облачных сервисов + локальные протоколы + самодельные ESP32 на ESPHome), HA даст меньше трения — просто больше готовых кубиков, которые собираются без написания конфигов вручную.

Требования к железу

Оба продукта легковесные по сравнению с типичным веб-приложением, но у openHAB (JVM) выше базовое потребление памяти в состоянии простоя, а у HA потребление растёт заметнее с числом интеграций и историей состояний в базе данных (recorder).

Цифры ориентировочные — сильно зависят от числа интеграций, глубины истории в базе (recorder у HA, persistence у openHAB) и от того, крутите ли вы рядом Zigbee2MQTT, Node-RED или базу данных отдельным контейнером. Если у вас настоящий «умный дом» с десятками автоматизаций и историей на месяцы — закладывайте отдельный SSD-диск под базу и 4 ГБ RAM с запасом на обе системы. Ориентир по конкретным цифрам и как их посчитать под свой парк устройств — в статье сколько RAM нужно для Home Assistant.

Важный практический момент для VPS: обе системы держат постоянное соединение с устройствами (MQTT, Zigbee-координатор через USB-passthrough или сетевой шлюз), поэтому сервер должен быть с минимальным даунтаймом и стабильной сетью — на дешёвых overselling-хостингах обе будут «залипать» одинаково плохо.

Автоматизации: YAML/UI vs Rules DSL

В Home Assistant автоматизации — это триггер → условие → действие, описанные декларативно в YAML или собранные визуальным редактором в UI (по факту это тот же YAML, только собранный кликами). Для 90% бытовых сценариев («если движение в коридоре после заката — включить свет на 10%») этого достаточно, и порог входа низкий: не нужно писать код, только выбрать сущности из выпадающих списков.

Пример простой автоматизации HA:

automation:
  - alias: "Свет в коридоре по движению вечером"
    trigger:
      - platform: state
        entity_id: binary_sensor.hallway_motion
        to: "on"
    condition:
      - condition: sun
        after: sunset
    action:
      - service: light.turn_on
        target:
          entity_id: light.hallway
        data:
          brightness_pct: 10

Для сложной логики (несколько условий, ветвления, работа с внешними API, состояниями во времени) в HA обычно подключают Node-RED поверх — это даёт визуальные блок-схемы и снимает часть сложности с YAML. Подробности — в статье про установку Node-RED на VPS.

openHAB предлагает Rules DSL — собственный скриптовый язык, синтаксически похожий на Java/Xtend, плюс поддержку JavaScript и Python через отдельные add-on'ы. Это мощнее «из коробки»: можно писать полноценную логику с циклами, функциями, обращением к внешним библиотекам — без установки Node-RED сбоку. Цена — более крутая кривая обучения: если вы не программист, Rules DSL первое время будет читаться тяжелее, чем декларативный YAML.

rule "Свет в коридоре по движению вечером"
when
    Item HallwayMotion changed to ON
then
    if (Time_IsDay.state == OFF) {
        HallwayLight.sendCommand(10)
    }
end

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

Когда выбрать Home Assistant, а когда openHAB

Обобщая практику эксплуатации обеих систем на VPS:

Выбирайте Home Assistant, если:

• у вас квартира или дом с потребительскими устройствами (Zigbee-датчики, Xiaomi/Aqara, умные розетки, облачные сервисы вроде Яндекс.Станции);
• важна скорость запуска и минимум ручной настройки;
• вы готовы мириться с тем, что часть кастомных интеграций из HACS может временно ломаться после крупных обновлений;
• нужна большая и активная экосистема голосовых ассистентов, карточек интерфейса, готовых дашбордов.

Выбирайте openHAB, если:

• в доме есть профессиональная автоматизация — KNX, Modbus, BACnet, промышленные контроллеры;
• вам важна предсказуемая, документируемая структура (Items/Things/Channels) для большой инсталляции на десятки комнат;
• вы умеете (или готовы научиться) писать логику кода и хотите сложные правила без дополнительного Node-RED;
• стабильность и минимум breaking changes важнее скорости появления новых фич.

Если сомневаетесь — начните с Home Assistant: у него ниже цена ошибки на старте, а мигрировать концепцию «комнаты → устройства → автоматизации» на openHAB позже, если понадобится, будет проще, чем наоборот. Обе системы, кстати, прекрасно живут на одном VPS одновременно на разных портах, пока вы выбираете — тестовый прогон на паре недель обычно снимает все сомнения быстрее любого сравнения на бумаге.

Что касается устойчивости к сбоям — не откладывайте бэкапы независимо от выбора: конфиги обеих систем компактны, но потеря месяцев накопленных автоматизаций и истории — обидная история. Инструкции по восстановлению разобраны отдельно для Home Assistant и для openHAB.

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