openHAB

Last reviewed Sep 13, 2026 · 906 words

Pick openHAB over Home Assistant when you want your smart home defined in text files you can diff, a rule engine that treats automations as programs rather than flowcharts, and a runtime that runs entirely offline with no account anywhere. Pick Home Assistant for everything else, and especially if you want the widest device support and the largest pool of people who have solved your exact problem. That is the short version of the Home Assistant versus openHAB decision, and the rest of this is about what living with openHAB is actually like.

Things, Items, Channels: the model you must learn first

openHAB's abstraction is stricter than Home Assistant's and it is the source of both its power and its learning curve. A Thing is a physical device or service (a Zigbee bulb, a weather API). A Thing exposes Channels (brightness, colour temperature, a temperature reading). An Item is a named piece of state you link to a channel, and Items are what rules, dashboards, and persistence work with. A binding is the add-on that knows how to talk to a class of Things; there are several hundred, covering Zigbee and Z-Wave, MQTT, KNX, Modbus, Hue, Shelly, Sonos, most TV brands, and a long tail of niche industrial and hobby hardware. New users routinely stall for a week on the Thing/Item distinction; once it clicks, the system is consistent everywhere.

Rules are code, and that is the point

The rule engine accepts a domain-specific language (the original), JavaScript, jRuby, Python, Groovy, and Blockly for visual editing, and rules can be written in the interface or in .rules files on disk. A rule is a trigger (an Item changed, a cron time, a system event) plus a body with full access to Item state and history. Time-based logic, hysteresis, "if nobody has been home for 2 hours", presence merging across three signals: all of that is a few lines rather than a nested YAML automation. Persistence (rrd4j by default, InfluxDB or JDBC optionally) means rules can ask what the average temperature was yesterday. If you have ever written a Home Assistant automation that grew a template sensor and three helper booleans to express one sentence, this is the part of openHAB that will feel like relief.

Java means 1 GB is the real minimum

The runtime is Java on an OSGi container, and it wants memory. 1 GB is the floor and on a Raspberry Pi 4 with 2 GB it is comfortable; on a 1 GB board it runs, but startup takes several minutes and adding a heavy binding can push it into swap. Startup time is the practical annoyance: a restart after a config change can take 1 to 3 minutes while bundles load, which is slower than Home Assistant's reload and matters when you are iterating on rules. The openHABian image for Pi does the OS setup for you; the Docker image is openhab/openhab with the config directories bind-mounted, and the web interface is on port 8080 (8443 for HTTPS):

services:
  openhab:
    image: openhab/openhab:latest
    network_mode: host
    volumes:
      - ./openhab_addons:/openhab/addons
      - ./openhab_conf:/openhab/conf
      - ./openhab_userdata:/openhab/userdata
    environment:
      - USER_ID=1000
      - GROUP_ID=1000
    restart: unless-stopped

Host networking is not optional in practice: mDNS and UPnP discovery for bindings need it, as do USB Zigbee and Z-Wave sticks passed through as devices.

Offline is real, and remote access is opt-in

Nothing in openHAB phones home. Bindings talk to local devices or to cloud APIs you configure; the core has no telemetry and no account requirement. Remote access is through the openHAB Cloud Connector, which uses a free service run by the openHAB Foundation, or you self-host the cloud component, or you use Tailscale and skip it. The home-automation category is full of platforms that quietly require a vendor cloud; this one requires nothing, and if the internet goes away your rules keep running.

The community is smaller and that costs you

The core repository's 1,139 stars understate a project with a busy forum and 16 years of history, but next to Home Assistant it is a small town. Fewer bindings for the newest consumer gadgets, fewer blog posts walking through a specific integration, and slower answers when something odd happens. Device support for mainstream Zigbee, Z-Wave, MQTT, and KNX is excellent; support for the latest cloud-only smart plug from a marketplace listing is where Home Assistant's numbers win. Read the first month with Home Assistant write-up and ask whether that path sounds like yours; for most first-timers it is.

What I'd do

If I were an engineer who wanted a smart home in version control, with rules written in a real language, running on a box with no account and no cloud, I would run openHAB on a 4 GB Pi or a small x86 box with the config directory in git and a Zigbee coordinator over USB. I would give myself two weekends before judging it. For a family who wants the most devices to just work and the most tutorials to follow, I would run Home Assistant and not look back. openHAB is the better system for the person willing to learn it, and the worse one for the person who will not.