I have two groups with partially identical items. Using Rules DSL I have
Member of Group1 changed or
Member of Group2 changed
If an item, which is member of both groups, changes the rule is triggered twice, which is intended. But is there a way to find the group to decide that under certain circumstances if the group is Group1, don’t do anything?
I have 5 air condition units in the house, 2 of them in the same room as this room needs 2 units. The items of each unit are in one group. So far no problem.
The room temperature item is member of both unit groups. When the room temperature changes some adjustments have to be made to the air condition units.
The rule itself loops through all unit groups the triggering item is member of. As a result the rule runs 4 times when the room temperature changes. The rule is triggered twice because the item is member of 2 groups and the loop adjusts each unit group the triggering item is member of, which is 2 in this case.
I’m not sure it’s completely clear but it’s probably clear enough.
There are lots of ways to implement this. I probably wouldn’t have the same Item be a member of more than one Group. That should eliminate some of this repetition. Just create a separate Item linked to the same Channel for the room temperature then you won’t have this duplicated looping because the Item belongs to more than one Group and you can keep the rule itself simple.
That’s what I already did for the most important items. Though it’s not “satisfying” in terms of structured programming.
As “triggeringItem” is only available together with a “Member of” trigger it should be possible to implement a “triggeringGroup” item as well.
The way it’s implements I don’t think it’s that simple. There isn’t a separate event for the Group and the way that this works behind the scenes is when the rule is loaded that Member of rule trigger gets unrolled and implemented as separate Item triggers. The Group information is lost at the trigger level.
As “triggeringItem” has quite a lot of “tags” attached to it, why not add a new tag “triggeringGroup” when unrolling the seperate item triggers? So the group triggeringItem was unrolled from could still be found.
If you think you know of a way to implement this I’m certain that a PR would be approved.
I’m not sure what “tags” you are referring to with “triggeringItem”. It’s just the Item that generated the event that triggered the rule. The Item is a part of the event and “triggeringItem” comes from the event.
There is no “triggeringGroup” event. So access to this information will require at a minimum changes to the event generation and processing subsystems, potentially the creation of a whole new event type.
I’m not a native speaker, so I’ll do my best to clarify things…
An item has different properties like “state”, “type”, “label”, … I guess that triggeringItem is a copy of the item which caused the event.
The item class could be expanded by a new property “triggeringGroup” which is empty for the item itself but set when unrolling the items in a “Member of” trigger. As I don’t know if “triggeringItem” is a reference by value or a pointer to the original item you are right. It might be a lot more work than it seems on first sight.
Not a copy. It’s a direct reference to the Item that the event concerns. And the Item does have the Groups it’s members of.
Neither triggeringItem nor triggeringGroup are properties of the Item.
Reference. A reference to the Item that triggered the rule is injected as a variable into the Rule based on the event that triggered the rule.
The rule triggers set up a subscription on the event bus. “When you see this event on this Item run the rule.” The event is then used to populate “triggeringItem” and other variables, not the trigger. There is nothing in the event that can populate “triggeringGroup”. All the rule sees is “Item Foo changed to ON”. It doesn’t know that that trigger was created through a “Member of” trigger. There is nothing in the event to say which Group the Item belongs to that created the event.
All that would need to be created.
Some might even argue that the way you are using Member of triggers shows a bug. What is happening is that the same rule trigger is being created twice on the rule, one for each Group the one Item belongs to. Having two identical triggers on a rule which causes the rule to be triggered twice for the same single event could be deemed erroneous behavior.
One could argue that a rule should only ever trigger once on a single event, never more than once from the same event.
It is actually supported to get the triggering group, but I’m not sure if it is supported in rules DSL.
In JS Scripting, groupName should return the name of the triggering group for group (i.e. member of) triggers similar to itemName returning the name of the actual Item that triggered the rule.
It must have changed how it works over the years. Way back when Member of triggers were introduced it was explained to me that the Group info was basically thrown away. It’s good to hear that’s not the case any more, at least for some languages.
I should have reviewed the JS Scripting docs instead of thinking it was all still working the same way.
So, @Jogobo, if you use JS Scripting (possibly Blockly) and perhaps other languages, you can get the name of the Group.