Zigbee binding

I am about to start merging some changes in the ZigBee binding, so please let me know if things go haywire. I’ve done a quick test with a couple of bulbs (an Osram colour and Ikea white bulb) and the Ember dongle and it seems to work fine. The majority of changes are in the library which is heavily tested elsewhere but it’s possible that some device types may be blocked due to some changes I had to add to get part of the framework through ZigBee Alliance certification tests. Please report anything strange :slight_smile:

It may take a little while for all this to flow through as I need to update the binding, then update the OH distro to get the latest libraries.

Maybe a bug in zigbee binding

Hello All I am new to openhab, So I may be wrong about this
In the past stable version of the openhab 2.4 the zigbee binding was working perfectly since the update to the new version it became a nightmare

I have tested the problem in two different machines with two different USB Coordinators (both coordinators use the ember chip)

The problem is at sometime usually after 2 days the Mesh does not update the network moreover it creates a lot of dead links.

For example a device A may shows that it has a link to another device B but the device B does not show a link to device A as a result there are a lot of delays in the network and the mesh does not update to fix the problem ( I even set the mesh update period to 5 minutes)

Picture 1 Shows a device with all the neighbors

after a day or 2

When the problem happens if switch off a router device and then back on then the router device Will not find the near by devices but all the other devices that already have this device in their list will continue to list it in their neighboring device and in their routes

I have tested the above with hue bulbs and ikea wall plugs

To restore everything back to normal you have to clean the cache and restart, Restarting alone does not fix the problem

Another instance on the second pi with the same devices


DEVICE 14371 HAS NO ROUTES NO NEIGHBOURS
BUT

A DEVICE 1 M AWAY LIST THIS ON ITS NEIGHBORS AND ROUTES

The mesh information that you show in these images does not necessarily mean that the network is not working. The coordinator manages the mesh - the binding does not have anything to do with this - it only provides this information periodically for information, but it does not update anything.

What is a “dead link”?

Wow many thanks for the fast reply

So the interface will not show the routes and neighboring devices in the Paper UI ? In the 2.4 you see messages in the log like ‘zigbee:device:01381645:001788010486f1f5’ has been updated. Now I do not see these messages moreover if a device goes offline and comes back online it will never show any neighboring devices is that normal?

if the paper UI will not show the actual links and neighbors then I do not have dead links. I was creating a graph using the information from the paper UI to see where I had the problem and I was assuming that some devices do not communicate with any other devices

The problem I have is that after 1-4 days the messages from the zigbee devices become very slow sometimes they take up to 2-5 seconds to reach openhab and sometimes they will not reach at all. I know that its a communication problem because the hue sensor has an led that lights up on movement where there is difficulty to sent a command. In order to resolve the problem I have to restart openhab and also clean the cache

Again thanks very much

Dear chris

I have notice that the latest hue firmware makes the Hue devices unresponsive ( at least at my case). I have tried to update 2 of my 4 sensors and those sensors became unresponsive. I have tried to pair with two different openhab computers

I have also tried some of the devices mentioned here https://www.openhab.org/addons/bindings/zigbee/
Xiaomi Aqara Human Motion Sensor (I have one aqara sensor that is working fine but gets disconnected a lot ) and IKEA Tradfri Motion Sensor

All devices get discovered connected to the coordinator but no device is sending any info.

I was wondering if that has to do with any patches to the zigbee devices that have to do with the recent discovered vulnerabilities

I’m afraid I’m not familiar with changes to the Hue firmware, or actually any recently discovered zigbee vulnerabilities. If you have a reference to the issue I will take a look.

its an old vulnerability that now is been patched

I am also currently trying a clean install just to check more on the problem

after further testing…
I have an ember coordinator

The problem occurs with the new firmware and the latest stable version of the openhab.

reverting back to the original 2.50 stable solves the problem

I made a clean install with the new version and When I try to add the sensors I get this message

Blockquote
2020-02-16 22:49:11.057 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 0017880104B75618: Starting ZigBee device discovery
2020-02-16 22:49:12.056 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zigbee:philips_sml001:01381645:0017880104b75618’ to inbox.
==> /var/log/openhab2/events.log <==
2020-02-16 22:49:12.057 [home.event.InboxAddedEvent] - Discovery Result with UID ‘zigbee:philips_sml001:01381645:0017880104b75618’ has been added.
2020-02-16 22:49:12.787 [me.event.InboxRemovedEvent] - Discovery Result with UID ‘zigbee:device:01381645:0017880104b75618’ has been removed.
2020-02-16 22:49:24.556 [me.event.InboxRemovedEvent] - Discovery Result with UID ‘zigbee:philips_sml001:01381645:0017880104b75618’ has been removed.
2020-02-16 22:49:24.609 [hingStatusInfoChangedEvent] - ‘zigbee:philips_sml001:01381645:0017880104b75618’ changed from UNINITIALIZED to INITIALIZING
2020-02-16 22:49:24.635 [hingStatusInfoChangedEvent] - ‘zigbee:philips_sml001:01381645:0017880104b75618’ changed from INITIALIZING to UNKNOWN
2020-02-16 22:49:24.674 [nt.FirmwareStatusInfoEvent] - Firmware status of thing zigbee:philips_sml001:01381645:0017880104b75618 changed to UNKNOWN.
==> /var/log/openhab2/openhab.log <==
2020-02-16 22:49:27.550 [ERROR] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880104B75618: Exception creating channels
java.lang.NullPointerException: null

at org.openhab.binding.zigbee.internal.converter.ZigBeeConverterTemperature.initializeDevice(ZigBeeConverterTemperature.java:79) ~[bundleFile:?]

at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.initializeDevice(ZigBeeThingHandler.java:492) ~[bundleFile:?]

