Zigbee binding

Without logs showing what was working, I don’t know. All I can say is that the converter hasn’t changed for 11 months. This is where the attribute is defined, so I think I can safely say that the binding isn’t any different in this respect.

I’d just need to see logs of what he binding was sending when polling (so 30 minutes of logs should do).

Hi there,

since update to OH2.4 I’m struggling exactly with the same problem

What is the actual problem it’s causing? Or is it just the warning you’re worried about?

Chris - I’ve got some logs for you. I’ve got an extra telegesis coordinator laying around so I just did a quick fresh install of openhab 2.3.0 release and added the device. the link below will take you to the log file showing the active power channel working. Thanks so much!

So every time you press the switch, you get these errors about the binding? That is quite strange as the binding is only done on startup :confused:

(Please also use code fences, or the </> button to format logs)

Thanks. It looks to me like this is not a major issue. It looks like the bind is working ok, but the system is not properly correlating the response, so we are seeing this error. I will take a look at this, but I do see a positive response from the device.

Eg -:

(ignore the attribute report that was received here - it’s not relevant to the bind transaction)

This resulted in the following error after the 10 second timeout -:

2018-12-18 19:40:23.819 [ERROR] [converter.ZigBeeConverterSwitchOnoff] - 282C02BFFFE022B8: Error 0xffff setting server binding

Clearly this bind was successfully acknowledged by the device, but the library didn’t correlate the response.

I think this can therefore be ignored for now.

1 Like

No the error message is after starting openhab.
The switches are power outlets. By turning them on or off in the App nothing happens.

This has nothing to do with the error then as the bind command is for reporting changes made to the physical device back to the binding.

so what should I do now?

I would suggest to look at the logs to see if it shows anything.

These are the error messages in the log file after reboot:

2018-12-20 21:36:52.369 [ERROR] [org.apache.felix.scr                ] - bundle org.apache.felix.scr:2.1.2 (39)Circular reference detected trying to get service {org.eclipse.smarthome.io.net.http.TrustManagerProvider}={service.id=124, service.bundleid=192, service.scope=bundle, component.name=org.openhab.binding.icloud.internal.to_be_moved.TrustManagerProviderImpl, component.id=15}
 stack of references: ServiceReference: {org.eclipse.smarthome.io.net.http.TrustManagerProvider}={service.id=124, service.bundleid=192, service.scope=bundle, component.name=org.openhab.binding.icloud.internal.to_be_moved.TrustManagerProviderImpl, component.id=15}
ServiceReference: {org.eclipse.smarthome.io.net.http.HttpClientFactory, org.eclipse.smarthome.io.net.http.WebSocketFactory}={service.id=153, service.bundleid=118, service.scope=bundle, component.name=org.eclipse.smarthome.io.net.http.internal.WebClientFactoryImpl, component.id=43}
2018-12-20 21:37:52.025 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.thingUpdated()' on 'org.openhab.binding.zigbee.telegesis.handler.TelegesisHandler@466cc8': null
java.lang.NullPointerException: null
	at com.zsmartsystems.zigbee.app.discovery.ZigBeeDiscoveryExtension.extensionShutdown(ZigBeeDiscoveryExtension.java:96) ~[?:?]
	at com.zsmartsystems.zigbee.ZigBeeNetworkManager.shutdown(ZigBeeNetworkManager.java:529) ~[?:?]
	at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.dispose(ZigBeeCoordinatorHandler.java:303) ~[?:?]
	at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:206) ~[?:?]
	at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.thingUpdated(ZigBeeCoordinatorHandler.java:315) ~[?:?]
	at org.openhab.binding.zigbee.telegesis.handler.TelegesisHandler.thingUpdated(TelegesisHandler.java:86) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]
2018-12-20 21:38:01.198 [ERROR] [ngle.telegesis.ZigBeeDongleTelegesis] - Unable to configure Telegesis dongle

Can you describe your problem - does anything work at all, or is it just that the switches don’t work?

This error is logged during the shutdown of the binding - it has already been fixed, but I’m not sure it should matter given it’s during the shutdown. You could try updating the libraries to 1.1.7 using @5ivers update script as it should stop this error.

I have the exact same problem with my xbee coordinator. It had been running perfectly fine on the M7 test release and I thought it would be fine to update to the 2.4 official release.

Since then I have the exact same problem as you have @stephanSH, the XBee Coordinator stays as Unknown. That’s very strange that this has changed between these 2 (quite similar - I haven’t checked the code though) versions !

You should update to the latest ZSS libraries (1.1.7) using @5ivers script and it will resolve this.

Thanks for the fast answer @chris. Quick question though: the script somehow tries to install the ZSS libraries for a 2.5.0 snapshot. I am however still running 2.4.0 but I guess it shouldn’t be a problem.

openhab> list -s | grep zig
273 │ Active   │  80 │ 1.1.7                  │ com.zsmartsystems.zigbee.dongle.telegesis
274 │ Active   │  80 │ 2.5.0.201812170851     │ org.openhab.binding.zigbee
275 │ Active   │  80 │ 1.1.7                  │ com.zsmartsystems.zigbee.dongle.cc2531
276 │ Active   │  80 │ 2.5.0.201812170851     │ org.openhab.binding.zigbee.xbee
277 │ Active   │  80 │ 1.1.7                  │ com.zsmartsystems.zigbee.dongle.xbee
278 │ Active   │  80 │ 2.5.0.201812170851     │ org.openhab.binding.zigbee.cc2531
279 │ Active   │  80 │ 1.1.7                  │ com.zsmartsystems.zigbee
280 │ Active   │  80 │ 1.1.7                  │ com.zsmartsystems.zigbee.dongle.ember
281 │ Active   │  80 │ 2.5.0.201812170851     │ org.openhab.binding.zigbee.ember
282 │ Active   │  80 │ 2.5.0.201812170851     │ org.openhab.binding.zigbee.telegesis

I’m not familiar with Scotts script - I thought it should allow you to use 2.4 with 1.1.7. I can confirm that the versions are compatible, so if the script allows it, then it should work (@5iver might comment here).

Yes, I can confirm it does, with the above list of packages it’s OK and indeed 1.1.7 did fix my coordinator.

Thanks @chris

The manual install script will install the current snapshot build with the libraries used in the snapshot or the current development versions. There is no option to use stable release binding with development libraries.

:sob:

1 Like

That wasn’t a negative (sorry). I just tend to manually compile and install things here, but the script is super useful which is why I keep recommending it :slight_smile: .

1 Like

I knew you were familiar with it. I was just being silly! :slight_smile:

1 Like