Introducing Distinct Color Temperature Selectors: Mireds and Kelvin

[schelv]

Proposed change

Described in home-assistant/core#101990 .

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

color_temp_mired:

color_temp_kelvin:

Additional information

Also described in home-assistant/core#101990 .

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[bramkragten]

This would be a breaking change, because we remove an existing used selector.

Instead, we should add a mode parameter to the existing color temperature selector, this should default to mired, to not be breaking.

[schelv]

This would be a breaking change, because we remove an existing used selector.

The existing selector is still there!
So no breaking changes.
I did remove it from the documentation, and renamed the file and the class, to avoid further usage.

Instead, we should add a mode parameter to the existing color temperature selector, this should default to mired, to not be breaking.

This direction was something I considered.
But having min_mireds, max_mireds, min, and max configuration variables at the same time? 🤢
Combining mired and kelvin in one class also doesn't give code that is easy to read and understand, because of all the switch statements that have to be introduced.

[frenck]

But having min_mireds, max_mireds, min, and max configuration variables at the same time? 🤢

We can guard that. keeping min_mireds & max_mireds in backwards compatible. From the Core end, we can also handle that in the schema to migrate.

[schelv]

We can guard that. keeping min_mireds & max_mireds in backwards compatible.

I'm not quite sure what you mean by this.

From the Core end, we can also handle that in the schema to migrate.

I hadn't considered migration because I'm unsure how it would apply to blueprints. If migration is possible, does that not imply that maintaining backwards compatibility is unnecessary, since everything could be migrated?

[schelv]

New attempt to solve the problem in #18627