at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:381) [bundleFile:?]

at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$0(ZigBeeThingHandler.java:238) [bundleFile:?]

at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:232) [bundleFile:?]

at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [bundleFile:?]

at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_222]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_222]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_222]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]

Blockquote
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
==> /var/log/openhab2/events.log <==
2020-02-16 22:49:27.603 [hingStatusInfoChangedEvent] - ‘zigbee:philips_sml001:01381645:0017880104b75618’ changed from UNKNOWN to OFFLINE (HANDLER_INITIALIZING_ERROR)
2020-02-16 22:49:27.617 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:philips_sml001:01381645:0017880104b75618’ has been updated.
==> /var/log/openhab2/openhab.log <==
2020-02-16 22:49:31.064 [ERROR] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880104B75618: Exception creating channels
java.lang.NullPointerException: null
at org.openhab.binding.zigbee.internal.converter.ZigBeeConverterTemperature.initializeDevice(ZigBeeConverterTemperature.java:79) ~[bundleFile:?]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.initializeDevice(ZigBeeThingHandler.java:492) ~[bundleFile:?]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:381) [bundleFile:?]

at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$0(ZigBeeThingHandler.java:238) [bundleFile:?]

at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:232) [bundleFile:?]

at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [bundleFile:?]

at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_222]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_222]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_222]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]

at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]

Please can you provide a debug log showing the issue - please provide it as a file.

I’m not sure what the issue with the Hue - does it join the network? It looks like it is? Unfortunately without knowing what has been changed, it’s hard to know how to resolve it, but I really would have expected the Hue bulbs to work ok as other ZigBee 3.0 bulbs do (I’ve tested quite a few).

I switched back to the 2.50 I saved the logs for the brieff time I used the latest version Here are the logs

your work for zigbee binding is amazing

Some suggestions in order to help you and help new users. Is it possible for the zigbee binding to create something like a wiki page that will be updated by the users, that will list per device info.

we can list firmware of the devices we use, coordinator that is tested with, version of openhab that its tested, if there are any special steps for pairing. example.json configurations, error logs if a device does not work etc. That way the info will be collected in one place for anyone to find

I am a newbie to openhab but some examples that i have discovered are
Tradfri Network extenter used to work on 2.40 but not on 2.50

philips has a dimmer switch that identifies as RWL021 and the same dimmer switch that identifies RWL020. The RWL020 will be discovered with some functions missing in order to make it work you have to copy a configuration from RWL021

xiaomi makes the same devices for the xiaomi aqara brand and xiaomi brand the same device made for the aqara Chinese market will work on openhab but not the European brand

Another Suggestion that might help is that if there is a way and if you find it helpful, we can donate and sent devices that we are not using

Wiki pages were removed from openHAB a few years back so we’d have to find somewhere to host this. I would love to have something like I have for ZWave, but that is driven through quite a large database application that I wrote, and from there it auto generates the documentation - I’m just not sure I want to do the same thing for ZigBee, although it would be helpful.

A simple wiki would be a lot easier, but unfortunately I don’t know how this can be acheived as it’s not provided through OH. Another suggestion is to add it to the binding docs on Github, but the docs aren’t really designed for that level of device specific detail (it’s only 1 page).

Sure - I’m always happy to accept donations - either money or devices. I quite often purchase devices just for testing so this does cost me a little :sunglasses:. There is a donation button at the bottom of my web page.

Is there a way and if yes. What is the best way to sent info or problems and bugs regarding the binding

Sorry - which specific part of my response is this question referring to?

Use the Github issues list to report bugs and use the forum to discuss things more generally.

Just wanted to check back in as it has been some time - has any way been added back into this binding so that I can send a CT command to a bulb and still access the bulbs brightness and/or on/off state? As of my last experience with this binding this was not possible as a CT command set the colorcolor channel to UNDEF and there were no individual on/off or dimmer channels thanks to channel consolidation.

Since some days I receive the following error every few hours:

[WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: received IOException in serial port event
java.io.IOException: Expected to be able to read 10 bytes, but saw error after 9
	at org.openhab.binding.zigbee.handler.ZigBeeSerialPort.serialEvent(ZigBeeSerialPort.java:303) [bundleFile:?]
	at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:81) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:780) [bundleFile:3.15.0.OH2]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:3.15.0.OH2]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1611) [bundleFile:3.15.0.OH2]

That is almost certainly not related to the original issue from 2016. Please start a new thread.
I notice some threads here mentioning issue with the serial binding if devices are queried too frequently.

@chris I recall you´d mention you have a Ikea Tradfri motion sensor for testing, right?
I just updated my Odroid system to latest openhab 52.5.3 (stable), which I assume updated to latest Zigbee as well.
I then tried to add my Ikea motion sensor again… It got added just fine… However, it doesnt really seem to do anything, (no data received from any of the channels).
Also there is no kind of a switch/contact channel, which makes it rather unuseable as a motion sensor I would say…

This is how it looks when it´s added and online:

I noticed the zigbee powersource says its MAINS… That can hardly be correct. Should it say DISPOSABLE_BATTERY ??

I think this devices does not really get added correctly.
Did you ever get to test it yourself?

I gave it a quick test - I forget exactly what the issue was now, but it’s not supported by the binding right now.

The binding will just report what the device reports. If you think it’s wrong (unlikely) then please provide the log showing the initialisation and I will take a look.

As mentioned in #501 on GitHub, the Lupus Mini sensor also reports power source as MAINS although it is a battery powered device.

If you think this might be a bug in the binding, I’ve provided a debug and sniffer log on GitHub. Just in case you want to investigate it Chris, it’s a minor inconvenience, at best…

Please can you provide a debug log showing the initialisation of the device. Without that I’ve really nothing to go on - sorry.