RGB (again)

🚧 Developers
1

Greetings.

So, for quite a while I have gotten into the habit of buying RGB/RGBW/RGBCT/RGBWW and using them as single rails. One RGB controller can power 3 dimmable bulbs just fine. Especially since other automation systems, like DMX, simply works in "channels" and it's up to you to group them. I routinely use these channels to power dimmable stuff, like fans and lights and motors. It's very financially efficient.

I think you see where this is going.

So, I bought a zigbee RGBWW controller, all is well, except, well, the RGB controller is HSB. This is an issue because:

a) H, S, B appear to be round. At least in the UI, maybe Maker API takes decimals, but the browser uses round numbers, meaning 255x255x255 (16.7M) is now 100x100x100, which is 1M. That's quite a bit of precision off. Pile onto this that some RGB lights don't even turn on under 5-7% and the pretty much peak at 50%, and I could have used that precision.

b) I can read Green and set Green in a RGB environment. In a HSB environment, I have to read H, S and B and then do math and then resend them, meaning that not only do I have to be aware of channels that really shouldn't have to change, but also that I may lack the precision to keep the other channels where they were. Because of rounding, I have no guarantee that the green channel will stay at 7/255 as I send another HSB value. If green is powering something that physically moves, I'm in for all kinds of fun.

I have seen that Hubitat supports a virtual RGB light. To my utter disbelief, a virtual RGB device takes no RGB and gives no RGB. This, in my mind, is ridiculous. I should be able to set up a vRGB device, work with R, G, B and it can sync its color to whatever is internally deemed as standard. I won't question it, I'm sure there was a reason.

This brings me to the Maker API.

"color":"PaleMoonlightSadness"

I own 5 soldering irons and 0 paintbrushes. I don't know what that is.

I was brainstorming and I figured that, at least one way, I could have some variables, expose them via Maker, and then have some sort of automation, either via rules or via external app. Basically, have a Maker interpreter which, OnChange for variables, would math and send HSB, but it seems like overkill. I'd have to do math over HTTP. That can't be good for efficiency.

Another way forward for me would be to just use one channel out of five. This would quintuple my hardware costs, but I could set them to "blue" in UI and then just work with device and brightness. I would also take the resolution hit because Saturation is gone.

So, can I have some input, please? Can this be a driver? Does it have to be Hubitat supported, or can this be done via community? What is the way forward?

1 Like
2

I have run into additional problems.

One of the RGB devices I tested with has a bit of a RGB gap. Basically, each color gets used and thus fades in time, at different rates. Meaning that teal-blue RGB bands have a lower blue output, making "white" actually a kind of reddish.

My RGB home system has a system that compensates for this, but, even without it, to set this to white, I just set it to white and then pull back on the red a bit.

I have tried to do this with Hubitat and have run into a bit of an issue. You see, when set to white, then it's reddish, cause burn-in. However, when trying to set a very light teal (my brain says light teal is the correct color) it simply goes into "teal" mode and it basically turns off red. I tried to set saturation quite low, but even at 10% it is distinctly teal.

Basically, when set to teal, it's in teal mode, and when set to white it's in red mode. And just to make sure my brain isn't the issue, I used the Hubitat desktop UI which allows for RGB input.

Below is 27,28,28 and 28,28,28 in RGB side by side. I used a pro camera and adjusted the color so a regular screen sees what I see not what a camera thinks of it. The pink is a bit too pink, but the difference is indeed this stark.

RGB
RGB800×280 30.6 KB

And before you say it, I have checked that R, G and B produce pure colors and they fade correctly. LED band fades correctly. Multimeter reports correctly. I thought maybe the controller was busted. I even made sure to reset it and to move the RGBCT to RGB + 2 dead channels in case it had some internal logic to correct for color temperature using the RGB (I use this trick).

And then I was clicking around idly and saw the log.

image
image1199×321 49.8 KB

The good news is, it indeed has produced what it has set out to do, namely 11% cyan and 11% red.

The bad news is, there's barely any nuance to RGB. It basically has 6 colors.

If this is down to the Zigbee protocol, then I am up a creek. I could use this as a centerpiece, seeing how "button make color go brr" is impressive, but I have a certain color I find pleasant and use everywhere and Hubitat can't do it. It gains a bit more resolution if I up the power, however, I'm not sure I want to see my own circulatory system every time I go next to it.

Even at 100%, 0, 200, 200 is teal and 0, 200, 150 is distinctly greenish. It has decided it is Hue 50 and Hue 46 and basically nothing changed. This means that using API to set RGB isn't going to help.

Also, I looked it up. Single color controller, 18€, 5 channel controller 19.50€. I'm basically better off buying the RGBWW just to use them as their own spares if a channel goes.

4

This is something i have had to deal with allot with my Govee Integration. What it goes down to is Hubitat is a HSB/HSV system, and any other requires conversions. Hubitat does have tools for that though. If you go down the path of creating your own driver you can use the Hubitat tools to perform conversions. The documentation for the object needed in the driver can be found at the link below

https://docs2.hubitat.com/en/developer/colorutils-object

