Zigbee binding

Tags: #<Tag:0x00007f4348c76810> #<Tag:0x00007f4348c76720>

I think that’s the way it is now, but I will check. Possibly the node added call is not made though until all the initial discovery tasks are complete (ie including the mesh info calls). I guess this is what you are getting at? I will check that as it may help a little during discovery, which is of course a busy time…

It is performed at the end of the discovery, and then periodically if the mesh update is configured.

I see your point now though and I’ll have a look at that - you might be right that this task is being performed during initial discovery even on EDs. I don’t think that’s an impact on the above issues I’ve seen in any case, as the slow discovery is also there for routers when they are still considered to be an ED.

I just had a look at the code - the routing table is not requested during initial discovery - only during mesh update if the type is a router. The neighbour table is however requested - this is “ok”, but I think you are right that an optimisation here is to remove this from discovery.

The only other request is the power descriptor - I think it is safer to have this before the discovery completes so we have the complete picture of the node.

Is this always happening or only under busy network?

If there is no load, let me explain why I think this should not be affecting (and hence my doubts). If the node descriptor was the very first thing to be discovered, it is just one outgoing command: it cannot delay the whole discovery.

As indeed we do not update the queue till the endpoints are discovered, endpoint discovery may still take several commands: this might delay things only if there are several other discoveries ongoing or the sleepy queue is full, but if it is not, there shoud be no difference.

That’s why I ask: if there is no load, even if the slowness seems to come from this, there must be another reason (even if it is somehow a side effect, I would like to figure out why), and maybe it is because somehow we are trying to complete route discovery, neighbour discovery, and child discovery, etc, before calling nodeUpdated? If node descriptor and endpoints are not sometimes the very first thing to be discovered, this may produce the effect of the whole discovery being delayed, but again this should only happen under load…


It’s always there.

Yes, there is - as I said above, it is not related to the isSleepy state - it is related to the queue itself (ie the fact that the queue profile is different). I’ll explain further below.

No - this is not the case - other than neighbours. I have a PR to go that will remove this, but it is in any case not the issue.

So, as mentioned earlier, the issue is not the isSleepy() state - the issue is the queue profile. The issue is that the queue has a minimum time between commands, and for sleepy queues, this is quite long (7.6 seconds!). Thinking about this some more, and I don’t think this is needed at all - we can drop this to the same as non-sleepy queues (50ms) and instead set the maximum number of outstanding transactions in sleepy queues to 1. This will mean that the pacing will be 50ms minimum between commands, but if a command completes it will send the next immediately (assuming it’s more than 50ms), and if it doesn’t complete, it will respect the 1 frame outstanding requirement imposed by the parent queue size in the router.

That should (I think) solve this :slight_smile:

FYI I’ve created two PRs -:

I’ll give this a test shortly to make sure it resolves what I was seeing, but any comments welcome as always :slight_smile:


I’ve now deployed an updated 1.1.11-SNAPSHOT of the ZigBee libraries. I would appreciate any further comments on the performance of this version - if there are no major issues in the next few days I will roll this out into the openHAB target platform so that it is available for everyone with the openHAB 2.5 snapshots.

To use the latest snapshot, see this thread for the update script -:

1 Like

Hey - I’m just getting back home so little late getting to install this new update - I don’t see this committed to master so how am I able to install this? I tried selecting dev and specifying the level but no luck. Are you pushing this to master? I’ve not had issue installing those.

As said above, please use the script from @5iver in the post I referenced. Specify the SNAPSHOT version that I referenced above.

for some reason whenever I install the 1.1.11 version my openhab instance doesn’t pick it up. The files get placed but I never see it in the karaf bundle list I end up just getting

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zigbee.ember [288]
Unresolved requirement: Import-Package: com.zsmartsystems.zigbee

Just to clarify for anyone with questions, it’s the Zigbee Library snapshot (option 3). The most recent version availble will be populated for you, so if you don’t see 1.1.11, you’ve selected the wrong option.

Check the files.
If you’re using the script, look in your addons directory and make sure the file sizes look correct. These will be jar files, so can be opened and viewed using an archive manager. There is a lot of changes going on, and I have seen garbage coming down. If the files look wrong, rerun the script. You may need to wait some time before rerunning the script. Your previous binding and libraries are in the /addons/archive/ directory, so you can manually restore them. The manual steps needed to do everything the script does are included in the readme.md, so you could always check to see if there is an issue with the files downloading.

If they are OK, restart the binding (or OH).
If the files look correct, I have also needed to restart OH at times. I’ve had trouble restarting the zigbee binding in the past, instead of doing an OH restart, but that may be resolved.

1 Like

heads up to anyone that might have been having issues as I was - it turns out that the files never came down correctly because I was using an old version of the script. As soon as I updated the script the files downloaded in a format that didn’t have the version number in the file name and everything started coming up correctly.

Thanks for the help!

1 Like

If/when time permits, I’ll put in a version checker to notify if there is an udated version of the script.



Chiming in on the “Duplicate entry” for the HUE Dimmer.
I can see the Dimmer as an “Unknown Device” in PaperUI Inbox.
The ID Checks out to be my HUE Dimmer that I previously installed.
The logs show this:

2019-03-10 13:08:06.935 [me.event.InboxRemovedEvent] - Discovery Result with UID 'zigbee:device:05000E5F:001788010408e12d' has been removed.
2019-03-10 13:37:39.061 [home.event.InboxAddedEvent] - Discovery Result with UID 'zigbee:device:05000E5F:001788010408e12d' has been added.

When I choose to ignore the device, it will pop up again in my Inbox and keeps being “Unknown”.
Not dramatic - but rather interesting IMHO. It is properly paired to my openHAB and works fine. The remote goes into “Sleep” from time to time but reacts immediately when I press it. So that is fine.

openHAB Version is 2.5.0 Build #1549.
Again not dramatic but it just rediscovers.

Just add the “unknown” device, and remove/delete it afterwards. It shouldn´t discover it again, unless you press the button on the back of the Hue dimmer.
I have simular situation from time to time, also with the Hue Motion Sensor… this one is actually discovered (2. discovery) when binding is restarted, and removed again automatically, just a second after.
I´m not aware of the reason. And I share the same opinion like you. It´s not dramatic, so I´ve just lived with it, focusing on more important issues.

1 Like

I’ve just added 3 OSRAM CLA60 RGBW bulbs; I was expecting a dimmer channel and on/off, but I think they must have been consolidated?

Sorry if this is a daft question, but I’m colour blind so generally just leave the “color” settings alone as I really can’t detect subtle colour changes…

How would I go about achieving switch & dimmer functionality using the colour controls?


Never mind, worked it out. Still don’t like colour wheels…

You don’t need color wheels - you can link the color channel with a dimmer item or switch item and it will work correctly.

1 Like

Yes, as Jared said, you can link a color channel to a switch item and link the same color channel to different dimmer item and both will work

1 Like

Since I updated the Zigbee binding and lib two days ago, I have had a hell with some of my devices like the Philips Hue Dimmer Switch, Osram powerplug and the Trust motion sensor… The Philips Hue motion sensor have also had a hickup, which I believe is due to running out of battery. I changed the batteries yesterday, and it has been running since.
Yesterday I removed the dimmer switch, Osram plug and the Trust sensor. Today they all are gone again (they still show online, but no reaction anymore).
This problem seem very much like the ones I had several months ago.

When I updated the binding two days ago, something went totally wrong. My Ember dongle wouldnt go online. It said problems with the serial port. Removing the dongle and add it again did not do any good either. I had to restart openhab to get it to run again. Then I had to remove the devices and add them again as well, ofcouse.

After this, I did some testing with a Xiaomi door/window sensor, which didnt work (ofcouse)… I dont know if it´s related, but since then I simly can not add the Trust motion sensor again… It discoveres fine, but never finished the discovery fully… I have tried quite a few times now. No luck…

This is what I´m running right now:

openhab> bundle:list -s |grep -i zig
311 x Active   x  80 x     x org.openhab.binding.zigbee
312 x Active   x  80 x 1.1.6                  x com.zsmartsystems.zigbee.dongl
313 x Active   x  80 x     x org.openhab.binding.zigbee.xbee
314 x Active   x  80 x 1.1.6                  x com.zsmartsystems.zigbee.dongl
315 x Active   x  80 x     x org.openhab.binding.zigbee.cc2
316 x Active   x  80 x 1.1.6                  x com.zsmartsystems.zigbee
317 x Active   x  80 x     x org.openhab.binding.zigbee.emb
318 x Active   x  80 x 1.1.6                  x com.zsmartsystems.zigbee.dongl
319 x Active   x  80 x 1.1.6                  x com.zsmartsystems.zigbee.dongl
320 x Active   x  80 x     x org.openhab.binding.zigbee.tel

Here is a debug log… Hope it shows something.
The latest triggering from the Trust sensor is at time
01:10:44 21.03.2019 (24 hour format). So somewhere between 01.10.44 and about 08.00 o´clock this sensor stopped responding. I log a postUpdate with time and date, each time a motion sensor is triggering, which is why I know, when the sensor last triggered. I have no idea when the dimmer switch stopped responding nor the Osram plug.
You should be able to find my tries adding the Trust sensor somewhere between 18.00 and 21.00 this evening.

zigbee.rar.txt (229.0 KB)

Kim - the current version of zmsmartsystem is 1.1.10. You are on 1.1.6. I think you may have an old version of Scott’s script for downloading the files. I know for me the old script wouldn’t detect newer than 1.1.6 and when I specified newer versions it didn’t work correctly. My guess is that because you have the new binding but old zsmart systems you are getting these errors. Def want to update to the real current version before too much debugging can take place.

FYI you can get current release version number from GitHub at https://github.com/zsmartsystems/com.zsmartsystems.zigbee/releases

1 Like