ioBroker

Last reviewed Sep 13, 2026 · 864 words

Pick ioBroker if you want to write your automations in real JavaScript and you speak, or can tolerate, German. Pick Home Assistant for everything else. That is the split after a decade of both projects, and it is not a criticism of ioBroker: its scripting engine is the best in the category, its adapter list is enormous, and its community forum is one of the most active in home automation. It is simply a smaller project (around 1,400 stars on the core repository, though the code is spread over hundreds of adapter repositories) built for a different kind of user.

Everything is an adapter, including the parts you'd expect to be core

ioBroker is a message bus plus a tree of objects and states. Every capability arrives as an adapter, which is a separate Node.js process: one for Zigbee, one for MQTT, one for the web admin, one for the JavaScript engine, one for each visualisation front end, one for history. The js-controller process supervises them and the state store, which lives in flat files by default and can move to Redis when you have thousands of states changing per second.

The upside is isolation and choice: a crashing adapter takes down only itself, and there are 500-plus adapters covering vendor clouds, local protocols, weather, calendars, and hardware that Home Assistant never got around to. The downside is that you assemble the system yourself. A fresh install does nothing until you add adapters, and each has its own settings page, its own update cadence, and its own maintainer, some of whom have moved on.

The install that works and the one that surprises people

On a Debian or Ubuntu host, the official installer does the whole job:

curl -sLf https://iobroker.net/install.sh | bash -

It installs Node.js, creates an iobroker user, sets up the systemd service, and puts the admin UI on port 8081. That is the supported path and the one the forum assumes when you ask for help. Docker works via the community buanet/iobroker image, which is well maintained, but many adapters expect to talk to USB sticks, mDNS, and multicast, so plan on network_mode: host and device passthrough from day one. The catalogue's 1 GB minimum is right for a dozen adapters; a Raspberry Pi 4 with 4 GB is the common baseline, and a small x86 box is more comfortable once you add history and a visualisation adapter.

Back up with iobroker backup from the CLI, which produces a tarball of objects, states, and adapter configs. Test the restore once on a second machine, because a system assembled from 30 adapter versions is exactly the kind of thing that does not rebuild from memory.

The JavaScript adapter is why people stay

Home Assistant automations are YAML or a visual editor, with Python only through escape hatches. In ioBroker the javascript adapter gives you a full Node runtime with an API over the state tree: on({id: 'zigbee.0.kitchen.motion', val: true}, () => setState('hue.0.kitchen.on', true)), and from there anything Node can do. Blockly is layered on top for non-coders, and there is a TypeScript mode. Complex logic that would be 80 lines of YAML with templates is 10 lines of code, and you can unit-test it. Node-RED runs as an adapter too, for people who prefer flows.

Visualisation is where it fragments

ioBroker has no single dashboard. There is vis, the original drag-and-drop builder; vis-2, its successor; jarvis; lovelace, which emulates Home Assistant's UI; and several more. Each is an adapter with its own widgets and its own learning curve. The flexibility is real and so is the choice paralysis. If you want a dashboard that looks finished on day one, this is the strongest argument for Home Assistant and its default UI.

Where it sits against the big two

Home Assistant has the larger community, the better mobile apps, the polished onboarding, and the higher chance that a random device has a working integration with a screenshot in the docs. openHAB is the other Java-flavoured veteran with a rules DSL; the Home Assistant vs openHAB comparison covers that pair. ioBroker is the third option, strongest in the German-speaking market where it started in 2014, and strongest for people who would rather write code than click through blueprints. The home automation category has no shortage of options; this one is for programmers.

What I'd do

If I were building a new smart home and did not already know I wanted to script it, I would run Home Assistant and not look back. If I had a Node.js background, a Zigbee stick, and a taste for writing my own logic, I would run ioBroker on a small x86 box with the native installer, add the admin, javascript, zigbee, mqtt, and history adapters, pick vis-2 and ignore the other dashboards, and schedule iobroker backup nightly. Either way, decide before the sensor count hits 50; migrating between the two is a rebuild, not an import.