Actually, because the lights are in a subgroup, you would need to use
gLights.getAllMembers.forEach[ i | i.sendCommand(OFF) ]
I believe that members only returns non-group Items that are direct members to gLights. Or even if does return the Group Items, it will then just return the gLights1 and gLight2 Groups and not the actual Light switches.
But when you send a command, as rossko57 indicated, the command gets forwarded from the Group to the sub-Groups and finally to the Items.
So in fact, your original would work, but the for loop wouldn’t be commanding the Items directly, its commanding the gLights1 and gLights2 Groups which forwards them to the Items.
It’s a good idea to give your Groups a Type. This will help make sure the commands are received and interpreted correctly.
Group:Switch gLights
If you add an aggregation function, you can then put the Group on your sitemap and see if any light happens to be ON.
Group:Switch:OR(ON,OFF) gLights
Sadly no. The problem is you have nested Groups. gSensors will only save to persistence direct non-Group Items that are members of gSensors. With the Items above, there are no non-Group type Items that are a direct member of gSensors. You need to add each subgroup individually.
gTemp*,gHumid* : strategy = everyMinute
This is one reason why I wrote Design Pattern: Group Based Persistence and frankly why I think developing some big hierarchy of Groups is kind of a waste of time. It’s useful when you want to aggregate a bunch of sensors into one value or command a bunch of stuff of the same type with one command (as above), or if you have a bunch of Items that need to have their events processed by the same Rule (Member of Rule). It’s less useful for sitemaps and completely useless for persistence. Instead of a hierarchy, I find it much more useful to think about Groups more like a tag. Instead of a tree, it’s more useful to think of a Venn Diagram.