home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.42k stars 30.66k forks source link

Flux RGBW Bulb Error on light.turn_on #15566

Closed rrubin0 closed 6 years ago

rrubin0 commented 6 years ago

Home Assistant release with the issue: 0.73.1

Last working Home Assistant release (if known): 0.72.1 ( worked perfectly )

Operating environment (Hass.io/Docker/Windows/etc.): Hassio running on Ubuntu Server

Component/platform: Flux (RGBW) LED Light Bulb

Description of problem: Unable to perform light.turn_on in 0.73.1 (LoveLace UI) Effects still function using UI light.turn_off still functions using UI

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

light:
  ### office desk lamp
  - platform: flux_led
    devices:
      !secret office_desk_lamp_host:
        name: office_desk_lamp
#
# if using the developer console services, light no longer turns on but turns off via this method:
Service
light.turn_on

Entity
light.office_desk_lamp

Service Data (JSON, optional)
{
  "entity_id": "light.office_desk_lamp"
}

Traceback (if applicable):

2018-07-19 22:29:34 ERROR (MainThread) [homeassistant.core] Error executing service <ServiceCall light.turn_on: entity_id=['light.office_desk_lamp']>
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/homeassistant/core.py", line 1021, in _event_to_service_call
    await service_handler.func(service_call)
  File "/usr/lib/python3.6/site-packages/homeassistant/components/light/__init__.py", line 360, in async_handle_light_service
    await light.async_turn_on(**params)
  File "/usr/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/lib/python3.6/site-packages/homeassistant/components/light/flux_led.py", line 266, in turn_on
    self._bulb.setRgbw(*tuple(rgb), w=white, brightness=brightness)
  File "/usr/lib/python3.6/site-packages/flux_led/__main__.py", line 868, in setRgbw
    raise Exception
Exception

Additional information:

rrubin0 commented 6 years ago

TEST 1: GUI CONTROL Turn light on via GUI = OK; no errors Open colorpicker in GUI = presented with menu which now includes "white value" slider increase white value via slider = no effect; no errors increase brightness via slider = no effect; no errors choose new color from colorpicker via GUI = no effect; no errors Turn light off via GUI = OK; no errors

TEST 2: Service Calls via Input Select Menu Select option in my input select list "cool" = no effect; no errors; entry in log "executing step call service" but light does not turn on; GUI shows light is on and is supposed to be at a white value; no errors

(and now it is not responding to on/off or color changes via GUI; GUI icon reflects the color it thinks it should be but light does not respond; no errors)

Select option "random" input selection = light turns on and is able to randomly pick a color (light responds to on/off commands after this option is selected; no errors) (also, if I now change a color via the colorpicker, the color does not change, the light responds to off command, but will not respond to an on command) Selecting my predefined "warm or warm dim" settings from the input select list have no effect; no errors

Selecting ANY effect from the GUI menu works like a charm (strobe; crossfade; color jump/loop) but brightness control is unresponsive and interrupts the effect; no errors

VERDICT (thus far) = The light only responds to on/off and effects...BUT If any value changes are attempted (color, brightness, white level) the bulb will become unresponsive to all commands except the OFF command until the last state was an "effect" setting or random color (aka a working mode).

All of the above tests were performed sequentially, with the same configuration used as the 'custom component' code (from 0.72.1)

btreecat commented 6 years ago

Excellent work! This is exactly my experience with my bulb.

-- Stephen Tanner Part 107 Certified Drone Pilot Web, Research, and Cloud Application Developer Virginia Tech Transportation Institute https://TannAir.com https://StephenTanner.com

On Thu, Nov 1, 2018, 01:07 Rick Rubino <notifications@github.com wrote:

TEST 1: GUI CONTROL Turn light on via GUI = OK; no errors Open colorpicker in GUI = presented with menu which now includes "white value" slider increase white value via slider = no effect; no errors increase brightness via slider = no effect; no errors choose new color from colorpicker via GUI = no effect; no errors Turn light off via GUI = OK; no errors

TEST 2: Service Calls via Input Select Menu Select option in my input select list "cool" = no effect; no errors; entry in log "executing step call service" but light does not turn on; GUI shows light is on and is supposed to be at a white value; no errors

