Как установить и настроить openHAB на VPS

MAATRIX

Если дом обвешан датчиками, розетками и термостатами от трёх разных производителей, рано или поздно захочется один центр, который видит их всех и не зависит от Wi-Fi роутера, который вы же сами иногда перезагружаете. openHAB — как раз такой центр: он не привязан к одному вендору, умеет разговаривать с десятками протоколов через биндинги и годами живёт на минимальном железе. Разберём, как поставить его на VPS, что реально заработает через облако, а что нет — и почему это не то же самое, что тот же openHAB на Raspberry Pi у вас дома.

Зачем ставить openHAB на VPS и чем это отличается от домашней установки

openHAB — Java-платформа, и в этом её сила: она не «облачная замочная скважина» одного производителя, а универсальный интеграционный слой поверх Zigbee, Z-Wave, MQTT, KNX, HTTP-API и ещё сотни биндингов. Обычно её ставят на Raspberry Pi дома, втыкают USB-стик Zigbee или Z-Wave — и всё общается по локальной сети.

На VPS сценарий другой. Сервер физически не может увидеть USB-радиомодуль, который стоит у вас в квартире, поэтому прямое подключение Zigbee- или Z-Wave-устройств через VPS не работает — это стоит понимать сразу, до установки, чтобы не тратить время впустую. Зато VPS отлично подходит для трёх других задач:

• Центральный хаб для облачных и API-based интеграций — Netatmo, Sonos, погодные сервисы, IFTTT, Telegram-бот для уведомлений.
• MQTT-хаб для удалённых датчиков — если дома стоит брокер (Mosquitto) или мост, публикующий данные наружу через VPN или TLS, VPS принимает и обрабатывает поток без привязки к домашнему интернету.
• Резервный/облачный экземпляр для дашбордов, правил автоматизации и логики, которая не завязана на локальные радиопротоколы, плюс единая точка доступа через файервол UFW и HTTPS вместо дырявого проброса портов из дома.

Если нужен именно Zigbee/Z-Wave хаб — держите openHAB дома (или на mini-PC рядом с радиомодулем), а VPS используйте как «второй мозг» для внешних интеграций и удалённого доступа. Комбинация «openHAB дома + MQTT-мост на VPS» — рабочая схема, и ниже я покажу, как её собрать.

Требования к серверу и подготовка ОС

openHAB — это JVM-приложение поверх Java 17 (или новее, в зависимости от актуальной ветки на момент установки), плюс встроенная веб-консоль, Karaf-консоль управления и куча биндингов, которые сами по себе тоже что-то жрут. Официальный минимум скромный, но на практике комфортнее закладывать с запасом:

Беру для примера Ubuntu 24.04. Первым делом — обновление системы и базовые пакеты:

sudo apt update && sudo apt upgrade -y
sudo apt install -y wget curl gnupg apt-transport-https ca-certificates

Java на актуальные версии openHAB подтягивается автоматически как зависимость apt-пакета (обычно это сборка Zulu или Temurin JDK 17), так что вручную ставить JRE не обязательно — но если хотите проверить, что именно встанет, сделайте apt-cache depends openhab после подключения репозитория из следующего шага.

Дальше решаете, каким путём ставить: нативно через apt (проще интегрируется с systemd и логами journalctl) или в Docker (проще переносить и откатывать). Разберу оба.

Установка openHAB: официальный apt-репозиторий

Подключаем ключ и репозиторий openHAB (актуальный URL и метод подписи стоит свериться на официальной странице проекта — практика подписи ключей apt меняется от релиза к релизу):

sudo mkdir -p /etc/apt/keyrings
wget -qO - 'https://openhab.jfrog.io/artifactory/api/gpg/key/public' | \
  gpg --dearmor | sudo tee /etc/apt/keyrings/openhab.gpg > /dev/null

echo 'deb [signed-by=/etc/apt/keyrings/openhab.gpg] https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable main' | \
  sudo tee /etc/apt/sources.list.d/openhab.list

sudo apt update
sudo apt install -y openhab

Включаем и стартуем сервис:

sudo systemctl daemon-reload
sudo systemctl enable --now openhab
sudo systemctl status openhab

Первый запуск разворачивает Karaf-контейнер и качает базовые пакеты — на VPS с 1 vCPU это может занять пару минут, наберитесь терпения и проверяйте лог:

sudo journalctl -u openhab -f

Когда сервис поднялся, по умолчанию веб-интерфейс слушает на портах 8080 (HTTP) и 8443 (HTTPS с самоподписанным сертификатом). Проверить с самого сервера:

curl -I http://127.0.0.1:8080

Если пришёл ответ — идём дальше, к настройке доступа снаружи.

Установка через Docker Compose — альтернативный путь

Если вы уже держите остальные сервисы в контейнерах, логичнее и openHAB завести так же — проще бэкапить конфиг одной папкой и переносить сервис на другой сервер при необходимости. Официальный образ поддерживается активно, конфигурация похожая на другие self-hosted сервисы в Docker Compose:

services:
  openhab:
    image: openhab/openhab:4.3.2
    container_name: openhab
    restart: unless-stopped
    network_mode: host
    tty: true
    volumes:
      - ./conf:/openhab/conf
      - ./userdata:/openhab/userdata
      - ./addons:/openhab/addons
    environment:
      - USER_ID=9001
      - GROUP_ID=9001
      - CRYPTO_POLICY=unlimited
      - OPENHAB_HTTP_PORT=8080
      - OPENHAB_HTTPS_PORT=8443

