Are light groups supposed to ignore "off" light's brightness?

Configuration
1

From what I can tell for the brightness of a light group (see light/group.py) it takes the arithmetic mean of all of the returned brightness attributes in the group and sets it as the groups brightness.

The result is if a light it turned off it doesn’t return a brightness attribute so 0 isn’t included in the mean calculation. So if one light is turned off in say a group of four lights the brightness is currently reported as 100% rather than 75%.

I’m trying to decide whether this is intentional or a bug? I could see it being useful to only know the brightness of only lights in the group that are on, but Id think it might be more useful to know if a light group isn’t at 100% when one of the lights is off.

Is there design behind this and if so what?

2

I’ve not looked into this but the above would make sense. If a light is off, it’s not dimmed, therefore brightness is not available (so not 0)
it therefore makes sense that the brightness is 100% of all other 3 lights are on full brightness.
If you were to set you 1st light to 1% brightness then it would be taken into consideration
Guess what you’re after is not so much an average brightness to see which light is off but a count of lights that are on?
If so have a look at the for loop example in the template section of your HA

3

This is by design. If you want to know that all your lights aren’t on, build a template that does that. You have to list out the entities inside the template in order for the template to update every time one of the lights inside of the group is updated.

You can doctor this template to get the other brightness.

light:
  - platform: group
    name: Kitchen Lights
    entities:
      - light.kitchen_ceiling_lights
      - light.kitchen_under_cabinet_lights
      - light.kitchen_spot_lights
      - light.pendant_lights

sensor:
  - platform: template
    sensors:
      light_count:
        value_template: >
          {% set lights = [
                states.light.kitchen_ceiling_lights,
                states.light.kitchen_under_cabinet_lights,
                states.light.kitchen_spot_lights,
                states.light.pendant_lights ] %}
          {% set lights_on = lights | selectattr('state','eq','on') | list %}
          {{ lights_on | length }} of {{ lights | length }} lights {{ state_attr('light.kitchen_lights','friendly_name') }} are on.

Your other option is to change the light group calculation on your local system by making it into a custom component.

4

It sounds like the current implementation is intentional and wanted in general, so I’m probably going to take your advice @petro and just make a custom component. Personally I look at the light group as a way to control and see the status of multiple lights at once so if I’m referencing the brightness attribute I’m not looking at the brightness of the lights that are on, I’m wanting to know how bright the room or area is in general. Using “on_states” makes sense in light groups for things like color temp where a light not being on doesn’t affect that attribute for all the lights as a whole, but the brightness of the group is affected by lights that aren’t on.

You guys are right though that I’m wanting to know if there are lights in the group that aren’t on since I’m comparing the current status of the light group with a scene to see if I’m still at that scene or not. When lights are off for some reason it throws off things since the room might be mostly dark with only one light matching that scene but the system thinks it is at the scene. I’m trying to avoid comparing with every single light in the group though since then if I ever add another light or move something I’ll have to go back and edit all of my automatons and scripts rather than adding or removing lights from groups.

5

I really like your use of the sensor template here, it is very cleverly done! I haven’t used a sensor template much and think I might have to start using them more. Thanks for sharing!

6

The unfortunate side to groups is that they cannot be used as triggers or in templates the way you want to use them. Triggers and templates only update when reference entity_id is updated. When you use just the group, it only triggers/updates on group changes, not the groups entities. Super annoying. If you want that functionality, you should move towards appdaemon or python scripts.

7

Sorry I should have been more specific. I meant light group instead of group.

So far with the light group I have been able to trigger and use them in templates when one of the entities inside of it changes because it takes the mean of the attributes in the entities. This is why the brightness not working as expected has caused some issues in my system when one of the lights is turned off.

I am interested in checking out appdaemon or custom python scripts eventually, but I’m not quite ready to commit the time necessary to learn and dive that deep yet. I still have tons of projects I can accomplish with the basic functionality.