HSB Colorpicker sets 50% Brightness when color is "picked"

stagf15 · April 15, 2020, 7:51pm

Hello,

I have a HSB colorpicker that auto populates on the sitemap through displaying a group. When I click on the associated colorpicker, it opens up and always defaults to 50% brightness. If I manually increase the brightness to 100%, it will send the correct command, but it will always snap back to 50%. If I click on any color it will select the correct color, but it will always set 50% brightness.

Here is some background info about this specific colorpicker: It is connected to an MQTT channel through a topic thing. Other colorpickers I have on my setup do not act this way (they seem to act correctly). This is my first MQTT device and first MQTT connected colorpicker. If I comment out the mqtt channel ("{…}") section on the item, the colorpicker seems to work correctly (it obviously doesn’t change the device colors, but the brightness “dimmer” below the colorpicker stays where I put it).

Here is the thing definition:

    Thing topic bulb1 {
    Channels:
        Type switch : power "Bulb 1 Power" [ stateTopic="stat/bulb1/POWER", commandTopic="cmnd/bulb1/POWER" ] 
        Type dimmer : dimmer "Bulb 1 Dimmer" [ stateTopic="stat/bulb1/RESULT", transformationPattern="JSONPATH:$.Dimmer", commandTopic="cmnd/bulb1/Dimmer" ]
        Type colorHSB : color "Bulb 1 Color" [ stateTopic="stat/bulb1/RESULT", transformationPattern="JSONPATH:$.HSBColor", commandTopic="cmnd/bulb1/HSBColor"]
        Type string : colorstr "Bulb 1 Color Str" [ stateTopic="stat/bulb1/RESULT", transformationPattern="JSONPATH:$.HSBColor" ]
    }

Here are the applicable items:

// ----- MQTT (Tasmota) Bulbs -----
Switch      BTL_bulb_1          "Table Lamp"                <light>             (MQTT, Lights)              { channel="mqtt:topic:np603:bulb1:power" }
Color       BTL_bulb_1_color    "Table Lamp Color"          <colorlight>        (MQTT, Lights)              { channel="mqtt:topic:np603:bulb1:color" }
String      BTL_bulb_1_colorstr "Bulb 1 Color [%s]"                             (MQTT, Lights)              { channel="mqtt:topic:np603:bulb1:colorstr" }
Dimmer      BTL_bulb_1_dimmer   "Table Lamp Dimmer [%d %%]" <slider>            (MQTT, Lights)              { channel="mqtt:topic:np603:bulb1:dimmer" }

I added a HSB Color String Channel and Item so that I could verify that the Result being returned by the MQTT client (tasmota bulb) was not in fact the culprit, and it does not seem to be. It returns exactly what is sent by the openhab command, and what the light physically appears to do.

This is a similar question to MagicHome RGB Led with Tasmota, Colorpicker in Sitemap doesnt work, though that thread seems dead and unsolved.

I just want the brightness slider to stay where I put it, and then remain there after I close the colorpicker window. (And also be in the same position the next time I open the colorpicker)

Thank you!

Thedannymullen · April 16, 2020, 1:39am

What browser or app are you using to view the sitemap? Is it browser, iOS app, android app?

stagf15 · April 16, 2020, 2:19am

The problem was noted on Mozilla Firefox (that’s my main browser). However, because you asked, I just tried it on Edge, Internet Explorer and Chrome, and they all acted approximately the same (IE is pretty horrible looking in general though, I guess it’s on its way out?). The brightness slider would “snap back” to 50% after selecting the desired brightness. The correct brightness command would be accepted, but then the next time I try to pick a color it would select that color at 50% brightness.

Edit: I just tried it on the Android App and it works properly, and I also tried it on HABpanel and it works properly, so this seems to be a Basic UI problem.

Thanks for the reply!

stagf15 · April 16, 2020, 2:34am

One more piece of information… If I refresh the page before opening the colorpicker for the item, when I do click on it, the brightness is correct (the current setting) for the first click on the color wheel. Once I’ve clicked, it then snaps to 50% brightness.

rossko57 · April 16, 2020, 9:57am

