Remove global limit on white light temperature

[amelchio]

Description:

Here are the supported temperatures of some popular bulbs:

Philips Hue: 2000K-6500K (the current 500-154 mired range)
LIFX Color 1000: 2500K-9000K
IKEA TRÅDFRI: 2200K, 2700K, 4000K

Obviously, Home Assistant cannot enforce a global limit and work properly
with all of these bulbs. So just remove the limit and leave it up to each
platform to work it out.

This commit updates the existing users and adds a clamp to Hue (where the
limit appears to have originated). It does not attempt to update other
platforms that might need extra handling of the larger range that is now
possible.

The UI also has a hardcoded range for the temperature and it would probably be good to scale it to the supported range of the current bulb. Unfortunately, that range is generally unknown.

@cgrin @armills what do you think of this?

Related issue (if applicable): fixes #6606

Checklist:

If the code communicates with devices, web services, or third-party tools:

• Local tests with tox run successfully. Your PR cannot be merged unless tests pass

[mention-bot]

@amelchio, thanks for your PR! By analyzing the history of the files in this pull request, we identified @armills, @leoc and @balloob to be potential reviewers.

[cgrin]

This should solve the issue of LIFX commands with color temps above 6500K being ignored, and looks like it sets Hue bulbs to 6500K in the event a command is sent with a higher temp. Given that, the changes I made in home-assistant/frontend#243 should work to update the temp slider ranges in the UI.

[emlove]

I don't think any change to this logic makes sense unless there is a plan in place for the frontend. I think the easiest step forward at the moment is to broaden the hass range to support all platforms, (so 2000K-9000K), and update the frontend respectively. (So use @cgrin's PR) Individual platforms can then apply their own clamps where required.

[amelchio]

That could also work, though I think it is odd to enforce a range that is wrong in every single case. In that case I would rather not enforce anything (just like color_name will accept every string).

How about a kelvin_range property on each light? The frontend would use that to scale the slider. To get started, the light component could default it to the current range.

[balloob]

I prefer platforms to get properties min_mireds and max_mireds that are exposed as attributes so that we don't have to guess or assume things in the frontend.

[amelchio]

I will add the attributes that @balloob suggests. Hopefully someone else can do the frontend.

As you can have a group of lights with different ranges, I think my initial commit still makes sense. It is just impossible for the core to do the check.

[houndci-bot]

whitespace after '['
whitespace before ']'

[houndci-bot]

whitespace after '['
whitespace before ']'

[amelchio]

I added global and LIFX min_mireds and max_mireds now. I do not feel comfortable updating the platforms where I don't have any hardware to test.

[balloob]

Bueno! 🐬

[ajma]

Can we update the documentation on how to use min_mireds and max_mireds too? I can do it if you give me an example

[amelchio]

@ajma There is nothing to update, these are internal values like for example supported_features that each light platform provides to tell the UI about their capabilities.