How can I create my own CT table

I've been deep diving into the CT drivers available. Trying to use Advanced Zigbee CT Bulb, Zigbee CT Bulb, Zigbee White Color Temperature Bulb (user driver). Besides learning a ton about 'switching drivers causes your HE to get mad' (if I make a switch things don't act well for a while, usually a hub reboot, refresh, config button mashes).
Here's the thing - I have a number of CT Bulbs. Some OSRAM, some Lightify, some 3rd party (Linkind) and some Sylvania. To complicate things each has it's own CT range it seems but I digress...

I can easily set the CT value in kelvin. sure. But the drivers all name the colors differently. Some have names flat out missing. EG; Daylight. When commanded via Alexa I get 'Electronic' displayed as the Colorname in 2 of the drivers.

Alexa voice control has a predefined list of color temp to names - and I don't agree with it either (Warm white and soft white are 2 different values per Wiki).
I would like to have the color temp table match the industry definitions (which clearly have no perfected standard - but I believe in Wiki).
As I look at the "ZigBee White Color Temperature Bulb - LGK Modified" driver - I can see the Authors attempt at making a table it's not very robust but it informs me that the colorname to temp value is driver created and not some hubitat thing.
I don't know where or how I can get the Advanced Driver so I can fix it and make a more useful table of names to values. How do I get a copy of that driver? I would also like to customize the driver specifically to allow me to set the Color temp range of the specific bulbs so it matches the bulb true capability as opposed to being limited to the Min value of the weakest bulb.
Has anyone explored this before me and resolved some or all of this? I've played with Circadian Daylight Coordinator, written some very simple "Motion and Mode Lighting" children and I'm still not happy with my overall results of control of CT bulbs.

Do you display those values somewhere? My impression is that most control systems have their own color->K scaling, so I consider the names displayed in Hubitat as just FYI.

For example, when you tell Alexa "soft white" it tells whatever it is talking to 2700K (or whatever it defined in its mapping).

Actually, this map is the other way around: color temperature (Kelvin) to name. This is more or less for informational purposes only, as @tomw mentions above. Any app in Hubitat that lets you choose names, like Simple Automation Rules or Rule Machine, does its own mapping. The driver ultimately accepts only numeric values. You can see the standard here in the setColorTemperature() command definition for the ColorTemperature capability: Driver Capability List - Hubitat Documentation - ColorTemperature.

