Add color_mode white

[emontnemery]

Proposed change

Add color_mode white

This is useful for RGBW type lights which don't support independent control of all channels; the light can be set to either white or a color, similar to a zigbee hs + color_temp light which can be set to either a color or white with adjustable color temperature but not both.
RGBW lights which allow independent control of all 4 channels should be using color_mode rgbw instead.

This adds a new parameter white (0..255) to the light.turn_on service. There's no new white state attribute.
Passing a valid white will set the light's brightness to the value aof white and set the light's color_mode to white

While similar to the deprecated white_value, this is not exactly the same:

• white_value was poorly documented, and integrations hence treated it differently
• white_value was present as a state attribute

To set the light in color_mode white:

Service call: {"service": "light.turn_on", "data": {"white":50}}
Light state after the call: {"color_mode": "white", "brightness": 50}

It's allowed to pass both brightness and white in the service call, in that case the brightness has priority and the passed brightness will be forwarded as "white" to the light.

Example:
Service call: {"service": "light.turn_on", "data": {"white":50, "brightness": 100}}
Filtered service call to the light: {"service": "light.turn_on", "data": {"white":100}}

If white is 0 the call will be converted to a turn off call:
Service call: {"service": "light.turn_on", "data": {"white":0}}
Filtered service call to the light: {"service": "light.turn_off"}

But brightness still has priority:
If white is 0 the call will be converted to a turn off call:
Service call: {"service": "light.turn_on", "data": {"white":0, "brightness": 100}}
Filtered service call to the light: {"service": "light.turn_on", "data": {"white":100}}

Type of change

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

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• 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

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

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[emontnemery]

I'm not entirely sure why this is needed, is it in case __eq__ is overridden to not return a bool?
Would it be more correct to hint that cur_color_mode and saved_color_mode are strings?

[MartinHjelmare]

Yes, if typing the attributes avoids the cast, that's better.

[frenck]

The white color mode is suboptimal, but merely here for handling exceptional cases. So I think this is OK.

It needs updates on the developer documentation, and I suggest we make clear this mode should only be used solving those specific cases.