Strange groups behavior

I have a light in a group that can’t be controlled from another group or Node Red. Just the light.landing

Here is my groups.yaml:

#groups.yaml:
#

downstairs:
  name: Downstairs Group
  entities:
    - switch.kitchen
    - switch.counterlight
    - switch.dining_room_light
    - switch.hallway_light
    
Upstairs:
  name: Upstairs Group
  entities:
    - light.landing
    - switch.kim_bedroom_light
    - switch.steve_bedroom_light
    - switch.guestbedroomlight
    - switch.officelight
    - switch.kim_desklight
    - switch.kim_sidelight
    - switch.steve_desk_light
    
AllLights:
  name: All Lights Group
  entities:
    - group.downstairs
    - group.upstairs

In my front-end, I have this nice set of controls:

Everything works as expected. The AllLights group is controlled like this:

So, can anyone explain why the All Lights control won’t turn on or off the Landing Light?
Could it be because the Landing Light is the only one in the light domain? All the others are in the switch domain.

I just noticed another oddity. If I turn on, or off any light in the upstairs or downstairs groups, the All Lights group also shows “On” or “Off” as expected. Except for the landing light.

That’s because the landing light is in the light domain, not the switch domain.

Since the landing light is not a switch, I think it needs to go into a separate group. You can change it to a switch with the new helpers.

Create light entities from all your switch lights

Create a light group from those lights (and the landing light) (new group via UI)

According to this others have problems too:

However, the way I think is intended to approach this is to use the “Switch as X” functionality to bring alle the switches into the light domain (seeing as they are lights). That would altogether avoid the mixed group.

But I see @jazzyisj beat me to the punch :smile:

If we gang up on him maybe he’ll believe us :smile:

Or create 1 template switch for the light entity…

True, but then you’re stuck with an old school group of switches or a new switch group.
You can’t create a light group from switch entities.

I considered that, but wouldn’t that require rewriting all of the automations and scripts that refer to, for example, switch.office_light?

If you name your lights the same as your switches are named you can just do a “Replace All” in your code editor for switch.some_light to light.some_light. Rinse and repeat for each switch. Only takes a couple of moments and you gain the light functionality for your new light group. (eg. brightness, colour etc). Don’t forget to change any service calls of switch.turn_on / turn_off that reference those entities to light.turn_on / turn_off also.

If you’ve referenced that group in your code you will have to change that too. The new light group will actually be in the light domain (eg. light.upstairs) so it would be group.upstairs to light.upstairs.

If you’re looking for minimum effort here and just want that toggle to work - you can do as @Didgeridrew suggested and create a switch from the light entity and I believe it will fix that issue. You’ll still need to change any reference of light.landing to switch.landing.

This would be the easy solution, but why can’t I mix light. and switch. domains in a group?

You can. Honestly I would think that toggle should work, it shouldn’t appear if it isn’t supposed to. But I did a test on my own config and had the same behaviour you did with mixed switch lights and light lights.

Did it again as all lights (switch->light and groups → light groups) everything works perfectly.

If you go to the UI of the switch you can create a light entity with the same name from right there, by using the dropdown to say it is a light (or fan, … on other switches that do not have the proper domain).

You can do a global search and replace over the yaml, but you won’t have to. The switch entity keeps working. The UI will just hide it. Later on, if you go to the device, you’ll see both the light entity and the switch entity right there.


I did the replace. The only catch is that is you have device triggers, conditions or actions, you’ll need to change the domain there as well. A quick search over the automations.yaml and script.yaml makes them quite easy to spot, as the domain of the entity does not match the domain mentiond in the device action.

The upside is Lovelace will treat it as a light, you can more easily find all lights, and integrations like Google Home will have the right type by default (although you can select the right type for switches there too).

So I played around a little more with this.

It seems to be only groups of lights and light switches that don’t work correctly. I created some mixed groups of lights and other switches and they all work ask expected (turn off and on when switched by a group in a group). Just additional info if anybody really wants to pursue it.

Just curious, why would Home Assistant behave different for light, if it does not know the switch is a light? Unless there already is an associated Switch as X that makes HA ignore it…

I actually DID have a Switch as X (god I hate that name) set up for the lights I was testing with. Deleted it, restarted just to be sure. Still experience the same behaviour. Group of/on from another group will not control the light entity. Controlling the group itself works fine.

Another thing I noticed, the “master” group toggle actually turns off, but the “child” group toggle doesn’t. The master should not be off if a child is on. (none of these groups have the all parameter set)

Edit: Huh… Just noticed that it looks like the swapped out Switch as X for “Change Device Type Of A Switch” when I went to recreate my light. Interesting. Guess I wasn’t the only one!

image

I like this method better because it doesn’t create a “_2” entity like the helper method does.

Does your light instantly update it’s state in the UI? I.e. if you turn it on from the wall, does it update in the UI?

That shouldn’t do that if the entity name doesn’t already exist. It doesn’t for me

That said, I had never tried changing the switch type right from the switch entity, forgot you could do that! And it does work well.

Yes. No discernable delay.