Pausing webcore

#1

Hi there,

I am looking to create a rule that would pause “ALL” rule, how can i go about it without having to select each one of them one by one.
Also i should be able to “resume it”
My end goal is to use ifttt, to resume all piston/pause all piston

Any ideas?

#2

Set a Boolean global variable @pause_all

Then st the top of each piston put a restriction
Only when @pause_all is false

Then create a master piston tgat changes the global variable to true or false.

There is I think an action to pause all pistons. But then you would have to restart them manually. Since there isn’t a piston running anymore to restart them for you
Edit: no pause all, but you can pause selected pistons and resume them as an action
Just a thought

#3

Or in the app you can disable all pistons.

#4

Or, if we are really thinking outside the box…

You could get a smart outlet that is compatible with IFTTT without using a hub. Then you could plug your ST hub into the outlet, and let IFTTT turn the power on or off. With no power to the hub, all pistons stop immediately.

The global variable that @Gopack2 suggested can work, but it requires a bunch of extra code, since things will often continue to run for awhile after the variable changes.

IE: Walk past motion sensor… 1 minute later it goes inactive… Then you flip the switch to pause the pistons… Shortly thereafter, the motion detector has been inactive for 5 minutes, so the code continues.

Again, it is possible, but all of the code needs to be thought of quite differently if you go that route.

Please don’t take this wrong @GGexe, but the only reason I ever pause a piston is when my code is in the development phase. A well coded piston would never need to be paused.

#5

Hi thanks everyone for your input.
After some thought it decided to go with @Gopack2 idea
Instead of doing the global variable route, i decided to create a custom “location mode” instead (named disable).
Then in each of my rule, to put a condition where “location mode” is not in “Disable” for example

@WCmore Thanks as well, i agree with your last statement, it was acutally for development phase that i needed it

#6

Good thought. I was thinking about exactly this after I suggested the other.

The only suggestion I have, is at the very top of each piston, put an if block in there. Have it check to see if location mode changes. Depending on how each piston is set up, have it cancel all pending tasks. That should stop any timers. If you have variables set up to validate other things, you may need to reset them to default values, in case the particular piston was in the process of executing. Then have it pause the piston.

You could also do the variable reset on piston resume.

Just a couple of thoughts

Good luck!

#7

Great suggestions!

Sometimes I wish we had a sandbox to play around in…

#8

You only need the “cancel all” if you are using “wait”, correct? If you set a variable to a date/time for an action to occur, and the restriction changes during the intervening time between the variable being set and the time it’s set for, the action won’t occur then, correct? The variable being set and the action are in separate if blocks as well.

#9

I believe so. Can’t think of any other at the moment. Maybe loops too?

Correct, however that variable will not clear out and will remain set at the date and time, when you resume the piston. Unless you clear it before the pause.

That should not matter, the cancel all is not limited to select if blocks, it will cancel all pending tasks for that particular piston.

@WCmore any other thoughts here?

#10

Even without a wait, this one will have issues if the timing is right (err, wrong):

  • Walk past motion sensor…
  • 1 minute later it goes inactive…
  • Then you flip the switch to pause the pistons…
  • Shortly thereafter, the motion detector has been inactive for 5 minutes, so the code continues.

Behind the scenes: When the motion firsts goes inactive, it sets a reminder X minutes in the future to complete the commands…

One solution for this case is to make the query on the ‘master switch’ inside the THEN section instead of as a condition. Such as:

This one would cause issues:

If MotionSensor stays inactive for 5 minutes
and
MasterSwitch is off    <--This line needs to be moved into another IF
THEN
    Run piston commands
END THEN
END IF

This one would work well:

If MotionSensor stays inactive for 5 minutes
THEN
    IF
        MasterSwitch is off    <--This line is not checked until AFTER 5 min
    THEN
        Run piston commands
    END IF
END THEN
END IF

This is a great example of how one must think differently if one wants to design a ‘kill-switch’ for a piston.

#11

It’s not THAT important. I have my override switches the way you have them, as a condition on the then, but I have a location setting that disables all primarily for testing. So i can ensure no other pistons will fire and I can isolate what I’m running/fixing/building/debugging. But thanks for the info! Very informative.