network_mode: host здесь не для красоты — часть биндингов рассчитывает на mDNS/UPnP discovery в той же сетевой плоскости, и без host-режима они просто не увидят устройства даже там, где это в принципе возможно. Если host-сеть на вашем провайдере недоступна (некоторые VPS-платформы её режут), пробрасывайте порты вручную (8080:8080, 8443:8443) — discovery-биндинги при этом отвалятся, но веб-интерфейс и MQTT/API-биндинги отработают нормально.

Пин версии образа (4.3.2 вместо latest) — сознательный выбор: openHAB регулярно выпускает milestone-сборки, и «мажорный» апгрейд посреди ночи без предупреждения вам не нужен.

Поднимаем:

docker compose up -d
docker compose logs -f openhab

Доступ извне: домен, HTTPS и файервол

Открывать порты 8080/8443 в интернет напрямую — плохая идея: веб-консоль openHAB и Karaf-shell не рассчитаны на то, чтобы по ним долбили боты. Есть два разумных варианта.

Вариант 1 — myopenHAB Cloud. Официальный облачный коннектор openHAB устанавливает исходящее соединение с cloud.openhab.org и даёт удалённый доступ к вашему инстансу без единого открытого входящего порта — это самый безопасный путь для доступа с телефона. Ставится как биндинг/аддон через веб-консоль (Settings → Add-ons → myopenHAB Cloud), после чего связывается с бесплатным аккаунтом на myopenhab.org.

Вариант 2 — свой домен + reverse proxy. Если хотите полноценный собственный URL с настоящим TLS-сертификатом (а не самоподписанным), поставьте перед openHAB Caddy или Traefik — оба умеют автоматический Let's Encrypt. Минимальный пример на Caddy:

home.example.com {
    reverse_proxy 127.0.0.1:8080
}

Один блок, сертификат и редирект на HTTPS Caddy настроит сам. Подробный разбор связки прокси и Docker-сервисов — в статье про Traefik как reverse proxy для Docker.

В любом случае закрывайте прямой доступ к 8080/8443 файерволом, оставляя открытыми только 80/443 (для прокси) или вообще ничего, если используете только myopenHAB Cloud:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw deny 8080/tcp
sudo ufw deny 8443/tcp
sudo ufw enable

Разбор UFW со всеми нюансами (что делать, если Docker обходит правила файервола напрямую через iptables — частая засада) — в статье про настройку UFW на VPS. Это важно: Docker по умолчанию правит цепочки iptables в обход UFW, и голого ufw deny для контейнерных портов может не хватить — либо публикуйте порты явно только на 127.0.0.1, либо настраивайте UFW-Docker интеграцию отдельно.

Подключение устройств и биндингов: что реально работает через облако

Раз мы на VPS без физического доступа к радиоэфиру, честно разложим биндинги на три группы.

Работают отлично, без оговорок:

• Облачные/API-биндинги — Netatmo, Withings, Sonos (через сеть), OpenWeatherMap, Telegram, IFTTT, HomeKit-мост (для управления через Siri после связки).
• HTTP/REST-биндинг — если ваши устройства (или домашний хаб) отдают HTTP API, VPS дотянется до него через интернет.
• MQTT-биндинг — если дома или на промежуточном шлюзе стоит брокер Mosquitto, который публикует топики наружу (через VPN-туннель или TLS-подключение к брокеру на VPS), openHAB на сервере подписывается на них как на любые другие MQTT-топики.

Работают с оговоркой «нужен мост»:

• Zigbee/Z-Wave — сам стик физически должен стоять там, где крутится софт, который его опрашивает. Рабочая схема: Zigbee2MQTT (или deCONZ) крутится на маленьком устройстве дома с воткнутым Conbee/CC2652-стиком, публикует состояния в MQTT, а openHAB на VPS подписывается на эти топики через защищённый MQTT-канал. Радиослой остаётся дома, логика и дашборды — на сервере.
• KNX/Modbus по IP-шлюзу — если шлюз доступен по сети (в том числе через VPN до дома), биндинг работает и с VPS.

Не заработают в принципе на голом VPS:

• Bluetooth-биндинги, всё, что требует USB-донгла впритык к машине с openHAB (без моста через MQTT/сеть).

Для организации моста между домом и VPS обычно поднимают WireGuard-туннель — тогда домашний MQTT-брокер и облачный openHAB оказываются в одной приватной сети, и вопрос портов/TLS для MQTT снимается сам собой.

Резервное копирование и обновления

openHAB несёт встроенный CLI для бэкапа конфигурации и правил:

sudo openhab-cli backup /var/backups/openhab/openhab-backup-$(date +%F).zip

В архив попадают conf/ (Items, Things, Rules, Sitemaps) и часть userdata/ (без логов и кэша JVM — это не нужно). Для регулярности добавьте в cron:

0 3 * * * root /usr/bin/openhab-cli backup /var/backups/openhab/openhab-$(date +\%F).zip

Если ставили через Docker Compose — бэкапить ещё проще: архивируете папки conf/, userdata/, addons/ целиком, они и так лежат отдельно от контейнера. Хранить архивы стоит не только на самом VPS, а копировать на отдельное хранилище — по той же логике, что описана в статье про бэкап Docker volume: один диск — не бэкап, это просто вторая копия, которая упадёт вместе с первой.

Восстановление — зеркальная команда:

sudo systemctl stop openhab
sudo openhab-cli restore /var/backups/openhab/openhab-backup-2026-08-20.zip
sudo systemctl start openhab

Обновление на нативной установке — обычный apt upgrade, но перед мажорным скачком версии прочитайте официальный migration-гайд: между крупными версиями меняется формат некоторых аддонов, и «обновил и забыл» иногда превращается в вечер с логами. На Docker — та же логика: сначала бэкап, потом смена тега образа в compose-файле, docker compose up -d и проверка логов.

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