-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
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 support for light color modes #47720
Add support for light color modes #47720
Conversation
Hey there @rytilahti, @zewelor, @shenxn, mind taking a look at this pull request as its been labeled with an integration ( |
I would expect Google, Alexa and Homekit requiring updates because of this PR |
# If a color is specified, convert to the color space supported by the light | ||
# Backwards compatibility: Fall back to hs color if light.supported_color_modes | ||
# is not implemented | ||
if ATTR_HS_COLOR or ATTR_RGB_COLOR or ATTR_XY_COLOR in params: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tests if ATTR_HS_COLOR
is truthy, ATTR_RGB_COLOR
is truthy, or ATTR_XY_COLOR in params
. The first two are defined so this code is always executed?
if ATTR_HS_COLOR or ATTR_RGB_COLOR or ATTR_XY_COLOR in params: | |
if ATTR_HS_COLOR in params or ATTR_RGB_COLOR in params or ATTR_XY_COLOR in params: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, tests are needed for the new code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't you use intersection here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if more readable:
if params.keys() & {ATTR_HS_COLOR, ATTR_RGB_COLOR, ATTR_XY_COLOR}:
You can also do
if any(key in params for key in (ATTR_HS_COLOR, ATTR_RGB_COLOR, ATTR_XY_COLOR)):
if (xy_color := params.pop(ATTR_XY_COLOR, None)) is not None: | ||
params[ATTR_HS_COLOR] = color_util.color_xy_to_hs(*xy_color) | ||
|
||
elif COLOR_MODE_RGB in supported_color_modes: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sure every fallback has a test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, the tests for the light component needs to be updated to test the new features as well as all the backwards compatibility cases.
): | ||
# Backwards compatibility for rgbw_color added in 2021.4 | ||
# Add warning in 2021.6, remove in 2021.10 | ||
r, g, b = color_util.color_hs_to_RGB(*self.hs_color) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r, g, b = color_util.color_hs_to_RGB(*self.hs_color) | |
# pylint: disable=invalid-name | |
r, g, b = color_util.color_hs_to_RGB(*self.hs_color) |
Does it mean those integrations will need to be updated to handle the new colour modes, rgbw and rgbww? |
8f9a1da
to
7c843a9
Compare
@Koenkk could you have a look at this from a z2m perspective? |
@dmulcahey, @Kane610 Can you review the proposal from the perspective of zha / deconz? |
Nothing jumps out for ZHA. LGTM Please notify me when this gets merged (in case I miss it), and I'll test it, update ZHA if needed. |
@emontnemery looks good, 2 things however:
{"state": "ON", "brightness": 100, "color": {"x": 0.7, "y": 0.3"}, "color_mode": "color_mode_xy"}
The |
elif ATTR_HS_COLOR in params and COLOR_MODE_HS not in supported_color_modes: | ||
hs_color = params.pop(ATTR_HS_COLOR) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could go all wallrus:
elif ATTR_HS_COLOR in params and COLOR_MODE_HS not in supported_color_modes: | |
hs_color = params.pop(ATTR_HS_COLOR) | |
elif COLOR_MODE_HS not in supported_color_modes and (hs_color := params.pop(ATTR_HS_COLOR, None) is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It becomes 4 lines instead of 2 after formatting though:
elif (
COLOR_MODE_HS not in supported_color_modes
and (hs_color := params.pop(ATTR_HS_COLOR, None)) is not None
):
color_mode = self._light_internal_color_mode | ||
|
||
if color_mode not in self._light_internal_supported_color_modes: | ||
_LOGGER.debug( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we log this as error
the first time per-entity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should start doing that in 1-2 releases, not yet. I added a comment in 63e4f4d.
I agree, changed in 577f787.
For an MQTT JSON light, I think we should add two new configuration variables:
For a light which is configured with
I agree, changed in 577f787. |
Forget about this, just saw #47993 |
Proposed change
Add support for light color modes, background in home-assistant/architecture#519.
The color mode will be stored in the light's state, but should not be passed to the
turn_on
service call.When turning on the light, the color mode is non ambiguous because only one color may be given.
Colors will no longer be force-converted through hs color space when updating state or in a
turn_on
call, instead the light's native color space will be respected.New attributes:
Defined color modes:
New methods added to the base component
LightEntity
:color_mode
supported_color_modes
rgb_color
rgbw_color
rgbww_color
xy_color
For backwards compatibility:
supported_color_modes
, it will be calculeted based onsupported_features
color_mode
, currentcolor_mode
will be guessed in the following order:COLOR_MODE_RGBW
if the light'swhite_value
andhs_color
are notNone
COLOR_MODE_HS
if the light'shs_color
is notNone
COLOR_MODE_COLOR_TEMP
if the light'scolor_temp
is not NoneCOLOR_MODE_DIMMER
if the light'sbrihtness
is not NoneCOLOR_MODE_NONE
otherwisesupported_color_modes
, aturn_on
service call withATTR_RGBW_COLOR
will be converted toATTR_HS_COLOR
+ATTR_WHITE_VALUE
.Deprecated:
Type of change
Example entry for
configuration.yaml
:# Example configuration.yaml
Additional information
Checklist
black --fast homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.The integration reached or maintains the following Integration Quality Scale:
To help with the load of incoming pull requests: