Trying to put together a few pistons, all similar in nature where there are scheduled events
Id like all events to occur at the same time, after reviewing the task scheduling policy, I thought i had it figured out by using “allow multiple scheduled tasks” but that doesnt seem to be the case. It seems to still be waiting for each to finish before moving onto the next event.
If I understand what you want correctly, I think you need to change the Execution Method attribute of the with statements to Asynchronous.
I’m not really sure, though, that you want the Task Scheduling Policy (TSP) of the with statements to be “Allow multiple.” If you go away, come right back, and then go away again, do you really want multiple of these sequences happening concurrently (and out of sync)? I would think you’d want them to effectively start over, which is what I think the default TSP of Override would do.
Oh, and for the middle with statement, you probably want something like this:
do (N)
with (N)
Location
do
Wait 3 minutes
end with;
with (N)
{everything}
do
Turn off;
end with;
end do;excellent thank you, ill give that a shot.
I thought TSP “allow multiple” would let multiple tasks occur at the same time. Might be a misunderstanding on my part.
What i really want to avoid is the lights or thermo etc action occurring after the wait period
Well I’m still new to WC, so take this with a grain of salt…
I believe “Allow multiple” for a given statement means that if triggered more than once (by the if statement being true more than once) the statement can run multiple times concurrently (shifted in time by when they were triggered.) But what you’re looking for, I think, is for each of the with statements in a sequence of with statements to “run” simultaneously for a given trigger. This is what the Execution Method controls.
So, instead of:
A
B A
C B
C
You want:
A B C
A B C
Where time flows downward in the “pictures” above. Make sense?
BTW, don’t miss my edit to my original response. 
When you add an Action, Location is the default selection under Devices. It’s kind of the generic “I don’t want to do these tasks to any specific device” option.
this one was real trouble maker , Switch 1 controls a sound machine that because of the way i had set this piston up didn’t start until 2 hours and 9 minutes after the goodnight routine was executed…aka it woke me up after i was already asleep haha.
Well, I’m not sure. I’d have to try it. I thought one of the problems you originally described was that it was waiting the 3 minutes for each device in everything. I.e., that it would wait 3 minutes, turn the first device off, then wait 3 minutes again, then turn the second device off, etc. If what you had waited the 3 minutes just once before turning off all the devices in everything, then yes, that would be fine.
oh thats my mistake explaining, it was doing each command one after another. (ex turn off lights, then turn on lights then after 9 minutes it would adjust thermo etc…)
Now that I’ve switched them to asynchronous that problem should be resolved? Will the piston will run all commands when it executes instead of one after another?
Ok, for my own better understanding, I just did a test with one with statement that has two devices, which included a wait task and a task to change the devices. It did what one would hope/expect - i.e., it did the wait once, then did the action to all the devices.
So now I’m not sure I understand your original issue completely. I can definitely see that the three with statements would execute one after the other, where all the tasks in one with statement would have to complete before the next with statement (and its tasks) would start, and that was not what you were looking for. But I don’t understand where the 9 minutes came from, given the picture of the piston you originally posted. I can definitely see that changing the Heater (I believe this is really your thermostat???) would take 3 minutes, or maybe slightly more given turning off the switches in the list before it. But I can’t see 9 minutes.
But I think the bottom line is, now that you’ve set the with statements to asynchronous, they should all “effectively” start at the same time and it should do what you want.
Fair warning: this is where you can stop reading if you don’t care about the details! 
I say “effectively” in quotes because I believe in fact it doesn’t actually “run” all three with statements “at the same time.” It still can only do one thing at a time. But, the important point is, when it comes to a wait, it will temporarily postpone that statement (i.e., the with statement), and then go on to processing the following (with) statements. Then, when the wait completes, the piston will run again and pick up the asynchronous with statement after the wait and do the rest of its tasks.
Can you post what this piston looks like now? Does it do what you want?
I ask because I don’t think that making the if statement asynchronous is what you want. The (with) statements that contain waits are the ones that need to be asynchronous.
Ah, ok, the 9 minutes came from the more recent piston you posted, not the original one.
ah thank you, its starting to make a little sense now haha… but it doesnt seem to be working the way I want.
I’d like each to start all tasks at the same time, it still seems to waiting for whatever duration before moving onto the next task, instead of pausing and moving to the next task, like you said
goodnight piston
Goodbye Piston
Log from Goodnight Command, it seems to have waited to set my thermostat then resquested a wakeup for 2 hours and did not run my switch 1 command… i’m assuming it will after 2 hours.
3/9/2018, 1:16:09 PM +916ms
+0ms ╔Received event [Home].time = 1520619370624 with a delay of -708ms
+118ms ║RunTime Analysis CS > 18ms > PS > 80ms > PE > 20ms > CE
+120ms ║Runtime (38662 bytes) successfully initialized in 80ms (v0.3.000.20180224) (119ms)
+121ms ║╔Execution stage started
+152ms ║║Executed physical command [Bedroom light].off() (13ms)
+153ms ║║Executed [Bedroom light].off (15ms)
+167ms ║║Executed physical command [couch light].off() (11ms)
+168ms ║║Executed [couch light].off (13ms)
+183ms ║║Executed physical command [Upstairs Hall].off() (13ms)
+183ms ║║Executed [Upstairs Hall].off (13ms)
+186ms ║║Cancelling statement #20’s schedules…
+209ms ║║Executed physical command [My ecobee].setSchedule([Sleep]) (18ms)
+210ms ║║Executed [My ecobee].setSchedule (20ms)
+214ms ║║Executed virtual command [My ecobee].wait (0ms)
+214ms ║║Requesting a wake up for Fri, Mar 9 2018 @ 3:16:10 PM EST (in 7200.0s)
+219ms ║╚Execution stage complete. (97ms)
+220ms ║Setting up scheduled job for Fri, Mar 9 2018 @ 3:16:10 PM EST (in 7199.996s)
+227ms ╚Event processed successfully (227ms)
3/9/2018, 1:15:20 PM +576ms
+0ms ╔Received event [Home].test = 1520619320576 with a delay of 1ms
+81ms ║RunTime Analysis CS > 15ms > PS > 48ms > PE > 17ms > CE
+83ms ║Runtime (38683 bytes) successfully initialized in 48ms (v0.3.000.20180224) (82ms)
+84ms ║╔Execution stage started
+91ms ║║Comparison (string) null executes (string) :65c3690fefcbb73537ed02fed3603633: = false (1ms)
+92ms ║║Cancelling condition #19’s schedules…
+93ms ║║Condition #19 evaluated false (4ms)
+93ms ║║Cancelling condition #1’s schedules…
+94ms ║║Condition group #1 evaluated false (state changed) (6ms)
+98ms ║╚Execution stage complete. (15ms)
+99ms ║Setting up scheduled job for Fri, Mar 9 2018 @ 1:16:10 PM EST (in 49.949s)
+109ms ╚Event processed successfully (108ms)
I just saw the reply where you suggested making the ‘wait’ statements asynchronous, not the ‘if’ statement . that was the fix!
Thank you!
The main issue is you set the wrong thing to asynchronous. The thing that needs to be asynchronous is the thing that can take a long time (i.e., contains a wait.) You set the if statements to asynchronous. That means that if the if statement itself contains a wait (which it does), the next statement after the if statement can start running. But there isn’t anything after it!
So, you can (probably) change the if statements back to synchronous. Then you need to (at least) set any with statement that contains a wait to asynchronous. If it were me, I’d just set them all the asynchronous (even though it really won’t “help” with ones that don’t contain a wait. But it will at least show the intention.)
You could also try using “Stays” instead of the wait. That seems to work better for me. So instead of changes to not present you’d have “stays not present”. That would eliminate one of your “waits”.
FWIW, I’ve had issues with stays, usually in pistons that subscribe to multiple things. E.g., let’s say you have a “ABC stays xyz for some time”. Well, if ABC becomes xyz, then the time starts and when it expires the piston runs again and then the trigger becomes true and the action occurs. So far so good. The problem I’ve had happens when later another event causes the piston to run again, and ABC is still xyz. Guess what? The time starts again and if ABC stays xyz for that time, the action happens again. So, for simple pistons stays seems ok, but once you get a little more complex, it seems to fall on its face. At least, that’s been my experience. Maybe I’m just not using it correctly. Basically, just an FYI.
Ah, I have a restriction in place that prevents it. So,
If I’m away for X mins and mode is Home, then run Goodbye.
That way, it only ever run once.
I don’t think that’s the reason. I’m sure it’s what the rest of your piston is.
Here’s a simple example of what I’m talking about:
I’m using simulated devices here but the same happens with various real devices.
In the scenario shown in the log below, I made the motion sensor active, then inactive, then waited more than a minute. It shows the “stays” trigger became true and logged a corresponding message. So far so good.
But next I pushed the button, and waited again for more than a minute. You can clearly see from the logs the stays trigger became true again.
So, as I said before, this is more of an FYI / heads-up in case you or anyone else runs into this.
3/9/2018, 7:17:11 PM +265ms
+1ms ╔Received event [Doral Ct].time = 1520644632214 with a delay of -949ms
+130ms ║RunTime Analysis CS > 18ms > PS > 71ms > PE > 40ms > CE
+134ms ║Runtime (39325 bytes) successfully initialized in 71ms (v0.3.000.20180224) (132ms)
+135ms ║╔Execution stage started
+148ms ║║Cancelling condition #4's schedules...
+149ms ║║Condition #4 evaluated true (2ms)
+157ms ║║Comparison (string) :b1070d1f86ac0eb5509e790e6c1d617d: is (string) :b1070d1f86ac0eb5509e790e6c1d617d: = true (2ms)
+159ms ║║Condition #5 evaluated true (9ms)
+161ms ║║Cancelling condition #1's schedules...
+162ms ║║Condition group #1 evaluated true (state changed) (16ms)
+166ms ║║Cancelling statement #2's schedules...
+176ms ║║Motion sensor stayed inactive for 1 minute.
+177ms ║║Executed virtual command log (1ms)
+193ms ║║Cancelling condition #9's schedules...
+194ms ║║Condition #9 evaluated false (11ms)
+196ms ║║Cancelling condition #6's schedules...
+197ms ║║Condition group #6 evaluated false (state changed) (15ms)
+200ms ║╚Execution stage complete. (65ms)
+202ms ╚Event processed successfully (202ms)
3/9/2018, 7:16:12 PM +98ms
+2ms ╔Received event [Button 1].button = pushed with a delay of 98ms
+95ms ║RunTime Analysis CS > 17ms > PS > 55ms > PE > 22ms > CE
+98ms ║Runtime (39320 bytes) successfully initialized in 55ms (v0.3.000.20180224) (94ms)
+99ms ║╔Execution stage started
+113ms ║║Comparison (enum) inactive stays (string) inactive = true (2ms)
+116ms ║║Adding a timed trigger schedule for condition 4
+118ms ║║Cancelling condition #4's schedules...
+119ms ║║Condition #4 evaluated false (14ms)
+120ms ║║Cancelling condition #1's schedules...
+121ms ║║Condition group #1 evaluated false (state changed) (17ms)
+128ms ║║Comparison (enum) pushed gets (string) pushed = true (1ms)
+130ms ║║Cancelling condition #9's schedules...
+130ms ║║Condition #9 evaluated true (6ms)
+131ms ║║Cancelling condition #6's schedules...
+132ms ║║Condition group #6 evaluated true (state changed) (8ms)
+135ms ║║Cancelling statement #7's schedules...
+142ms ║║Button pushed.
+143ms ║║Executed virtual command log (2ms)
+146ms ║╚Execution stage complete. (48ms)
+148ms ║Setting up scheduled job for Fri, Mar 9 2018 @ 7:17:12 PM CST (in 59.969s)
+157ms ╚Event processed successfully (156ms)
3/9/2018, 7:15:55 PM +102ms
+1ms ╔Received event [Doral Ct].time = 1520644556963 with a delay of -1861ms
+98ms ║RunTime Analysis CS > 18ms > PS > 59ms > PE > 20ms > CE
+100ms ║Runtime (39330 bytes) successfully initialized in 59ms (v0.3.000.20180224) (99ms)
+102ms ║╔Execution stage started
+109ms ║║Cancelling condition #4's schedules...
+110ms ║║Condition #4 evaluated true (2ms)
+115ms ║║Comparison (string) :b1070d1f86ac0eb5509e790e6c1d617d: is (string) :b1070d1f86ac0eb5509e790e6c1d617d: = true (1ms)
+116ms ║║Condition #5 evaluated true (5ms)
+117ms ║║Cancelling condition #1's schedules...
+118ms ║║Condition group #1 evaluated true (state changed) (10ms)
+121ms ║║Cancelling statement #2's schedules...
+128ms ║║Motion sensor stayed inactive for 1 minute.
+128ms ║║Executed virtual command log (1ms)
+139ms ║║Condition #9 evaluated false (6ms)
+140ms ║║Condition group #6 evaluated false (state did not change) (7ms)
+142ms ║╚Execution stage complete. (41ms)
+143ms ╚Event processed successfully (143ms)
3/9/2018, 7:14:56 PM +872ms
+0ms ╔Received event [Motion Sensor 2].motion = inactive with a delay of 49ms
+74ms ║RunTime Analysis CS > 14ms > PS > 45ms > PE > 15ms > CE
+76ms ║Runtime (39329 bytes) successfully initialized in 45ms (v0.3.000.20180224) (75ms)
+77ms ║╔Execution stage started
+89ms ║║Comparison (enum) inactive stays (string) inactive = true (1ms)
+91ms ║║Adding a timed trigger schedule for condition 4
+93ms ║║Condition #4 evaluated false (10ms)
+94ms ║║Condition group #1 evaluated false (state did not change) (11ms)
+103ms ║║Condition #9 evaluated false (6ms)
+104ms ║║Condition group #6 evaluated false (state did not change) (7ms)
+107ms ║╚Execution stage complete. (30ms)
+109ms ║Setting up scheduled job for Fri, Mar 9 2018 @ 7:15:56 PM CST (in 59.983s)
+115ms ╚Event processed successfully (116ms)
3/9/2018, 7:14:50 PM +351ms
+2ms ╔Received event [Motion Sensor 2].motion = active with a delay of 77ms
+95ms ║RunTime Analysis CS > 19ms > PS > 54ms > PE > 23ms > CE
+97ms ║Runtime (39301 bytes) successfully initialized in 54ms (v0.3.000.20180224) (95ms)
+98ms ║╔Execution stage started
+110ms ║║Comparison (enum) active stays (string) inactive = false (2ms)
+112ms ║║Cancelling any timed trigger schedules for condition 4
+113ms ║║Cancelling statement #4's schedules...
+114ms ║║Cancelling condition #4's schedules...
+115ms ║║Condition #4 evaluated false (10ms)
+116ms ║║Cancelling condition #1's schedules...
+117ms ║║Condition group #1 evaluated false (state changed) (13ms)
+127ms ║║Condition #9 evaluated false (7ms)
+128ms ║║Condition group #6 evaluated false (state did not change) (9ms)
+131ms ║╚Execution stage complete. (32ms)
+132ms ╚Event processed successfully (132ms)