My dimmers changed value two times

[doob_marley (Roger)]

Hi!
When I my dimmer lights turn off with BasicUI or Alexa commands the dimmer update a state two times. The first update it’s 100% to 0% and the segond update is 0% to xx%. The phisical light is off but in BasicUI it’s open.
This is the log.

[INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command OFF

[INFO ]penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become OFF

[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 100 to 0

[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 0 to 98

How i can resolve this?

[rossko57]

See -

Autoupdate - a primer

I’ve found myself having to investigate and/or explain some of the features of autoupdate over time, and thought an in-depth view would be helpful. These notes apply to openHAB version 2.5 Overview Autoupdate is primarily a “speed up” feature for openHAB Items. Mostly we can ignore it, but sometimes you may get an unwanted or unexpected effect, or you may wish to exercise more control. To fully understand autoupdate, we must understand the difference between command and state of Items. If w…

to explain what you are seeing in the log.

But what’s missing is an eventual report of 0% from the device?
If your mystery dimmers happen to be zwave, the binding has a poll-after-command feature which can have the timing adjusted per device to improve behaviour.
Setting is somewhere in the device configuration in the UI

ZWave State Update Incorrect after issuing dimmer command

Hi, I’m having an issue with the state update applied to my ZWave nodes. The behavior is I apply a command to a ZWave device. The command is received and processed. However, the state update on the device doesn’t match the command. Example: Apply Dimmer switch command: from 100% to 0% (simplistic example) Device behavior: Light turns off completely physically (so 0% on light itself). So success here!! State within HabPanel or Paper UI: 49%. So failure in setting correct state update. Note: I…

[DrRSatzteil (Thomas Lauterbach)]

I think it would be important to know what device/binding you are using. I do have a yeelight bulb that behaves a bit like that. It always shows the last brightness value before it has been switched off.

I had to resolve this by using a proxy item.

[doob_marley (Roger)]

My device is a Z-Wave Qubino Flush Dimmer Plus
I tried to disable and then enable Auto-Update metadata but not work.

[chrismast (chris)]

@rossko57 could the auto update function also be the reason why I see this behavior? (I still did not find a solution to it).

[rossko57]

@chrismast

could the auto update function also be the reason why I see this behavior?

No.
Autoupdate never issues commands.
The UI issuing commands all by itself is a bug.
Related -

Min/Max settings in new UI

With OH3 I switched from habpanel to the new UI (still using habpanelviewer). I use thermostats (Homematic) to control the temperature in my rooms. I use the stepper item now in the UI to change the temperature. Just like in the old habpanel (and sitemap) I chose min (18° C) and max (23° C) values for the temperature. Whenever a window is opened the Homematic system sets the temperature to 5 °C, it has always been like this, this is not related to OH. Here is the difference: When I close the wi…

[doob_marley (Roger)]

Well, the solution or idea for this issue? The ItemStateChangedEvent is repeat unnecessary.

[INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command OFF

[INFO ]penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become OFF

[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 100 to 0

[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 0 to 98

[rossko57]

@doob_marley

The ItemStateChangedEvent is repeat unnecessary.

If you do not like seeing that, then disable autoupdate for this Item as already suggested.

@doob_marley

Well, the solution or idea for this issue?

@rossko57

But what’s missing is an eventual report of 0% from the device?
If your mystery dimmers happen to be zwave, the binding has a poll-after-command feature which can have the timing adjusted per device to improve behaviour.
Setting is somewhere in the device configuration in the UI

[doob_marley (Roger)]

The auto update not works. I need item state becomes to 0% because in the app or Basic UI show the light it’s ON but really the light is OFF.
I disable the Command Poll Period in zwave dimmer configuration at it says here but not works.
If send comand ON and OFF throug the wall switch, it works OK.

[rossko57]

@doob_marley

The auto update not works.

What “not works”?
If you mean that with autoupdate disabled, your Item does not get updated?
That is a good thing, that means that you have exposed the real problem that autoupdate was hiding.

Your zwave device is not reporting state changes promptly.

@doob_marley

I disable the Command Poll Period in zwave dimmer configuration

It’s the “Command Poll period” that I was referring to - after openHAB has sent a command, the binding polls the device once for its new state.
If that happens too quickly, you might get a status between where it started and where it will eventually finish.
If it doesn’t happen at all (because you disabled it) you might not get a status (depends on the device).

[doob_marley (Roger)]

When I say “not work” Im refer the issue persist.
The dimmer acts weird. Sometimes it goes from 100% to 0% fine, and sometimes it sends two state events in a row.

[INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command ON
[INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become ON
[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 0 to 100
[INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command OFF
[INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become OFF
[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 100 to 0
[INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command ON
[INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become ON
[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 0 to 100
[INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command OFF
[INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become OFF
[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 100 to 0
[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 0 to 12

[rossko57]

You’ve still got autoupdate enabled on that Item.
I think you would understand what is happening better if you disable autoupdate on that Item.
Hiding the timestamps makes it harder for you to understand also.

[chrismast (chris)]

Thanks @rossko57.
I played around a bit and it seems that when I move the Dimmer item to “properties”, hence not under the equipment, it does not automatically execute when opening the Location card.
When I move it back (and hence have on/off plus dimmer items in it) it does auto send a command again.

[doob_marley (Roger)]

No, the autoupdate is disabled on Item. If I enable the autoupdate the Item change the state from 100 to xx.
If I disable, the item change the state from 100 to 0 and then from 0 to xx.

2021-02-04 23:33:29.853 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command ON
2021-02-04 23:33:29.861 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become ON
2021-02-04 23:33:29.866 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 0 to 100
2021-02-04 23:33:33.330 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command OFF
2021-02-04 23:33:33.338 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become OFF
2021-02-04 23:33:33.363 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 100 to 0
2021-02-04 23:33:48.665 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command ON
2021-02-04 23:33:48.686 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become ON
2021-02-04 23:33:48.690 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 0 to 100
2021-02-04 23:33:56.312 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'rebedorllum_Dimmer' received command OFF
2021-02-04 23:33:56.322 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'rebedorllum_Dimmer' predicted to become OFF
2021-02-04 23:33:56.327 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 100 to 0
2021-02-04 23:33:57.328 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'rebedorllum_Dimmer' changed from 0 to 12

[chris (Chris Jackson)]

Have you checked the debug logs to see what is happening? This might help and is generally a good first step when debugging a problem

[rossko57]

@doob_marley

[penhab.event.ItemStatePredictedEvent]

Autoupdate is enabled on this Item. That’s only a nuisance, but it hides your view of the ‘real’ updates the Item is (or is not) getting from zwave.