LIFX: add lifx_set_state service call

[amelchio]

Description:

As suggested in #7477, this is a LIFX-specific service that is just like light.turn_on except it does not actually turn on the light (unless asked to).

Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.io#2620

Example entry for configuration.yaml (if applicable):

automation:
  # Reset all lights from our evening fun (but do not light up the whole house).
  - alias: Bright morning light
    trigger:
      platform: time
      after: '06:00'
    action:
      - service: light.lifx_set_state
        data:
          color_temp: 200
          brightness: 200
          transition: 180

Checklist:

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

• Local tests with tox run successfully.

[mention-bot]

@amelchio, thanks for your PR! By analyzing the history of the files in this pull request, we identified @fabaff, @shmuelzon and @BillyNate to be potential reviewers.

[houndci-bot]

undefined name 'get_descriptions'

[balloob]

Wouldn't something like lifx_set_state make more sense ? You're not just adjusting the color, also brightness etc.

[amelchio]

I didn't think lifx_set_state carried much meaning, seeing that every service call is about changing the state. I changed it anyway, at least it does not give the wrong impression like lifx_set_color did.

[balloob]

I guess we can think of other names, set_attributes, set_properties… guess all of them are slightly confusing.

[balloob]

Since it's in LIFX and does not interfere with normal running of hass, I'm fine with it.

[houndci-bot]

undefined name 'changed_power'

[houndci-bot]

comparison to False should be 'if cond is False:' or 'if not cond:'

[houndci-bot]

comparison to True should be 'if cond is True:' or 'if cond:'

[amelchio]

I changed the service call into lifx_set_state and gave it the capability of also turning off the light. It now matches the LIFX HTTP Set State pretty well and is also what @keatontaylor suggested in issue 4005 (except it is not global and thus does not help Flux).

[keatontaylor]

I really hate to stay this, especially considering that personally I really want to see this functionality, but I think these types of changes that are to a single platform but drastically change the method in which automations will interact with lights is the wrong direction in an effort to unify components into a single platform.

If each of the light components offered bundled technology outside the scope of the core light component in HA we lose the ability to control lights across platforms in a unified way. This type of fragmentation is something I would highly wish to avoid, especially in a component such as lights that I strongly feel needs to be reworked in order to provide some consistency among the different type of lights.

Overall I'd prefer the unification and abstraction of the light component so that we can prevent code duplication and provide a highly coherent and cohesive platform for further development.

@amelchio, @balloob I would like to hear your thoughts if you have time.

[amelchio]

@keatontaylor I do agree with your vision, which is why I started out with #7477. Read the "Alternatives" and "Further work" sections to see how I think this should preferably be done (it matches your thoughts).

However, I honestly do not see that goal being reached any time soon. For a unified solution, we need motivated non-LIFX developers to step up as well.

I think it's a shame that Hue etc. owners are missing out but at the same time I am not going to forfeit functionality just to promote some higher purpose. Hence this PR.

[balloob]

There is currently no common ground for set_state functionality outside of LIFX, as they are the only ones that implement it. Once a couple of light systems come available that support this, we can reconsider.

For now, it's the only way any of this functionality can be made available.

If each of the light components offered bundled technology outside the scope of the core light component in HA we lose the ability to control lights across platforms in a unified way.

I think that this is a tad dramatic. All functionality that is shared across multiple platforms will still be available. Just not edge cases like changing the state on a device that's off. We'll be fine.