@vPeteWalker, all of your goals can be accomplished in a single block, using no @global variables, and without having to initialize the local variable.
Here is the basic structure I would use,
(although your line 25 should point to your button presses)
What you cannot see in the pic above is I have TCP set to Never…
Edit: This post may be helpful as well. (auto-reset at 4am)
To see it in action, I used the same code above,with a few extra log commands:
To test, I pushed the button many times during the 1 minute period, but notice all the action takes place at the very beginning, and after the full timer expires:
That’s a good way to pass a piston to a beginner. Personally, with my human brain, I’m not a fan of double negatives, using my method will help the more you get into WebCoRE, and allows for more creativity and testing more complex pistons in the future. For example, when you define the boolean initially, if you leave it blank, and save the piston.
Below the piston, there will be an “edit” mark next to the local variable, and you’ll be able to set the boolean there, on the fly, without opening up and editing the piston.
Well, @vPeteWalker joined us three hours ago…
(but even experts appreciate variables that work right out of the box)
I hate to be the bearer of bad news, but unfortunately, your pistons above will not work unless you resort to using a global, or re-structuring the piston some other way.
What do you mean it won’t work unless I resort to using a global variable? 
I have loads of pistons running like this with local variables for years! For example…
Sorry, but that logic you are using to trigger off of a local stay will FAIL if any of the other triggers touch this piston during that time period.
Using your example,
Even if {Volume_change} stays false for 5 minutes, both of those commands will be aborted if any of the following happens within those 5 minutes:
Which is why I would never recommend coding that way.
To summarize, OP’s sensor will spam the piston… and the extra triggers would break your idea here, @Alwas…
My suggestion would be to try the piston in this post.
Ok, I understand that the OP’s sensor will spam the piston. But why doesn’t my piston work? Won’t those “triggers” be ignored until the wait is over?
Triggers are never really ignored. They are either subscribed to, or not.
(although I guess a device will be ignored if it is not being “subscribed” to, LOL)
Perhaps this breakdown will help…
Device’s switch), then
trigger that piston*cough* … as well as all other pistons with that same trigger)If we use the above as a foundation, we can write code to have different things happen on subsequent runs… but each event will still trigger that piston again at the top.
If you want one event to have multiple outcomes, it is up to us (the programmers) to make this happen.
(IE: using variables or other tricks)
… but it’s important to remember:
If we are still subscribed to a device’s attributes,
(IE: Device’s switch)
then changing the wording of a piston will have ZERO impact on the number of times the piston will execute.
In other words, the number of times a piston will execute is entirely based on what device(s) and attribute(s) are subscribed to.
Any changes to the wording will only impact the flow or direction after the trigger comes in.
(not the trigger count)
TL;DR
No amount of coding in webCoRE will stop a trigger from coming in.
(other than perhaps Pause piston)
Take this silly example:
IF GrandfatherClock's tick changes to tock
Then
Take a shot of espresso
Wait 5 hours
END IF
I would be bouncing off the walls 6 seconds
(or 
shots)
after this piston started!
As you know, I struggle with WAITS. SO, during a WAIT, I presumed that any events that act on a subscribed trigger would be ignored during that piston’s WAIT. So in the OP situation, the blinking light would be “ignored” during the WAIT. Then, once the WAIT was finished, if the trigger fired again (the light was still blinking), a PUSH and another WAIT would occur, and the process repeats until the light stops blinking.
OK, I see how you are…
You like my silly example, but had no interest in my insightful and in-depth post above it.
LOL
All jokes aside, if a blink from his light triggers the piston once…
then every blink will trigger that piston
(no matter how the piston is worded)
This concept has nothing to do with waits really. Each time the “Device’s attribute changes”, the piston starts over at the top, and I drink another .
Just to clarify… This does not happen!
Each event will fire again from the top regardless.
(even the opposite of the event will trigger at the top)
Ok, yes, I did favor the espresso code…
So what happens to the piston that has the wait when a new trigger comes in? It’s cancelled and the new execution takes its place?
Ie, the piston that is waiting is not placed into a queue and finish later. That execution is cancelled, and the “new” one (from the most recent trigger) takes its place. Of course unless the programmer codes for such an event.
The same trigger always starts over at the top…
If you are asking what happens to the previous instance that was WAITING?
Well, that answer depends entirely on the wording of the code… and can easily be an hour long conversation, with exceptions to nearly every statement, LOL
But the quick & dirty answer usually lies with TCP settings.
Even though it feels like exactly what I was using in a previous iteration, but I’m happy to try! Also testing out @Alwas 's solution at the same time. I thank you both very much.
Sorry to get a bit off topic on your thread…
Please only test out one piston at a time.
All other related pistons should be paused when testing a new piston.
(so they don’t unintentionally step on each others toes)
Oh by all means man… I found the grandfather’s clock very appropriate! 
I really appreciate your help. Indeed, I am only testing one at a time… should have been more clear. Thank you!
@vPeteWalker Apologies if I jump in again on your thread but @WCmore has made some quite extraordinarily definitive statements, so absolutist in their conviction, and contrary to my own, that I feel compelled to reply to them, luckily I’m not the litigious kind. 
So out of respect to you @WCmore I went to the trouble of making a video (edit-deleted) showing clearly how my above posted piston works, with the local variable {Volume_change} stays false for 5 minutes and works, even while clicking Switch 52 on/off and …
07/06/2020, 07:57:23 +192ms
+261ms ║Volume_change changed to true after 5 minutes
07/06/2020, 07:52:18 +532ms
+6349ms ║Done 9 to 1300
07/06/2020, 07:51:36 +176ms
+218ms ║Volume_change changed to true after 5 minutes
07/06/2020, 07:46:30 +39ms
+6347ms ║Done 9 to 1300
So using wait’s for local variables within pistons, like in my posted piston, or my suggestion to the OP works. Maybe we need the “Master of Disaster” to make a final pronouncement!
LOL… I won’t make “extraordinarily definitive statements” without testing first…
(you will see my time stamps, but it feels silly trying to “prove” it to you)
… For the record, I never said the variable would change, I said the commands would not follow thru after the STAY… regardless of what the variable does.
Here is a simple piston, using your code…
(I normally code differently, but I wanted the test to be fair)
In this test, I flipped Switch 1, to start the piston normally. During the STAY time period, I flipped the totally unrelated Switch 2. (different device, different block of code, with nothing crossing over)
If you look closely, you will see no mentions of schedules after the :37:21 interruption.
(the second unrelated trigger was where it aborted)
I am not going to waste time showing screenshots of the other 3 scenarios, but I can assure you… Flipping either lightning bolt (Switch 1 OR Switch 2) will prevent the STAYS from following thru…
I think I will stand behind my earlier statement.
Oh my goodness! I can’t actually believe it! Sticking to what we’ve been talking about (I feel introducing “similar” code, with ‘else’s’, is confusing and a distraction) and I don’t how to say this gently, but you’re wrong. And I won’t insist on an apology from you WCmore, because I understand how human relationships and even geopolitics can be destructive when people stick to certitudes of opinion, but an apology in private would not be mentioned again. 
In order for this not to go to the Supreme Court, I am openly and freely sharing the logs from my plus eighteen month piston that “doesn’t work”, where I continuously click switch 52, and the local variable stays doesn’t break.
07/06/2020, 09:32:31 +364ms
+0ms ╔Received event [Home].time = 1591515152141 with a delay of -777ms
+252ms ║Volume_change changed to true after 5 minutes
+257ms ║Volume_change changed to true after 5 minutes
+260ms ╚Event processed successfully (260ms)
07/06/2020, 09:32:21 +896ms
+1ms ╔Received event [Zzzzz MUTE MUTE].switch = off with a delay of 150ms
+256ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 9:32:32 AM CEST (in 9.99s)
+347ms ╚Event processed successfully (346ms)
07/06/2020, 09:31:43 +602ms
+2ms ╔Received event [Zzzzz MUTE MUTE].switch = on with a delay of 189ms
+304ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 9:32:32 AM CEST (in 48.236s)
+315ms ╚Event processed successfully (315ms)
07/06/2020, 09:30:19 +407ms
+1ms ╔Received event [Zzzzz MUTE MUTE].switch = off with a delay of 174ms
+349ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 9:32:32 AM CEST (in 132.386s)
+360ms ╚Event processed successfully (360ms)
07/06/2020, 09:29:18 +231ms
+0ms ╔Received event [Zzzzz MUTE MUTE].switch = on with a delay of 112ms
+255ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 9:32:32 AM CEST (in 193.655s)
+266ms ╚Event processed successfully (266ms)
07/06/2020, 09:28:44 +116ms
+1ms ╔Received event [Zzzzz MUTE MUTE].switch = off with a delay of 176ms
+391ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 9:32:32 AM CEST (in 227.635s)
+401ms ╚Event processed successfully (401ms)
07/06/2020, 09:28:07 +718ms
+1ms ╔Received event [Zzzzz MUTE MUTE].switch = on with a delay of 172ms
+284ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 9:32:32 AM CEST (in 264.14s)
+337ms ╚Event processed successfully (337ms)
07/06/2020, 09:27:25 +723ms
+1ms ╔Received event [Zzzzz MUTE MUTE].switch = off with a delay of 120ms
+2266ms ║Done 9 to 1300
+6382ms ║Done 9 to 1300
+6460ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 9:32:32 AM CEST (in 299.959s)
+6469ms ╚Event processed successfully (6469ms)
And if even more proof was needed, in my next post I’m going recreate exactly the same piston as the OP, with my suggestion’s of course, with logs, showing it working.
And here are the logs, 1 minute wait, you can see I’m pressing the trigger button repeatedly during the wait, nothing happens, and the wait correctly changes the variable to false after 1 minute.
07/06/2020, 12:56:33 +388ms
+0ms ╔Received event [Home].time = 1591527393295 with a delay of 93ms
+152ms ║false variable changed to false
+155ms ╚Event processed successfully (155ms)
07/06/2020, 12:56:08 +955ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 159ms
+121ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:56:33 PM CEST (in 24.219s)
+139ms ╚Event processed successfully (138ms)
07/06/2020, 12:55:55 +212ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 157ms
+124ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:56:33 PM CEST (in 37.959s)
+135ms ╚Event processed successfully (134ms)
07/06/2020, 12:55:49 +144ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 774ms
+186ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:56:33 PM CEST (in 43.966s)
+200ms ╚Event processed successfully (201ms)
07/06/2020, 12:55:43 +348ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 117ms
+113ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:56:33 PM CEST (in 49.835s)
+124ms ╚Event processed successfully (124ms)
07/06/2020, 12:55:33 +165ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 200ms
+123ms ║(Variable Test #3) Dehumidifier FULL!
+134ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:56:33 PM CEST (in 59.997s)
+141ms ╚Event processed successfully (141ms)
07/06/2020, 12:55:27 +223ms
+0ms ╔Received event [Home].time = 1591527327175 with a delay of 47ms
+119ms ║false variable changed to false
+121ms ╚Event processed successfully (121ms)
07/06/2020, 12:55:05 +917ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 118ms
+107ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:55:27 PM CEST (in 21.151s)
+119ms ╚Event processed successfully (119ms)
07/06/2020, 12:54:49 +532ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 114ms
+106ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:55:27 PM CEST (in 37.537s)
+116ms ╚Event processed successfully (115ms)
07/06/2020, 12:54:43 +167ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 177ms
+215ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:55:27 PM CEST (in 43.793s)
+226ms ╚Event processed successfully (226ms)
07/06/2020, 12:54:36 +358ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 323ms
+110ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:55:27 PM CEST (in 50.707s)
+122ms ╚Event processed successfully (122ms)
07/06/2020, 12:54:27 +42ms
+1ms ╔Received event [Zzzz Remote Futon].button = pushed with a delay of 750ms
+126ms ║(Variable Test #3) Dehumidifier FULL!
+137ms ║Setting up scheduled job for Sun, Jun 7 2020 @ 12:55:27 PM CEST (in 59.996s)
+147ms ╚Event processed successfully (146ms)