Adventures with ColorCapabilities

I’m creating this to track info/process in my advendtures with colorCapabilities…

• read ColorCapabilities for all bulbs
• collect data, check if they lie… sadly they do 👎
• automatically do the right thing in the color convertor based on value

read ColorCapabilities for all bulbs

This was easy, done as part of reading ColorTemperaturePhysicalMinMireds and ColorTemperaturePhysicalMaxMireds change. #2010

collect data

Reported data

• IKEA Trådfri CWS: xy
• IKEA Tradfri WS: ct
• Innr RB 250 C: hs, ehs, xy, ct
• Innr RB 285 C: hs, ehs, xy, ct
• Muller Light Tint: hs, ehs, xy, ct
• IKEA FLOALT: ct
• IKEA GUNNARP: ct
• Hue E14: hs, ehs, xy, ct
• Osram E27: hs, ehs, xy, ct

This is bad news, as both the Innr RB 250 C, and Tint, report support for enhancedHue… which neither seem to accept. They are also not rejecting it with UNSUPPORT_ATTRIBUTE, which means either: busted firmware or we maybe we’re writing values that are out of range. I have not dug out wireshark yet to dig deep.

OK, they actually do respond!

But why would they announce support if they, in fact, do not support it… this is troublesome.

automatically do the right thing in the color converter based on value

Looks like we can differentiate between xy and ct capable bulbs with this date…

Hue/Saturation is tricky… but something like this can work:

bit	support	converter
0	hs	enable hue/sat support in convertor
1	eh	enable enhancedHue if on manufacturer whitelist or enhancedHue == true
3	xy	enable xy
4	ct	enable ct

manufacturer list seems to be:

• Hue
• Osram

Tint doesn’t seem to work at all Innr mixed bag of some bulbs working other not, so we should err on the side of not auto enabling.

raw data dump

device	lightingColorCtrl
RGB(W)
Hue LCT012	{"colorCapabilities":31,"colorTempPhysicalMin":153,"colorTempPhysicalMax":500}
Innr RB 285 C	{"colorCapabilities":31,"colorTempPhysicalMin":153,"colorTempPhysicalMax":555}
Innr RB 250 C	{"colorCapabilities":31,"colorTempPhysicalMin":153,"colorTempPhysicalMax":555}
Osram CLA60 RGBW Z3	{"colorCapabilities":31,"colorTempPhysicalMin":153,"colorTempPhysicalMax":526}
TRADFRI bulb E27 CWS	{"colorCapabilities":8}
Tint LED bulb GU10/E14/E27 350/470/806	{"colorCapabilities":31,"colorTempPhysicalMin":153,"colorTempPhysicalMax":556}
WS
TRADFRI bulb GU10 WS 400lm	{"colorCapabilities":16,"colorTempPhysicalMin":250,"colorTempPhysicalMax":454}
GUNNARP panel 40*40	{"colorCapabilities":16,"colorTempPhysicalMin":250,"colorTempPhysicalMax":454}
FLOALT panel WS 30x30	{"colorCapabilities":16,"colorTempPhysicalMin":250,"colorTempPhysicalMax":454}
FLOALT panel WS 30x90	{"colorCapabilities":16,colorTempPhysicalMin":250,"colorTempPhysicalMax":454}

[sjorge]

Uh ow, I managed to crash both the Innr and Tint bulbs! I made a scene with hue/sat as it required enhancedHue, thinking that maybe they only support it in scenes but not the command’s (which is against ZCL spec, but hey)

They keep looping this and need a hard poweroff for ~30 secs before working again.

[sjorge]

I’m going to close this, we’re using limiting color_temp to be within range. The colorCaps attribute is useless as a lot of bulbs seem to advertise suporting ehs, but they don’t.

The crashing behavior is fixed by setting meta.enhancedHue to false and scene_add now properly deals with this.

Also the color weirdness seems to be mostly fixed by picking either XY or hs for settingthe color.

Tint, Osram: use (e)hs Innr, Hue, Ikea*: use xy

Ikea still had horrible greens, but it’s ‘by design’ according to u/tradfri on reddit 😦