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).
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!
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.
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 !
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).
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.
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 .