2.2.8 Color Map is broken in web interface NaN?

[jtp10181]

Continuing the discussion from Release 2.2.8 Available:

I went to revisit my driver I was working on to find the color map seems to not load a color from anything and starts off as NaN for all values. I tested using the Virtual RGB Driver in case my driver was causing the issue.

Set the color:

Refresh the page:

Here is my rantings about the issues with the colormap implimentation:

How to handle LED strip and keep color separate from brightness

As a temporary solution I have set the driver up to use a custom attribute 'brightness' for the brightness so the level can be used for the HSV values which drive the color picker. Doing some research on Smart Things with this the info I found seemed to point to the color picker on ST only using the HUE and SAT values which also seems to coincide with how the LED strip app works as well. I am still thinking there should be some formula where I can take the RGB values and the brightness from th…

[bertabcd1234]

I've noticed this too, but I don't know if it's new in 2.2.8--I do remember seeing "NaN" in the color picker before, but that may have been when the device was new, before the attributes that comprise the color map (hue, saturation, and level) were populated. Regardless, it does seem like the picker could be pre-populated with the color if all parts of it are known, as they are in your screenshots.

As for the colormap implementation, the issue in that post seems that your device is reporting brightness/level separately from color, which is odd since an RGB value includes brightness as in inherent part of the set of values (e.g., 255, 255, 255 is white at 100%; 128, 128, 128 is about 50% gray, and...it gets more complicated for other values because of perceived brightness of R, G, and B, but similar idea ). I don't think this is a Hubitat issue--my biggest question is what the device means when it reports these separately. But one oddity on the Hubitat side is that "level" is called that when the color model--including the components of the color map--are the HSB/HSV model and not HSL, so just some non-conventional terminology (and range of values, though easily/linearly scalable to whatever conventional range if needed).

[jtp10181]

So its hard to explain, the device basically uses a Hue / Sat only color picker. And then a separate brightness slider. I believe this is the correct implementation for a color bulb. This also appears how ST had it implemented from the research I had done before (the color picker was H/S only). Not sure why the device converts that to RGB for its API reporting but thats what it does... If I do set the Hue and Sat to say 0,100 which sets the device to 255,0,0, then set the JUST the level to something like 10, and then refresh the device still reports back 255,0,0. So even though it is reporting the RGB, one value should always be 255 since it using only the Hue and Sat to create it, it is not taking into account the brightness to figure the RGB value it reports back. Not sure if that makes sense but it makes sense in my head

If the color picker on Hubitat could just use an alternate attribute for the 'v' somehow I would be a happy camper!

Example of color picker, notice there is no dark tones because you can only set Hue and Sat:

Also playing with HomeKit now and it has the same setup, a H/S picker and then a brightness slider. As does the interface in Alexa, it only allows you to pick full brightness colors and then adjust the brightness with a slider.