[mainui] [colorpicker] don't send commands on external state changes

[Rossko57]

OH 3.2 M4 MainUI

This is essentially a repeat of [https://github.com//issues/789]#789 which was for knob widget, but here for color picker widget.

When the Item state updates and causes a change in widget display, unwanted commands are generated as though by user action.
This is a particular problem for slow-ramping devices issuing interim updates - the interim state update causes a new command to be issued to match the interim state, and the original command is trampled over.

Detail discussion in community here
https://community.openhab.org/t/colorpicker-with-zen31-controller-bounces-around/131390

Most essential data, events.log following single user click on picker

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 especially second Item command, values matching earlier state change.
(I presume we don't get a command on every change due to widget throttling.)

[Argurth]

On a page, I have an oh-colorpicker controlling a philips HUE group.

If the page is opened on a browser, and if I light on one of this group's room using a wall switch, I can see, on my browser developer console, a POST that update the color of the group (for exemple, 221,0,1), resulting in all the rooms of this group being lighted on.

The color sent is always a gradient between black and the target color, or between the actual color and black if the update is triggered during a switch-off.
With multiple room, it become impossible to turn off the lights (as when you successfully switch off a room, switching off another room can trigger the problem again and light all the rooms).

If my browser is closed, the problem is not present.
If I remove the colorpicker from the page, the problem is not present.
As soon as I add the colorpicker again, the problem come back.

I don't seems to have this problem with the switch or slider widget.

I suppose this is linked to this issue, as it look likes that when the room turn on, the group color state is updated and propagated to be displayed on the oh-colorpicker widget, but then the colorpicker widget seems to be sending a command to update the group value, resulting on the new value being applied to all the rooms.

What is weird is that this problem started to appear when I upgraded to OH4.
This github issue is opened since OH3.2, so I should have been affected before, but I don't remember having it on OH3.4

[arins]

I have the same problem. When I update the color from zigbee2mqtt I can see the color jumping around in UI. UI is sending the commands without the user changing the color from UI but the commands are probably from the state change. I think this is a bug because color picker should NOT send commands on state update.

[mattventura]

I have the same issue with my Sengled color smart bulbs. They support both RGB and color temperature. If I put a simple on/off + temperature slider on the page, it works fine. If I put only the color picker on the page, it also works fine. But if I put both of them on the page at once, the RGB controller will trample over the updates from the on/off and color temp controls.

[digitaldan]

@florian-h05 this one is biting me in the butt as well, i'm developing a new binding that supports color, and i thought i was going crazy that every time my color item was updated, it would also then receive a command 2 seconds later, in an endless loop over and over again. Turns out i had the Main UI up on one of my many browser tabs and the color picker widget was sending a command 2 seconds after getting an update

openhab-webui/bundles/org.openhab.ui/web/src/components/widgets/system/oh-colorpicker.vue

Lines 111 to 114 in 9791035

	setTimeout(() => {
	this.updateValue(this.pendingUpdate)
	this.delayUpdate = false
	}, 2000)

I don't know if you maybe have an idea for a fix, if not i can take a look later in the week. Thanks!

[florian-h05]

I know this type of problem, super annoying that Framework7 components only have change events, we would need an input event.
I don‘t have a exact idea, I think it might help to have a look at my work in #1894 and #2096.