# What formula does HE use for HSL to RGB?

What formula does HE use to convert HSL values to RGB? I have an hsl of (55,94,100) and hubitat says that is RGB (15,83,255). Every single online converter and formula I've found says it is (255,255,255) so what formula is HE using?

The problem seems to be because of the scale HE uses. Hue is normally expressed in degrees (0-360) but HE measures it 0-100, so what's the conversion you guys use? I can't imagine it's just a linear conversion? On top of this I believe the minute L = 100 it's white... but in HE L is 100% and it seems it doesn't apply somehow?

I think it is what you imagined. I believe that they use a percentage for all 3 values. For example, in order to program my LEDs to red, the HSL is (0, 100, 50) and for white it is (0, 0, `100)

But the level my device currently says is 100%. Always. Because that’s really the dimmer value. HSL the L is “lightness” not “dimmer level.” From what I can tell I can read the H and the S but the L is hidden?

What I’m trying to do is determine the current rgb color of the bulb. Do I have to do it from the temperature?

How are you converting to HSL? Hubitat has an `hsvToRGB()` method (for HSV), but I'm not aware of anything built in for HSL. HSV and HSB are the same, but HSL is different, so if you are getting unexpected results, that is likely where this is coming from.

You are correct about the other piece: Hubitat's default hue model scales values from 0-100 as opposed to 0-360 (some drivers offer a "high-res hue" option that is 0-360), and as far as I've seen, that is indeed a linear conversion (just multipled or divded by 3.6).

If the question is indeed about Hubitat's built-in HSV conversion, what I've seen with that matches what I've found with online converters. One example--though I didn't run this one through Hubitat to check (55 * 3.6 = 192.5 ~= 193, so that's what I'm using here):

Note that I am not a color model expert, but the above is some of what I learned when trying to convert from CIE "xy" color to Hubitat's HSV model. This is, apparently, difficult to do accurately and is something I'm still trying to figure out (I can get it to reliably reproduce conversions I've found online--and to match what Home Assistant reports for the same devices, which apparently no one is complaining about--but many are still poor approximations for the actual colors produced by the bulbs I'm writing the driver for, so not really useful in the real world). Hopefully some of it is helpful to you, too.

1 Like

My finding was that Hubitat uses HSV even though it appears to be labeled HSL in the attributes (which creates confusion with the SwitchLevel dimmer related attribute for level). And that hue is expressed in the range of 0..100 instead of 0..360, presumably for legacy ST consistency.

With those things taken into consideration, I used the conversion formulas from the wikipedia entry for HSV and HSL and then later confirmed that the Hubitat conversion libraries give the same results when performing conversions.

More chatter here from a previous discussion: Shelly RGBW2 doesn't respond to Hue commands

2 Likes

If you want to use rgb values to create whites.. Check out my community rgbgenie code.. I used rgb led strips to give full color temperature white control with no white element..

In this video.. I have a RGB only strip

It's kind of tedious, but I just convert between HSV, HSL, and RGB, maybe multiple times and depending on what info is available at a given time.

For example, Shelly bulbs report their color in terms of RGB and expect updates in RGB. Hubitat uses HSV. Other inputs may give HSL.

So, for example if I need to handle a setHue command, I may need to query RGB from the device or use the cached RGB attribute and parse values out. Then convert it to HSV to get the current saturation and V values, then setColor with those values plus the new hue, which ultimately converts the new values back to RGB before setting them on the bulb.

If anything, it gave a good excuse to experiment with unit testing on Hubitat.

Thank you! I didn't notice HE uses HSV. The reason I was saying HSL is because that's what the UI kind of implies:

All I'm trying to do is take the current color of a bulb and display it as an RGB color in a custom dashboard I'm building (I'm at the point where, unfortunately, I've given up on the built-in dashboards and decided this was as good an opportunity as any to learn React).

Thanks all, once I realized it was HSV not HSL, all good (`colorsys` is an awesome JS library for converting various color formats fyi).

I'm slowly getting this new dashboard idea to come together:

2 Likes

Sorry for bumping up the thread.

I'm making a custom driver for RGBW device. And while testing I found some weird inconsistency:
It seems to me that Hubitat dashboard is using HSL color space (the one with the most saturation at half the brightness level) while a color picker in the driver page is using HSB (with the most saturation at the highest brightness level).

Am I missing something?

That looks right, though it looks like Dashboard actually displays both RGB sliders (below) and HSL sliders (above, plus the very bottom). So, the device page and not Dashboard is a better match for the "raw" values that the device actually uses (HSB/HSV), but Dashboard just happens to display different UI options to get you there.

Before sending the command to the device, Dashboard will convert to HSB, as that is the format that an app must use when sending commands to the device via the standard methods. Given both this and that there is an easy and reliable conversion among all three models, this shouldn't be a problem, and it's definitely not something you should notice on the device/driver side--the app just happens to use a slightly different UI (why, I can't tell you...).

Not sure if you're writing a driver and trying to troubleshoot something or if you were just curious, but either way, that's what it looks like is happening to me! (An unfortunate side effect for regular uses is that they can't use the device page to figure out an HSB value and then use RGB or HSL on the Dashboard to re-create the same, at least not without converting first.)

Well.. That behavior would be fine for me)

But when I set HSL values on dashboard to Hue=0, Saturation=100, Level=40 (numbers for better illustration) I see 80% of 'red' on the dashboard itself and I see 'Level=40' is passing down to my code without any conversion.

The value from drivers page color picker also passing without any conversion as is. I can see it in logs.

At least I know now that HSB is the working colospace (that I can rely on as a proper one) Would be nice to mention it in the developer documentation in parameter description of the 'ColorControl' capability.

That is supposed to happen: the color picker on the device page is HSV/HSB, matching the underlying standard color model of Hubitat.

If Dashboard is sending un-converted HSL values like it's HSV/HSB, then...that seems odd. I was not able to replicate that in my admittedly minimal testing. For example, setting to HSL 72, 66, 33 on Dashboard sent `setColor(20,80,55)` to my device, according to my logs:

This is about what I would expect based on HSL to HSB conversion, plus the fact that Dashboard uses the standard 0-360 (degrees) model for hue, where as Hubitat's default (and my device) will scale this to 0-100 (percent, I guess?):

If other values are not working as you expect, perhaps they are using an HSL to HSV conversion algorithm that is incorrect (in some cases) or at least does not match your expectations.

EDIT: OK, I do see some unexpected things for other values. Not sure what exact conversion they're doing, but it does seem that they at least didn't make the mistake of treating HSL as HSB/HSV:

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.