That is the behavior I would expect. In the case you describe the Item isn’t directly a member of the parent Group, its Group is the member. You would need to flatten the Group hierarchy in this case or create a special purpose Group that includes all the Items you care about.
This is also known and expected. If the subGroup doesn’t have a type it doesn’t get updated when its members update so there would be nothing to trigger the parent Group as the subGroup never receives updates.
For you particular design perhaps it is less useful. But other designs may depend on exactly the current behavior where one wants the subGroup to be the triggeringItem. The individual who coded this chose to support the latter design rather than the former. Personally, I agree with that decision as the latter approach handles more use cases, is IMHO more consistent with other Group behaviors (e.g. if you iterate through MyGroup.members you get the subGroup Items, not the members of the subGroups), and there are workarounds to support your approach (e.g. create a special purpose Group).
Not exactly. Groups are Items too. The subGroup is the member of the Group that caused the rule to trigger. So the subGroup IS the Item that caused the rule to trigger. But, as was the case prior to the Member of trigger, Groups do not change or receive updates unless they have a type.
That is debatable and I could be convinced of this. But the solution would be requiring a Type for any Group used as a Rule trigger even when using Member of. The solution would not be going back to the case where a Group gets updated and changed even when it has no type (this caused all sorts of problems which is why it was changed) and the solution would not be doing recursive Member of triggers as that would be a breaking change and IMHO be less flexible over all. It would also be inconsistent with other Group behaviors.
Probably a little of both. The Member of trigger was always designed to only support a single level. From the posting that introduced the new trigger (see link below):
“Member of” only works on items that are direct members of a group. It does not traverse nested groups. In the rule below the “triggeringItem” implicit variable will be one of the groups that are nested within AllLights (SwitchLights or DimmerLights) and not the base items (SwitchLight01, SwitchLight02, DimmerLight01, or DimmerLight02).
The unintended consequence part is a result of the fact that Groups do not receive updates when they don’t have a type. This was actually a breaking change in OH 2.2 from before there was a Member of trigger and the change was made to fix some pretty significant problems. But as a result, subGroups will never update when their members update so those updates will never trickle up to the parent Groups.
No it doesn’t. It’s perfectly legal to do something like:
Group:Number AllStrings
And have all the members of AllStrings be String Items. AllStrings will still get updates. It just will never have a useful state itself. I’ve never tried it but I think AllStrings will remain NULL.
In a more useful case you can do
Group:Number:SUM AllSwitches
which will set the state of AllSwitches to the number of its members that are ON.
There are all sorts of combinations of Group types and member types that are possible and useful and even in those cases where the combination is not useful, the Group will still receive updates.
The posting Features for Rules that work with Groups is the most comprehensive short of looking at the source code for now.