deCONZ needs a ConBee dongle or RaspBee shield

One plugin, sitting inside a vendor application

The single most common misunderstanding about this repository is what it is. The README calls it the deCONZ REST plugin, and its job is to provide a REST API to access Zigbee 3.0, Zigbee Home Automation and Zigbee Light Link devices.

It is not a standalone daemon. It is a C++ plugin loaded into the deCONZ application. The README makes this concrete later on: precompiled deCONZ packages are available per platform and those packages contain the main application together with the pre-compiled REST API plugin. Install the package and you get both.

That shape explains the repository layout, which is unusual for something calling itself an API. The root is not a `src/` directory but a flat list of `.cpp` and `.h` pairs named after the domain: `air_quality.cpp`, `alarm_system.cpp`, `appliances.cpp`, `backup.cpp`, `change_channel.cpp`, `daylight.cpp`, `device_compat.cpp`, `device_descriptions.cpp`, `de_web_plugin.cpp` and `de_web_widget.cpp`. There are directories for `crypto/`, `cj/`, `device/` and `devicetype` style groupings, plus `button_maps.json` with its own `button_maps.schema.json`, and `description_in.xml`.

The `.cpp` and `.h` files at the root are the plugin itself, compiled against `CMakeLists.txt`. `de_web_plugin.cpp` and `de_web_widget.cpp` are the HTTP and widget halves, and `de_web_widget.ui` is a Qt Designer form, which says a good deal about the host application.

The user-facing front end is separate again. The Phoscon App is a browser based application supporting lights, sensors and switches, documented separately on the Phoscon site. So the arrangement is: a Zigbee radio, a C++ application from dresden elektronik that speaks to it, an HTTP API plugin inside that application, and a browser UI on top.

The hardware line decides whether deCONZ applies to you at all

The README is blunt about this. To communicate with Zigbee devices you need one of two things: a RaspBee or RaspBee II Zigbee shield for the Raspberry Pi, or a ConBee, ConBee II or ConBee III USB dongle.

The same list is repeated under hardware requirements, along with the supported Raspberry Pi models: Pi 1, 2B, 3B, 3B+ or 4B.

This is the reason the plugin is not a general purpose option. If your Zigbee coordinator is a USB stick from another vendor, or a bare module behind your own firmware, none of this applies.

The vendor coverage is broad but specific. The README names Zigbee 3.0, ZHA and ZLL, and lists Xiaomi Aqara, IKEA TRÅDFRI, Philips Hue, innr, Samsung and many more, with the supported device list maintained on the project's wiki rather than in the README. The topic tags add `conbee`, `raspbee`, `raspberry-pi`, `home-automation`, `zha` and `zll`, which is a fair summary of the ecosystem it serves.

So the correct evaluation order is: confirm the radio, then confirm your OS, then look at the API.

Platform support is a list with names struck through

The supported platform list reads like a support policy rather than a feature list, because the retired entries are still shown with strikethrough.

On the Debian side, Raspbian is listed with Jessie and Stretch struck through, followed by Buster, Bullseye and Bookworm. On Ubuntu, Xenial is struck through while Bionic, Focal Fossa and Jammy remain. Windows 7, 10 and 11 are listed, and macOS is listed without version detail.

The struck-through names indicate that Jessie, Stretch and Xenial are no longer current entries in the supported-platform list.

Packages are distributed per platform from the project's own download host. Windows and macOS have dedicated directories, and Linux builds are served under `raspbian/beta/`, `ubuntu/beta/` and `debian/beta/`, where the beta in the path matches the release schedule rather than indicating unstable software.

Manual installation on Linux is two commands, installing the `.deb` and then letting apt fix dependencies:

sudo dpkg -i <package name>.deb
sudo apt-get install -f

Building the plugin yourself is a separate path, described in `BUILDING.md` rather than in the README, so there is no build command to copy here.

Running headless is two systemd commands, and the GUI fights you for the radio

On a Linux box with no display, the README explains that the deCONZ package ships a systemd script so deCONZ can run without an X11 server, and then gives the sequence.

First enable the service at boot:

sudo systemctl enable deconz

Then disable the GUI, because the sd-card image and the default installation autostart the deCONZ GUI:

sudo systemctl disable deconz-gui
sudo systemctl stop deconz-gui

That second part is the real lesson. A headless server install does not merely fail to start; it starts the GUI service instead, and two services holding the same USB dongle is the kind of thing that produces intermittent flapping rather than a clean error. Disabling `deconz-gui` before relying on the headless service is not optional polish.

The upgrade path deserves the same attention. The README marks the following instruction as important: if you are updating from a previous version, always create a backup in the Phoscon App and read the changelog first. A Zigbee network coordinator holds the state of your whole mesh, so the backup is not optional either.

Weekly betas, a BSD licence, and a C++ core built on seven libraries

The release cadence is the most distinctive operational fact about this project.

Beta releases are scheduled roughly once per week. After one to three betas a stable version is released and a new beta cycle starts. The visible tags match that pattern: v2.33.0-beta on 2026-04-12, v2.33.1-beta on 2026-06-23, then v2.33.2 stable on 2026-07-17. Each release has a milestone updated during development with the related pull requests, and stable and beta releases both ship precompiled packages.

That cadence cuts both ways. It means fixes and firmware updates arrive constantly, which is valuable when a device misbehaves. It also means there is a meaningful difference between running a stable tag and running whatever the current beta does, and for a home installation that is a choice rather than a detail.

The third party libraries the plugin uses are listed: ArduinoJSON, the Duktape JavaScript engine, SQLite, Qt, a qt-json fork, OpenSSL and a colorspace library. Duktape is the interesting one, since it embeds a JavaScript engine inside a Zigbee stack, and it explains why the repository carries device description files rather than only C++ device classes.

The licence is BSD 3-Clause, permissive, with `LICENSE.txt` at the root. The project is not archived and the last push was on 2026-09-10, after the latest stable tag. There is a `CONTRIBUTING.md` and a `.github/` directory, and community support runs through the deCONZ Discord server rather than the issue tracker for general questions.

Documentation is split across three places, which is itself a sign of how large the surface is: the REST API reference, the deCONZ C++ plugin API, and the DDF plus C++ device API documentation, the last of which is what you want if you are contributing a device type.

Editorial conclusion

Adopt deCONZ if you want a local Zigbee coordinator with an HTTP API and you already own ConBee or RaspBee hardware, since the plugin is only usable behind one of those radios. Do not adopt it as a general Zigbee library, because it is a plugin for one vendor's deCONZ application rather than a standalone daemon, and do not skip the hardware list. Verify first that your adapter generation is supported, that your OS matches one of the listed platforms, and read the changelog and take a Phoscon App backup before updating, as the README insists.

Frequently asked questions

Official sources

1. dresden-elektronik/deconz-rest-plugin on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases