Open garage door and then close it with no Motion

[ptdalen]

1) Give a description of the problem
I want to have the garage door open upon arrival, then close automatically after 5 minutes of no motion. I have a piston that opens the door for myself or my wife and it works fine, but how do I also close it using just one piston. We don’t always open the door when we arrive, so I have a piston that only opens when a global variable is true. It works just fine, just wanted to add an auto close to the same piston

2) What is the expected behavior?
Open the door when we arrive, and close it after X minutes of no motion.

3) What is happening/not happening?
Not sure how to include the motion detection in the same piston.

4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)
(PASTE YOUR LOGS HERE BETWEEN THE MARKS)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

[c1arkbar]

Create a blank device variable.

If contact 1 or contact 2 is open
Save matching device list to variable
And
Motion 1 stays inactive for xx time
Then
Using device variable
Close
End if

[ptdalen]

Only one contact in this case, but two people who could trigger the “Open”

So contact is open, but motion will not be inactive when the piston runs, right? Or will it “wait”.

Here is what is happening (as it should)

I or my wife previously set a global variable to true (open the door when I get home)

One of use arrives. If our variable is true then open the door and set the variable to false.

At that time the motion is active or will be pretty soon.

Then the piston completes.

I’m confused by the Device variable in this case. I’ve used them before to capture state and then later set it back.

Where would you put this logic? In another else?
Would the piston wait for the stays inactive to be true?

[ptdalen]

Like this? I put a 90 second pause, because the Garage door opening does not trigger the motion sensor, so I need enough time for me to get to the garage and trigger motion. The sensor is a cheap one and takes a few minutes to go back to inactive, so I just have it set to 10 seconds of Staying inactive. I’m not sure this would work, but I can give it a try?

The part that I’m most unsure about is the “Stays inactive” section.

[c1arkbar]

Device variable is not necessary. I mistakenly thought you had multiple garage doors.

Add the logic to the bottom of the piston. You can also add a condition that one of your variables needs to be true so it will only happen after you said it should open upon arrival

[ptdalen]

Ok, thanks. I think I’m getting closer.
I believe pistons are run from top to bottom (unless you change to run async)
I’ll try this when I get home. My question is on line 27 I have a pause for 90 seconds. Main goal for the wait 90 seconds is to give me enough time to get into the garage and trigger motion, otherwise it seems to me as if the garage would just close again since it will have been inactive for more than 10 seconds., right?

So please have a look at my updated piston and let me know if it looks good.

[c1arkbar]

I believe pistons are run from top to bottom (unless you change to run async)

Pistons are run top to bottom always except for one condition that I can’t think of right now @webCoRE_Minions I know on of you knows this answer.

The only thing asynchronous changes is waits. It allows the piston to move past any waits and continue excuting other conditions/actions beyond a wait.

My question is on line 27 I have a pause for 90 seconds. Main goal for the wait 90 seconds is to give me enough time to get into the garage and trigger motion, otherwise it seems to me as if the garage would just close again since it will have been inactive for more than 10 seconds., right?

If the garage can open without setting the motion to active then you probably do not need this 90 second wait. Stays looks at the future so the device will need to switch back to inactive then stay that way for 10 seconds.

Final thoughts

You can get away with sticking the logic for closing the garage at the very bottom of everything. This reduces the redundancy in the code. No need to type it out twice. Your 90 second waits will still work the same if you decide to leave that in there.

[ptdalen]

Quick Question: if this is broken out and the close if put under its own IF statement, wont it close the garage door for any scenario where the door is open and motion stays inactive?

That is not my end goal. There are other pistons and situations were I want the door to stay open until I close it.

My goal for this piston is to only automatically close if it was opened by this piston

[c1arkbar]

Ok leave it. Sorry I was working with a limited scope.

[ptdalen]

No worries at all. I greatly appreciate it. Learning more and more here. I ended up adding a local variable called close the door. to the logic, so it only closes if that variable is true. It gets set to true when the door gets opened with the previous logic.

[ptdalen]

So here is my final Piston. I’ll call it Open Garage Door based on arrival for multiple people (ON Demand using IFTTT). Long name, haha. My wife and I each have our own IFTTT. I have two IFTTT triggers that can set the variable. One is just a simple button trigger, the other is a SMS trigger. That way I can send a SMS message to a specific number and it will set the variable to true. Its kind of fun to be in the car and say 'Hey Siri, text the house", what would you like to say to the House. “Open the door when I get home”. Boom! Of course I could just say “Hello House” The SMS IFTTT Trigger is set up to work with any word

[c1arkbar]

Awesome!! Once you have it all working set up a post in #Examples with the details!!

[bangali]

I know on of you knows this answer.

me?

pistons run top to bottom unless there is an every statement which is being executed in which case only the every timer block is executed.

more here:

Piston executes from top to bottom?

this is a common one i see in posted examples, so thought a short note on it might be useful. pistons execution almost always starts at the top and stops at the bottom, unless there is an exit statement somewhere in the piston that gets executed conditionally or unconditionally. there is one exception to this, that is a timer statement. when executing a timer, the piston execution starts with the every and stops at the end every. as an example if this is the piston: if contact changes to ope…

[c1arkbar]

I knew it was something but couldn’t exactly remember. Thanks man!

[bangali]

anytime dude!