Zigbee binding

If you are having an issue with the script, please report it on its thread or open a GH issue.

Currently I have one big trouble bulb that seems to discover/ connect but refuses to accept commands. I’ve attached debugging of it doing the initial discovery as well as a failed command. Is there any sort of setting I can adjust that might help it work better/ extend some sort of timeout perhaps? the device in question is : F0D1B8000006432A.

Thank you!

log.txt (20.8 KB)

The log shows that the stick returns an error sending the message, so the issue is a low level ZigBee issue.

Two things you can do - firstly ensure that you have enough routers in your network so that there are routing options to fill any “gaps” in the network. Then I would suggest to use a newer version of the library which has better handling of transactions and will perform up to 3 retries which may help. Of course, if the communications issues within the network persist, then retrying won’t help, but if things are marginal, then it may improve the link.

Thanks for the info Chris - the two giving me issue were both new bulbs and once I swapped them out with a different one everything is good. My guess is that those two bulbs just have some sort of manufacturer defect.

Hi Chris - just installed the new 1.2.0 release of the libraries but they seem to fail -

Error starting bundle 413: Could not resolve module: org.openhab.binding.zigbee.xbee [413]
Unresolved requirement: Import-Package: org.openhab.binding.zigbee
-> Export-Package: org.openhab.binding.zigbee; bundle-symbolic-name=“org.openhab.binding.zigbee”; bundle-version=“2.5.0.201906190824”; version=“2.5.0”; uses:=“org.eclipse.smarthome.core.thing,org.eclipse.smarthome.core.thing.type”
org.openhab.binding.zigbee [418]
Unresolved requirement: Import-Package: com.zsmartsystems.zigbee.dao; version="[1.1.0,2.0.0)"
Unresolved requirement: Import-Package: org.openhab.binding.zigbee.handler
-> Export-Package: org.openhab.binding.zigbee.handler; bundle-symbolic-name=“org.openhab.binding.zigbee”; bundle-version=“2.5.0.201906190824”; version=“2.5.0”; uses:=“com.zsmartsystems.zigbee,com.zsmartsystems.zigbee.security,com.zsmartsystems.zigbee.transport,gnu.io,org.eclipse.smarthome.config.core,org.eclipse.smarthome.core.common.registry,org.eclipse.smarthome.core.thing,org.eclipse.smarthome.core.thing.binding,org.eclipse.smarthome.core.thing.binding.firmware,org.eclipse.smarthome.core.thing.type,org.eclipse.smarthome.core.types,org.openhab.binding.zigbee.converter”

Yes, the 1.2 version of the libraries will not work with openHAB at the moment. This is not a simple maintenance release (hence the version number change) and has a number of breaking changes.

If you look in the binding repository you will find a PR under review to adapt the binding for the new version and I would expect this to be ready in a week or so.

Hi, I have OpenHAB 2.4.0 and the Zigbee binding, with an Ember stick and some IKEA Tradfri bulbs. I’m having some troubles with the bulbs not responding all the time. Today I even had a bulb suddenly turning on, while there was no trigger. I’m in the process of trying different solutions; the reinforced concrete might be a problem. But I also read some thins in this thread about devices joining and leaving and fixes in snapshot builds for it.

Would it make sense for me to try one of those snapshot builds?
Would it require to update OpenHAB to a 2.5.0 snapshot as well? Or can I run a 2.5.0 snapshot of the binding on my OpenHAB 2.4.0 install? (I use Openhabian b.t.w.)

Any news regarding the conbee(2)/raspbee hardware?

I have noticed that the mozilla webthings zigbee addon supports those natively. I tested it and have no problems so far. Could that be of any help for this binding?

No - no news.

Not really. The driver is mostly working, but it needs someone to spend some time using it and finding where it locks. Probably it’s not a lot of work, but personally I don’t really have the time to look at it right now.

Is there a way to test and debug this without fiddling with an openhab setup - Running it from an IDE or something? I have a conbee 2 stick and a metering plug for testing here.

Sure - you can develop directly with the Z-Smart Systems libraries.

