Adding a parameter would break drivers that expect only three if you pass a fourth, which would be every driver out there right now (and would require a change to the capability as it currently is documented). EDIT: Wait, you mean in the map, not a separate parameter. That I could see...
The proposed RM fix is probably a good compromise. If you turn on high-res hue, just be sure to know what you're doing. If you don't, keep it off and use the drop-down colors (which already don't work for 360-degree hue, again because I'm guessing there's no standard way for an app to know whether a driver has this setting enabled...and I'm guessing most other apps don't work well with this either). It's probably something you should enable only if you have a specific need and know what you're doing. I'm guessing Hubitat added it to a few stock drivers due to specific requests or to experiment with other ideas for a newer, unfinished color capability model.
As you suggested, I set a custom action for my Sengled element color plus bulb, but it doesn't seem to work:
When I hit "Run Actions" on this rule, the first and third actions work but the action in the middle (setColor(50,98,75) on Sengled Lamp) has no visible effect on the bulb.
No, I was wrong--I mentioned this later but forgot that setColor takes a map (a parameter type that RM doesn't let you input), not three separate values.
However...firmware 2.1.7.121 was just released, which lets you use values from 0-360 (under the assumption that you know what you're doing and will only use values your device allows). So...no need for any workaround at all anymore. Yay!
Am I alone in wondering why Hubitat doesn't offer the option of entering bulb color values as RGB instead of (and by that, I mean "in addition to") HSV? Some of my workflow involves tried-and-true RGB recipes that it would be somewhat of a PITA to convert individually.
What makes things more puzzling is that there's a drop-down showing "RGB" and "CT", and that HSL values must still be entered after choosing "RGB" lol.
Sorry if this is either (a) a sore point, or (b) asked-and-answered 1000 times. I just got here yesterday, and have searched the Forum, seeing no definitive Q&A on this topic. (Heck, even this thread is well over a year stale...)
I think it's more or less just arbitrary* that they chose HSV/HSB as the color mode rather than RGB. However, it is easy and reliable to convert in either direction. If you're writing a custom app or driver, you can even use Hubitat's built-in methods to do this. If you're using a pre-built app, you'll have to deal with whatever their UI provides (in a custom app, of course, you can do whatever you want); in most cases, this is probably going to be HSV to match the underlying driver commands, but anything is technically possible.
A driver could also provide a custom command to accept values in whatever format, but since it wouldn't be standard, you'd be limited in what apps you can use this with. Presumably you are using these devices with apps (automations) and not manually running commands from the device page all the time.
(*OK, I don't think it's entirely arbitrary: most Zigbee bulbs work with HSV under the hood, and Hubitat's device model largely mirrors that of SmartThings, which I assume was originally aimed as being mostly a Zigbee hub, though both it and Hubitat support Z-Wave--and have since their introduction. So, I'm mostly guessing based on terminology ST used throughout some of their APIs and whatnot that suggest a Zigbee leaning, like "clusters" instead of "command classes," even when dealing with Z-Wave. Most Z-Wave bulbs I've seen do use RGB, so had ST focused on Z-Wave since the beginning, perhaps we'd be using that by default instead.)
Agreed in all respects, but hasten to point out that the most common pushback I'm seeing from prospective Hubitat customers is something along the lines of, "But I don't want to have to program it!" And asking n00bs to "go figure out what HSL/HSV is and then find a way to convert your values... yada, yada" is most definitely going to sour their experience.
Whereas it's so simple and common practice to offer a toggle switch in the UI so users can enter the color values they have/like/understand best — allowing the hub to sort it all out invisibly behind the scenes. Instant gratification, happy customers and a sure win-win for the Sales Dept.!
There are seveeal built-in apps that let you just choose a color name like "Red" and be done with it. IMHO, anything more than that requires the user to understand something about a color model, and I'm not sure there's a strong case that one model is "friendlier" than another here, just what you happen to be familiar/comfortable with personally -- which for the vast majority of people is, I suspect, nothing. However, how an app asks for a color is entirely up to that app (just a matter of how it can be converted to the HSV values the device ultimately needs), so if you think some particular place a specific app could use different options, maybe ask the developer what they think (for community apps, for example, usually the developer has a thread; built-in, not usually, but you could post a feature request).
However, how an app asks for a color is entirely up to that app (just a matter of how it can be converted to the HSV values the device ultimately needs), so if you think some particular place a specific app could use different options, maybe ask the developer what they think (for community apps, for example, usually the developer has a thread; built-in, not usually, but you could post a feature request).
