What do you mean move it out so it is a unique statement.
If you follow the blue bars from your first IF statement, do hih see how the second IF is part of your first one? It’s part of the “else” statement, expected only if the first is false.
If you move it using the triangles near your piston line numbers, you can drag it below the other IF statement and it’ll be independent.
Exactly! Now I think you just need to click in your second IF statement and change ANY to ALL so lights only turn off when all doors stay closed.
Let me know if this works?
Good catch - thank you.
Let me try this out.
It might be easier to roll your after and before statements into one.
Time is between Sunset and Sunrise.
But I have different tasks with each one. I have an extra switch on sunset.
Oops. Missed the extra device.
Since the IFs are not “async,” does the first IF need to trigger to check the next IF statement?
Or if the contacts are closed for 5m, it would trigger the second IF regardless if a door opened?
Would there a problem if I made them both async IFs? I guess I don’t fully understand the difference.
I know IFs run in sequence and async can run at the same time. But if the first IF is never triggered, it would never check second IF statement - is how I’m thinking about it.
Any trigger will run the whole piston, top-to-bottom. You could make them asynch but I don’t think there would be any benefit to it in this case.
No, async only matters if you could need to evaluate two conditions in parallel. In that one, either one is true or the other is… There’s no need to evaluate them asynchronously.
Do you have any example pistons where async would be necessary vs sync?
I tried to find one on the wiki page but couldn’t.
I don’t know why I am having a hard time understanding this.
It’s more for parallel execution of complex IF statements. I don’t have a specific example, but think of something along these lines:
IF door#1 opens
Then if someone’s presence changed to away, then turn off a bunch of lights and close a garage door
Then if someone’s presence changed to present and time is between sunset and sunrise, then turn on a bunch of lights and open a garage door, else open a garage door, and if time is after 6pm Turn TV on in the family room
IF door#2 opens
Then turn on a light
If the two are run synchronously, when Door#2 opens it will trigger the piston to execute top-to-bottom, burning up time on the first IF block. By the time the lights are turned on from the Door#2 block, there would be a perceivable delay.
If the two are run asynchronously, when Door#2 opens it will only execute “Then turn on a light”. Furthermore, if Door#2 is opened while the IF block is already running for Door#1, it will execute immediately rather than waiting for the other IF block to complete.
Hope that didn’t make it even more confusing?! lol
Thanks, I think of getting it.
Is this a better example?
If door #1 opens
Then notify me with push notification
If door #2 opens
Then Turn lights on, wait 10m, and turn lights off
If door #3 opens
Then turn lights on and turn TV on
So if running in sync and door #2 opens, then door #1 or #3 opens 5m later.
The 1st and 3rd IF won’t run because the piston is stuck on the wait 10m?
If running in sync, does it also mean:
If door #1 is open
Then turn lights on
If door #1 changes to open
Then shut garage
Since the first IF is a condition and the second is a trigger, when the door changes to open, noth IFs would execute? If running in async, only the second runs?
One thing you have to consider is how the Piston actually started. What you’ve built there in your last example is a Piston that is “subscribed” to three different door sensors. The piston is going to basically hum along and watch those three sensors and if ANY of them Open it will execute the ENTIRE piston.
The only difference between what you’ve got there and how it will operate with SYNC or ASYNC is going to be when you open Door 2…and the difference will be WHEN the IF for Door 3 is evaluated. If you open Door 2 with Sync ON then the piston will wait for 10 minutes, turn the lights off and then check on Door 3. If you put ASYNC on, then it will still evaluate all 3 IF blocks but it won’t wait 10 minutes before checking on Door 3.
The opening of any of those doors will run the entire piston. So if you open Door 2, then wait 5 minutes and open Door 3 (regardless of SYNC or ASYNC) the entire piston will run again and it will evaluate all the IF blocks again.
But know that with SYNC ON after the 5 minute Wait after opening Door 2 it’s going to check on Door 3. Essentially you’ll have the Piston running twice. Once because you opened Door 2 and it’s waiting to check on Door 3 and once because you opened Door 3 which causes it to run the whole piston again (starting by checking Door 1, then 2, then 3).
Thanks for the response.
So is it best to make all three IFs ASYNC or make 3 separate pistons?
Certainly it depends on what you’re looking to do… There can be reasons for or against. but if you’re monitoring 3 separate doors and doing different thing with each then perhaps it’s best to make three different pistons.
I have 16 Z Wave light switches throughout my house and they have a double-tap feature to them. In different rooms I’ve done different things with them. So I opted to put them all in their own pistons. But I set the pistons up to use all variables for everything. So that way I can just duplicate it as I add more switches and make a few changes and I’m done.
Well I have another piston that is just a notification piston, so it looks like this:
If door #1 opens
If door #2 opens for 10m
If switch #1 turns on
If switch #2 is on for 60m
I have like 10 different notifications all in the same piston. So im wondering if I should have a different piston for each.
I’m not saying that one way is inherently better or worse than the other. You just have to understand the effects of what you’re doing if you have multiple triggers which will start your piston. If you have 10 IF conditions in it then all of them are evaluated whenever that piston gets started. If you’ve accounted for that then fine…but if you start seeing some unintended behavior then you may want to make some changes.
There’s also the ability to use Switch Blocks, which can significantly reduce the number of conditions that are tested against. There’s also the option to write a piston which intelligently knows which door opened and then only reacts to that one rather than checking every one (research $currentEventDevice).
(Check this very good thread…you may find it useful: Understanding $device, $devices, $currentEventDevice, etc )
So there are many options that you can use…