openHAB в Docker Compose: готовый файл

MAATRIX

Если вы уже пробовали Home Assistant и упёрлись в его облачную интеграционную модель или просто хотите систему умного дома, которая не ломается после каждого обновления, — присмотритесь к openHAB. Это Java-платформа с открытым кодом, которую разработчики годами держат курс на протокольную независимость и стабильность API, а не на красивые анимации в интерфейсе. Ниже — рабочий docker-compose.yml, который поднимает openHAB на VPS или домашнем сервере за одну команду, плюс разбор всех нюансов: сетевой режим, проброс USB-стиков Zigbee/Z-Wave, бэкапы и безопасный доступ снаружи.

openHAB vs Home Assistant: когда выбирать именно его

openHAB (Open Home Automation Bus) существует с 2010 года и построен на OSGi/Java поверх Eclipse SmartHome framework. У него другая философия по сравнению с Home Assistant:

• Протокольная независимость. Openhab не привязывается к одному способу представления устройств — Items (абстрактные сущности: Switch, Dimmer, Contact) отделены от Things (физические привязки к конкретному протоколу). Это позволяет менять железо под капотом, не переписывая правила и интерфейс.
• Стабильность релизного цикла. LTS-ветки (Long Term Support) поддерживаются годами, breaking changes анонсируются заранее. Если вы обожглись на Home Assistant, где интеграция может исчезнуть или измениться в минорном релизе, — это ощутимая разница.
• Более 500 биндингов (bindings) — от KNX и Modbus до MQTT, Zigbee, Z-Wave, LIFX, Sonos, Nest и десятков нишевых протоколов промышленной автоматизации.
• Порог входа выше. UI менее «вылизан», настройка через текстовые файлы (.items, .things, .rules) или полностью через веб-интерфейс — на выбор, но документации и community-контента заметно меньше, чем у HA.

Если вам важна предсказуемость на годы вперёд и вы не против один раз разобраться в модели Items/Things — openHAB окупается. Если нужен максимально быстрый старт с готовыми интеграциями «из коробки» — присмотритесь к материалу про Home Assistant в Docker Compose, там подход и структура файла похожи, но акценты другие.

Готовый docker-compose.yml

Вот рабочий конфиг для актуальной на конец августа 2026 года ветки openHAB 4.x. Официальный образ публикуется в openhab/openhab на Docker Hub.

version: "3.8"

services:
  openhab:
    image: openhab/openhab:4.3.2
    container_name: openhab
    restart: unless-stopped
    network_mode: host
    devices:
      - "/dev/ttyUSB0:/dev/ttyUSB0"   # Zigbee/Z-Wave USB-стик
      - "/dev/ttyACM0:/dev/ttyACM0"   # если стик определяется как ACM
    volumes:
      - ./openhab_conf:/openhab/conf
      - ./openhab_userdata:/openhab/userdata
      - ./openhab_addons:/openhab/addons
      - /etc/localtime:/etc/localtime:ro
    environment:
      TZ: "Europe/Moscow"
      USER_ID: "9001"
      GROUP_ID: "9001"
      EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Moscow -Xms256m -Xmx768m"
      OPENHAB_HTTP_PORT: "8080"
      OPENHAB_HTTPS_PORT: "8443"
    cap_add:
      - NET_ADMIN

Ключевые моменты:

• network_mode: host — не опечатка и не лень. openHAB активно использует UPnP-дискавери, mDNS/Bonjour (для HomeKit-эмуляции, Hue-эмуляции, обнаружения устройств Sonos/Chromecast), и эти механизмы плохо работают через NAT контейнерной сети Docker. Официальная документация openHAB прямо рекомендует host-режим для полной совместимости биндингов. Минус — теряется изоляция портов, поэтому firewall и reverse proxy обязательны (см. раздел про безопасность ниже).
• Три volume разделяют роли: conf — файлы конфигурации (items, things, rules, sitemaps), userdata — база данных истории (JSONDB, persistence), логи и кэш, addons — скачанные вручную JAR-биндинги, которых нет в каталоге Marketplace.
• devices — проброс USB-контроллеров Zigbee (Conbee II, Sonoff Zigbee 3.0, Texas Instruments CC2652) и Z-Wave (Aeotec Z-Stick, Zooz 700). Если вы не знаете, как определяется ваш стик, посмотрите вывод ls -l /dev/serial/by-id/ на хосте — там имя стабильнее, чем ttyUSB0, которое может меняться местами при перезагрузке.
• EXTRA_JAVA_OPTS с -Xms/-Xmx фиксирует границы Java heap. Без этого JVM по умолчанию может забирать до 25% доступной хосту памяти, что на VPS с 2 ГБ RAM оставляет системе слишком мало.

Если у вас ещё нет базовой установки Docker и Compose на сервере, начните с пошаговой инструкции Docker Compose для продакшена на Ubuntu 24.04 — там разобран весь путь от чистой системы до готового к работе демона.

Первый запуск и настройка бриджей

Поднимаем стек и ждём инициализации — первый старт JVM с распаковкой OSGi-бандлов занимает 2-4 минуты, это нормально:

mkdir -p openhab_conf openhab_userdata openhab_addons
sudo chown -R 9001:9001 openhab_conf openhab_userdata openhab_addons
docker compose up -d
docker compose logs -f openhab

Дожидаемся строки вида Started openHAB в логах, затем открываем http://<ip-сервера>:8080 (или ваш домен через reverse proxy). Мастер первого запуска попросит выбрать пакет («Standard», «Expert», «Simple») — берите Standard, если не уверены. Дальше:

