Mike, you might be able to use a private boolean to prevent multiple instances of this rule running. First line could stop the rule if PV false. I assume this would not impact the original rule that might still be running.
Does anyone know how much of the beginning of this rule is redundant? I'm trying to prevent the motion from triggering after someone turns the switch on manually -- at least for a few minutes.
Bruce,
Does private boolean preclude a rule from running in Rule 4, like it did in Rule 3? Or is it simply a like a virtual switch, that I can use in Rule machine to "exit rule" for example. I cant find any documentation as to what it does in the support docs.
Works like a local variable. In rm4 it doesn't do anything to action execution unless you explicitly use it that way.
Restrictions are gone. So only whatever logic you use for it will apply. It's like a simple Boolean variable, that starts out true. You can test it, set it, have other rules set it, and trigger off it. It's all up to you what you do with it. It can often be used instead of a virtual switch to remember some state.
1 Like
So, I know I said I couldn't think of how you'd use an XOR....well, I did. 
Took me a while but it finally clicked. Thanks again for taking the time to explain it to me.
Every time I think I've wrapped my head around 4.0, I get surprised by something. I threw together a quick rule to wake me up at 6:43 AM on August 27th, and it got the job done. But it also turned on the light at 6:43 AM on August 28th. Why? I know as soon as someone points out my error, I will say "Doh!".
Your trigger runs at 6:43 everyday.
In your actions you have your dimmers that you set.
Although you have a condition defined you have not actually used it.
Leave your trigger.
In actions use an IF-THEN.
IF
Date is Aug 27th. (The condition you have already defined)
THEN
Turn on dimmers.
END-IF.
Thank you. My head was erroneously thinking RM 3 Restriction and RM 4 Condition were the same, but they are not.
While I've done 30+ rules in RM 4 that are all working as intended, I haven't reached full understanding of the somewhat murky terminology. For example if you want to edit an If/Then construct, the UI to go through says you are editing an action.
I know it is easier said than done, but if would be nice if a future RM separated the notion of creating actions (things to do) and logic constructs (initially empty; into which actions are inserted).
How would you structure this rule to avoid mutliple instances. I tried private booleans, and it didnt work.
@bravenel, could you have a look at this please?
I'm sorry to add to this thread, I'm still trying to get the hang of RM4. What I want to accomplish, when my presence arrives, wait for porch motion to be active, then unlock Door. Cancel unlock if no motion is detected within 3 minutes. I've tried wait for event with timeout but as I understand it, timeout cancels the wait, but not the subsequent actions. Any help would be appreciated!
Something like this, maybe:
Trigger:
Presence arrives
Actions:
Wait for events: porch motion --> timeout: 0:03:00
IF porch motion active then unlock door.
1 Like
Hey, don't be sorry!
Let's work through this:
How about this:
Trigger Event: Presence arrives
Actions:
Set PB true
Set PB false delayed 3:00
Wait for motion active, timeout 3:01
IF (PB true) Unlock door
You arrive, make sure PB is true (from previous time), then start 3 minute timer to set it false. Wait for motion, but only for 3 minutes. When there is motion (or time runs out), if PB is still true it must be within 3 minutes, so unlock the door. It it was longer than 3 minutes, PB is false. Bam!
2 Likes
Thank you both, both make sense to me now! Special thanks to you Bruce, I appreciate the level of community engagement, I have never seen such commitment from any other HA platform. Thanks!
1 Like
This is why I keep coming back to this thread just to read. I love seeing problems and solutions, and this is the most clear-cut PB example I've seen yet. 
1 Like
I'm working on merging several old rules into one RM4 for my dishwasher monitor and I think I have come across a potential issue with quick firing triggers.
My testing suggests that the rule stops wherever it has got to if it is triggered again. Is this expected behaviour?
In my example sometimes the door contact trigger has a bit of a jitter and sends open/closed/open in quick succession. My initial version of this rule had the door contact if/then section at the bottom of the script. Watching the logs for this when this happened suggested that the rule triggered fine on the first "open" but didn't get to process the door contact if/then section by the time the second "open" started the rule again. Moving that part of the code to the top (as it is now, see below) solved the problem.
Although in my case this is only a problem because the contact sensor location isn't great, but I guess there are other cases with multiple triggers that might fire one after another with not enough time between for the rule to complete it's script. If so I guess it's something to bear in mind when creating longish rules?
It is quite possible to have multiple simultaneous instances of a rule either running, or in the process of running. By the latter, I mean for example a rule that is fired and then has a delay, so it is pending that delay to come back to life.
In theory there can be many instances of a single rule. But each instance is unaware of this, and all instances share a single set of state variables. In some cases, this multiplicity is intended and works as expected. For example, a simple motion rule that has a delay with cancel where one side of an if is waiting for motion to recur and the other is waiting to turn off a light (but gets cancelled).
Where it breaks down is in complex rules, especially ones with nested IF-THENs that have embedded delays and have multiple triggers. The rule must use a state variable to know where it is in the nesting structure. If a second instance of that rule starts up, that second instance will trample on the first instances state it needs to process the nested IF-THEN. You will see this failure in the logs as an error about not being able to "pop from a null".
So, Rule 4.0 affords a great deal of power to the rule author, but that power can lead to things that just won't work. You have to think through what happens every time the rule is triggered. If you have complex multiple triggers, you are more likely to get into trouble. Resist the temptation to bake everything into one rule. If you need to deal with complexity, use Global Variables to link multiple rules, each of which is relatively simple, simple enough that you can think through the consequences of what happens. If the complexity is such that you can't think through all of the possible variations, then it is too complex. This is not necessarily easy stuff. This is the result of an event driven 'engine', that is simply responding to events as you instruct it.
1 Like
I think this is the crux of it.
I wanted to merge my several rules into one mainly in the interests of keeping everything in one place and tidying it up, but in terms of functionality, maybe that was not the best plan.
Tidying up should not motivate the design of your automations. Think about it, you're placing importance on how an administrative interface looks. You don't live in the administrative interface, you live in the house. Make the house work, and put up with the admin interface as needed. Use consistent naming, but don't dwell on the apps list appearance.
3 Likes
You're talking to a guy who has all his spanners hanging in size order on pins in the workshop - I like tidy!
I do take your point, but the better organised the rules, the easier I find it to make modifications as required.
1 Like