Hi Chris - hope you have been well. I just wanted to pass two things by you .

  1. I have noticed my devices(mains powered ones) will consistently ‘fall off’ and turn offline for a bit. Generally they will eventually come back to online without any intervention at some point but I can also hasten the process by disabling and re-enabling the thing. is there some sort of setting that I can enable that will help prevent this from happening? Everything works just fine while they show as online. I have only noticed this since moving to a new home and as such my network size did increase - I’ve got at least 30 or so devices now. I was thinking maybe there is some setting that I may need to adjust to work better with this network? I’ve attached a subset of logs that hopefully can help… I dont know that it includes one falling off to offline but I did include re-enabling the thing where it instantly comes back online. I also wasn’t sure if it was maybe just a java issue or something with the thread locking up.

  2. Is there still any discussion about the binding and the ‘UNDEF’ logic between the ColorColor item and the CT item? I"ve attempted to use this as an ‘indicator’ of color/CT status but i’ve found it to not be reliable - I’ve been forced to use a manual independent switch to track it myself. I’ve also noticed that this UNDEF logic causes me to constantly lose status on if the light is online / brightness. I’ve linked a dimmer and a switch to the ColorColor item but when I initially send a CT and change its status these loose their info until I manually edit the switch or brightness. Once I do that I’m able to see the status as well as adjust the CT temp.

I do understand some of this may be improved in the latest libraries release - if you think that is the case let me know / let me know of a snapshot version you’ve been running that seems ok and I can give that a try. I’ve been with the understanding the latest snapshots have been a mess so I’ve stuck on the M release for now but I can change that. Thanks for all of your help!

openhab.log (581.3 KB)

If it is systematic, then there are a few reasons I guess. Firstly, there could be issues in the network that are causing this, and if so, this is going to be hard to spot as all we will see in the logs is, well, nothing other than the timeout.

It could of course be a bug in the binding with the detection of the OFFLINE device. This uses a timer that expects to receive data from the device at least once in a certain period. This period is a little more than twice the minimum of the polling period, or the reporting period. If the device doesn’t report as it’s configured by the binding, then this could cause this.

Now we know that some devices (ie the Xiaomi devices) don’t respect the configuration, so it’s quite possible that this would happen in this case, but most devices that are really ZigBee should respect the configuration of reporting period.

The only way to be sure here is with a log. Unfortunately I’m not sure what the log you’ve provided is trying to show. I don’t see any nodes going offline, and the log is very short (just a few minutes) so we can’t build up a picture of what is happening from this.

Not that I’m aware of. Personally I don’t really like the way this is implemented, but this is what was agreed to provide the same functionality across bindings.

I don’t think the new libraries will change much in relation to these issues.

That is crazy - so no way to tell if a bulb is online or not when in CT mode. I can’t imagine why other bindings are that way as well. Is there any way I’m missing to get an on/off status that works 100% now? I’ve had a switch item linked with the color channel but it goes haywire once the color channel goes undef because of CT mode and I can’t link a switch item to a colortemperature channel.

I’d like to have something on my sitemap/habpanels that truly represents the state of the light.

Disregard the previous edit of this post - i was able to get things happy by flipping some bulbs on and off. seems they got into an odd state. I have linked to a folder of logs, however, that should include data on a bulb thing going offline and then coming back online. A number of them just came online right before I pulled the log - the things came online as a command was sent to the channels. Sorry the files are big- i had edited it down to 10 meg rollover but apparently an update reset that. I still wish I could find good advice on splitting out the zigbee /zsmart logs into their own file but still working on that. Thanks for all of your help!

Regards,
Jared

@chris is it possible to configure the polling interval of a channel through HABmin/PaperUI? If not, how can it be configured?

I want to say “yes”, but at the moment I can’t work out how to get this working under PaperUI. It may not be available for all channels, but for some channels at least there should be channel level configuration options available, and polling should be one of the settings (along with other reporting configuration).

This is available for the dimmer and switch channels at least (I just checked the source), but at the moment I can’t see where to configure this in PaperUI. I thought that it was an option in the channels list, but I’m not seeing that in my test system here (which I’m still struggling with given all the changes to the build environment).

HABmin should show this, but I’ve not got it configured in my dev system as I’m trying to run a simple system so we can work out what is wrong with the IDE. I’ll see if I can add HABmin into the IDE and hope the development environmentl doesn’t break :unamused:

Thanks @chris! I noticed that my OH version (2.5M1) is probably too old. It looks like it was released before the relevant PR was merged. I’ll try to update to a recent snapshot. I was a bit hesitant to do so because of the recent stability issues…

The transition time setting isn’t available in PaperUI either, so maybe HABmin is required for polling as well?

Were other channel configuration options available? The binding attempts to work out what is supported by different devices, and will only provide configuration options if the appropriate configuration attribute is supported.