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

Tags: #<Tag:0x00007efedde053c0> #<Tag:0x00007efedde05280> #<Tag:0x00007efedde051b8>

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!

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

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!

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.

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

1 Like

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?

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.

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.

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.

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?

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.

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

1 Like