Disallow ambiguous color descriptors in the light.turn_on schema#7765
Merged
Conversation
houndci-bot
reviewed
May 25, 2017
e99cbdf to
d4abb55
Compare
d4abb55 to
f919659
Compare
f919659 to
46bd75a
Compare
46bd75a to
d7121e6
Compare
Contributor
Author
|
I'm torn about |
emlove
approved these changes
Jun 1, 2017
Contributor
emlove
left a comment
There was a problem hiding this comment.
I like this idea.
I think color temp is an appropriate inclusion. It's really just another definition of a color. A light can't use an RGB color and a color temp at the same time.
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description:
There are quite a lot of different ways to specify colors and making them mutally exclusive seems simpler than making rules of precedence.
Strictly speaking, this is a breaking change: previously you could have an XY and an RGB light in a group and make one light red and the other one blue with a single service call. I don't think losing that ability will be an issue. Also, profiles can no longer have their xy-value overwritten, only the brightness. Again – not a real loss.
The real breaking change is that it will now point out some configurations that have previously been ambiguous or redundant.
I have pooled
color_tempwith the color-setting ones because I think it should imply a white color.The
white_valueis not included due to it being separate from all the others. In an RGBW light, thewhite_valueaffects the W while all the others affect the RGB.Opinion can probably differ on the above points and I am prepared to adjust given some sensible arguments :)
Breaking change notice: The
lightcomponent will now refuseturn_oncalls that specify redundant or ambiguous colors, such as using bothcolor_nameandcolor_rgbin the same call.Checklist:
If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
toxrun successfully. Your PR cannot be merged unless tests pass