Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add color_mode white #51411

Merged
merged 4 commits into from
Jun 6, 2021

Conversation

emontnemery
Copy link
Contributor

@emontnemery emontnemery commented Jun 3, 2021

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:

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:

# Guard for scenes etc. which where created before color modes were introduced
if saved_color_mode == COLOR_MODE_UNKNOWN:
return True
return cast(bool, cur_color_mode == saved_color_mode)
Copy link
Contributor Author

@emontnemery emontnemery Jun 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@frenck frenck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@emontnemery emontnemery merged commit e560e62 into home-assistant:dev Jun 6, 2021
@home-assistant home-assistant deleted a comment from AMODLT Jun 7, 2021
@home-assistant home-assistant deleted a comment from AMODLT Jun 7, 2021
@github-actions github-actions bot locked and limited conversation to collaborators Jun 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants