Does anyone know if groups within groups are treated any differently than if I added the sub-group's constituents? I have a hierarchy of groups (e.g., "main lights" are all common area lights, and "all lights" are all lights, including those in main lights), and am wondering if there's any difference between the two styles of group creation. In my example, when I go to construct the "all lights" group, I could either a) add the "main lights" device + all the extra lights or b) add every individual bulb and dimmer.
I do groups within groups. In my case I have a set of groups for each room (e.g. Living Room, Rec Room, Upstairs Bathroom, etc.), then a set of groups for each floor (e.g. Main Floor, Upstairs), then a master group (e.g. All the Inside Lights). For the second set, such as Main Floor, I select the room groups and any necessary individual lights that aren't part of a room. The 'All the Inside Lights' group is each floor group. I use groups in RM rules where possible to make adding/removing individual devices easier and less disruptive. I also use groups with my Amazon Echo where possible to make voice controls easier to manage and more intuitive.
Personally I don't understand why you would want to do this. Groups only allow you to control all the included lights together. If you want to have a function that turns all the lights in the house off, it is much easier to create a virtual switch or button that when activated would trigger a rule to turn all the lights off. Creating a group to do this function will add unnecessary overhead to the hub. In order to get this function from a group, the hub will have to update the group device every time any of the members change. And if you have that group within another group, that's another device that would have to change. Where does it end? I think there are much easier ways to accomplish what you are trying to do. Other than turning off, when do you ever want to do the same function with all the lights in your house?
1 Like
There is a need to do this. For example I want to create different lighting scenes with a group of lights where a subset of lights are on and some are off. Without groups every scene has to know about all the lights and has to set them up according. If I want to change lights in scenes then I have to update every scene for all the lights within them. With groups and sub groups then I can just add or remove from one of the groups instead.
For example I have two lights in the front on a room( front1 & front2) and two side lights (side1 & side2) and two rear lights (rear1 & rear2). IN order to have five scenes front(turns on front lights), center(turns on side lights), rear (turns on rear lights), allOn(turns all lights on), and allOff(turns all lights off).
Without groups I would have to mix all lights with all the scenes:
front= front1:on, front2:on, side1:off, side2:off, rear1:off,rear2:off
center= front1:off, front2:off, side1:on, side2:on, rear1:off,rear2:off
rearr= front1:off, front2:off, side1:off, side2:off, rear1:on,rear2:on
allOn= front1:on, front2:n, side1:on, side2:on, rear1:on,rear2:on
allOff= front1:off, front2:off, side1:off, side2:off, rear1:off,rear2:off
If I want to change it this is a big maintenance nightmare.
With groups I can instead just do:
frontGroup=front1,front2
centerGroup=side1,side2
rearGroup=rear1,rear2
allGroup=frontGroup,centerGroup,rearGroup
Then my scenes just become:
front= frontGroup:on, centerGroup:off, rearGroup:off
center= frontGroup:off, centerGroup:on, rearGroup:off
rear= frontGroup:off, centerGroup:off, rearGroup:on
allOn= allGroup:on
allOff= allGroup:off
Now if I want to add a new light to the rear, I just have to update the rearGroup and not a bunch of scenes.
It gets worse as you start using the lights across rules too.
I'm sorry but I don't think you understand what the original point of the thread was. None of what you said is a group within a group. These are groups within scenes, which is totally different.
What the original posters were doing was creating 2 groups of 2 bulbs each. Then creating a third group which contained the other two groups (not the 4 individual bulbs). They then created another group which consisted of those super groups. That is what I don't think is a good idea. What you're doing doesn't apply as it is not a group within a group.
Yes that is what is said I dont think you read the second part of what I said. Note that the allGroup contains three other groups (frontGroup, centerGroup, rearGroup) which those sub groups then contain the bulbs.
If I want to change lights in scenes then I have to update every scene for all the lights within them. With groups and sub groups then I can just add or remove from one of the groups instead.
I use it the same way you do, to create 'inheritance' from cascading sets of groups.
It was originally to simplify rule creation where I found myself duplicating the same lists of devices over and over again and then having an increasing maintenance burden for those rules and scenes as I added more devices.
One example: I added an additional dimmer in my living room. I needed to go back and add it to all the lighting-related rules and scenes for my living room, for downstairs, for all lights, for the front part of the house to appear home when we are away, and so on.
Ryan is right that, on the surface, these are most useful for actions that act on them all, like turning all off or all on. But you can get a lot of utility out of the options to have group switches reflect whether any/all are on or off in the group. And you can use the group aliases to simplify the lists for capturing and restoring scenes, plus for other benefits and use cases that I'm still discovering.
Another example: if I turn off 'master bedroom', I want all lights to go off and my broadlink IR remote to turn off all of the IR devices. But I don't always turn 'master bedroom' on. I usually turn on one light, but the group switch turns on if any lights are on based on how I configured it. So I can turn on one light and then refer to them all as the group and get the intended effect without having to write a bunch of complicated logic to determine and track the group state with virtual switches or variables in my rules. And changed events on the group switch can be used as triggers in RM to drive actions like device commands for the broadlink IR. And I can also have my 'upstairs' group actions affect 'master bedroom' in the same ways without any additional logic other than the groups hierarchy and settings.
In the end, single sourcing and cascading the group definitions is a lot more efficient for maintaining the group lists (my original propose), but I'm actually doing more automation with them than I was before because of some of the useful behaviors around group switches and other features.