Govee has been a real pain with this as i have 3 different methods to manage, and you are right that there are conversions problems. Because of rounding the values do move slightly as they get converted back and forth. There is also the confusion that the b or v in HSB or HSV doesn't directly translate well to brightnes or level in some cases and more crude happens. Feel free to review my code for the Govee Integration if you want to see how i manage the conversions it isn't perfect though.

Something else to consider is RGB is just way to distinguish color. As i went down this rabit hole trying to figure out how to handle this stuff with my driver and as i was thrown curveballs by Govee i found many different scales used to create a color. I honestly don't know enough about any of them to say if one is better then the other, but just know they are different. That said you can certainly put a RGB value into Hubitat on the device screen when a color is entered/selected via the color picker. If you have the raw numbers you can simply input them instead of selecting from the gradient option displayed.

3 Likes
5

I have generally found a lack of nuance being a problem with the strip or controller. Is this new gear you are trying for the first time, or is this old gear you changed the controller on to use with Hubitat and it has lost the ability to provide the color you are looking for?

I would certainly argue that controller makes a big difference and there are a ton out there.

I suspect the problem isn't that hubitat can't do it, but that the controller and strip together can't figure it out.

One change i made in my driver that varies from the Hubitat default RGB drivers is i don't consider the V/B of HSL or HSV as brightness. I do the conversion from Hubitat's HSB value and send that to Govee. Then I submit another command to set the brightness to 100%. This helps preserve the brightness of the converted value.

2 Likes
6

Frankly, this set of posts were more of a self-check, as I couldn't believe that I haven't made a terrible mistake. I'm still not sure. It felt that at any time someone will say "duh, use RGB setting in hubitat" or someting like that.

I can do it in code, this isn't the issue. I've seen the hex setting that takes RGB. I know how HSB is done. None of these are an issue. As posted in my second part, I used hubitat's RGB UI to set it, it's not that it's HSB, it's that setting RGB doesn't help with my 2 issues.

Making a RGB call would mean that I have to track R, G and B just to change R, and that it internally converts it, so it solves nothing. The limitations are still there. Colors still don't listen to me.

I would rather be beaten in an alley way and have my pizza stolen. I have written and soldered my own smart home.

I am aware of the limitations with RGB, as my own built system has been working fine. In fact, if you want color control, here's how I fix it: Each device that has a channel, be it single (LED) or RGB (3 LEDs) and so on, all have a percentage and several settings: S0, S1, S20, S40, S60, S80 S99 and S100. These have values you can set for when the percentage is 0, 1, 20, etc.

The reason these exist is so you can have 0 to be 0V (and no consumption), but 1% could be 30/255, as this is the minimum light on. Then, for every value between, the output value is interpolated, as you measure it with a lux meter, allowing for calibration of all devices. I personally mix 3, 4 and 6W spots and nobody can tell. Another reason for 0 and 100 is that these are the only values if the device is on-off as opposed to dimmable.

These keep colors defined no matter the use and model. You can also count on-hours and up the limits as the LEDs have burn-in. All you have to do is re-set the white point at every 20% and the color maintains over the entire span.

I know how to do it, I just wasn't expecting such a valley between, say, thermostats and a whole rule logic system and ... setting a color.

1 Like
7

The controller is new, because ZigBee, but the strips are old enough to have burn-in. But as I show in the logs, how can I blame the controller, when 27,28,28 RGB is logged by Hubitat as "cyan, 11%" and the strip is cyan, 11%? And 28,28,28 is "white 11%" and the strip is white, 11%? It's not the controller's fault.

And I guess I was thinking out loud, mostly. I know what the solution is, I was just kind of hoping I am missing something obvious. I actually thought there was a RGB controller already done.

As for the actual solution, well, the math is very clear.

The cost of ZigBee controllers for what want far exceeds the cost of a dude with a drill. As much as I loathe to modify the last room in the house, because of the way it has to have its wires, the way forward is to extend my current wired solution, which is 485 (DMX).

At least a wired controller, for only one extra cable, provides 24 channels with independent control.

I've used this for every other room. Tine to stop being lazy and start laying cable.

9

I am not sure that proves anything. The color name doesn't really mean anything, it is what the output is. changing that value to 27 does appear to push the color toward Cyan a little bit. Just a very dim level of it.

There is certainly some rounding in the values with the conversion though. I think you are spot on when talking about running the controls from your DMX setup though. I really don't think trying to get Hubitat to match what that platform can do is very reasonable comparison.

1 Like
10

Oh, I know what the solution is. I just didn't expect for a RGB controller which has 3 channels to not be usable as just 3 independent channels. This has never happened to me in any system ever, from wifi controllers to DMX to DMX/ART-NET to regular custom built 433MHz. It has always been possible to use a 3-4-5 channel controller any way you want.

The solution is to use wires, a DMX controller and a DMX sender via USB (requires software) or via ART-NET (can be done in network). The ART-NET is a bit more expensive, but mine can control 8192 devices. And with a device in every room, 24-32 channels are enough to run anything. In fact, they are modular, you just add more channels.

It does require out-of-hubitat software, but it's not hard to do.

