Update tradfri v5

[lwis]

Description:

Improved colour handling from library.

[NovapaX]

That weird UI behaviour is not new. I believe it's been there all the time, but with the new color wheel it's way more obvious.
(with the old color picker it just looked like you tapped wrong)

I think it has something to do with the color roundtrip from hass update -> gateway change -> hass updating based on gateway info -> color reflecting in UI.
I haven't had time to debug it to see where it goes wrong.
I've noticed the issue only once because our color light is in the kids room (they like to pick a color before going to sleep) and we use the tradfri remote/switch mostly for that.
And when they are sleeping it's not really desirable to play around with that light 😃

[lwis]

@NovapaX I think @ggravlingen and I have found the issue with the strange behaviour we were saying.

Do you know where this logic comes from? We end up with rounding errors going back and forth between the gateway, and I was wondering where the normalisation math comes from?

[ggravlingen]

This must return a float

[NovapaX]

I have really no idea where that comes from. As far as I can see (git blame) you put it in there with this PR 😜
I know what it does: convert between two different XY coordinate systems.
Looking to the state of things (literally) from UI to light we go from: Hue/saturation -> RGB -> XY -> Tradfri-specific-XY and all the way back before it is reflected in the UI again. Some small rounding errors are expected
But indeed it looks like that should return a float. :)

I've only done some work on the platform and on the color wheel UI. Nothing specific to trafdri lights.

On should wonder: Why can't all these vendors just settle on some uniform inplementation and interpretation of standards? 🤔

[ggravlingen]

@NovapaX @lwis when I poked around with colors in pytradfri, I noticed that that it seems you set hex values in the app. The gateway then sets the correct color of the bulb and converts hex->xy. Ideal would be to send hex from Home Assistant. Unfortunately, the gateway only accepts a predefined list of hex colors. I guess we could replicate this in Home Assistant (only a predefined set of colors), even though I suspect that users would not appreciate that.

The transformation mentioned by @NovapaX involves linear algebra and transformation matrices (https://github.com/home-assistant/home-assistant/blob/8742ce035a36b3a4a176123b620fe82e55d5a4e2/homeassistant/util/color.py#L201) and given that they are rounded floats, I suspect that they will contribute to the behaviour we see in Home Assistant.

[NovapaX]

Can I make a unique_id PR against this branch?

[NovapaX]

@lwis I just created a PR (#13439) against this branch to add unique_id's and support for color temperature on color bulbs. I think if you approve we can just merge it into this one and make it easy for other to test some more.
Would be nice if we could get this into the next release cycle.

[MartinHjelmare]

Please don't add more features to this PR.

[NovapaX]

Ok. I’ll rebase and re-PR when this is merged. 👍
This PR on itself looks almost good to me.
Edit: oh it’s fine. I had a little remark to the code but that’s not from this pull request.
I can confirm this works for white spectrum and color bulbs, without a change to configuration or re-pairing with the gateway.

[lwis]

Any objections to this being merged?

[MartinHjelmare]

LGTM!

[ggravlingen]

Any chance of cherry picking this into the 0.66 beta?

[NovapaX]

Why? Current implementation is not badly broken right?
Okay: we would trade two flaws. Currently color setting on an colorbulb is a bit broken. In this PR setting color_temp on an colorbulb is not possible.
Or am I missing something?

[lwis]

I think we should wait, given that we're half way (?) through the beta phase.

[ggravlingen]

No, you’re right, let's wait.

[balloob]

During the beta phase we should only cherry pick bug fixes. New features will have to wait.