Using a Local Variable to Stop Rule From Executing Immeditately

Get Help
,
#1

I don't have reason to use variables too often. I haven't had an opportunity to test this yet, but here's what I'm trying to do.

When I get back, sometimes, my SO is with me. The devices arrive at nearly the same time, but sometimes separated by minutes. That that happens and the below routine runs, it's usually after we're in the house, and the garage door reopens. Sometimes I forget to reclose it (honestly, it SHOULD as the "close garage door" routine is in my Goodnight, but I'm getting around to troubleshooting that now, and that's a different issue.

My question is: is this the best way to do this, or is there a more elegant way that I'm just not aware of?

I'm Back rule:
back

This is mostly to make the rule more elegant, I will troubleshoot no problem without input, I'm just not used to variables yet. Thanks for any suggestions.

Edit 01: used the wrong image.

#2

Could you be a little more specific on the intent of the rule? Do you just want it to run when the first person gets home but not the second?

edit 01: fixed comment based on corrected image :slight_smile:

#3

Yeah, I used the wrong image. the != was an error that had been corrected, I just grabbed the wrong image off my desktop.

Intent: delay reprocessing for 5 minutes (or whatever the final Set Delay_Im_Back time is set to (after END-IF).

#4

Gotcha. First, if your rule works, well done and good job on a creative use of a variable.

Second, a couple of things might make your life a bit easier. There's a built-in special-use variable called "private boolean." It defaults to true. You could have a required expression that allowed the rule to only be triggered if private boolean was true. Set it to false first thing in the rule. Then at the end of your rule set it to true with a delay of 5 min.

Third, while your use of a number of value 0 or 1 is perfectly valid, there's a variable type called "boolean" that can either be true or false. Most folks with a programming background would use that instead, but for what you're doing it doesnt make any practical difference.

1 Like
#5

Gotcha. Sounds kind of like what I'm doing already. I'll test this over the next few days. Thanks for your input!

#6

Yup. Just a tad cleaner. But if what you're doing works... no reason to mess with success.

#7

I occasionally use Private Booleans in my routines, but have become curious whether they automatically get "reset" (to TRUE) on any of the following events:

• Clicking DONE after editing a Rule;
• After a firmware update;
• During restart after reboot or power outage;

Or do they maintain state until actively changed by a Rule??

#8

None of those will change the value; it will only be changed if you change it (or really if a rule does, since you can't just edit it manually like a variable).

1 Like
#9

Good to know, esp. after @bravenel informed me a few weeks back that clicking "DONE" on a Rule (that's already running) will effectively Stop the rule in mid-stream and reset it in all other respects. Before that, I had thought of these as spawned processes ("jobs") that carried through to completion regardless of future edits to the main Rule.

I can now see the wisdom of some users who Clone a rule before editing, Pause the original, and then Edit the clone. This further thwarts certain kinds of Rule corruption from the looks of it. But it does beg the question, "Does the cloned rule's Private Boolean carry the same True/False value that the original one had at the time of cloning?"

(I will assume "Yes" without directly testing.)

#10

I believe I've seen in the past, and I haven't checked before writing this, that the cloned rules PB will point to the original rule that was cloned. So you will have to go into the cloned rule and change the PB to point to 'This Rule' assuming the PB was for the rule it was defined in. If that makes sense. :wink:

#11

Ah, yes, I recall seeing that same advice somewhere, too. Thanks for the reminder.

#12

This is no longer true in the latest release of Rule 5.1 (older versions not included). The value of Private Boolean in held in the rule's state, and is copied to a clone. It used to be that setting PB of **This Rule** referenced the rule's appId, which would be wrong for a clone. This is no longer the case.

I take it back. Setting PB for **This Rule** will not work correctly in a clone, and must be edited to work as expected. It is using the appId of the original rule, not the clone.

2 Likes

Download the Hubitat app