Zwave - Items not waiting for the acknowledge


I use openhab 2.1 stable with zwave 2.2.0-snapshot and I have a basic understanding problem.

Do items in openhab2 wait for the acknowledge of a device that is connected to the power supply system?
I have a rule that triggers a FGWP101 Metered Wall Plug Switch.

Sometimes the the signal doesn’t arrive at the device, it’s not near to the controller and it’s possible that I have to use a repeater.
But the item (Switch) in openhab changes the state although the device didn’t change the state.

So openhab shows me a wrong situation. Switch is on although device is off.

Is it possible to configure that openhab waits for the acknowledge or to check, if the last command was successful?
And if it wasn’t successful, then retry it or do something else?

And another question going in a similar direction:

When I change the state of the FGWP101 Metered Wall Plug Switch directly at the physical switch of the device, the item also dosn’t change the state in openhab.
Is this correct or do i have a wrong configuration?

Thanks for your help.


No, because not all devices or technologies provide an ack.

Eventually, based on the polling period configured in the zwave binding, the Item will be updated to the device’s actual state.

Not all bindings will support this and not all devices for a given binding will support this. It is just a technical limitation and not something that can be worked around. There might be something that can be done with zwave but I don’t know. I’d recommend filing an issue on the zwave binding and see what the devs say.

Possibly. Again, not all zwave devices report to the controller when they are manually triggered. Again, the true state will eventually be picked up during the network poll but the polling period is many minutes long.

But there are some devices that need to have their Association Groups set to 1 (I think, maybe 2) so that the device knows to report the state to the controller. If that device doesn’t have support for Association Groups then you are unlucky enough to have a device that doesn’t support reporting manual switches.

@rlkoshak you describe the current situation and that sounds reasonable.

In my opinion it would be great to add a mechanism to the binding concept that by default behaves like you stated, and if the technology supports two-way communcaton/ACK it should not wait for the polling period to revert the state.

Somehow i allways thought it worked this way :slight_smile:

With zwave, it is I think pretty hard for the binding to know which devices do this reporting. I don’t think there is anything in the device description that would tell the binding that this switch will report and this other switch will not. It just knows the two are switches.

With Z-Wave, every command gets acked. The standards state that if the command is acked, then we can consider that the command was implemented. So it’s perfectly possible to have a system that only changed the item state once it was acked.

For manual changes, most devices will report the change, and this should normally work fine. There are some devices that don’t have such a mechanism, but they are pretty few and far between now. ZWave plus also provides functions for the controller to directly know what reports have been sent (so long as the device provides this feature) although in most cases this isn’t needed as we add this manually into the database anyway.

Thank you for your replies. This helps me a lot to understand the system. :grinning:

I tested the FGWP101 Metered Wall Plug Switch near the controller and if i use the physical switch there, the change is noticed by openhab2. So in this case the problem was the distance to the controller.