Colorpicker with ZEN31 controller bounces around

  • Platform information:
    • Hardware: mini-PC
    • OS: Win10
    • openHAB version: 3.2.0.M4

I have a Zooz ZEN31 controller for a RGB light strip. It is configured in HSB mode. I have 12V supply to the ZEN31 and a 12V LED strip. The issue I am having is that after I change the color (e.g., use a color picker to choose a new HSB value), the controller will often go right back to the prior setting. Other times, it will go to some random position. The time period in which this happens appears to correspond to the command poll period. Often, but not always, the controller will then move again afterwards, to a new position which seems to be sort of random. Sometimes, it will behave as it should. I never know what to expect. (Note: I did read rossko57’s primer on Autoupdate, see below).

This odd behavior only seems to occur when the ZEN31 is set up to use a ramp period to transition from one setting to another. If I set this ramp to 0 seconds, the change is instant, and I don’t see this odd jumping about behavior. It does what it should consistently.

Given the above behavior, I set the command poll period to be longer than the ramp period, e.g., command poll period = 3000 ms and ramp period = 1 second. However, this didn’t solve the problem. After waiting the command poll period, the random jump still happens.

I then found and read the primer on autoupdate by rossko57, and the discussion on dimmer behavior sounded much like what I was experiencing. Based on that information I then set autoupdate to false, yet this didn’t have any observable impact. This seemingly random jumping about behavior continues.

I also experience something similar with my GE 46201 dimmer wall switches. If I click the dimmer control a few times to brighten up the room, often the dimmer will just march it back down again to where it was. This is also sporadic and sometimes it doesn’t occur at all. If I click very slowly, giving plenty of time between clicks, it will usually behave as it should. As above, setting autoupdate to false did not change anything.

There must be something I’ve overlooking. If anybody has some possibilities for me to check out that would be very helpful. Thanks.

Comment; autoupdate only affects internal Item states in openHAB. You seem to be describing events at the physical device, or maybe only for the GE device? It’s not that clear.
Sharing your events.log may give a clearer picture of the openHAB end, at least.

Hi, thanks a lot for your help. We should probably just focus on one thing at a time. Here is the events log for the color picker with the ZEN31. In this particular instance, the colorpicker was at (97,100,100). I commanded (258,100,100), and it went to (124,60,81) and then finally (124,60,80).

2022-01-07 20:15:27.849 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'HutchLEDStrip_ColorControl' received command 258,100,100
2022-01-07 20:15:28.927 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 97,100,100 to 124,60,81
2022-01-07 20:15:30.036 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 124,60,81 to 124,60,100
2022-01-07 20:15:30.036 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'HutchLEDStrip_ColorControl' received command 124,60,81
2022-01-07 20:15:32.395 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 124,60,100 to 124,60,81
2022-01-07 20:15:33.285 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 124,60,81 to 123,60,80

Okay, from openHABs view - to begin with, it looks like a ramping dimmer that just gets bored, or has a limit set.
Command as expected.
Followed a second later by an update to an interim value, presumably a report from the device.
Followed a further second later by another update to an interim value, presumably a report from the device.

Then there’s a second command. I’m guessing you did not do that.
This looks to me like a UI widget bug, where it generates commands erroneously in response to state updates. This was identified and fixed for slider and knob widgets, maybe colorpicker escaped that.

Try issuing a single command from rule or API explorer, with no UI active.

I used the API to get the current color state: 58,86,50
I then posted a new color state in the API: 58,86,100
I used the API to get the new state: 33,90,100

So this is strange. This would indicate it’s not the widget, correct? The controller itself appears to be acting erratically.

If you want to instruct the device to do something then you must command the Item.
Updating Item states is purely internal to openHAB. If you have a real device linked to your Item, you would normally leave its state alone so that it reflects what the device is telling us.

Maybe I don’t fully understand. I posted a new color state in the API, using POST, which sends a command. The device indeed physically reacted to the command by changing the color of the LED, albeit incorrectly. Is there another API command I should be using?

Okay, you sent a command, not a state. It is pedantic, but these are different things inside openHAB and we’ll get in a big muddle if we don’t draw the distinction.

What did your events.log look like for that experiment?

Hi, here is the event log:

2022-01-08 11:34:35.734 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'HutchLEDStrip_ColorControl' received command 58,86,100
2022-01-08 11:34:36.718 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 57,86,49 to 33,90,86
2022-01-08 11:34:40.889 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 33,90,86 to 33,90,100
2022-01-08 11:34:41.967 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 33,90,100 to 57,86,100

