Light toggle sends brightness 100 followed by a lower value

[davorin (Richard Klingler)]

Good morning (o;

In my openHAB 3.3 test setup I have several Hue lights controlled via a ConBee II stick…

Now I placed those lights in a list card with toggle items…

When I toggle a light to turn on I see in the logs that openHAB sends 100 command for full brightness immediately followed by a lower value:

2022-10-03 10:05:07.734 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Kitchen_Brightness' received command ON
2022-10-03 10:05:07.759 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Kitchen_Brightness' predicted to become ON
2022-10-03 10:05:07.831 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Kitchen_Brightness' changed from 0 to 100
2022-10-03 10:05:08.309 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Kitchen_Brightness' changed from 100 to 56

Anyone knows what is going on here?

[MDAR (Stuart Hanlon, UK importer of Velbus hardware)]

If what you’re seeing is the same as with the Velbus environment, it’s along these lines

Your ON instruction sets the new target state to the device.

The Binding converts that to a desired value of 100

The device then updates the Item with the actual states until it reaches your new desired value.

If I bother to look at the logs, I see things like

(Made up data)

Changed from OFF to ON
State update 100
State update 0
State update 24
State update 46
State update 67
State update 88
State update 100

[davorin (Richard Klingler)]

Think that isn’t it…

When I toggle the light it sends first 100, then a second later a lower value like 15 is reported…and the light stays at the lower 15% brightness…so it is not increasing to the initial value of 100.

When I use the brightness slider in the locations tab and set it to 100% and then 0% the toggling works again for full brightness…

I assume the lower value comes back from the Hue light…so maybe some parameter available in ZigBee for setting the ramping for switching on?

[MDAR (Stuart Hanlon, UK importer of Velbus hardware)]

Oh, I see.

Sorry, I didn’t realise that you meant your lamp wasn’t continuing to change.

I hope you find the issue.

[rossko57]

@davorin

Anyone knows what is going on here?

To understand what you see in the logs, understand ‘autoupdate’.

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…

You can change the behaviour by disabling autoupdate.

You haven’t described the physical response at your device, but guessing that it resumes a previously-set brightness when you command it ON - many people would see that as desirable behaviour.
(This is very device dependent, not all bindings do it that way)

Is this a problem for ypou, or just a puzzle over the logging?

[davorin (Richard Klingler)]

Actually I did describe the physical behavior above:

“When I toggle the light it sends first 100, then a second later a lower value like 15 is reported…and the light stays at the lower 15% brightness”

Will try if the “autoupdate” disabling solves this…