Got "all: true" option for Light Group entity like Group entity

Feature Requests
, , ,
1

Hi

I’m wondering if it was possible to have an option which says. It will state “on” the switch of the lights group only if ALL lights are “on”.

Set this to true if the group state should only turn on if all grouped entities are on
I saw this somewhere for Group entity I think but not on Light Group.

In the moment, I saw that will be “on” as soon as one light is “on”.

However, I have an issue on one bulb (linkquality signal something like that) and sometimes it’s state doesn’t change. So my automation will be broken because this bulb doesn’t have the same state as others.
Is it possible today to get this condition in HA ?

Thank you

Regards

2

This makes no sense. A light group is a collection of lights that act as one, so by definition they are all on when the light_group is on, and all off when the light_group is off.

If that is not the desired use case, then use groups, which already had this functionality.

3

Thank you for your answer

I agree with what you said, but as I said, I think it should have this option because if one of these bulbs doesn’t receive the action, that will directly impact the state of the group light.

Example : I ask to switch off all my livingroom lights using one light group.
But One bulb on Six doesn’t receive the action. It’s stays On.
The state of my group light is ON… It should be OFF because as you said all lights represent only one but in this case it’s wrong… Only one is ON and 5 others are OFF.

Does it make more sense for you?

4

No because every example you have used to justify it involves a defective light.

if one of these bulbs doesn’t receive the action

one bulb (linkquality signal something like that) and sometimes it’s state doesn’t change

But One bulb on Six doesn’t receive the action

The only purpose for this Feature Request appears to be to compensate for a defective light. The obvious solution is: fix the light. :man_shrugging:

1 Like
5

afaik it’s not always true.
If you turn on one light whis is a member of a group, the latter turns on too, regardless state of the rest of lights.

1 Like
6

Yes that’s my problem :).

Indeed in Lovelace, if I turn ON one bulb of this group, the group lights is ON

That’s why I suggested the all true attribute like Group :).

@123 , you said to me “fix your bulb” . OK but what I said, it was just an example for my use case. Some others should exists. What I try to say, it’s that one bulb should not break the sense of the group’s light state which is (control all lights together). If one is defective or even, just one is selected, the state of this group lights could stay unchanged because ALL are not changed.
The famous “all: true” feature. Like that, the state of my group lights will really represent the state of all my bulbs (ON or OFF)

Hopping it’s more clear. My English could be not very well.

7

What other reason besides a defective light?

Anyway, you are under no obligation to justify your Feature Request any further. The proof of its merit will come when it convinces a developer to implement it. Good luck.

2 Likes
8

Then you are using light_group incorrectly. If you are using a light_group you should not be changing the states of the individual lights within, you cannot turn on half or three quarters of a light, it is either on or off.

If you require that flexibility, you can use groups as I stated in my post.

2 Likes
9

Actually you can. Light appliances which consists of several separate lights in nothing unussual nor new. those were over here long before home automation has been invented.
So I would say you are wrong. Especially since current implementation fits such use-case very well.

Despite of that, HA doesn’t disallow to manipulate with lights which are member of light group. So all I say is, that your statement I initially commented on is just false in regard of how it works in HA

And one more thing: groups cannot replace light groups because of lack of light specific features.
So one following your suggestions ends up with very limited functionality

1 Like
10

@anon43302295 Indeed, maybe we should not use “in separate way” but in HA it’s always possible and we can use in separate way.

Maybe you said:

you cannot turn on half or three quarters of a light, it is either on or off.

But you wanted to say:

you should not turn “on” half or three quarters of a light, it is should either “on” or “off”.
image
In this case, my light group is “livingroom lights”. I just switch on “Gledopto 1” and the state is ON but Gledopto 2 is always OFF (of course, it’s contained in the group lights).

And as @maxym said, the Group entity comes with really few features afaik. You can’t manage color, brighness ect ?
Anyway, it costs not so much work for developpers to add just this feature (option). Whatever the use case that the end user wants to use this option at true.

@123

The proof of its merit will come when it convinces a developer to implement it.

When and how the developpers can read my suggested feature ? usually, I write it on Github but here I don’t know how is it working

To finish @123

What other reason besides a defective light?

As I said you always can select only one bulb in the UI. So every cases which turns around of
don't have all lights contained in the group lights which are not in the same state.

Thanks for your answers and I will just wait this option. If there is an other place or way to report a feature, tell me because I don’t know.

11

Think of Feature Requests as a classic ‘wishing well’. You throw a coin into the well, make a wish, and hope it comes true.

There’s no formal process for evaluating, scheduling, or prioritizing Feature Requests. Someone with appropriate software development skills, reads a request, likes what they see, builds it, then submits it as a Pull Request (PR) to Home Assistant’s GitHub Core repository (or Frontend repository). Once submitted as a PR, a formal review process takes place. The development team determines if it is a useful addition, or not.

12

Alright I understand much better the process right now, thank you :slight_smile:

13

It would be very easy to create a binary sensor in yaml that would meet your requirements…


So something like: 
binary_sensor:
  - platform: template
    sensors:
      LightGroupAllOn:
        friendly_name: "All Lights in Group on"
        device_class: lights
        value_template: >-
          {{ is_state('light.light_kitchen', 'on')
             and is_state('light.light_toilet', 'on')
             and is_state('light.light_batchroom', 'on') }}
14

You’re right, for my automations that will be help me to avoid wrong conditions. Thank you.
Until to have my option in Light Group, I will do this.

15

Not at all, I said exactly what I meant.

If you have one light, you cannot switch it half on or half off, you can only switch it on or off. It is completely binary.

The purpose of light_group is to make a group of lights behave as one light. The behaviour you are suggesting is not complimentary to that purpose.

16

and how it applies to light appliances which consist of more separate lights ie bulbs switched separatelly?

BTW. there is a quote from light group docs proving you are drawing wrong assumptions

The group light platform lets you combine multiple lights into one entity. All child lights of a light group can still be used as usual. but controlling the state of the grouped light will forward the command to each child light

Bolded part negates your assumption. the purpose is clearly stated by the first and the last sentence

17

I just don’t think your request will be honored;
we already have a light group sensor and i don’t think they’re going to change the behavior of it ( personally i don’t see need for it, and if I needed it, I’d use the binary sensor I already suggested :wink:)

18

No, it doesn’t. You can use each individual light as you wish, but this topic is about the single light entity that is generated by the light_group component, which is designed to behave as one light, not an aggregation of multiple devices. For the latter we have the group component, as I have stated several times.

19

I’m not commenting on what this topic is about but on your wrong assumption which is not even aligned with docs.
While doc of this component clearly assumes controlling of individual lights you are saying opposite. Let me quote you again

Unfortunatelly it doesn’t work well with lights (and you know about it, don’t you?) And because light groups do the job better than groups it makes me even more confident you are wrong.

20

If you believe that I’m wrong, you are entitled to that opinion.

For balance though, things that would suggest the opposite would be zero votes and that my knowledge of the system has credited me with solving 300 issues on the forums, in contrast with someone who only solved one by pointing out that a thread was a duplicate.