The log indicates it finally reached the color state that it was commanded, but I didn’t observe that at the time. Like I said, I queried the state using the API after the LED had physically changed to the new setting and it said 33,90,100. Yet, the events log says it was at the commanded state. Weird. Maybe I queried the state during the ~1 second that it was 33,90,100 before finally changing to the commanded state. That’s a possibility.

Anyhow, it’s acting like autoupdate is set to true, but I can confirm it is set to false.

Okay, this log looks good. The device has (slowly) ramped to where it should do,making interim reports. That’s all beyond openHAB’s control.

Importantly, there is one and only one command.

It was 4 seconds vefore it reached the final value. Easy enough to repeat your experiment and check more than once.

I see absolutely no sign of that.
If autoupdate were in action, it would generate a “predict” event in your events.log in response to the command, and shortly after that the Item state would be changed to the prediction. All within 50mS probably - long before the command even gets to the target device.

Then, a second or so later, we’d probably get an interim update from the device and change it again. And after maybe 5 seconds, another update to final value.

You can always set autoupdate true if you want to, and observe the effect. It will make zero difference to the end result.

Please satisfy yourself this is all working as it should be. When you’re happy, we can revisit the double command that I believe is the root of your pain and looks possible to be UI widget bug.

Okay, I’m slowly getting this. Thank you, by the way, for taking time out to help me diagnose this.

Okay, I’m getting it. The device is giving interim updates as it should, but if Autoupdate was true, we’d see “Item (item name) predicted to become (some state)” in the events log. And I do see that if I set autoupdate to be true. So I think I’m with you there.

Right, and as you said it does not.

Okay, good, I feel like I made progress, at least in understanding how OpenHAB works. So the color widget – I see the effect of the interim reports during the dimmer ramp time. The color widget shows some interim state, and finally settles on the final (commanded) state. You mentioned earlier that this effect was identified and fixed for slider and knob widgets, but may have not been caught for the colorpicker widget. Should I open a ticket on this or is their additional sleuthing here to be done? Thanks!

That is what is supposed to happen, yes.
(The OH server reports changed states to the UI which updates graphics)

Let’s confirm what we got, first.

The expected result of clicking on the colorpicker widget is that one command gets issued to the Item.
Any amount of subsequent state changes or display changes should cause no further commands, only user poking should do that.

The now-fixed bug on knob widget caused it to issue extra commands in response to it getting a new state. That’s not often even noticeable - turn knob to 50%, issue 50% command, get 50% update, get an extra 50% command, who cares.
But it becomes a problem if you get interim values from a ramping device.- turn knob to 50%, issue 50% command, get 25% interim update, get an extra 25% command, all gone wrong.

Now, I’m completely speculating the color picker widget is doing something like that, based solely on the presence on two commands in your original event log - where you didn’t say you clicked twice. (Well, plus the big hint that the 2nd command was hot on the heels of, and value-matched, a state change)

Over to you to demonstrate and clarify exactly.

Gotcha. Okay, here’s an example with the colorpicker widget. I issued only ONE command, the initial command – to change from (248,69,32) to (110,69,32). I did this by clicking on the Hue slider once with the mouse.

Here is the event.log:

2022-01-08 18:59:50.352 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'HutchLEDStrip_ColorControl' received command 110,69,32
2022-01-08 18:59:51.352 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 248,69,32 to 244,55,27
2022-01-08 18:59:55.523 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 244,55,27 to 244,55,32
2022-01-08 18:59:55.538 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'HutchLEDStrip_ColorControl' received command 244,55,27
2022-01-08 18:59:57.835 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 244,55,32 to 244,55,26
2022-01-08 19:00:00.709 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 244,55,26 to 244,55,27
2022-01-08 19:00:01.755 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HutchLEDStrip_ColorControl' changed from 244,55,27 to 244,55,26

Note the second ItemCommandEvent. That was NOT commanded by me. Is this the kind of evidence you need? Let me know what additionally I can provide you with to arrive at a conclusion.

Good enough for me, the “extra” command reflects a preceding state change 200mS earlier, which sounds about right for a local UI round trip.
Made a github issue -

Nice! I feel like I contributed a tiny something to OH now, though you did most of the brain work. Thanks again for your help.

1 Like