Sorry if this isn't clear - it's been a rough week.
I have a couple rules using rule machine 4.0 that's based on a time period and and a change in motion sensor.
One opens my garage door when I walk out the front door between 7 and 9am - but because I don't have a contact sensor on the garage, it doesn't know that it's open or closed, so it only has a change state using the chamberlain driver
Meaning when my wife walks out behind me, the garage door closes.
The other is turning on the tv and lights in my tv room when we walk in between 6pm and 9pm, and setting the mode. If someone walks out the door during that time period, it tries to retrigger the even - including resetting the lights to their original state, and setting the tv inputs back to the original mode (we may have switched during the night to playing a game, etc)
Ideally, I'd like both of these events to 'know' that I've already triggered them once, and that they shouldn't trigger again.
What am I missing?
You could try adding a private boolean condition. Something like this:
Trigger Events:
Contact Switch - Front Door Open
Time is 9:16 AM
Actions:
IF Time between 7:00 AM and 9:15 AM THEN
IF Private Boolean is False THEN
set Private Boolean True
open garage door
END-IF
ELSE
set Private Boolean False
END-IF
You could set a local boolean like what I have in this rule example that prevents duplicate notifications when my back kitchen door opens multiple times in a short period of time. Here, it can only send a notification once per 10 minutes.
I was using private Booleans in my rules but started to have issues where it wouldn't change back after the specified time passed. Another user told me Hubitat's private Boolean function was wonky and to try setting up local Booleans instead. So far, it has worked more reliably for me.
I haven't had any problems with private booleans, but I don't think I have any rules where I am using them with a delay. My rules are more like the example I posted above, where Private Boolean is set because of a condition.
Private boolean is unique that only the rule itself can check whether it's PB is true or false but other rules can change it. This is done so the the rule doesn't need to open the parent Rule Machine app to get the value (like rules do with Global Variables) and is therefore able to run more quickly.
Local variables are accessible only from their rule so other rules cannot modify them or check their value.
Global variables can be seen and modified everywhere but in order to check or modify them, the child rule has to spin up the parent Rule Machine app which is time consuming.
The one thing with Private Boolean is that there is no way to know what the value is unless you go into the rule and see whether the condition checking it's truth is true or false. With variables, you can see on the rules main page what the current value of a local variable is. And in the Rule Machine parent app you can see the value of all global variables.
Your issue with modifying private boolean with a delay will happen if your delay doesn't have a cancel on it that will be executed if an indicating action takes place. This is the exact same problem you will have controlling switches where actions have delays. Since a switch is a binary device and PB is a binary variable, all of the mistakes people make with switches you can also make with PB. The only problem is, its not easy to see if there's a problem with your PB. You can see immediately if a switch is in the wrong state. That's why PB issues will sometimes go undiscovered for some time. The person assumes its working right when it really isn't.