(That being said, the above point deserves two pieces of clarification: the color names in RM and SAR are actually RGB/hue-sat approximations of CTs that ultimately use the setColor() command, so if your bulb is in fact CT-capable, you should use the CT-specific actions instead, and there as far as I remember from any stock apps, you can only specify the numeric CT--no conversion from name attempted. Regardless, the driver will ultimately only take a number here, so conversion, if any, must be done on the app side. The second point is that I think I found the specific driver you're talking about, and there are some custom/non-standard commands in it, like setColorSoftWhite(). These would not be used by any stock apps, including the Alexa or GH integration, as they are not standard commands, and are ultimately just shortcuts--albeit things controlled by the driver, but again not generally useful unless you specifically call this command--to things like setColorTemperature(3000).)

The above is based on my assumption that you are looking at the colorName attribute. Again, this is one-way only: numeric value (from either hue/saturation [which Hubitat also calls RGB] color or CT value--though only the former is technically required as far as I can see--to the colorName attribute). Again, you can look at the ColorControl capability docs to see that this just an attribute, which (by convention--and because it's what makes sense--though there's no formal requirement) most drivers will set based on the current hue/saturation or CT value: Driver Capability List - Hubitat Documentation - ColorControl. So a command like setHue() or setColor() will generally ultimately change the colorName value, but there's no way to take one of these names in (e.g., "chartreuse") and set the hue/saturation or CT based on that; colorName is just derived based on the other attributes.

If you're interested in seeing even more, you can look at Hubitat's example RGBW bulb driver. The setGenericName() and setGenericTempName() methods simply read the current hue/saturation or CT values and set the colorName to match: HubitatPublic/examples/drivers/GenericZigbeeRGBWBulb.groovy at master · hubitat/HubitatPublic · GitHub. This is a one-way map, with no way to do the reverse (at least not elegantly, and again nothing that any app, including a voice integration, would be able to depend on).

Or... tl;dr Hubitat only accepts numeric values for standard commands like setColor() and setColorTemperature(), so anything else is a conversion done on the app (including voice assistant integration) side. :slight_smile:

1 Like

FWIW, I have never experienced this when changing a device’s assigned driver.

Hubitat makes the code for a few example drivers available in their public GitHub. But if it’s not included there, then there is no way to see the code for any built-in drivers.

@bertabcd1234 that was the single greatest response! TY for taking the time to write that.
I recognized upfront that a name is just a name - the numeric value is the gut component. Absolutely and makes sense especially when you take into consideration even google and alexa don't agree on names! I remember when Pantone was becoming a standard ... :slight_smile:
This link:
if (value <= 2000) genericName = "Sodium"
else if (value <= 2100) genericName = "Starlight"
else if (value < 2400) genericName = "Sunrise"
else if (value < 2800) genericName = "Incandescent"
else if (value < 3300) genericName = "Soft White"
else if (value < 3500) genericName = "Warm White"
else if (value < 4150) genericName = "Moonlight"
else if (value <= 5000) genericName = "Horizon"
else if (value < 5500) genericName = "Daylight"
else if (value < 6000) genericName = "Electronic"
else if (value <= 6500) genericName = "Skylight"
else if (value < 20000) genericName = "Polar"

really says it all for me. I just finished an excel table of Google home, Alexa Developers, Advanced Zigbee CT Bulb, Generic Zigbee CT (dev), Sengled Element Plus and Zigbee White... LGK modified.

It's simply amazing the differences! (I'm willing to share the spreadsheet if there is any interest)
For example Warm White with Alexa is 2200 - but it's 3000 with Google and 3300 with HE. thats a humongous difference. Cool white is another - 7000 for Alexa vs 4000 on google with no equivalency on HE (Moonlight maybe?)

Why is this important to me? nuances of confusion happen in the transition of computer to human. I have never told a light 'Be Incandescent'. But Soft white? sure. And I don't like that I have a different result if I ask Alexa to do it, Google to do it or Hubitat to do it. And since Hubitat is my base, my standard it was my thought to build out from there.
If I can make a custom driver for each of my bulbs, with a standardized set of colortemp names, I can truly feel like what I see in Hubitat reflects what I do in real life. At least that was the thought this AM at 8am. LOL. And now that I've learned there are some example drivers - I've a start point toward my goal.

With all my thanks. You guys really are the best. Shu

PS - @marktheknife You need to come to my house. I excel at breaking things. The driver just hung up hard and I had to factory reset the bulb and re-detect it to get it working again. (I switched from the Sengled Element Classic (legacy) back to Advanced ...CT and it just went hosed.

Have you considered using Hubitat scenes? Then you can activate the scene by band, and you can control the specific CT for all devices in the scene.

Alternatively, I'm pretty sure Google can accept voice commands like "Set Bulb X to 2700 Kelvin." I don't think Alexa could the last I tried...

In case it hasn't become clearer since 8 AM: what I wrote above is a long way of saying the driver doesn't matter. It takes only numeric values. Alexa or Google are doing numeric conversion, and there's nothing you can do by the time it gets to the driver (to be honest, I don't know if this could be the Alexa Skill or GH app on the Hubitat side or what you can do with custom code there--or if this is truly an Alexa or Google conversion--but that's outside the driver regardless).

1 Like

Completely understand Master yoda! I really do get the value vs name you spent so much effort making clear.
The issue I can work on is the tile in my dashboard saying 'incandescent'. Having it reflect the names I personally like and where I set most values (numerically of course!) will reflect a more user friendly visage to me.
Of course - Just to make everyone laugh - imagine what happens when I get bothered by RGBW? HA

I did call it! got my lights to match up super well with the wiki and my desires with the voice control commands I use - except my dashboards use 'group dimmer-2.1' driver in numerous places for gangs of bulbs.
So of course the HE driver has that old table I don't like in it! Are there any known examples of Group dimmer groovy driver!!!?!?!

For now, I'll 'fake' the values by taking them from a bulb and pretending their from the group driver. Really is nice! Would you believe there are HTML colors that match some names?