I hate ‘me too’ posts on existing threads, however in this case can I add another sample
Running openHAB 2.5.0.M5 Milestone Build on a RPI4 openHABian, I see occasional random periods where it can take 2-5minutes for a Zwave command to change the state of a device, then multiple events fire immediately. The logs don’t show much - typically, the state change is noted, but the feedback that the end device has changed doesn’t arrive:
[ome.event.ItemCommandEvent] - Item 'sBed1_Lamps' received command OFF
[nt.ItemStatePredictedEvent] - sBed1_Lamps predicted to become OFF
In the normal case, the device changes state within 0.5S, and acknowledges back the change.
The random events of blocked Zwave communication happen about 1-2 a day, and don’t have much correlation between day / night, and although it could be an external factor like RF interference, the issue can disappear as quickly as it arrives. It could well be RF, or a multi-hop mesh taking 2 mins to time out and blocking other commands.
The Z-Wave network viewer in HABmin shows 30 devices, with 9 with a single-hop to the controller, which is interesting. One battery device (a door FGK101 door sensor) seems to have bad connectivity (red lines), which is slightly odd as I’d not expect a battery device which spends most of its time sleeping to be doing routing. The rest of the devices are densely connected with many routes to the controller.
This makes me wonder about moving a mains powered ZWave device and waiting for the nightly network heal to see if the network viewer changes.
The transient nature of the issue makes it harder to capture useful logs - which I must agree is no help. I probably should run with debug on the ZWave binding, but haven’t done so to date. Chris’s instructions to do this via the Karaf shell are here for reference:
log:set debug org.openhab.binding.zwave
log:set default org.openhab.binding.zwave