(and now it is not responding to on/off or color changes via GUI; GUI icon reflects the color it thinks it should be but light does not respond; no errors)

Select option "random" input selection = light turns on and is able to randomly pick a color (light responds to on/off commands after this option is selected; no errors) (also, if I now change a color via the colorpicker, the color does not change, the light responds to off command, but will not respond to an on command) Selecting my predefined "warm or warm dim" settings from the input select list have no effect; no errors

Selecting ANY effect from the GUI menu works like a charm (strobe; crossfade; color jump/loop) but brightness control is unresponsive and interrupts the effect; no errors

VERDICT (thus far) = The light only responds to on/off and effects...BUT If any value changes are attempted (color, brightness, white level) the bulb will become unresponsive to all commands except the OFF command until the last state was an "effect" setting or random color (aka a working mode).

All of the above tests were performed sequentially, with the same configuration used as the 'custom component' code (from 0.72.1)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/home-assistant/home-assistant/issues/15566#issuecomment-434932016, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO3HOsqhePPcmfCUuiElH-Uc4BnGxcgks5uqoGRgaJpZM4VXfBB .

oblogic7 commented 6 years ago

I don't see any mention of whether or not you tested with mode: 'RGBW' set on the config. Can you confirm that you added that before testing?

rrubin0 commented 6 years ago

Mode RGBW is the default to my knowledge. My config is posted in /packages/office if you want to look. I’m mobile so I can’t link as well.

oblogic7 commented 6 years ago

You do have that mode set on your config. I'm curious to know how the light behaves if you set mode: rgb. If that doesn't improve anything, try removing the mode completely. That will cause the component to use whatever mode the bulb/library is returning. Let me know if either of those cases behave differently.

rrubin0 commented 6 years ago

OK, I was able to re-test just now. As requested, I changed the flux_led bulb mode from RGBW to RGB and restarted HA using 0.81.2 default code/library. Results are as follows:

Turn light on via GUI = OK; no errors Open colorpicker in GUI = presented with menu which does not include a "white value" slider increase brightness via slider = OK; no errors choose new color from colorpicker via GUI = OK; no errors Turn light off via GUI = OK; no errors Select option in my input select list "cool" = OK; no errors increase/decrease brightness via slider = OK; no errors Select option in my input select list "warm" = no effect; no errors - FAIL

VERDICT: All functions of the bulb work properly (including effects, random, strobe) EXCEPT selecting 'warm' white light (via input_select); no errors. Since the white light is primarily what I use on this light, it is a deal breaker to use this as a long-term workaround.

oblogic7 commented 6 years ago

That is helpful. Sounds to me like the bulb is reporting that it is RGBW compatible, but requires the white level to be set via the warm white functions on the library. I will take a look at the code and see if there is a way we can work around that or if there is a way that the library can already handle this situation.

btreecat commented 6 years ago

This is exactly why I tried to detect the difference in input commands and then if detect warm white, call the setWarmWhite() method instead of the setRGBW().

Setting the bulb to RGB works fine for color but doesn't support the warm white channel.

I don't think it's reliable to have a predefined hard coded list of bulb Id that work with rgbw/rgb/w modes. It's a great way to play whack-a-mole with hardware support. But not sure what the alternative is other than just require a bulb to have a mode be set and trusting it.

Additionally there is a cold white channel (w2) in the underlying library. Does the ha light package support more than one white ch option or an ability to pick one or the other? I hadn't had time to look into that deeply enough.

-- Stephen Tanner Part 107 Certified Drone Pilot Web, Research, and Cloud Application Developer Virginia Tech Transportation Institute https://TannAir.com https://StephenTanner.com

On Fri, Nov 2, 2018, 09:47 Matt Snyder <notifications@github.com wrote:

That is helpful. Sounds to me like the bulb is reporting that it is RGBW compatible, but requires the white level to be set via the warm white functions on the library. I will take a look at the code and see if there is a way we can work around that or if there is a way that the library can already handle this situation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/home-assistant/home-assistant/issues/15566#issuecomment-435385067, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO3HKcxZcFwm6sqaf0ACFhBe8sPj0TEks5urEzTgaJpZM4VXfBB .