In my experience, the commands do eventually go through, but it’s after 10 minutes (yes, almost exactly 600 seconds, reproducibly) to take effect.
When I go back to my previous 2.1 install, the delay goes back to the ‘normal’ 5-10 second average, which seems to be different that what was seen in the other thread… (Note that the 2.1 install is using org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar due to needing the ZWave security support introduced then, and ran stably for several years!)
Also, note that I have 2 ZWave sticks (both Aeon); one is used for the ‘normal’ 50+ node ‘main’ network, while the second is used for only 2 lock devices running security. I found that the security binding could not complete in the ‘busy’ network, but running the two sticks side-by-side worked well for several years. For debug purposes, the second (‘secure’) stick is not in the system (and was never in the system for the ‘clean’ install), but both behave the same on both 2.1 and 2.5, so I don’t think it’s the stick.
Beyond the debug logs, is there anything else I can provide that will help debug the reason for the extreme lag?
Edit to add: Going back in my notes, I see that about a year ago I tried to migrate to 2.4, but had the same problem. At the time there was no compelling reason for me to use 2.4, so since I was also fighting some other problems at the time, rather than fight it at the time I just went back to 2.1. The point: I was seeing high ZWave latency back on 2.4 as well.
What addons do you have installed? There have been many changes between 2.1 & 2.5.
Any invalid addons configured in 2.5 cause all addons to reload every minute trying to load the invalid ones.
I have (based on the previous thread), and it’s not… system is basically idle. There is a noticeable spike on openhab boot and zwave enumeration, but after that dies down cpu usage is ~3%. There isn’t any reason I can see that the OS or USB device would be waiting on any CPU resources.
With that much of a version jump you should delete (NOT Exclude) all your device Things and re-discover to get the new binding settings. They will keep the same Thing IDs so your Items and rules will still work.
When I did the migration from 2.1, I had weather, nest, tesla, astro, and a few other bindings.
When I did a clean install, though, only the zwave binding was loaded. It was a very clean install; didn’t touch the files at all, just used paperui to install the zwave binding, and saw the same behavior.
Currently I’m back working with the migrated old install (cuz I have lots and lots of devices, along with rules and other things, and who wants to re-enter that?), but for debug purposes I can easily switch to a ‘clean’ install.
I assume you do not have any zombie or ghost nodes in your network to mess up routing. Let’s see if Chris has any suggestions tomorrow. It is night in the UK now.
This ghost-node thing is what I’m most worried about, as this hardware is several years old, and has had a large variety of devices run on it over time. There are several devices that have failed or been removed over time… I did remove all the ‘not responding’ and ‘failed’ nodes that the binding discovers (based on threads such as Zwave ghost devices), but honestly I’m not convinced that everything is totally happy and consistent, and I can’t find better details on how to debug much deeper into figuring out the node-level health.
What I really don’t want to do is the obvious step of excluding all the devices, hard resetting the controller (or just buying a new one to be sure…) re-adding everything (including several nodes that are physically very difficult to access)… and then find out that the problem still exists.
If you jumped from 2.1 to 2.5 you have to delete all of the z-wave things as so much code was rewritten around 2.4.
I have made a jump from 2.3 to 2.5 recently and it took some time for the zwave network to settle down and response rates to return to their previous timings.
I have a VM I can use on a mac to run Windows stuff… but can you point to a specific zwave health tool? Are you referring to the Zensys tools? I’ve played with those, used them to remove ghost nodes, etc. When using the tools, the zwave devices respond instantly, unlike the openhab 2.5 binding. (Response time using zensys is <1s. Response time with openhab 2.1 is ~5-10 seconds. Response time with openhab 2.5 is 600 seconds.)
I did a completely clean install of 2.5.2, and still saw the problem. So, no old .things/.items/.cfg/etc files hanging around. (Clean install refers to Openhab; I did not exclude/reset controller/include all the devices.)
That is not normal so you are starting with an issue.
That is confirmed by the fact your secure locks would not work and considering the extra packets to negotiate security I am not surprised at that latency.
I consider normal as mostly sub 1 second and majority perceived as instant and that is with 150 nodes.
How many nodes do you have? You say a lot so default config on some of them would not be wise.
Secondly read this person’s experience.
He had an issue with locks and assumed his issue was routing as you have assumed it is the binding.
In the end he had a single node spamming the network.
this was the outcome from the other person that thought his secure locks had an issue.
Actually it was quite trivial. Turns out one of my FGS-223s went rogue and sent power reports every second effectively spamming the network. And it just happens that it’s situated right in the middle of the apartment and a lot of traffic is supposed to be routed via it. Basically just didn’t let through the wake-up beam, so the lock just couldn’t wake up when it was needed. After I fixed the rogue parameters of the FGS, HC2 almost instantly found a good route to the lock and now it works great! Hail to the king zniffer! 
