I have tested this with both HabPanel and Classic UI.
I have an on/off button for a Z-Wave Dimmer switch Called “KitchenMain”
When I click this button. The following events are processed.
2019-03-05 11:39:26.033 [ome.event.ItemCommandEvent] - Item ‘KitchenMain’ received command OFF
2019-03-05 11:39:26.072 [nt.ItemStatePredictedEvent] - KitchenMain predicted to become OFF
2019-03-05 11:39:26.094 [vent.ItemStateChangedEvent] - KitchenMain changed from 100 to 0
2019-03-05 11:39:27.743 [vent.ItemStateChangedEvent] - KitchenMain changed from 0 to 49
Notice that a random event occurs changing the dimmer from 0-49. The light remains off despite seeing this in the log. However my dimmer button changes to 49.
A Similar issue occurs when turned back on.
2019-03-05 11:46:47.190 [ome.event.ItemCommandEvent] - Item ‘KitchenMain’ received command ON
2019-03-05 11:46:47.209 [nt.ItemStatePredictedEvent] - KitchenMain predicted to become ON
2019-03-05 11:46:47.218 [vent.ItemStateChangedEvent] - KitchenMain changed from 0 to 100
2019-03-05 11:46:48.847 [vent.ItemStateChangedEvent] - KitchenMain changed from 100 to 51
The light stays on, looks like it’s 100% but the dimmer switch on the UI Panel goes to 51.
11:46:47.190 ... Item ‘KitchenMain’ received command ON
11:46:47.209 ... KitchenMain predicted to become ON
11:46:47.218 ... KitchenMain changed from 0 to 100
11:46:48.847 ... KitchenMain changed from 100 to 51
First the command comes from your rule or UI. We know your binding is going to pass that along to your device.
Second, there’s a prediction. Your Item has autoupdate enabled, and this is what autoupdate does. Guesses what the outcome of a command will be.
Third, the Item is updated according to autoupdate’s prediction.
It’s a dimmer, so autoupdate has guessed ON means 100%. Maybe it’s the kind of dimmer that actually turns on at a remembered value from last use - but autoupdate doesn’t know, cannot guess. This is the best guess it has.
That’s all over in a few milliseconds, because its all happening internal to openHAB.
A second later, we get another update. That’s come from the device, via the binding. I don’t know but can guess that is actually a response from the device to being sent the ON command, seems a reasonable thing to do.
But … what “should” be the value of that response? It might be “this is what I got right now”. Does that mean before, after, or during the turning-up/on process? Does it mean “this is what I will get afterwards”?
Should ON go to the last dimmer setting or 100%? Does it mean “done that, here’s where I am”?
Everyone plays by different rules here.
In this case, what you’d really like to know is the device state after it has finished processing the command. Delaying poll after command is one way to get that.
Or maybe for this dimmer it’s telling the “truth” all along, and ends up at 50%. .
This is the correct way to solve this issue. Some devices, such as dimmers and locks, take some time to reach their final state after being sent a command. Lengthening the command repoll interval prevents the binding from polling for the new state while the device is still transitioning from the old state to the new state.
Note that some devices automatically report their state at the end of the transition to the new state. If the device automatically reports its state at the end of the transition, you can disable the command repoll.