Ignore lights being turned on with a specific color value and effects.

[maxi1134]

Hi there!
I hope y'all are doing great!

I have this issue where I sometimes turn on lights with specific colors and effects in some automation. (Mainly for accessibility as I don't hear too well ).
Unfortunately, those get turned to white by this integration.

Would it be possible for the tool provided here to ignore lights being turned on with "effect" or "color_name" and its counterparts?

Thanks!

-Maxi1134

[callumgare]

I would also love this! Honestly it’s how I presumed it would work by default and I was very confused when I realised it didn’t seem to work this way. I understand there maybe technical reasons why this is tricky to implement but purely from a user experience perspective if I have a switch or automation or something that turns on a light and explicitly sets a colour when it does so then I would expect that request would be respected.

Without this behaviour it breaks things like scenes. I have a scene to turn on a few accent lights and set them to some soft colours. However when I activate the scene the lights are very briefly turned on to the desired colours but then AL turns them to white. With home assistant scenes I can at least activate the scene a second time and have it work which is annoying but manageable. However I’ll often use the Home app on iOS to control my lights (via the HomeKit integration) and with the Home app scenes work as a toggle, once you turn on the scene tapping it again will turn off the scene and all the lights in the scene. That means you can’t simply activate the scene twice and have it set the colours correctly the second time.

@basnijholt I see you mentioned in a different issue that this is something you were considering looking into #2 (comment) did you ever get a chance to do that?

Least this come across too negative, I should say I love AL and and very much appreciate all the hard work that’s gone into making it!

[th3w1zard1]

Possible duplicate of #2
If you are using take_over_control: true, then as long as you turn the light on before executing the desired state, adaptive lighting will set the light as manually controlled and will stop adapting the light.
Example:

alias: Turn light on with custom settings
sequence:
  - service: light.turn_on
    data: {}
    target:
      entity_id: light.bedroom_ceilingfan_lights
  - service: light.turn_on
    data:
      flash: short
      effect: strobe
      color_temp: 180
    target:
      entity_id: light.bedroom_ceilingfan_lights
mode: single

If you only call the 2nd light.turn_on, and the light is off, adaptive-lighting will adapt the light. Having two separate calls there tells adaptive-lighting that we've turned the light on, and we set it's state., so it'll fire the manual control event.

Sorry if this isn't intuitive but I just looked at the code and I don't see a way around this. If you turn a light on outside of HA, there's no way for adaptive-lighting to know if the color/brightness data was set during turn on or if it was the last state. I tried checking the state change event briefly with the following code:

            # Do not adapt any lights turned on with custom brightness/color_temp/rgb_color
            if (
                ATTR_COLOR_TEMP_KELVIN in new_state.attributes
                or ATTR_RGB_COLOR in new_state.attributes
                or ATTR_BRIGHTNESS in new_state.attributes
            ):
                _LOGGER.info(
                    "%s: Light %s was turned on with custom settings."
                    "Setting as manually controlled.",
                    self._name,
                    entity_id,
                )
                return

but there's no information in the attributes that make this feature request actionable.

In order to implement this, we'd have to log the last state of every light once they're turned off. It just wouldn't be practical, and would open the integration to more potentially hidden bugs down the road.

[maxi1134]

Doesn't the HA has a last_state and new_state under the entity?

I know I access this object using Node-red. Surely the API also has it.

[th3w1zard1]

@maxi1134 would you mind elaborating on how last_state is saved in hass? Do you have any node-red automations you could post utilizing this?

I'm a bit new to home assistant's developer api but I know the config option cache_state exists in zigbee2mqtt, which when enabled will store all prior state changes made to an zigbee device, for use in hass. This behavior makes me think hass doesn't keep a record of state changes.

As far as I'm aware, hass only has a last_state and new_state during state_changed events which don't happen when a device is offline.

[maxi1134]

@maxi1134 would you mind elaborating on how last_state is saved in hass? Do you have any node-red automations you could post utilizing this?

I'm a bit new to home assistant's developer api but I know the config option cache_state exists in zigbee2mqtt, which when enabled will store all prior state changes made to an zigbee device, for use in hass. This behavior makes me think hass doesn't keep a record of state changes.

As far as I'm aware, hass only has a last_state and new_state during state_changed events which don't happen when a device is offline.

Sorry for the tardiness, I was out of the country!

This is what I see in node-red:

[basnijholt]

I am implementing an option adapt_only_on_bare_turn_on which instantly triggers manual_control when turning on with brightness or color in PR #709.

Enabling this will make sure AL doesn't take over when setting a scene.

[zimmra]

I am implementing an option adapt_only_on_bare_turn_on which instantly triggers manual_control when turning on with brightness or color in PR #709.

Enabling this will make sure AL doesn't take over when setting a scene.

This is a big deal IMO, and exactly what I've been hoping for.

My only notable gripe with A.L. has been not being able to utilize scenes/automations/scripts/etc 'as intended' and having to implement additional service calls to get the desired end result.

This is expected for 1.19 release?

[basnijholt]

Yes, it is already in the 1.19.0b3 release 😃

[maxi1134]

This works for me on 1.19.0b4.

Thanks a lot! I've adapted my node-red flows already.