RM 4.0 Rule Questions and Optimizations


Got it. DUH! Thanks


Thanks for winning the question of the day prize.
Works a treat.
Oh, and your prize is no more stupid questions from me.
Only for a week though. :smile:


I still can't make the already-discussed, "contact been open for more than 5 minutes - notify every 5 minutes until closed" rule work. What am I missing? The rule below fires up every 5 minutes and is never canceled, even if the contact closed.


Because you haven't told it to END REPEATING. END-REP.
Does this give you an idea?
Look after the THEN.


It's because you have just told it to start and never stop. The on cancel option is there to give it the chance to cancel or stop. You then need to tell it when to do it.

Need to change the triggers to changed then IF any contacts open do this

Cancel repetition

Or no cancel at all but use a simple condition.


I was of an impression that cancellation is automatic when the triggering condition is no longer "true"? Was I wrong thinking that?


There is no True/False in RM 4.0. Cancel on Truth Change no longer exists. You have to issue a cancel manually.


Read the documentation, it shows how to do it.


What happens with this trigger when one contact opens while another is already open? Will it span a separate process which will track that specific device and point %device% global variable to the device that triggered it, or will it be a single process and %device% will always point to the first device that triggered the action in the first place?


It will create a new instance when it is triggered. And in that instance %device% will refer to the triggering device.


Here's what I can't figure out. If I do this

Trigger : any open

If any open then repeat every 5 mins
delay 4:55 min
send notification %device% is open

Let's say device A triggered this, and then device B triggered another instance, a minute later.
Now when first if comes to a 2nd evaluation and if device A is already closed, will it still do the repeat since device B is open?


Yes. The evaluation of the "If any open" is independent of how it got there. If any of them are open, then that condition is true. But at that point, the device that started it may be closed, so you will be notified erroneously that it is open. There's no foolproof way to do multiple device notifications in a single rule like this. You could use 5 cloned rules, one for each door instead, Rules are free.


I know that's not an option now, but what if you could add an operation on %device%? Then I could trigger using any device from a list, but then inspect a specific one in the list. This would open a few quite elegant solutions.

I understand the rules are free, however not all of us are in the business of writing rules, and maintaining them. Some user convenience and creature comfort go a long way to keep the lemmings happy :slight_smile:


Interesting problem. I'll think about it.


I'm not sure if this will help, but here is how I'm monitoring a couple of doors.


Do Stop Actions and Cancel Delayed Actions have a rule-wide effect, i.e., do they cancel all "cancelable" and "delayed" command within the same rule?

If so, then I see how to break your rule - open backroom screen door, then within a 25 sec interval open and close the french doors. If Stop Repeating Actions command is rule-wide, then your backroom door notification will be canceled even though the door is still open.


well crap. I guess I'll be separating those now. Thank you for the find!


Small pet peeve - would it be possible to unify the current time attribute name across the whole of RM? Somewhere it's "current time", somewhere else it's "time of day". With a list of available options quite long sometimes it takes awhile to realize that similar things have different names in different places.


That’s because there is a difference. In a Trigger, it is time of day as you are telling the trigger at what time of the day it should fire. In a condition it is current time as you are comparing the condition to what it is right now.


It could have been a plausible explanation, only if it weren't for the fact that it's Time of day in the condition and Current Time in the trigger. And guess what, the set up form is absolutely same.