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.
You can put the zwave binding into debug or trace mode and watch the binding logs. If the event is coming from the device you should see message traffic coming from there.
That’s really weird behavior but I think this pretty definitively identifies the culprit. For some reason, the device itself is reporting this new value.
I’ve no further advice from here except to check your other devices to make sure your association groups are not somehow interacting with this device.
Whatever is happening, it’s happening outside of OH though. The binding is doing it’s job and updating the Item based on what the device is telling it.
Thanks @rlkoshak and @rossko57 (for the link)
While I’d love to understand what is actually happening and the potential issues I may see with this the following steps fixed the behavior.
With the GE switches and using HabMin.
I went to Things and chose the switch. Then set “Command Poll Period” under “Device Configuration” to 3000 (formerly 1500) and it fixed the behavior.
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.