As per the previous thread, no-one opened a github report on BasicUI. “Just wanting” doesn’t get it fixed.

Trickx · October 21, 2020, 10:51am

I can confirm this behaviour on my setup with

OH 2.5.9
Tasmota driven LED bulb connected via MQTT

While JSONpath parsing of a switch works fine,
the colorpicker jumps back to 50% brightness after setting a color in most cases (but not always).
The command is send correctly.
It seems that the status update is not processed correctly.
JSONpath parsing works fine when triggered externally as well as via the colorpicker:
2020-10-21 12:42:56.995 [vent.ItemStateChangedEvent] - BTL_bulb_1_color changed from 234,100,100 to 105,94,100

Additionally, when I change the color externally and re-open the colorpicker, a white color and brightness of 50% are shown.
My interpreatation is that the communication between the bulb item and the colorpicker is somehow buggy.

My questions:

Was an issue opened at github on this on the meanwhile?
Is there an debugging option (loglevel) to trace communication between item and GUI elements?

rossko57 · October 21, 2020, 11:24am

This is remarkably simple.
Clicky-slidy user actions at the UI generate commands to openHAB Item.
All Item commands are shown by default in your events.log
So for your problem above, a simple events.log extract will do.

Trickx · October 21, 2020, 1:27pm

Via Tasmota’s web interface I set color to red with full saturation and brightness.

The corresponding log looks like this:
2020-10-21 15:12:13.923 [vent.ItemStateChangedEvent] - BTL_bulb_1_color changed from 359,63,100 to 359,100,100
When I open the colorpicker after an reload, it shows correct values:

After changing the color 1 or multiple times, brightness jumps to 50%.

The log does not give any hints in this:
2020-10-21 15:17:01.278 [ome.event.ItemCommandEvent] - Item ‘BTL_bulb_1_color’ received command 238,92,100
2020-10-21 15:17:01.327 [vent.ItemStateChangedEvent] - BTL_bulb_1_color changed from 359,100,100 to 238,92,100
2020-10-21 15:17:05.348 [ome.event.ItemCommandEvent] - Item ‘BTL_bulb_1_color’ received command 116,6,100
2020-10-21 15:17:05.427 [vent.ItemStateChangedEvent] - BTL_bulb_1_color changed from 238,92,100 to 116,6,100
2020-10-21 15:17:08.384 [ome.event.ItemCommandEvent] - Item ‘BTL_bulb_1_color’ received command 46,98,100
2020-10-21 15:17:08.424 [vent.ItemStateChangedEvent] - BTL_bulb_1_color changed from 116,6,100 to 46,98,100
2020-10-21 15:17:09.315 [ome.event.ItemCommandEvent] - Item ‘BTL_bulb_1_color’ received command 303,82,100
2020-10-21 15:17:09.391 [vent.ItemStateChangedEvent] - BTL_bulb_1_color changed from 46,98,100 to 303,82,100

Additionally, when the colorpicker is closed and opened again, it shows a white color:

Closing the colorpicker and reloading the page solves this issue.

So, from standard log events I don’t see a hint why the GUI misbehaves.
I tried to set log level to debug, but I’m flooded with logs in this case.

rossko57 · October 21, 2020, 1:54pm

Okay, that’s good. openHAB is doing everything it should.

That’s not going to reveal anything about what the UI is doing independently.

So, which UI are we talking about? One of the sitemap based ones it seems. If it is BasicUI, everything in that old post still applies. Try it on ClassicUI to see if that is better behaved. The BasicUI colorpicker widget is deficient, and no-one has logged a github issue for it.

Trickx · October 21, 2020, 2:30pm

BasicUI in order to enable the iOS app.

Yes, looks like.

I cross checked it with HABPanel, which works fine.

Does it make sense to raise an issue on github, since OH3 is on it’s way?

rossko57 · October 21, 2020, 2:32pm

Not a fair comparison since it does not use sitemaps.

I would say so. Might be a trivial fix. Might get ignored “won’t fix”. Might have carried forward the same code in OH3 UI.

Trickx · October 21, 2020, 6:07pm

Github issue: https://github.com/openhab/openhab-webui/issues/427

