Tradfri v5 - unique_id's and color_temp support on rgb bulbs

[NovapaX]

This PR depends on #11187 getting merged first. (it's currently based on that branch.) Once that is merged I'll change the target-branch to dev.

Description:

unique_ids for lights and light groups:

These are based on the gateway_id and the group/light id. The group/light id's can change when users re-pair their devices, or when users reset their gateway to factory defaults.
This is the best we can currently get on this platform.
Unfortunately tradfri doesn't expose the serial numbers on their API (while they do for thier Homekit integration)

setting color temperature on a color/rgb bulb:

Unfortunately the CWS (color white spectrum) bulbs don't react to setting their color_temperature value. So we need to convert the color_temperature to hs(b) and set that with set_hsb.
This solves a feature regression compared to the previous platform/library version.

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. *Your PR cannot be merged unless tests pass

[NovapaX]

Pinging:

• @lwis to approve as a owner of the update_tradfri_5 branch
• @balloob to approve the unique_id implementation (this is my first one), so I can get that right before this gets out of my control ;)

[NovapaX]

Closing this until #11187 is merged. Will rebase and reopen a PR then.

[balloob]

Use the device info serial instead of crafting your own: https://github.com/ggravlingen/pytradfri/blob/master/pytradfri/device.py#L111

[NovapaX]

Of course I would’ve used that if it actually returned anything other than a blank string. ☺️

[balloob]

Sounds like a bug upstream 😉

[NovapaX]

Yes. You’d say. Bit it looks like the gateway doesn’t return it, so it’s not a bug in pytradri.
I’ll do some packet sniffing to make sure.

[lwis]

IIRC the raw data contains a blank string.

[NovapaX]

Wasn’t there someone in the community who had contact with a tradfri dev at IKEA?
Maybe we can ask if they can modify the gateway firmware to include it in thier response, and if so at what timeframe.
Else this current unique-is is the best we can get I guess.

[lwis]

They don't seem to be very receptive to queries as it's not a public API. So we either forego unique I'd until IKEA provide a better solution, or we use this.

[balloob]

I'm fine with the current implementation. Or do we know if Tradfri is reusing IDs if we unpair/pair a bulb?

[balloob]

Sorry, just saw the other comments. Disregard

[NovapaX]

Ok. Then I think we should use this. As the benefit of using unique-id and thus being able to use the entity registry is quite large for users.
I was just thinking. We can also use the ‘first pairing’ timestamp as a unique iD. That will also reset on a new pairing. But we’d not get duplicates on factory resetting the gateway.
But that attribute is more of a guess, so I doubt that’s a good idea.

[NovapaX]

I’ll do some tests to see under what conditions a bulb will end up with a new id. So we’ll have that clear and can put a note in the docs.

[NovapaX]

In the following cases a bulb will not get a new id:

• changing the name in the gateway (via the app)
• assigning it to another tradfri-group via the app
• assigning it to another tradfri-group by pairing with a remote. (pushing the pair button on the remote close to the bulb)
• resetting the bulb (turning it off and back on 6 times) and pairing it again with a remote. (without explicitly removing the device from the gateway via the app)
  This one was the most critical to me as that can happen accidentally.

In the following cases a bulb will get a new id:

• explicitly removing the bulb from the gateway via the app.
• resetting the gateway to factory defaults and pair the bulb again (in this case the id could be an id already in the registry. Because the gateway will start assigning id's at the beginning of its id-pool)
• replacing the gateway and pairing the bulb to the new gateway (in this case it can't get an id thats already in the registry as the gateway id is different.)

Note: In almost a year of use I have had no reason yet to reset the gateway to factory defaults as it's a pretty stable product.

[balloob]

I like the idea of using the pairing timestamp, that should never become a duplicate

[NovapaX]

It appears that was a wrong guess and we can't use that.
I checked it on my gateway and that timestamp it corresponds to the date the last firmware version was made available (and installed on my gateway), and not to when I last set it up after a factory reset.

[NovapaX]

Ok, something is getting mixed up here. I am very sorry!
I'm closing this until I sort it out.