Increase the polling delay after a command beyond 15 seconds

[ghys]

• OH Version: 3.0 (Release)
• Binding Version: 3.0 (Release)

If the problem is associated with a device, please provide the following -:

• Device name: ZMNHCD
• Device version: ?
• Link to database: https://opensmarthouse.org/zwavedatabase/614

---

My situation with the above device is the following: I've been leaving the "polling period" and "command poll period" to their defaults (86400 & 1500, respectfully) for years, until I noticed that the current state of the rollershutter wasn't reported accurately until half an hour later, or if I sent another command, for instance STOP. It does however, update 1.5 seconds after I sent the command to the item.

Examples: Command UP sent and state updated 1.5 seconds then 30 minutes after:

2021-01-11 09:40:46.368 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'VoletSalon_BlindsControl' received command UP
2021-01-11 09:40:46.389 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'VoletSalon_BlindsControl' predicted to become UP
2021-01-11 09:40:48.483 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VoletSalon_BlindsControl' changed from 0 to 4
2021-01-11 10:10:48.240 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VoletSalon_BlindsControl' changed from 4 to 100

Command DOWN sent and state updated 1.5 seconds after, and after a subsequent STOP command:

2021-01-11 17:46:56.883 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'VoletSalon_BlindsControl' received command DOWN
2021-01-11 17:46:56.886 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'VoletSalon_BlindsControl' predicted to become DOWN
2021-01-11 17:46:58.788 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VoletSalon_BlindsControl' changed from 100 to 94
2021-01-11 17:47:36.431 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'VoletSalon_BlindsControl' received command STOP
2021-01-11 17:47:36.730 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VoletSalon_BlindsControl' changed from 94 to 0

So I've been looking into either:

1. decreasing the polling period to something like 30-60 seconds - the device is mains-powered
2. increasing the command poll period so that the polling after a command is done when the rollershutter has finished going up or down after a command (it takes about 30 seconds to do so).

The second option would have my preference since I don't really need to poll this device except some 30 seconds after it has completed a command. Besides, looking at my current network map: if I understand correctly more frequent pollings would transit from node 4 (the ZMNHCD) to node 1 (the controller) through node 9 or 10, which are battery-powered?

However, it seems the max for this parameter is 15000 milliseconds: https://github.com/openhab/org.openhab.binding.zwave/blob/d25f5ade971a478b021dd1cdccd36355c03d6cf4/src/main/java/org/openhab/binding/zwave/internal/ZWaveConfigProvider.java#L225

Is it possible/reasonable to increase that maximum, or am doing it wrong?

[digitaldan]

There was an issue where polling was not being enabled on channels due to a change in how channel linking happens in the core, this was fixed a few days ago , see #1493 , not sure if thats the issue here?

if I understand correctly more frequent pollings would transit from node 4 (the ZMNHCD) to node 1 (the controller) through node 9 or 10, which are battery-powered?

afaik battery devices do not act as repeaters, only mains devices can route messages to other nodes.

[cdjackson]

I would suggest to disable polling. The intention of this is a quick check after a command is sent, so having this in the minute range is not within the intent and I'm worried that if there are multiple commands within a such long period, we'd have to manage this differently to avoid polling overlapping with commands.

[cdjackson]

afaik battery devices do not act as repeaters, only mains devices can route messages to other nodes.

Correct.

[ghys]

afaik battery devices do not act as repeaters, only mains devices can route messages to other nodes.

That's what I thought too, so I might be misinterpreting the map. I indeed have:

zwave_nodeid 1
zwave_neighbours 9,10

for the controller and nodes 9 & 10 are battery-powered.

[cdjackson]

Remember, the map does not show routes - it shows neighbours and battery powered neighbours will not be used for routing.

[cdjackson]

I say "will not" - to be clearer - I should say "can not" - it's not possible to use a battery powered device for routing as they do not have an active received.

[ghys]

Remember, the map does not show routes - it shows neighbours

I guess I wrongly assumed that routing legs were only between neighbours, that's why it didn't make sense. Thanks for the explanation!

About the original problem, I'll just decrease the regular polling period, and disable the repolling after a command.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/strange-z-wave-network/120121/18