Allow /get for color_mode

[sjorge]

As mentioned in the discussion linked in Koenkk/zigbee2mqtt#6402

Here is a local diff I've been carrying for a while, it allows manually getting color_mode and actually parses the random numbers into something more descriptive.

I use this to manually drop either color_temp, color.x + color.y, or color.hue + color.saturation from the json payload before processing, so I also have the correct color info.

[Koenkk]

I want to wait to merge this once there is more clarity in: home-assistant/architecture#519

Besides changes in the pr also all converters have to be updated to return the correct color_mode (e.g.

zigbee-herdsman-converters/converters/toZigbee.js

Line 1044 in cc6c4d0

if (key == 'color') {

)

[sjorge]

Yeah, this is just what I had so far as a set of patches I carry (when not testing stuff).

I don't like the proposal there of adding 'new' color modes not defined in the ZCL though, at least not as an attribute called color_mode, then we get into the 'system_mode' mess where HA and ZCL don't agree on what should be in it. HA is a consume of all of this, but it's not the only one.

Probably a few things that need to happen in addition to this:

• update color and color_temp converters to also switch color_mode
• (optionally) filter out the non active mode values from the color payload.

I can append this to this PR, or we could do them in follow up PR's

[sjorge]

Seems home-assistant/core#47720 got merged, sadly it does not really map to ZCL's color_mode cleanly (the on/off and dimmer stuff)

mapping ZCL color_mode updates to the following should work pretty well though and it probably a good start.

COLOR_MODE_COLOR_TEMP = "color_temp"
COLOR_MODE_HS = "hs"
COLOR_MODE_XY = "xy"

I'll rebase the PR later tonight and rename ct -> color_temp. I will also set color_mode when /set is called. The filtering of the inactive keys for color and color_temp I'll do in a follow up PR. Not sure how we can do this for now as it looks like just returned color with the active attributes have them merged with the old values too 🤔

[sjorge]

@Koenkk that should cover setting color_mode correctly I think.

Edit: tested with a Innr E14, Tint GU10, and Ikea FLOALT

[sjorge]

Found an issue with scene_recall not updating color_mode, retesting with extra change.

[sjorge]

Thats... annoying

Zigbee2MQTT:debug 2021-03-16 17:25:24: Received Zigbee message from 'office/light/desk/bulb', type 'readResponse', cluster 'lightingColorCtrl', data '{"colorMode":2}' from endpoint 1 with groupID 0
Zigbee2MQTT:debug 2021-03-16 17:25:46: Received Zigbee message from 'office/light/desk/bulb', type 'attributeReport', cluster 'lightingColorCtrl', data '{"colorMode":0}' from endpoint 1 with groupID 0

I have to wait ~1-2 sec before reading colorMode, I guess we'll need to just set it based on what is in state instead...

[sjorge]

OK, 2nd way give the expected behavior, would still have liked to just read it. But I couldn't find a way to read it after X timeout. Oh well.

@Koenkk can you double check this? That should at least got the color_mode attribute added with hs/xy/color_temp depending on the last set color mode.