What is string format for color attribute?

[jtp10181]

Looking at another driver it was setting the color attribute to the hex code of the color, which I thought made sense so I was trying it out. Noticed after doing that the "setColor" color picker would always just show black [0,0,0]. After removing the color attribute the color picker is back to using the hue, sat and level values. The RGB attribute seems to have no effect on the color picker.

If I can control what the color picker is showing via the color attribute this would be awesome and is functionality I asked for in the past! I just need to know what format it is supposed to be set?

Docs are vague.

[kewashi]

The color string is in form:

#rrggbb

Where rr is the hex value of red, gg hex value of green and bb hex value of blue.

The hsl values are color fields with h being hue on a 0 to 100 scale as opposed to the typical 0 to 360 radian scale.

s is saruration and l is light and both are on 0 to 100 scales like h, but that is standard for these parameters.

I have functions in HousePanel to convert back and forth from rgb to hsl so let me know if you need that.

[bertabcd1234]

I don't think this was ever actually standardized. I know it's in the capability docs (likely a carryover from ST), but none of these example driver seem to use it at all from what I can see:

• HubitatPublic/virtualRGBW.groovy at master · hubitat/HubitatPublic · GitHub
• HubitatPublic/GenericZigbeeRGBWBulb.groovy at master · hubitat/HubitatPublic · GitHub

Where it is used, I have seen hex:

• HubitatPublic/LifxColorBulbLegacy.groovy at master · hubitat/HubitatPublic · GitHub

But I'm not aware of any actual conventions for this or anywhere in the platform that relies on this data (and it's nothing that effectively could not be computed from the other attributes, like hue, saturation, and level).

[jtp10181]

Ok I see the example in the Lifx driver. That is exactly what I was doing, setting it from the output of the rgbToHEX function (just had mine saved to a string variable first).

@support_team So is this a bug then? When I set that it break the color picker. I would really LOVE it if the color picker would pull from that color hex value instead of the h/s/level attributes, thats what I am hoping it is trying to do.

This RGB controller, along with others I have worked on, the actual "level" is separate from the RGB values. So when you convert RGB to HSV/L you have no where to save the last component of it. I save the actual level reported by the device to the level attribute, which then gets used in the color picker and makes it incorrect most of the time. I beat this to death before, so I wont do it again, but that's the gist of it. If the color picker for setColor could pull on another attribute it would solve the problem.

First set the device:

No color attribute:

Color picker after refreshing the page (using incorrect level value but still shows a color)

---

Bug - set color attribute:

Color picker defaults to 0,0,0

[gopher.ny]

[hue:0,saturation:0,level:100] is the format.

[DubbyDad]

Definitely belongs in the Dev Docs. No such thing as too much specificity there, IMHO.

[jtp10181]

Ok thanks, I almost was going to assume that but didn't feel like stabbing in the dark for hours!

[bertabcd1234]

@gopher.ny

[hue:0,saturation:0,level:100] is the format.

Can you point to any built-in driver that actually does this? (For real, I can only find ones that don't -- doing either nothing at all or another format, like above.)

[gopher.ny]

@bertabcd1234

Can you point to any built-in driver that actually does this?

This is a composite attribute handled by UI. Drivers have hue, saturation, and level individually.

[jtp10181]

@gopher.ny I cant belive this works now! I thought it was a lost cause a while back but I guess it got fixed somewhere and I never knew about it!

Now I need to go fix the other drivers I have messed with that needed this before.

For the record here is what works. This is sending the value as a map, which then goes in as a string in a sort of ugly format with { } but it works so I'm happy.

List hsv = ColorUtils.rgbToHSV(rgb)
sendEvent(name:"color", value: [hue:Math.round(hsv[0]), saturation:Math.round(hsv[1]), level:Math.round(hsv[2])])

You can see the color picker is now using the correct "V/L" value and not the level attrbiute! YAY!

---

Tried to make it look like a map by setting a string but this does NOT work:

sendEvent(name:"color", value: "[hue:${Math.round(hsv[0])}, saturation:${Math.round(hsv[1])}, level:${Math.round(hsv[2])}]")

NOT WORKING Like this

[bertabcd1234]

@gopher.ny

This is a composite attribute handled by UI.

Does this mean it's implicitly available even if never sent as an event? I've never tested that. But it's definitely absent from the UI in many drivers (and a in a different format in any i can find that do), even ones that do this as any color device should:

@gopher.ny

Drivers have hue, saturation, and level individually.

[jtp10181]

Yeah I have no idea what any of that means either but I set it manually in my driver and it fixes the color picker. So happy!

@bertabcd1234 you really only need this for RGB devices that handle the RGB values and level (brightness) separately. Which includes this ZEN31 I am working on, Govee LED strips, and possibly my Tuya Wifi LED strip also, I will have to revisit my drivers.
For example you can set R to something like 125 at 100 brightness, but it will be dimmer than R of 255. Or you can set R to 255 and the brightness to 50% with similar results. Or you can set R of 125 and brightness of 50% and it will be even dimmer yet.

If the device uses HSV/L only, or adjusts it brightness only based on the RGB to HSV conversion internally then setting the level as the "L/V" value would work fine.

[kahn-hubitat]

My garden hue app uses hsl

def newValue = [hue: hueColor, saturation: saturation, level: 1]
hues[which].setColor(newValue)
hues[which].setLevel(blevel,fOnTime)
}