I've looked at the one official driver example with ColorControl, in that one the attributes "RGB" and "color" are not set, can I infer from this that those attributes are not needed and are just optional? Are integrations with Alexa and Google Home requiring these to be set? I don't use either, but do want to get it right for those that do.
That is my assumption, as well. Here is another Hubitat driver, closed source, but also implementing only these attributes:
(This is a Hue Bridge bulb.) I think the "RGB" and "Color" attributes might be holdovers from the similar capability on SmartThings, where there also seems to be some confusion (see here, among I'm sure other places: Capability Color Control "color" Attribute & Command ambiguous, incorrectly documented, and/or improperly used in DTHs - Devices & Integrations - SmartThings Community). As long as all of the attributes above are populated for "ColorControl" device, my experience is that they work fine.
Hubitat also has a colorName attribute listed for this capability, which I guess their Hue Bridge integration doesn't do. I'm assuming you looked at their generic Zigbee RGBW bulb driver, which does. I don't think this is necessary for Alexa/GH and apparently not at all if they didn't do it in their own driver, and it's certainly a bit redundant in that it can be inferred from hue or CT values (and not standardized so probably not very useful anyway; I just report what Hubitat does for the same Hue or CT ranges in their example driver).
1 Like
Thank you @bertabcd1234, not having been here long I do prefer to confirm things with those that have. I do have the colorName attribute implemented so I’ll leave that in for now. On the subject of Google Home and Alexa, are there issues with mixing ColorControl and ColorTemperature in the same driver? I’ve seen some things that may indicate that Google Home could have issues, but believe the problem was in fact something else.
You can "sniff" Hubitat's internal drivers and see the Capabilities, Attributes and Commands.
I wrote an App for that...
3 Likes
I can't imagine why there would be an issue. This is a very common setup: ColorControl for the RGB portion and ColorTemperature for the tuneable (cool/warm) whites. This is exactly how a Hue White and Color bulb (perhaps their flagship product) works. The only problems I've seen is if these capabilities are declared but all the apparently-truly-required attributes aren't populated with something (I know it makes Google Home not like the devices).
1 Like
Yes, I thought about that, but no time yet...
Thank you! Saves me time 
Edit: though it shows all available declared attributes, not necessarily those that are actually implemented. Like the RGB and color ones, declared through the capability but as it seems, very seldom, if at all, implemented. Getting the implemented ones would be a bit more work, and depends on the device being used and having received the requisite events first.
I know, it's what I have in my strip drivers as well. I guess that if someone has issues, they'll report it. Just thought I'd ask if it was something known and I just hadn't seen it, being rather new and all. 
Declaring a Capability includes the Attribute(s) and Commands for that capability. There are additional one-off attributes of course, but why declare them and not implement? Yes, I can see that some manufacturers of bulbs never implemented lightEffects, for example, but the driver would have to handle the 'do nothing.'
That button will appear on the Device Info page and someone might click it or put in a number then click it. Even if the feature doesn't exist, you wouldn't want a driver to spit errors.
1 Like
Yes, which for a Capability like ColorControl includes two attributes very seldomly implemented, apparently not even the built-in drivers use them.
EDIT: It is however very handy to use an App like yours to check what is declared, then it's just a matter of checking what is actually in use when it comes to Attributes.
Commands is a different thing, they do need to be handled, as you say.
I think we're at the "tree falls in the forest..." level. It's 'implemented' in the sense that mem is allocated.
Because of my interest in HubConnect, I 'see' attributes a little skewed. I'm usually working on a virtual device and thus it may have no specific implementation, it's a generic implementation. Thermostats for example, RGBW -- led strips, bulbs, etc. get mirrored as generic attributes. My experience therefore may not be translatable to your specific case. 
I see what you mean, from that perspective it really doesn't matter one way or the other, if it is declared as existing, it exists.
1 Like
hue, saturation, level is what makes your actual color
I see a ton of people ignoring the L in HSL in their drivers.. In my opinion thats why color from some of these bulbs always seems washed out... I did work on the inovelli rgbw bulb drivers and can way more accurately re-produce color.. In fact all of the “official” smart things drivers for rgb bulbs ignore the L value..
colorMode: required for RGBW states weither the bulb us in CT or color modes
colorTemperature: required for CT bulbs
colorName is not required it is a FYI field
2 Likes
I'm not sure if you meant to reply to me specifically; if so, the "L" should Indeed go with level when setting color, and HSL does indeed make up the whole color; I did not mean to imply otherwise. All I was saying is that Hubitat's examples use only hue or CT when calculating the color name.
This is part of what spurred the original post. The docs actually say that this is a required attribute for the Color Control capability, despite the fact that many drivers don't populate it. Further, the original RGBW driver example from Hubitat even declared it as a custom attribute (perhaps an accident leftover from early development--the color model wasn't stable in the earlier days of the platform), something you shouldn't have to do for required attributes as mentioned above. It's a bit of a confusing world in the color space still--e.g., the actual color attribute says it's required too, but none of Hubitat's drivers appear to do that, either. Oh, and Hubitat's latest update to that RGBW driver removed the explicit colorName attribute declaration (probably because it really is there, but was that a platform change recently or just a mistake/unnecessarily line in the driver? I'll test this with one of mine later...).
2 Likes
Wasn’t replying to you specifically.. Just adding to the conversation on what I learned from working with color bulbs
It sure does... I'm going to update the drivers I work on .. Just for conformance..
Attributes
RGB - STRING
color - STRING
colorName - STRING
hue - NUMBER
saturation - NUMBER
That is why I started this thread, I want to be as conformant as possible. For "RGB" and "color" I think I will currently interpret it as attributes not needed to be set based on this thread. For colorName I use the definitions in the example driver. I looked at one of your drivers before and remember you had more color names, have been thinking about adding that, but I still see no real use for the colorName attribute. Not sure what I, or anyone, would truly need it for?
1 Like
Hubitat's own drivers don't do this, so I'm guessing the docs are either accidental carryovers from ST (where this doesn't seem to be clear, either) or the early days of Hubitat when they were still trying to figure out how color commands and attributes should work. @mike.maxwell has written enough drivers he can probably comment on whether the docs are really correct here.
Since Hubitat's own drivers don't use the supposed color and RGB attributes from Color Control (nor is the exact type and format required of their values clear), my plan is to continue doing the same in my own drivers.
1 Like
I agree .. As a programmer I love defined specifications.. If you know what is expected it is less likely to have issues with integration with other aspects of the system..
1 Like
I agree fully, unfortunately this system is still early days and I guess we get to muddle along and piece together from various sources what the specs are to be, on the other hand, we get to be part of affecting what the specs are to be since not everything is set in stone. There's the good and the bad 
1 Like
Yea.. That is what makes it a bit harder.. Have to make mistakes on the way to learning it... I had tried to use some groovy features to inspect the methods and classes to start generating some documentation.. But this appears to be mostly blocked (understandably) ...
Yes, all is sandboxed, and the execution environments are even different for metadata and the rest of a driver for example... Looking at the available methods I've found some undocumented but useful stuff, but yes, it is limited what can be inspected.
1 Like
