I definitely agree.
The current specifications for Capability “Color Control” are sufficient for many devices, but is deficient for others.
Unfortunately SmartThings didn’t (doesn’t!) have any process for enhancing or revising an existing Capability. It is a difficult problem, as there would have to be ways to ensure existing DTHs and SmartApps don’t break, and maybe even figure out ways they can automatically adapt.
What if the device doesn’t accept an independent value for the W diode? What if the device only accepts hue and saturation as most smart lights (at least ZigBee based ones) do?
The major issue with getting multiple brands to show the same color isn’t the use of a hue, it’s that the various devices have different abilities to reproduce colors. There isn’t a standard color space like with TV/Movies. The best option is to use X/Y coordinates in the color space, but that still has issues even for a single brand like Hue since various products have different capabilities.
Indeed, the inconsistencies with light temperatures have been a problem for me for many years before we had the current technology, but this is new territory for lighting designers and we better get ahead of it before it becomes even more of a cluster F. I have been through this already in TV technology monitoring and color space and this to me looks just like the early days of digital TV. At least now the manufacturers are using actual color temperatures of the white diode. Now only if we could buy more nice controllers like the Fibaro to control a decent RGBW device. Since the Fibaro RGBW controller IS a true four channel device, we could start by writing a specific control command that works with Fibaro through ZW or ZB.
However I do understand that XY based devices wont work with a true 4 channel color space interface, but a secondary dumb down code interpretation could be implemented when connected to old Hue/ XY space. It just seems we need to begin programming in 3-4 channel sooner rather than later when it’s all a really sloppy mess.
Seems like RGB channels could be used for all but color accurate spaces where D6500 is required and then the W diode would be spec’d for the installation. In my space all TV backlights are pure white and no other colors are needed there. BUT in other spaces an RGB blend can work well. Any lighting designer can sit and build presets if given tru RGB 3 channel values, but try doing it using several different controllers or generic bulbs or strips using a color wheel and you will feel my pain.
I’ve recently developed my own device handler for the Fibaro RGBW Controller, and was lucky enough to stumble upon this thread.
I’m particularly concerned and frustrated by SmartThings’ blasé attitude towards device capabilities. In my view device capability definitions in general need to be tightened up, this means:
With regards to the “Color Control” capability:
For the time being, my Fibaro RGBW device handler sets the color attribute to a complete map containing red/green/blue/white/hue/saturation/level/hex/name keys:
Likewise, the setColor() command will accept a map with any combination of those keys, and will happily translate between RGB, RGBW, HSV, Hex, and Name color definitions.
Any feedback on my device handler is greatly appreciated btw.
On a related note: It would be great if the color picker control in the GUI (color_control tile) was updated to support the RGBW color space and output a white value. Right now, it currently has an extra zone at the top, which looks like it should support a white value (warmWhite to coolWhite), but doesn’t (?). The preset colors also seem to be somewhat broken.
On another related note: At the moment, it seems that color level reports (whether obtained via switchColorReports or SwitchMultilevelReports) can only received for one channel at a time. This has the undesirable consequence that the device status is updated with intermediate color values as the individual channel reports come in. It would be great if there was a way to obtain to complete color state of a device in one message/report, although I’m not sure if the underlying Z-Wave or Zigbee command class definitions support this yet (?).
So am I, friend,… So am I.
SmartThings’s answer is that they have higher priority issues and that they are working on complete overhaul of the concept.
It’s a precarious situation.
Hello Lars,
I am currently hitting the Smartthings API. When I hit the endpoint to get a devices status https://api.smartthings.com/v1/devices/{deviceID}/status I am getting the following color codes for one of my devices:
"colorControl": {
"saturation": {
"value": 65,
"timestamp": "2021-01-20T14:18:35.614Z"
},
"color": {
"value": null,
"timestamp": "2020-12-31T17:38:10.288Z"
},
"hue": {
"value": 75,
"timestamp": "2021-01-20T14:18:35.614Z"
}
},
However within every color converter I add this into (eg. HSV, HSB converters) the color is way off of the actual color that the device is. For example that color above shows this when I throw it into a HSV to RGB color converter:
But the actual color of the light is purple. What am I doing wrong?
Yeah that is because of a SmartThings quirk. SmartThings uses hue in % (0-100). So if you put 0.75*360 =270 and put that in your converter you will get purple.
Thanks Lars 
Hi! I have a concern that Is SmartThings is using HSV color with the Hue and Saturation are can be controlled while Value is always = 100.
