Recently I posted a response to someone having issues with color on a strip bulb - and got an opinion:
In an effort to move a lead ball down the pitch - I need to heartily disagree.
Worth - how do we measure that? how many affected? How much work to do? or long term value?
One of my points i had made during my comment was that there were discrepancies between color names. I had simply suggested that the color name table used by HE could be a system variable and let users choose.
The original idea some months ago, was that instead of every driver having a color table, that the color table be a system table referenced - a user could choose 'Amazon, Google, or Hubitat (default)'. Existing drivers wouldn't HAVE to be modded, but new drivers could take advantage.
I did a lot of analysis on this subject, and have since customized any/all drivers with color tables. I created a hybrid table so that when I tell Alexa a CT color (EG;) I get the same as I do with Google.
This goes back to the deviations of color from the early days of computers - we had RGB, then CMYK, and now HSL. all to describe a color. Yes. I'm painfully aware of the nuances of each, but in general terms it muddies the water instead of clarifying. Recall that Pantone came into existence so that colors could be standardized (then of course, copyrighted).
For all my CT drivers (I've 4) I now custom control them so they all work identically, or as best I can make it. It's a bit of a pain, but to me it's a kludge since there is no front end standards to take control and it's left to developers to write whatever they want.
So. is this post going to effect change? umm no. I've learned the hard way this isn't the place to change the world. But occasionally, (I'm using that judiciously) there are postings here that do help flesh new thoughts and idea which I take to other places now, more open to these types of discussions. I'll read yours with an open mind.
I guess I wasn't clear here. There is exactly one place where this matters, the colorName attribute as reported by the driver. This affects only what text gets displayed for the attribute in the UI. It does not affect the rendered color on the device, the "friendly" predefined color names (like "red") in apps like Basic Rule, input from a voice assistant like Alexa or Google Home, or really anywhere else.
Because I do not leave my device detail pages open all the time to look at this value (or have an attribute tile on Dashboard that displays it, for example), what text gets displayed here mattters not at all to me. The attribute could disappear entirely, and I wouldn't care. (In fact, I've really often wondered why it's there...parity with SmartThings in the early days would be my guess, maybe?) As I mentoned there (and elsewhere), it is simply calculated from the hue and saturation values (if in RGB mode) or the color temperature (if in CT mode).
So I guess the question for you is: where are you using the value of this attribute where it matters?
lol you quote 'worth' then ask me about my implementation... weird... but I don't specifically care about the displayed name, I care about the CT values themselves. my tables control both so that a color name from a picklist shows the same on my screen as the icons on my google dev apps as show on the Alexa. As well, by mapping the names to more closely match Alexa, non HE connected devices continue to 'play nice'.
Because I interpret worth/value to be affected by if or how the data is used. I have no use for it, hence it is of no worth to me. So, the queston becomes what value it has to you and why, which likely includes where/how you're using this data.
What picklists? Again, the value a driver reports for colorName does not affect anything an app like Rule Machine, Basic Rule, or a voice assistant uses for predefined color or color temperature names. This is defined in-app on Hubitat. For example, telling Rule Machine "red" will use something like hue 0 and saturation 100, even if you modied your color table to call this "purple" and made "red" something different or took it out entirely. (Try it!)
This is just how the platform works. The setColor() (and setHue()) and setColorTemperature() methods on Hubitat take numbers, not names. Any name conversion must be done in an app before calling these commands on a device. (Related: there is no guarantee two different apps wll mean the same thing wth the same color name.)
Further, apps do not have the ability to read into driver code and do any sort of rerverse lookup with number-to-name calculatons (the field variable you seem to have defined in the snippet of code in the other thread is just one possible way of doing this but not something an app can "see" regardles). So really the only place this could matter is if you take the value of the colorName attribute and use it somewhere.
An app can see that (but only after it's already calculated/set). Hubitat Dashboard could, too, though only as text, and if you use a "custom" Attribute tile. That seems a bit odd to me. Perhaps Google Home displays the value of this attribute somewhere too (maybe that's actually why Hubitat has something for it in the fist place...is that what we're all missing here? ). But it's still just a calculated value that isn't useful for setting the color/CT so that when you say "cool white," one bulb gues to 4000 K and another to 4100 K because there they seem to match. That's what it sounds like the wish is, and the above is why that wouldn't work. It will, of course, if you do set one to 4000 another to 4100 K (via whatever means) and want them to both display the same thing for colorName afterwards. But this attribute so little used, the question is: where is the reward for the work put in to making this name match? Agan, for me there's none because I don't look at it, and no apps I use show it anywhere, either (and again, this is different from in-app color pickers to set the value, the only place I encounter names on a regular basis...all serious questons trying to understand your use case better).
This provides the HUBITAT definition of color. It is used when you set the colorName attribute. It will take a while to work into all devices (it is already in mine).
The broader term of setting color. Both Google and Amazon have color to HSV tables to work their commands. So if you use those, you get consistent colors as will as the Hubitat color name.
Feature request would be a setColorByName command for drivers as well as a getColorByName (returns HSV) for apps/rule machines (allow control of devices w/o setColorByName).
Finally, for dashboard control, you could add a colorBulbByName template that acts like the colorBulb template. When put is selection mode, it would pop up a list of viable color (CT) names vice the color wheel.
4-5 yrs ago, my first smart device was a wifi bulb from Kasa - and the only functional driver I found was from... DjGutheinz. You're a legend to me!
I'll start to learn, implement and use the new functions as I progress. Thanks for knowing so much, and then sharing.
FWIW, I think we're basically saying the same thing. What it sounds like your use for this is now will not work (given the above explanation), and the above is a proposal for a means by which it might—as likely or unlikely as it is to become part of the platform.*
Where I'm still confused is what effect anything in the other posts and threads you've made about this has anywhere. The colorName attribute is calculated value and only works in one direction; there is no going back from the name to a numeric color (hue, CT, etc.), no matter how you modify the names. All Hubitat apps ultimately have to work with numbers given the capability/command definitions. It sounds like you see some use for this somewhere, even as-is; I'm just confused where, since the displayed value of this attribute should be it. Maybe a screenshot would be worth a thousand words.
*EDIT: I should add that this approach certainly would work, today, with or without a "standardized" platform capability--but only as custom commands. Rules, (custom) apps, and whatnot could use these; voice assistants or direct Dashboard manipulation that relies on standard commands and attributes, not so much.
One of the new functions allows you to define several color presets for a device, get them the way you like, and passing to all of the Kasa devices. Not as utilitarian as I would like since tile integration is iffy. But rule integration works using the custom command.
I don't know the answer to the first question. You can create one by using Amazon (Google) to set a color by name and seeing what the color map generated is for that name. You would do this using the Alexa App and the color list in the device's page on that app.
I believe that convertHueToGenericColorName is derived from the early implementation represented in the public driver below. The explicit method is "setGenericName".
This is from a library of tools that I've put together for Matter development, but this color naming tool works for other technologies.
As explained on that Wiki, there is a "standard" set of color names used for HTML/CSS which are set out in RGB form here: https://www.csscolorsapi.com/ . The code in my library uses a "closest distance" algorithm based on distances in 3D space to find a matching color for any HSV / RGB value. If Amazon is using this "standard" set of colors, this should provide a match.
). But it's still just a calculated value that isn't useful for setting the color/CT so that when you say "cool white," one bulb gues to 4000 K and another to 4100 K because there they seem to match. That's what it sounds like the wish is, and the above is why that wouldn't work. It will, of course, if you do set one to 4000 another to 4100 K (via whatever means) and want them to both display the same thing for 
