Zigbee binding

WeRo · December 22, 2018, 3:09pm

Update regarding my problem.
I manually went thru all steps of Scotts script.
ZSS is 1.1.7
Snapshot is 2.5.0
All Items deleted in jsondb
All items added by Paper UI
All channels in my items file updated
There are no error messages anymore in openhab.log
event.log looks fine too

BUT changing the switch by Control in Paper UI or by the App still nothing happens.
Now I’m completely helpless.

Any hint is appriciated!!

UPDATE: I had to reset and synchronize the devices newly - now everything works fine!!

jfrank1845 · December 22, 2018, 4:01pm

Hey Chris - sorry for the confusion - I did ‘reclycle’ my logs file share and reposted different files for other logs. You are correct that the version I loaded up on a side system was 2.3 and the power readings were working there. I too am a bit confused as to where the label changed between active power and total active power… I’ve tried various versions to catch the spot but still haven’t gotten it totally locked in. I’m going to guess that you should at least be able to get this cleared up fairly easily in an upcoming release? I do also know the ‘switch’ channel starting being dectected as a dimmer in recent versions yet when I installed 2.3 it is still showing as a dimmer so perhaps an ota update or something?

Thanks so much and hope you have a wonderful holiday!

chris · December 22, 2018, 9:33pm

There’s not really much to go on in the log unfortunately.

ZigBee battery devices the comply with the standard should respond - they are required to poll once every 7.5 seconds, and their parent is required to queue frames for this period as well…

Devices leaving, and rejoining, is not uncomon. This is under the control of the coordinator - sometimes the coordinator may ask a device to leave and rejoin again and it’s possible that the Xiaomi devices don’t do this properly. It’s impossible to tell without seeing a sniffer log.

Sorry - not so helpful I’m afraid.

chris · December 22, 2018, 9:37pm

What device is this for? The binding will typically not provide a switch channel if there is a dimmer channel - if this is what you’re seeing, then this is normal.

Can you provide the network XML file for your network (it’s in the userdata folder).

Thanks - you too

Fredrik_Andersson · December 23, 2018, 8:51am

Thanks for your answer. Im trying to understand the log. It seems like the binding request a neighbor update to my end device (28379) lumi.weather. Im a noob in this but it seems from the log that the sensors answers with “relaylist” (isnt that neighbors?) but the binding seems to ignore that. Below is a small cut out from the log where the neighbor update is sent, and from what i can see the device responds. Im also posting a log with a longer time perspective incl the first one.

00158D000247ECE1 = lumi.weather (28379)
0017880102043D5B = gateway? (9C1E)(39966)
000D6F0012EA8781 = phillips hue light (works)
000B57FFFE8F3219 = ikea tradfri dimmer

2018-12-23 09:07:28.765 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: Update mesh
2018-12-23 09:07:28.768 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: scheduled [NEIGHBORS]
2018-12-23 09:07:29.735 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: running
2018-12-23 09:07:29.738 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementLqiRequest [0/0 -> 28379/0, cluster=0031, TID=DC, startIndex=0]
2018-12-23 09:07:29.741 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=28379/0, profile=0000, cluster=49, addressMode=DEVICE, radius=31, apsSecurity=false, apsCounter=220, payload=00 00]
2018-12-23 09:07:29.744 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EzspSendUnicastRequest [type=EMBER_OUTGOING_DIRECT, indexOrDestination=28379, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=220], messageTag=220, messageContents=00 00]
2018-12-23 09:07:30.778 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspSendUnicastResponse [status=EMBER_SUCCESS, sequence=151]
2018-12-23 09:07:30.782 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspSendUnicastResponse [status=EMBER_SUCCESS, sequence=151]
2018-12-23 09:07:30.786 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingRouteRecordHandler [source=28379, sourceEui=00158D000247ECE1, lastHopLqi=246, lastHopRssi=-84, relayList=9C1E]
2018-12-23 09:07:30.790 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspIncomingRouteRecordHandler [source=28379, sourceEui=00158D000247ECE1, lastHopLqi=246, lastHopRssi=-84, relayList=9C1E]
2018-12-23 09:07:37.743 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: ManagementLqiRequest response CommandResult [TIMEOUT]
2018-12-23 09:07:37.746 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: request NEIGHBORS failed. Retry 1, wait 2154ms before retry.
2018-12-23 09:07:39.903 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: running

https://1drv.ms/t/s!AijwO0Pec8KrgvtHvM0lT9vEmtFjAQ <- log file
EDIT: The short log was wrong device.

curlyel · December 23, 2018, 9:17am

Just to let you know: I have two of them currently and they remain connected once properly included.
BUT, probably…

… just because they have direct reach to the coordinator (CC2531 in my case) without the need of routing.

I’ve noticed, that they could be silent for a very long time as long as the measurements (temp/hum/pressure) are not change.

chris · December 23, 2018, 9:20am

I do not see any response. I think you are looking at the EzspIncomingRouteRecordHandler message? This is not a response from the device - it’s a message from the coordinator.

chris · December 23, 2018, 9:21am

Yes - I think this might be an important point - it looks likely that @Fredrik_Andersson sensors are connected via another router and this is likely why they periodically drop out. I suspect that the router is aging them out, and they then do not support the ZigBee rejoin.

Fredrik_Andersson · December 23, 2018, 9:53am

