Set light parameters while off workaround using a virtual dummy light

Configuration
,
1

Hey guys. I need some help for something I want to do with my lights.

My main goal is to have control over my lights temp/color/brightness without having to turn them on. I imagine for example saying that at 5pm, any light that is on or gets turned on after that time should have warm temperature. At 12pm, any light that is on or gets turned on should have a red color so I don’t blind myself at late hours. These are just examples.

I haven’t been able to find out a way to detach temp/color/brightness settings from on/off state for lights (and if there is please point me to it!) and it appears it is not possible with most light brands. The closest discussion I found was this one, and while the solution of having separate helper numbers and setting those values every time I call light.turn_on would be plausible, I’m trying to create a less cumbersome solution. I feel I’m pretty close and just need help figuring out some small blockers.

My current idea is to have a virtual dummy light, which is always on, and which will have the current setting for my parameters of interest. Then, after any light state is changed, I retrieve all turned on lights, and set their parameters to the ones on the dummy light. Doing this I only need to automate my dummy light’s parameters with all available methods for managing lights, and I have the option of not setting those values on every light.turn_on as long as I don’t care about momentary state change after turning on the light.

Here’s how much progress I have on this idea:

  • I already have a dummy light using HACS Virtual Components integration

  • I have a way of polling all turned on lights on light state change and dynamically adding/removing them from a group with the following automation:

alias: Update turned on lights group
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.lights_on_number
condition: []
action:
  - service: group.set
    data:
      object_id: turned_on_lights
      entities: >-
        {{ states.light | selectattr('state', 'equalto', 'on') |
        map(attribute='entity_id') | join(',')}}
  - service: group.set
    data:
      object_id: turned_on_lights
      remove_entities: light.all_lights, light.ceiling_lights
  - service: group.reload
    data: {}
mode: single

What is missing:

  • Have an automation run on any dummy light state change, so that the dummy light state for the parameters of interest is copied to the turned on lights group.

Here are my current issues:

  1. I don’t want my group.turned_on_lights to contain any light group. This is because I could have a group only partially on, and modifying the state of the group would turn on the other lights. You may have seen I have an instruction for this on my automation, where I’m removing some groups. I would like to know if there’s an automatic way of getting the list of lights that are actually groups.

  2. I can’t call light.turn_on service on group.turned_on_lights because it is not a light. The UI does allow me to modify parameters of this group as a normal light though. Is there any way I can turn this group into a light? Or create it as a light group in the first place?

I believe solving those two issues would allow me to create this automation. Any help or feedback is highly appreciated. Thanks!

2

Light groups created via a Helper or YAML configuration can be rejected using |rejectattr('attributes.entity_id', 'defined') , but you may need to manually update the template to accounts for group created by other integration such as zigbee groups which do not have unique attributes. Optionally for those situation or other random lights you want rejected, you can add custom attributes in configuration.yaml. This can be especially useful for entities like indicators or screens that fall under the “light” domain, but shouldn’t be treated like elements of room lighting.

You can pass the list of light entities in your group to the target of light.turn_on

service: light.turn_on
target:
  entity_id: "{{ state_attr('group.turned_on_lights', 'entity_id') }}"
3

This was perfect! Thanks for that! For the second blocker I had I realized that while the UI doesn’t allow me to set group.turned_on_lights as my entity id for light.turn_on, it still worked if I passed that value through YAML.

Again thanks a lot! I can finally move forward with this :grin: