[SOLVED] Dynamic group weird behaviour in rule

Setup, Configuration and Use Scripts & Rules
,
1
  • Platform information:
    • Hardware: Pi
    • openHAB version: 2.5
  • Issue of the topic: please be detailed explaining your issue

Hi !
I have made a group to which items are added and removed through a rule(first).
I want to trigger another rule(second) whenever anyone of the member items of the dynamic group receives update.
Here are the rules

import org.eclipse.smarthome.model.script.ScriptServiceUtil

rule "Update group security alarm"
when
        Item securityAlarm received update
then
        gSecurityAlarm.members.forEach[ item | gSecurityAlarm.removeMember(item)]
        if (securityAlarm.state==OnOffType.ON) {
                securityAlarmExec.sendCommand("Home Secure")
                gAllSensors.allMembers.filter(s | s.state == ON).forEach[ item |
                           val testItem = ScriptServiceUtil.getItemRegistry.getItem(item.name.substring(0,item.name.length()-2))
                           gSecurityAlarm.addMember(testItem)]
        }
        else{
                securityAlarmExec.sendCommand("Home Security OFF")
        }
end

rule "Execute security alarm"
when
        Member of gSecurityAlarm received update
then
        securityAlarmExec.sendCommand("Home Security Breached")
end

The weird problem I am facing is that if I add some items to the group gSecurityAlarm and later remove them from the group, the second rule still gets triggered if the removed item receives update.
For example I add door sensor item to the group gSecurityAlarm and remove it, then the second rule should not trigger if the door sensor receives update because it has been removed from the group. But, surprisingly it gets triggered.
What am I missing?

2

If I recall, the Member of trigger is actually expanded out internally at rule load time. Meaning it will not work with dynamic membership.

You’d have to code it the longhand iterative way, as we did before Member of was added.

3

Ok. Thanks a lot for clarifying.
Shouldn’t this be added somehow to the normal functionality of dynamic rules?

4

You can ask. Perhaps someone has asked already.
But I wouldn’t expect urgent action. It’s not a common requirement and interest in Rules DSL development is waning.
I imagine this would be harder to do than it first appears.

Perhaps the JSR223 rules of one kind or another support this better (or should be made to), but I could not say.

There are workarounds meantime in DSL, the “old fashioned way”

I suppose a dirty way would be to put your affected rules in their own file, and when you change group “touch” the rule file to force rule refresh.

5

Ok then maybe I should live with the old school way. Thanks btw

6

One thing though, after removing the unwanted items from the group, if the system is restarted, then the second rule does not get triggered from the removed items. So as a simple workaround that I can see, just restart OH after removing items.

7

Well, if you’re messing with fairly advanced dynamic Groups anyway, perhaps it’s worth considering a move to New Rules. It certainly has the capability to more cooperative with that kind of thing.

Request for comment @rlkoshak @5iver is there already support for dynamic membership triggers?

1 Like
8

I assumed you were properly varying groups dynamically.

If you mean just editing essentially static groups, just reload yes.

9

Yes, I add items dynamically as can be seen in the first rule.
Showing the group in the sitemap, the items inside the group change when items are added or removed.
I also added logInfo lines to see the member items in the logs every time items are added or removed. And it confirmed that the group is dynamically maintained.

10

Yes dynamic groups work. That has nothing to do with rules.

In rules DSL, the Member of trigger (only) does not work with dynamic groups.

11

The trigger is also working as intended if items are added. But the items keep triggering the rule number two even after they are removed from the dynamic group. That is what I can see
So, if I have removed one or more items, a restart is required and then again works as intended.

12

Yes. The Member of rule trigger doesn’t work properly.

1 Like
13

This is a known limitation with Member of triggers across both Rules DSL and Scripted Automation. A Member of trigger gets expanded to separate Item triggers for each member of the Group at load time. So a reload of the .rules file should be sufficient to regenerate the triggers. You don’t need to restart all of OH. This is why rossko57 recommended touching the .rules file which should be sufficient to cause OH to reload that file and therefore regenerate the rule triggers based on the current Group’s membership.

In Scripted Automation you have a little bit more flexibility. You can have Rules and scripts that create other Rules. So you could periodically or in response to an event remove the existing Rule and then recreate it which will regenerate the triggers.

I can point you to examples if you like. It’s pretty advanced stuff even for scripted automation though.

1 Like
14

That would be great. Thanks
So, is that a sign that we should move towards scripted automation in the long run.

15

Given that Rules DSL will be deprecated and Scripted Automation will be the default for OH 3, the long run isn’t necessarily as long as you might think.

There are other submissions to the Helper Library that do something similar as well. See Helper Libraries for openHAB Scripted Automation — openHAB Helper Libraries documentation or [beta testers wanted!] Jython addon w/ helper libraries (requires OH 2.5.x) if you want to use Python to get started.

1 Like
16

Thanks a lot @rlkoshak and @rossko57 .