1. Settings → Add-ons → Bindings — устанавливаем нужные протоколы. Для USB-стиков это Zigbee Binding или Z-Wave Binding, для умных розеток и датчиков на MQTT — MQTT Binding (плюс отдельный MQTT-брокер, о нём ниже).
2. Settings → Things → + — добавляем bridge (сам USB-контроллер), openHAB просканирует порт автоматически, если проброс из docker-compose сработал. Если Thing не появляется в списке — проверьте docker compose exec openhab ls -l /dev/tty* внутри контейнера.
3. Discovery устройств после подключения bridge обычно запускается сам (background discovery), новые Things появляются в разделе Inbox с иконкой «+».

Для MQTT-биндинга нужен отдельный брокер — Mosquitto легко добавляется вторым сервисом в тот же compose-файл:

  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mosquitto
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./mosquitto_data:/mosquitto/data
      - ./mosquitto_config:/mosquitto/config

После этого в openHAB создаёте Thing типа «MQTT Broker» с адресом localhost:1883 (сеть общая благодаря network_mode: host у обоих сервисов).

Персистентность и бэкап конфигурации

Файлы в openhab_conf — это по сути ваша логика умного дома в текстовом виде, и держать их только на одном сервере рискованно. Практичный подход:

• Инициализируйте git прямо внутри openhab_conf:

cd openhab_conf
git init
git add .
git commit -m "initial openhab config"

• Настройте .gitignore для служебных файлов (*.log, временные файлы редактора), а сами .items/.things/.rules/sitemaps коммитьте при каждом значимом изменении.
• Для userdata (история показаний датчиков, JSONDB с состояниями) git не подходит — это бинарные и часто меняющиеся данные. Тут лучше обычный архивный бэкап по расписанию:

#!/bin/bash
# /usr/local/bin/openhab-backup.sh
STAMP=$(date +%F_%H%M)
tar czf /backups/openhab_userdata_${STAMP}.tar.gz -C /path/to/openhab_userdata .
find /backups -name "openhab_userdata_*.tar.gz" -mtime +14 -delete

Добавьте в cron (0 4 * * * /usr/local/bin/openhab-backup.sh) и синхронизируйте архивы на внешнее хранилище — S3-совместимый бакет или другой сервер. Общий подход к автоматическим снапшотам конфигураций для контейнерных сервисов разобран в статье про Docker Compose для продакшена: частые ошибки и решения, если хотите унифицировать бэкап-стратегию по всем сервисам сразу.

Отдельно у openHAB есть встроенный механизм экспорта — в UI это Settings → Backup, который упаковывает conf и часть userdata в один архив прямо из интерфейса. Удобно для разовых снапшотов перед рискованным обновлением, но не заменяет регулярный автоматический бэкап.

Безопасность: доступ снаружи без риска

Раз мы используем network_mode: host, порт 8080 (и 8443, если включён HTTPS-listener) торчит наружу напрямую с хоста — это не изолированный порт контейнера, который можно было бы просто не публиковать. Здесь два обязательных шага:

1. Firewall. Закройте 8080/8443 для внешнего мира на уровне ufw/iptables, оставив доступ только с localhost и, при необходимости, вашей VPN-подсети:

sudo ufw deny 8080/tcp
sudo ufw deny 8443/tcp
sudo ufw allow from 10.8.0.0/24 to any port 8080

1. Reverse proxy с HTTPS для внешнего доступа. Если нужен доступ к панели снаружи (не только из дома), поднимайте Traefik или nginx на отдельном порту (443) с TLS-сертификатом, который проксирует на 127.0.0.1:8080. Подробная настройка с автоматическими сертификатами Let's Encrypt разобрана в статье Traefik как reverse proxy для Docker — конфигурация для openHAB отличается от примеров там только целевым портом сервиса.

Если проброс наружу вообще не нужен — самый безопасный вариант завести WireGuard-туннель и открывать панель только через VPN, вообще не публикуя 8080/8443 в интернет ни в каком виде.

Отдельно: не используйте дефолтный пароль администратора и включите Basic Auth или полноценную авторизацию в Settings → API Security, если панель хоть немного доступна извне — по умолчанию openHAB не требует логина при локальном доступе, и это осознанный компромисс разработчиков ради простоты первого запуска, а не забытая мера безопасности.

Ресурсы, обновления и типичные проблемы

Java-платформа тяжелее по памяти, чем событийно-ориентированный Python-стек Home Assistant — это стоит закладывать при выборе тарифа:

Это ориентир: точная цифра зависит от числа биндингов и глубины истории — проверяйте реальное потребление через docker stats openhab в первую неделю и корректируйте -Xmx.

Частые проблемы на практике:

• OutOfMemoryError в логах — решается увеличением -Xmx либо переносом тяжёлой истории датчиков с JSONDB на внешнюю БД типа InfluxDB, которая не держит всё в heap JVM.
• USB-стик «пропадает» после перезагрузки — типично, если в devices указан /dev/ttyUSB0, а после ребута он стал /dev/ttyUSB1. Используйте стабильный путь /dev/serial/by-id/usb-... вместо ttyUSBx.
• Обновление между мажорными версиями (4.2 → 4.3) ломает часть кастомных правил на старом синтаксисе Xtend. Перед апгрейдом делайте полный бэкап userdata и conf и тестируйте новую версию отдельно, если правил много.
• Discovery не находит устройства при network_mode: bridge вместо host — самая частая причина обращений на форуме openHAB, решается переходом на host-сеть.

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