Multiple things when using deCONZ ZigBee

  • Platform information:

    • Hardware: Raspberry Pi 4
    • OS: Raspberry Pi OS / x64 / 11 (bullseye)
    • Java Runtime Environment: 11.0.15 (Temurin-11.0.15+10) (running in Docker)
    • openHAB version: 3.4.4 (running in Docker)
  • ConBee 2 USB stick

Dear community,

Please bear with we if it’s a dumb question, but I want to understand this: I’m running several ZigBee devices and as ZigBee gateway I’m using a ConBee 2 USB stick.

When adding a thing within openHAB via the deCONZ binding (e. g. an Aqara sensor providing temperature, pressure and humidity), there is always one separate thing per device and “measurement target” (temperature, pressure and humidity) - so a single physical device is split into several things, e. g.:

  • Sensor1_Humidity

  • Sensor1_Temperature

  • Sensor1_Pressure

Each thing only has a single channel (either humidity, temperature or pressure) plus some metadata (e. g. last updated). When converting them into items, it looks like this:

  • Sensor1_Humidity_Humidity

  • Sensor1_Temperature_Temperature

  • Sensor1_Pressure_Pressure

So due to the split on the thing-level, this leads to some kind of semantical duplication - but I never really wondered about that.

But yesterday, I added a smart plug via the AVM Fritz binding and this device is recognized within openHAB as a single thing with multiple channels (e. g. temperature, current voltage, current energy, etc.) - and this feels much more natural to me.

Long story short: why is it that the ZigBee devices are split into different things per sensor, but not the smart plug? Is the ConBee implementation responsible for that or is there anything how I can tweak that in openHAB?

Thank you :wave:t2:

The question is how the device is presented on ZigBee side (which is what deconz exposes). If the device is exposed with different ids, then openHAB also creates different things. With the current design of the binding it is not possible to group devices with multiple ids.

Okay, that’s what I was thinking. So it’s a question for the deCONZ team, right?

Difficult, what deconz does is exposing what the device reports, so that is probably correct. It would require a rewrite of the openHAB side to properly group these devices based on their UID.

I have a environmental sensor that reports these UIDs for temperature and humidity:


And my Futur blinds report for the blind itself and the battery sensor


So it might be possible to figure out what belongs together by looking at the UIDs. However, that would be a breaking change for all existing installations, because we need code to handle more than one id per thing. I have currently no idea how we should handle that gracefully.


Ah okay, thank you for the additional explanation. So it seems there’s nothing I can do at the moment - which is not a problem at all, just wanted to understand where this is coming from.

1 Like