Like Chris I am surprised by the volume of energy reports.
Are you tracking your power usage minute by minute?
Does your energy supplier charge you for peak load? If not I am not sure why you would be interested in the KVAH readings but great bragging that you have it. The most interesting thing is this is going into a channel called current? I would expect A to go into the current channel. What device type is node 59?
Before troubleshooting the delays I would recommend:
-
Turn off the KVAH or A reporting from all of your devices unless you really need it. Unless your power factor or Voltage is way out of range it will tell you a very similar story to your kWh or W reading anyway.
-
Change the W to report on change if the device supports and turn off periodic reporting. Set a change appropriate to the device. If it is a PID controlled device like an automated coffee machine report on a largish change say 30%. If it is a device that goes into standby set it even higher.
-
Set kWh to only report every few hours or even only daily unless you need blow by blow usage.
That will then clear the decks so we may be able to see what is going on bu tit will be difficult with all those messages.
As to the premise of the question regarding performance:
In a good environment, a simple direct zwave request will take 20 to 30 ms from send to network ACK. If you are really interested I would recommend that you invest in a UZB-3 and flash it as a zniffer and you will see the actual network calls. The logging on openHAB is very good so you can probably get away without. You just lose sight of a lot of what goes on under the covers.
You need to appreciate that ZWave is one thing at a time. There is no clever buffering or store and forward so that really defines the maximum number of simple requests you will ever get through in the current version.
So at that level, in a well configured network with a lot of direct connections pushing the network beyond a simple message every 50ms is going to end in problems. So that is only 20 messages per second above which requests will definitely start back up in openHAB.
So giving this some tolerance allow 100ms to 200ms average per call and your network should cope and you will rarely notice anything slow with 5 to 10 messages a second. This is why turning off any wasted reporting makes sense.
I don’t run zigbee so how do you think this compares to zigbee? You should never wait very long.
As to this strange issue you have, the first thing is definately to clean up the amount of unnecessary traffic.
Prior to the latest SDK the recommendations where to do exactly what openHAB has implemented and call the zwave stick with some retry options so the issue is probably not openHAB specific andyou would probably have the issue if you tried another software.
The flow in simple terms is:
openHAB calls the controller with options to retry delivery.
Internal to the controller the protocol tries to recover from any issues by retrying upto a maximum number of routes. This is all internal to the zwave controller stick and you will only see this if you get a zniffer. The last thing it tries, if the application sets the option for the call, is an explorer frame that should find anything on your network but is very costly in terms of network utilisation.
All this is going on in the code on your Aeon controller and the fact that the light is behaving like that suggests something in the application code inside the controller is getting in an unusual state for some reason as yet unclear. It could either be from the network side or due to how openHAB interacts with the controller under certain circumstances. If it was the latter I am sure we would all have issues so this probably is not the case.
If all internal attempts fail only then does the call return to openHAB and openHAB can try again or if it takes too long for the stick to come back openHAB will also timeout the call and unlike the released version of openzwave tidy up.
So there is the challenge in troubleshooting this for you. For most of what is happening we are blind as there is no debug output from the actual controller and you do not have a zniffer. We have the log from openHAB that tells us nothing about any issues in the stick or about anything on the network while the stick is in this odd state.
Happy to have a look at a new log when you have turned off all of those reports. If nothing obvious form that it all gets a little more complicated.
good news.