Okey sorry guys thats the coordinator answer. Im in the learning of understanding Zigbee traffic, can you recommend a good sniffer? Is it CC2531?
In my first test I didnt have any other devices than the aqara device. So it should be no routing. But it depends. I had reseted the controller in the thing. Does that exclude all devices and start over? Or does it still hold the devices?
The device works for now. But the neighbor discover fails 13 times then starts over. Is that normal?

2018-12-23 10:51:30.778 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: ManagementLqiRequest response CommandResult [TIMEOUT]
2018-12-23 10:51:30.784 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: request NEIGHBORS failed after 13 attempts.
2018-12-23 10:51:30.791 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: running
2018-12-23 10:51:30.798 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D000247ECE1: Node SVC Discovery: complete
2018-12-23 10:51:30.805 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 00158D000247ECE1: Node 28379 update
2018-12-23 10:51:30.814 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D000247ECE1: Node updated - ZigBeeNode [IEEE=00158D000247ECE1, NWK=6EDB, Type=END_DEVICE]

chris · December 23, 2018, 10:00am

Maybe, but the coordinator will also age out devices - it’s a requirement of ZigBee 3 now, and even older implementations normally had this… I’m not sure if there are any settings to control this, but the aging will force the device to rejoin, and it seems these devices won’t do that.

I use the CEL stick. I’ve never managed to get the CC2531 to work here (as a sniffer that is). The problem with the CEL stick is they need firmware to be programmed - I did offer a while back to program some if people were interested.

ZigBee coordinators do not hold a list of devices that are connected to the network, however if you reset the coordinator, then it will stop any devices using the network as the security configuration will change. You will then need to reconnect all devices.

The device is not responding, so yes, it is normal that the discovery will fail.

curlyel · December 23, 2018, 10:16am

Mine CC2531 came with the sniffer firmware programmed. I had to flash the zstack firmware instead to make use of it for the Zigbee binding.

Before re-flashing the dongles, I’ve tried the the sniffer Application from Texas Instruments. It worked so far as I’ve been able to see some zigbee packets recorded/decoded…

chris · December 23, 2018, 10:18am

Yes, so did my sniffer, but I couldn’t get the software to work properly on my Mac. Admittedly I didn’t try super hard as I have lots of other sniffers, but it wasn’t super simple.

The Silabs/CEL works well and is better built, but costs a bit more than the cheap China TI clones.

Fredrik_Andersson · December 23, 2018, 10:26am

Where could I get a stick like that? Im very interested in zigbee traffic, many new smart product in sweden use zigbee. I have some power measures from schneider electic (Wiser) which I would like to sniff.
If I have a sniffer is it possible for me to help with the progress of xiaomi aqara sensors? I would like to learn.

chris · December 23, 2018, 10:34am

You can get the TI from AliBaba if you want to try that - they are about 10 or 15 Euro. If you want the CEL, then I would be happy to get one for you, program it, and send it to you. It probably costs about 60 Euro though I think (that’s just the price of the stick and postage - the sticks are around 40 GBP).

These are the ones I got for some others a while back I think -:

The older EM357 (£37)
https://www.digikey.co.uk/product-detail/en/cel/ZM357S-USB/ZM357S-USB-ND/4477124

My sniffer software and Wireshark documentation etc is here -:

If you use the TI stick, the sniffer software doesn’t work with that stick, but the Wireshark documentation is still useful.

Fredrik_Andersson · December 23, 2018, 11:03am

I would be very interested to get one from you.

chris · December 23, 2018, 11:24am

Ok, if you PM me your address we can sort it out. If anyone else wants one at the same time, let me know in the next day or two.

WeRo · December 23, 2018, 1:19pm

As I said yesterday everything worked fine until openhab-restart after backup tonight.
Now the dongle is uninitialized again - and these messages appear in openhab.log

2018-12-23 14:08:09.841 [ERROR] [org.openhab.binding.zigbee          ] - FrameworkEvent ERROR - org.openhab.binding.zigbee
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zigbee [191]
  Unresolved requirement: Import-Package: gnu.io

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1613) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
2018-12-23 14:08:09.881 [ERROR] [org.openhab.binding.zigbee.telegesis] - FrameworkEvent ERROR - org.openhab.binding.zigbee.telegesis
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zigbee.telegesis [196]
  Unresolved requirement: Import-Package: gnu.io

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1613) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528) ~[?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]2018-12-23 14:09:23.653 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zigbee-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zigbee [191]
  Unresolved requirement: Import-Package: gnu.io

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
2018-12-23 14:09:23.666 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zigbee.telegesis-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zigbee.telegesis [196]
  Unresolved requirement: Import-Package: gnu.io

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
2018-12-23 14:09:33.736 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zigbee-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zigbee [191]
  Unresolved requirement: Import-Package: gnu.io

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
2018-12-23 14:09:33.763 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zigbee.telegesis-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zigbee.telegesis [196]
  Unresolved requirement: Import-Package: gnu.io

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]

chris · December 23, 2018, 1:21pm

You need to install the serial driver.

To fix this use the following console command: feature:install openhab-transport-serial

WeRo · December 23, 2018, 1:22pm

Yes I did this yesterday

chris · December 23, 2018, 1:22pm

Well, this is the problem you have according to the log you just posted. Or is the log an old log?