Allow independent control of white level on flux_led component#13985
Allow independent control of white level on flux_led component#13985balloob merged 5 commits intohome-assistant:devfrom
Conversation
Also preserve brightness on color change.
| random.randint(0, 255), | ||
| random.randint(0, 255)) | ||
|
|
||
| #effect selection |
There was a problem hiding this comment.
block comment should start with '# '
| if rgb is not None: | ||
| self._bulb.setRgb(*tuple(rgb), brightness=self.brightness) | ||
|
|
||
| #brightness change only |
There was a problem hiding this comment.
block comment should start with '# '
| from homeassistant.const import CONF_DEVICES, CONF_NAME, CONF_PROTOCOL | ||
| from homeassistant.components.light import ( | ||
| ATTR_BRIGHTNESS, ATTR_HS_COLOR, ATTR_EFFECT, EFFECT_COLORLOOP, | ||
| ATTR_BRIGHTNESS, ATTR_HS_COLOR, ATTR_EFFECT, ATTR_WHITE_VALUE, EFFECT_COLORLOOP, |
There was a problem hiding this comment.
line too long (84 > 79 characters)
|
Please check the travis builds for lint errors, too: |
| @property | ||
| def white_value(self): | ||
| """Return the white value of this light between 0..255.""" | ||
| return self._bulb.getRgbw()[3] |
There was a problem hiding this comment.
Currently, the light entity will request the white_value even if not SUPPORT_WHITE_VALUE. Will this raise an error ?
There was a problem hiding this comment.
Retrieving index 3 should not directly result in an error because the flux_led library will always return something on that index even if None. So it would depend on how the code calling white_level handles the values. I can add a sanity check if None or non integer values are not supported.
There was a problem hiding this comment.
If it's None, then it's fine as that is the expected return value for "no value"
|
Seeing as this is the most recent change to the flux component, I'm kind of certain it's what broke it for me. As it stands all I'm able to do is turn the device on/off and change the brightness of the Log isn't throwing any obvious errors. |
|
The change on this PR separated the W channel on RGBW to the white level slider instead of controlling W via the brightness slider. This makes sense because RGB brightness should be controllable independently of W brightness. After looking at this for just a few minutes, I see that the flux.switch component uses xy_color and brightness to control color temperature, so I expect that the flux.switch component is expecting the W channel to respond to brightness level. Don't have time to dig any further tonight, but I think that adding support to flux.switch for RGBW mode would possibly make this work as expected. I will hopefully have time to look into it more tomorrow. |
|
Also since the latest update, it's broken scenes for me with the flux_LED component. Specifically if I send both RGB and Brightness settings, it changes the RGB but ignores the brightness change. This is true for both RGB and RGBW units. If I send the brightness change on its own it works fine, but coupled with colour change it ignores the brightness. So: ....alters the colours only. .... changes the brightness. The YeeLights in this same scene operate as normal, so it does appear to be a specific problem with the lux_LED component. And it ocurrs whether using brightness or brightness_pct This problem is also present when directly doing this via the Services tab in Hassio. |
|
I've opened a new PR that should correct the issues that were introduced. If either of you can confirm the fixes it would be great. |
|
Total noob, so have no idea how to install this sorry. Thanks for getting onto it so quickly. |
Description:
Allows independent control of white level on flux_led lights in RGBW mode. Also preserve brightness on color change.
Checklist:
tox. Your PR cannot be merged unless tests pass