Trigger MemberOf of multylevel heredity (type: core.GroupStateChangeTrigger )

I have the following construct (that works)
But just for my understanding:
these groups “doors” and “windows” belong to another group called “doorsWindows”.
Is it possible to selct only “doorsWindows” and react on all their child updates?

(Btw. all groups are marked as BaseType: “Contact” and Aggregation Function: “One OPEN then OPEN else CLOSED”; Usecase is a TTS reminder via cronjob, but String should be prepared allready before)

Greatings David

Seems like a really easy experiment to perform to find out. Come back and tell us. Typically one uses “descendent” instead of “member” in other parts of OH where members of subgroups are included so I’d guess the answer is “no”, but in the amount of time it took you to post this and for me to respond you could have tried it out and got your answer.

Sorry I did not pronounced. I dit test and It does not work. So the correct question is: Do I have to take the workarrount like above (selecting all lowest groups) or is there a easier way?

Don’t use the subgroups at all would be another way. Just put all the windows and doors into the same Group and trigger off of that.

yes and no :wink: I am using the Label of these groupt to concatenate my TTS String with the real world names for “window” and “door” like: “Guestbath-window is open since 15min”. or “Can not lock maindor, because some windows are open.”

You can potentially use tags to identify what is a door or what is a window. That might be easier even than Groups.

On the other hand it costs nothing to have a rule triggered from two Groups member-of …

Inside rules, when Group handling, we can distinguish ‘local’ members from ‘cascading’ allmembers.
And so far as I know, the rule trigger setup machinery actually calculates target Items and sets up many individual triggers at compile time.
On that basis, a possible OH enhancement would be an Allmembers of trigger.syntax. Might be easy to implement, even though it’s easily worked around anyway and offers no performance advantage.

I don’t know how it works in other rule engines, however the most basic way I could satisfy this was by using this code:

Probably the core rule engine has its own way. A lot depends how items are tracked, in my case I wanted simplest way thus I have one global state listener for all items and then iterate over all rules which are triggered by state event. Even if its suboptimal it works as there is usually more items than rules. :slight_smile:

I thougt the same way of Code-Snipped. But often enough I waste my time in thinking of “there must be an existing construct I HAVE to use” :wink: