Deconz for


Strange as it May sound yes the update was Successfully completed. The error are about software that is missing to flash the conbee stick. All usb related.

If you restart the addon it should state that the firmware is up to date.


I’ve just developed a new deCONZ Add-on for (sorry @gjong, definitely not trying to step on your toes at all, I’ve had a look at your Add-on and it’s excellent work, but I’m aiming for both Conbee and RaspBee support).

  • This add-on should support both Conbee and RaspBee.
  • This add-on relies on a Docker Hub image (not local build) which should make installing fast, on both amd64 and armhf; and, there is a build pipeline in place to automatically update the image and add-on when a new deCONZ beta is released.
  • This add-on should persist your ZigBee network data in your config folder in a subfolder called “deconz” (which will persist through version updates).
  • This add-on runs on the host network and allows you to change the listening ports of the webui and websockets interfaces with config variables (should help with uPNP detection with the PWA WebUI).

I would be grateful for any beta testers since this is my first Add-on - I’ve verified that it works on my end on a RasPi 3, but more testing is definitely needed.

To install, add this repo to your Add-On Store tab:



Sounds awesome @marthocoo

Great work!


@marthocoo its good to have a central image that would work for both the Raspbee and the Conbee. I only build one for the Raspbee because none of the other docker images seemed to work. To look if it works properly with the Raspbee I installed your image and uploaded a backup I took from my own docker image.

Though it took several attempts to upload the backup it finally worked and I can confirm the image works within Hassio with the Raspbee. All the lights, groups and scene’s where imported and seem to work.


@gjong Thanks for testing! Unfortunately in doing more testing it appears that my addon doesn’t persist the configuration like I thought it did - seems that there are more places on the filesystem that user data are stored. Does your addon persist config through an upgrade/reinstall? I’ve raised an issue with the deCONZ dev to see if I can get something added to deCONZ itself that would help with this. Until then I’ve added some info to the addon regarding backing up and restoring config before upgrading as a workaround.


It does persist through updates of the addon. I store the data in /data/deconz and then symlink it to the default deCONZ folder. But I doubt that it will last a uninstall and re-install, since that directory is then removed by resinos.

I’ve had issues with the default hassio mounts not working properly, but that was fixed when I moved over to the debian-base image of franck.


@gjong Interesting - I didn’t consider that the directory is removed during uninstall (maybe defeats the point of persisting?) but not upgrade. Maybe mine will work fine during upgrade then since all I’m doing is changing root’s homedir to /data, so that the .local/share/dresden-elektronik/deCONZ subfolder is created inside /data.


@marthocoo I’m trying to get the HASS io plugin working. How do i specify which USB device to use?

I have a conbee connected to hass. It shows up in the hardware listing when i SSH into HASS and give the command “hassio host hardware” .

I also have other Serial usb devices connected to my hass io (smart meter reading).

If i go to the webpage, i only see a conbee gateway with the ip address hass IO, no conbee device as i previous had on an other system running deconz.


So does it work? If the gateway is discovered on that page it should be working.


@marthocoo After some experimenting i found the source.
It works only if the deconz usb device is the only usb serial device connected to hass io.
Any idea how to do a work around ?

My suggestion would be to use a conif paramter with the usb name of the conbee gateway. I would use the /dev/by-id/ device path to always point to the conbee gateway.


I’m going to take a look into this but I don’t have a quick fix unfortunately. May involve some rethinking of how the addon works. First I need to do some tests against the base Docker image to see if this problem is present there too.

Can you do me a favour? Open an issue at and include more details - specifically can you figure out what ttyUSB number the Conbee is being assigned when your other serial device is also attached?


I will do that.

Another thing i noticed.
When i restart the host container, it does not add all of the devices. I have a lot of them ( approximate 40). Each time it is different which ones. I think this has to do with the fact that deconz has not yet listed all of the devices before Homeassistants plugin asks deconz for the device listing.

@Robban Could this be the case ?


Could be. What happens if you restart Deconz afterwards?

I have on my to do list to add support for adding new devices without restarting hass. Might help with this


@Robban Restart of Deconz Docker does not help, the detected devices stay the same.


Sorry. Not 100% today, I meant HASS of course… Will all devices be available if you restart hass after everything is up and running?


@Robban If i restart the home assistant containter, all devices show up.


Ok. Would you mind enabling debug for deconz component to see if you get any messages from Deconz about added devices?


I’m guessing you’re on RaspBerry Pi? I think it may be a limitation of the hardware, or a limitation of the platform.

Hardware maybe because there isn’t enough resources to load all the devices quickly enough.

Platform maybe because doesn’t let you block startup until your Add-on is ready to go - you can just specify what phase of startup your Addon gets loaded in (and I’m loading the Add-on as early as possible). I think there may also be a deCONZ issue as when using Conbee on armhf deCONZ basically tries to find RaspBee first, times out, and then finds Conbee. So that introduces some delay too.

In the short term, you’ll have to resort to restarting the HA container to pick up all deCONZ devices, I’m sorry to say.


An ugly work around for this would be to use the discovery function. It takes some additional time before the discovery component is complete and would possibly give deconz the extra time it needs to start up.

A small warning is that with config entries coming up, discovery might become faster to load after the initial set up so it might only solve it for a few weeks.


No problem, What scenario specific do you want me to record ?