I have put a test binding version here for anyone who wants to try some new features before I merge them.
The main features this adds is a change in the way discovery/mesh updates work, and an increase in the amount of data that is persisted. The overall goal here is to reduce network congestion (especially following a startup) by persisting information between restarts. This avoids having to request all the basic information about the device again (and again…) which puts a huge load on the system on large networks.
Before I merge this I’d welcome some feedback (maybe @5iver and @TheNetStriker you might be interested in testing ). The XML file that the system creates is likely to be quite large now - I’d be interested to know how large your files get. I could possibly consider writing the data into separate files per device (as per ZWave) if it’s a problem.
I’ve also added a random logarithmic backoff for devices that don’t respond to discovery requests - I’m thinking of slowly increasing the lower bound on the retry time to slowly remove all communications from these devices if they aren’t responding to basic requests.
More information on these two changes if you want to comment are below -:
This version also has converters for atmospheric pressure and humidity in support of the Xiaomi Aqara sensor - (I might merge these into the master sooner rather than later) -:
Yes they work fine with the Ember dongle until the Ember dongle stops sending commands. I have looked through the windows logs, and found nothing. I tried debug logging on nrjavaserial, but that is not very informative, nothing is turning up. Unlikely to be serial communication anyway since I still get incoming events.
Resetting the binding also doesn’t really work, only full restarts work. Would like to get a more stable system.
So far, so good (HUSBZB-1). XML is currently 886KB (27 devices, 5 of which are powered off). I usually have to refresh Habmin after restarting the binding to get the links to show up, but with this version, they seem to pop right in. [EDIT: I take it back… I got lucky. Only a few of them popped in and the rest were missing links so had to refresh.]
Filtering the log for error and exception turned up a lot of these which I do not recall seeing before (GE Link bulbs)…
I’ve not seen a problem where the Ember dongle stops sending commands. If you are referring to the previous log you posted, it’s not related to the Ember I think - it’s somewhere else in the system. The Ember is still sending and receiving just fine in that log.
If you are thinking of changing to another dongle to resolve this issue, I suspect the same problem will exist.
I’ve seen this before with a bulb I have here. When I power cycled the bulb they stopped (it’s a “Trust” bulb so not GE). It would be interesting to see a debug log of the response that’s causing this if you can grab one.
Yes - but this doesn’t have anything to do with the dongle - right? The network manager is not sending anything TO the dongle so the dongle doesn’t respond. There are a few messages received from the dongle as other things also happen from time to time. All the ASH communication (ie the dongle communication) is working perfectly (at least from what I saw in your logs). For this reason I don’t believe that this is related to the dongle - or do you disagree?
No - it’s likely an issue with the binding is my best guess. It could be another binding, but probably unlikely.
FYI, I saw this too… but thought it was just because I had dropped the updated jar (after renaming it) while OH was running or due to the new changes and the devices hadn’t been queried yet. After restarting the binding (might have been an OH restart), the channels came back.
No - there shouldn’t be any real reason to have to do this, but devices need to somehow be rediscovered again - if the dongle doesn’t report them, and they don’t send updates (as is the problem with Hue bulbs) then it can be difficult to discover them.
The new binding uses a new persistence, so any previous data is not used.
Yeah - why not. I’ll take a look at what’s happening - I expect it’s still a case of overloading with polling etc (I think all your devices are Hue lamps?).
The reason for the long delay is as I thought - there’s a large backlog of traffic getting queued. Unfortunately at the moment there’s no transaction management layer in the binding to handle this better (it’s on the list…)