Jumpy colour wheels: Workaround by not reading colour data for certain bulbs

[WTell]

Issue

Color handling (as @ebaauw describes in #814 ) remains "jumpy", in the sense that gliding through or setting different RGB or CCT colours will make the colour wheel in the Home app jump between different colours, possibly overriding the colour stored in the colour picker in the Home app.

The issue is probably to colour settings being "fed back" from deCONZ or from the bulb, interpreted by the various layers/APIs and then translated back into some other colour in Home, perhaps with a delay (before which the user has chosen another colour).

Suggestion

Some users use the Home app (possibly with Siri) exclusively to control their lights, as I do. I am not reliant on any colour data going "upstream" from the bulbs and back into Home. I suggest that it would be possible to work around this issue by disabling the ability for deCONZ to feed colour back into Home for chosen bulbs, so that this issue is – while not fixed – at least rendered harmless.

This could for example be implemented in config.json, where the user could specify an array of light IDs that will not have the colour setting read back from the REST API.

[ebaauw]

That's what I already mentioned:

I should probably ignore xy for non-Hue lights in ct colormode.

[WTell]

Thank you, @ebaauw . There is still "jumpyness" when setting RGB colours, too. Would

ignore xy for non-Hue lights in ct colormode.

address this as well?

[ebaauw]

The jumping is a combination of:

• Poor HomeKit design on Apple's part and poor API design on Hue's and dresden's part; and of
• Using sub-par lights, that don't handle colour too well.

In Zigbee, you send a command to a light to request it to change the colour. The light reports it's actual colour through attributes. A proper modelling of this would be to distinguish between target colour vs current colour. Instead, both target and current colour are represented by the same API attribute and HomeKit characteristic(s). The same holds for brightness and colour temperature, by the way.

Usually this is not too big a deal, but there are a couple of cases where this hurts:

• When you change the brightness or colour (temperature) using a longer transition time. E.g. when you set the brightness from 100% to 10% over a period of, say, 10 minutes. You set the slider from 100% to 10%. But when the light state is refreshed by the gateway/bridge, it "jumps" back to 95%. The slider will continue to move down to 10% over the next 10 minutes, "jumping" each time the light state is refreshed by the gateway/bridge;
• When the target state and actual state differ noticeable. This typically happens because Zigbee lights use a different colour space than your PC or Phone. The target colour needs to be translated from RGB Hue / Saturation to CIE 1931 xy; the actual colour from xy back to Hue / Saturation. The math behind this is no fun, and imperfect (as in: doesn't always return the exact original values). Usually the differences are too small to notice, but when the requested colour cannot be displayed by the light you'll see the colour "jump". This will happen more often on sub-par lights which support fewer colours, and don't give a clue what colours they support.

Now, if you would control your lights exclusively by HomeKit, we could decide to ignore the actual light state, and simply only show the target light state in HomeKit. There might be a mismatch between the displayed colour (temperature) in HomeKit vs the actual colour (temperature) by the light, but you probably wouldn't notice nor mind. However, when the light would be controlled from elsewhere (using Zigbee controllers, using gateway/bridge rules, using other API clients, like the Hue or Phoscon app), HomeKit wouldn't be updated.

[WTell]

Now, if you would control your lights exclusively by HomeKit, we could decide to ignore the actual light state, and simply only show the target light state in HomeKit. There might be a mismatch between the displayed colour (temperature) in HomeKit vs the actual colour (temperature) by the light, but you probably wouldn't notice nor mind. However, when the light would be controlled from elsewhere (using Zigbee controllers, using gateway/bridge rules, using other API clients, like the Hue or Phoscon app), HomeKit wouldn't be updated.

Thanks for the thoughtful and detailed explanation. For my RGB lamps in particular, I have no other control than through HomeKit, so I don’t mind at all ignoring the actual light state (save for on/off). I can try to hack something together to get this to work the way I imagine and report back my experience.