1 Like
11

You have a RGB controller and a LED band and moving from 27,28,28 to 28,28,28 only changes it a little, or do you mean in the UI?

12

I have Govee Devices with their included controller. Specifically i do most of my testing on a Govee Glide Hexa Pro device. if i set from the UI to use RGB 27,28,28 it displays a mostly white color. When setting it to 28,28,28 it changes ever so slightly. It is clearly a very slight change in the cyan/blue output, but not much. Keep in mind my driver doesn't work like most default drivers on Hubitat. Hubitat mostly uses the last value in their conversion from RGB to indicate brightness/Level. I don't do that with govee devices. I let the conversion process as normal and then set the brightness on the Hub to 100%. Govee devices function with RGB Values and not HSL like the Hubitat hub.

So in my case when i set the UI to 27,28,28. The UI converts that to HSL and then passes that into the driver routine. In the driver that value is then converted back to RGB with Hubitat's built it tools. The key is now at this point the converted value being passed to the Device in RGB already includes brightness based on the various rgb values. So the driver then sets the device to 100 % as the RGB value will put the brightness to what was really requested.

The result when comparing the values you provided are that the output is very slight. Both near white with the one leaning toward a slightly more blue color because of the setting used. They are also very dim compared to what the device can put out so i think 11% is spot on. I don't really trust the colors being assigned as every device is different in how well it generates colors.

Specifically, to answer your question if it wasn't clear above. It is very slight change. If you don't watch the device when you click on the command to apply it you may not even see it. It is a very slight change, but noticiable if you are watching it as the command is executed.

13

What is your RGB controller make / model ?

2 Likes
14

It's a generic, find-everywhere device. I think the label says Miboxer, but the design and specs are everywhere on the web. Amazon sells them by the boatload.

And I do not have a red offset issue, the color mismatch is secondary.

What I was hoping for is to access channels individually. Also, I'm playing around with the device.

In web interface:

SET RGB to 0, 255, 150. OK, this makes it 44, 100, 100 HSB, which is 0, 255, 163 when opened back. I did the math. 0, 255, 163 is indeed 44% into Hue, which is 158. Seeing how the step is 3.6 and rounded, the next HSV value is 43, which is 0, 255, 145.

Wunderbar. Either because I do HTML or the hubitat itself, my green resolution is 145, 163.

Let's try the Maker API.

Maker HSB works, but it's HSB, same limitations. All 3 channels at once, low color resolution.
Maker RGB, however, get more interesting.

553333 is interpreted as 0, 24, 27
335555 is interpreted as 0, 25, 27.

Well that's weird. Turns out, "java.lang.NullPointerException: Cannot get property 'value' on null object on line 517 (method parse)" on the second line but not the first.

so it hates some values.

The docs state that
image
but this is incorrect and generates issues. The correct version is of course
{"hex":"FF0400"}
which, when encoded, works, in the sense that it takes a RGB and makes it into an HSV, with the same limitations.

It takes 553355 but not 335533. If it starts with a 3, it hates something. I suspect there's some error rattling around in the parser.

curl http:///apps/api/14/devices/11/setColor/%7B%22hex%22%3A%22335533%22%7D?access_token=X generates an error despite the fact that AFAICT the URL is decoded to {"hex":"335533"}

This is just a bonus, though. Accepting RGB and putting it into HSB is just a convenience.

1 Like
15

Anyway. Like other have said, I am too far down a rabbit hole that is meaningless. Here's the gist:

a) Hubitat appears to be HSB and that's that. Until (and if there's ever) a rewrite, this is nailed down.

b) Hubitat uses 0-100 for Hue, apparently internally. This lowers H resolution to 3.6 degrees, or 4 if rounded, and that has DRASTIC effects on certain spots, especially when dimmed down. This is especially visible if you have a powerful device that is expected to hover low, rather than a bulb that pretty much hovers around designed power.

c) There is no way to use a RGB controller as 3 separate controllers with 3 separate controls AFAICT. Seems simple enough but I know nothing about what is under the hood of Hubitat. If important integration relies on HSB, I'm probably never getting it.

d) Either use another system and send commands or live with the gamut. It's probably good enough if you think color and nuance is basically the same.

e) Maker API doesn't offer more resolution and the RGB extension is a courtesy (and might have a few bugs).

f) The fact that having a fixed hue ("color") and sending it "more" and "less" is probably more user-friendly, means that the HSB is unlikely to change. High-definition color is probably out of scope. I still hold hope for a 3-channel approach to RGB, but if this is the case it might be hard to do universally. We may be looking at a compromise and it's hard to blame anyone for this.

As far as I am concerned, I have dug as deeply as I think is reasonable. I'm marking this as closed. Thank you all.

1 Like
17

Thanks for that, but from what little I understand, and it's very late for me, but the device is very nice and has its own channels and commands. I don't know enough about my cheap device to do that, and the Z31 is discontinued. It appears to have retailed around 60€.

If I ever get into writing drivers, who knows. For now, I'm in my own world, swearing at a line buffer that runs in a different thread and sometimes eats a Maker API line.

1 Like