elcosomalo · October 13, 2022, 5:41pm

Two years later (almost 3) the color picker is in the same situation.
Is it there any other way to choose color from the sitemap? sliders? something?

Lolodomo · October 14, 2022, 11:14am

There were no contribution during this time to replace the existing color picker.

AndrewFG · November 17, 2022, 7:55pm

See this [BasicUI] HSB Colorpicker sets 50% brightness when color is “picked” · Issue #427 · openhab/openhab-webui · GitHub

=> can you please let us know if your items have a state presentation part in their labels?

elcosomalo · November 17, 2022, 10:23pm

Color	LuzRGBHUE     	"Color luces RGB TODAS"        	                <colorlight>  {channel="mqtt:topic:local:RGB:LampRGB", channel="mqtt:topic:local:RGB2:LampRGB2", channel="mqtt:topic:local:TV_RGB:LampRGB3"}	
Switch	LuzRGBSwitch    "Switch luces RGB TODAS"    	                <lightbulb>	  {channel="mqtt:topic:local:RGB:LampSwitch", channel="mqtt:topic:local:RGB2:LampSwitch2"}
Dimmer  LuzRGBCT        "Temp Fria/Calida TODAS [%d]"                   <lightbulb>	  {channel="mqtt:topic:local:RGB:LampCT", channel="mqtt:topic:local:RGB2:LampCT2"}
Dimmer  LuzRGBbrillo    "Brillo TODAS"                                  <lightbulb>	  {channel="mqtt:topic:local:RGB:LampRGBbrillo1", channel="mqtt:topic:local:RGB2:LampRGBbrillo2", channel="mqtt:topic:local:TV_RGB:LampRGBbrillo3"}

AndrewFG · November 17, 2022, 10:33pm

elcosomalo:

Color	LuzRGBHUE     	"Color luces RGB TODAS"        	                <colorlight>  {channel="mqtt:topic:local:RGB:LampRGB", channel="mqtt:topic:local:RGB2:LampRGB2", channel="mqtt:topic:local:TV_RGB:LampRGB3"}

Ok. That destroys my hypothesis

AndrewFG · November 18, 2022, 10:01am

@elcosomalo is it correct that you have these four separate channels? If so then the problem is perhaps not in the color picker but rather in your channels themselves.

In particular if you have one channel that is RGB, then you need to be aware that this does not contain brightness information. An you have another seperate Brightness channel that does not contain colour information.

By contrast the OH color picker contains BOTH color and brightness in one channel. This is encoded as an HSB value. So if you want to use the color picker, the you need some way that converts your input RGB color value together with your input brightness value to create a single combined HSB channel whose data can be used with the color picker. You will also need to split the HSB output of the color picker into two parts that you send to the device as RGB and brightness separately again.

There is a similar issue with the Color Temperature. A white lamp can have a Color Temperature (cold … warm) which represents a very specific locus in the RGB or HSB color space. Whereas a full color lamp has a large range of capabilities. Normally you can/should only use either CT and brightness, or RGB and brightness, controls on a given lamp. Mixing them up does not really make any sense.

EDIT: and can you please explain how your items seem to be connected to two mqtt channels?

elcosomalo · November 18, 2022, 12:15pm

Names are just “RGB” because that’s what the lamps are after all. I’m using the “Color” type so I think thats enough. I’ve tried ColorHSB but I also had the problem with the color picker.
Two of the lamps are RGB + CT. One is a led strip with no CT.

EDIT: and can you please explain how your items seem to be connected to two mqtt channels?

Simple, they control 3 devices with one single item since I want all those to have the same values.

AndrewFG · November 18, 2022, 5:14pm

I am frightened by your use of the words “just” and “simple” … you think it should simply just work but evidently something doesn’t… ??

How does the item look in the main UI (e.g. below)? Do you have valid values for all three HSB elements (H=0…360, S=0…100, B=0…100)?

And to be more specific, if you use an external manual control of the lamp, do the respective values move on the UI? If any of the values are ‘stuck’ this tells you that the problem arises from how the channel reads your data from MQTT…

Hmm. I would nevertheless advise you to use one item per channel, at least until the issue is resolved.