I am trying to set up some advanced rules with multiple triggers.
To be honest i understand how to write rules, but not what is under the hood.
Are there any potential downsides in having “many” rules with a lot of triggers?
Lets say a rule looks like this and i have like 30 of them.
//TestRule
rule "Test"
when
Item Something1 changed or
Item Something2 changed or
Item Something3 changed or
Item Something4 changed or
Item Something5 changed or
Item Something6 changed or
Item Something7 changed or
Item Something8 changed or
Item Something9 changed or
Item Something10 changed or
Item Something11 changed or
Item Something12 changed or
Item Something13 changed or
Item Something14 changed or
Item Something15 changed or
Item Something16 changed or
Item Something17 changed or
Item Something18 changed or
Item Something19 changed or
then
do some stuff based on other stuff
end
Would be nice to know before i put a lot of work in them
The negative side of this is - if all these items change within a millisecond of each other, the rule will run multiple times.
As mentioned above, better off doing a group with those items with a timer inside the rule so if the timer exists (meaning it’s running), not to run the rule again if another item changes in the group when its running.
Thanks for the input with the group. I will do that
About the timer: I wannt all the items as trigger beacuse each of them is important. If i doo the timer thing and 2 items change very fast in series both changes could be important but i could miss the later one… right?
It is usually possible to code carefully to avoid that, using variables derived solely from the triggering event, and none from “current state” (which as you suggest, might change after triggering): Depends exactly what is done.
Everything mentioned so far is correct but I wanted to provide some additional info.
As mentioned, it’s probably best to use a Group with a Member of trigger for ease of flexibility and to make writing the rule easier. If you need to know the Item that triggered the rule there is the implicit variable triggeringItem which is a reference to the Item that triggered the rule.
Even if you list each Item individually you’ll have access to the triggeringItemName to know which Item triggered the rule.
In OH 3 only one instance of the rule can run at a time. So if the rule is running and then gets triggered again, that second trigger will be queued and not run until the previously triggered rule completes. Therefore, especially with a rule that has lots of triggers, you can’t always rely on it running immediately when that trigger is received.