56 occurrences in about 9 minutes… about every 10s… regularly?
Yeah - I was just looking at the log. It’s more than I’d expect I think, but a whole load less than @TheNetStriker. Not something I’ve noticed so much before, so will take a look at this…
Thanks.
Also found a log from @AFromD and it’s also more regular (369 in a few minutes - more like what I see with @TheNetStriker).
In itself retries aren’t an issue - the system retries and all’s well, but this level of retry is not helping anything…
An earlier log I have shows 1012 in an hour (every 3s).
I currently have bursts which last 10 seconds with approx 40-50 events every 5 minutes on average. I have several devices that are on switched outlets and not available at night.
In total around 2100 over 4 hours.
So the 5 minute interval (can be 2 to 10 minutes) seems reasonable, 5 devices are not availble, so I guess 10-15 queries should suffice.
If the binding keeps running like it does now, I might put them on regular outlets. But there is nothing more annoying than wanting to go to bed, and not being able to turn the lights off. So I kept them switched up to now.
And my Hue motion sensor did turn up after half a day, so currently everything is running as it should
Hi Chris, thanks for taking a look at this. Please let me know if you have a new release to test this again.
Some comments:
with this binding, I don’t have the problem where TX CMDs suddenly stop and a restart of the binding doesn’t help.
This binding sometimes takes forever to discover channels. With one trust bulb, it discovered a dimmer iso color channel, which was only rectified after restarting OH twice. I guess this might be due to less frequent discovery of channels. How about giving it an option to retrigger discovery of channels?
This binding has problems discovering my Hue motion sensor. One time, it took half a day, now it hasn’t come up after a whole day. I defined it in a .thing file. In the log I see it trying to communicate with it, but it just spits out debug level error messages.
I had the binding crash once, where the dongle would still show as online, but nothing was getting through anymore. I was able to resolve it by restarting the binding. I have a log of the non-responsive state, not of where it happened.
I’ve also seen this with the same bulb - I’ve not looked into it yet but will do so.
I thought that your Hue motion sensors were not working -:
Please provide a log if you have one.
I have found a bug with the Ember driver which I’ll fix tonight. It’s a corner case following retries so it would be interesting to see if it’s related…
Trust: Maybe it is because the lamp also exposes a dimmer channel, which the binding then hides in favour of the color channel. It might have been that it discovered the dimmer, but not the color channel, so it showed a dimmer.
It’s my Smartthings motion sensors (I have three) that are not being discovered at all. Hue was working.
I’ll open a bug on github with logs of the crash and my motion sensor
BTW, this binding also showed a battery channel on my Hue motion sensor, the time that it worked, it showed 200%, so I am not confident that it actually works. There also is a switch channel of unclear purpose shown.
It’s probably related to the saving of data between binding restarts. With this version, I don’t request all the information from the device on startup - the idea being to increase startup speed and reduce network congestion. However, if something didn’t save correctly then the initialisation may not work properly.
The channel consolidation is the same either way so I don’t think there’s a problem with that.
Is that still the case - the issue I thought was that it was only showing a temperature channel? Please can you update the issue with some information (ie logs) as there shouldn’t be any reason it’s not being discovered.
Please provide a log showing the issue - without this it will never be fixed (if there is actually a problem!).
Again, please provide information on the issue or it won’t be fixed.
With regards to the Smartthings motion sensors: There are no logs. I try to associate, watch the log tail and nothing comes up. It only showing a temperature channel was with an older version of the binding, where I also had a hard time trying to get them to show up at all. Since then I have reset the motion sensor for another try at discovery from the get-go and that wasn’t succesful any more. So I have no newer logs since I posted them in the issue on github.
I can post a log of the Hue channel discovery as soon as they will show up. Logs from two days ago are already purged.
This is probably not related to the binding then I guess - if there’s no association in the first place, then the binding doesn’t even know about the device so there’s little it can do.
Hi All,
I’ve been testing the ZigBee binding with a EM357 based gateway (running the NCP 5.6 firmware) and so far things seem to be working. I have a feature branch that enables communication with the gateway over TCP rather than serial: the gateway I have just serves the data stream over a TCP socket rather than a serial port. My modifications automatically handle disconnects and restarts the binding upon reconnection.
I’d be happy to prepare a PR if there’s interest in having that functionality in the official binding… it’s also handy for dongles: socat and ssh can be used to “sling” communication to a different host for debugging or where the openhab server can’t host a dongle (or where java serial configuration would be a pain).
Hi,
Thanks for the comments. Maybe this could be considered as a possible enhancement, but a TCP version should not be implemented within the Ember coordinator I think. Coordinators should be kept separate, and if you have a link to a different system, then it should be implemented in a way that is not linked like this. If it is really just an extension of the Ember dongle, then I would suggest to just use socat as the extension.
In the short term the binding is going to be refactored so I would at least hold off any PR until after this is completed (a few weeks hopefully).
Cheers
Chris
Hi Chris,
Thanks for the feedback. I did originally attempt to use socat rather than modify the binding, but RXTX requires a native module that I just wasn’t able to get working on my OpenHAB box (and it ultimately felt like another point of failure to have another process involved).
I didn’t think it made sense to create a separate coordinator type because the data communication is otherwise identical (the device has a EM357 running the EmberZNet NCP firmware), differing only in the type of ZigBeePort required.
I’m not familiar with any of the other ZigBee coordinators, but I imagine any that communicate via serial could also be used in the same way so it could be useful to allow TCP communication for those as well… conceptually similar to a printer being connected directly versus via a print server.
To be honest, I’m not very keen on this as it’s quite messy. We had the same discussion a long time ago about doing this in the ZWave binding and for the same reason, it was not implemented.
I’m not sure that your analogy with redirecting a printer is the same. When you redirect a printer, it’s the OS that normally does this. We don’t have to modify all the programs that use the printer to know how to redirect it to another place. In the same way, I would prefer to keep this outside of the binding - otherwise we find that someone wants to redirect using another protocol, and it just becomes unmanageable and unmaintainable.
Well, I guess I’m not thinking in terms of “redirecting” a port in the Windows sense… when I create a printer using, say, CUPS, I can choose various options of how to communicate with the printer… serial, usb, jet-direct, etc. In this way, I sort of see OpenHAB and its bindings as being the equivalent of CUPS in this case.
Judging from a quick search and my own experiences, serial to IP seems like a common enough use case that supporting it wouldn’t be a completely unreasonable proposition. I might even go so far as to say I thought it an unfortunate omission that OpenHAB didn’t have some internal component that bindings could use to communicate in a stream with devices using serial or tcp (or …??)
I can certainly understand the need for maintainable code though I’m not sure I would agree that this qualifies as “messy”: the code required is pretty simple and communication via TCP sockets is more straightforward in Java than serial communication.
Anyhow, if the general consensus is that a PR for this type of capability is not likely be accepted, that’s ok… the link above can serve as a breadcrumb in case anyone else has use for it.
I’ve started to create a ZigBee log viewer to try and make it easier to view logs - it’s mainly written for myself so I can more easily see what’s happening in the binding, but if you want to use it, then feel free. Note that you need to be registered on the site to use it (I’ll probably change this at some point, but since it’s very much WIP, I wanted to limited visibility slightly!).
For those familiar with the ZWave log viewer, you’ll be pretty much at home with the ZigBee viewer 
.
Select your file -:
Adjust the filters -:
View the log -:
Clicking on a line will display the full packet trace -:
As I said, it’s very much WIP and has a load of limitations, but feel free to use it if you like…
2 Likes
I’ve created a new test binding here.
This is an extension of the one I posted a few days back. It does fix a corner case bug with the Ember chip when there are retries, fixes a few issues with serialisation, and improves logging for Ember and Telegesis dongles to work better with the log viewer.
I’ve also merged a new channel for battery voltage as a few devices I’ve got don’t report battery percent, instead they report voltage (the newer SmartThings motion sensors for example). This channel is also merged into master.
I thought the previous test binding was already merged to master, so that was what I was on. Dropping this new test binding in (after renaming it to match my previous file name), one of these popped up. All but 3 of my devices came online (they had been before upgrading). After restarting the binding, all but 2 devices (GE bulbs) came online (power cycling bulbs got them back up) and I didn’t see this exception, so maybe it was just caused by dropping in a newer version?
2018-02-19 18:52:16.310 [DEBUG] [g.zigbee.internal.ZigBeeNetworkStateSerializerImpl] - Error loading ZigBee state
java.lang.NullPointerException: null
at com.zsmartsystems.zigbee.ZigBeeEndpoint.setDao(ZigBeeEndpoint.java:467) ~[?:?]
at com.zsmartsystems.zigbee.ZigBeeNode.setDao(ZigBeeNode.java:824) ~[?:?]
at org.openhab.binding.zigbee.internal.ZigBeeNetworkStateSerializerImpl.deserialize(ZigBeeNetworkStateSerializerImpl.java:162) ~[?:?]
at com.zsmartsystems.zigbee.ZigBeeNetworkManager.initialize(ZigBeeNetworkManager.java:272) ~[?:?]
at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.initialiseZigBee(ZigBeeCoordinatorHandler.java:324) ~[?:?]
at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.lambda$1(ZigBeeCoordinatorHandler.java:402) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
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) [?:?]
I did see this after the binding restart too (Centralite/SmartThings outlet)…
2018-02-19 19:03:37.800 [DEBUG] [com.zsmartsystems.zigbee.zcl.ZclCluster ] - 5709/1: Error reading attribute 772 in cluster 2820 - UNSUPPORTED_ATTRIBUTE
In case you tried to stop these, I’m still seeing them…
2018-02-19 19:15:50.060 [DEBUG] [ystems.zigbee.internal.ZigBeeNodeServiceDiscoverer] - 7CE524000014AF33: Node SVC Discovery ManagementRoutingRequest returned CommandResult [ERROR (UNKNOWN,0x02), ManagementRoutingResponse [7491/0 -> 0/0, cluster=8032, TID=NULL, status=NOT_SUPPORTED, routingTableEntries=null, startIndex=null, routingTableList=[]]]