WAIT or STAYS? (to have something happen 3 hours after something else) Does it matter?

#1

Mainly just curious right now for my current piston build, but I wonder if it might matter in other situations.

I know there are probably certain contexts in which one would be better than the other. I’m just not sure. I assume with something this simple, it’s irrelevant, but just checking…

Using WAIT:
If SWITCH1 turns ON
WAIT 3 hours
Do Something

Using Stays:
If SWITCH1 stays ON for 3 hours
Do Something

The only effective difference I can think of with this particular comparison is that, in the WAIT scenario, the ‘Do Something’ would happen regardless of whether SWITCH1 was still on or not after the 3 hour period, whereas with the STAYS scenario, the Do Something would be dependent on SWITCH1 still being on after the 3 hour period.

Is that right?

#2

Some people here can give you a better answer but my two cents would be this,

IF motion sensor changes to ACTIVE
Turn lights ON
Wait 3 minutes
Turn OFF

In this case, if you leave the room and come back, and if this happens right around the 3 minute countdown, you lights will go OFF first and came back up… Which can be annoying.

In this light example it’s better to use STAYS inactive. So light would never go OFF as long as there is motion in the room.

#3

Thank you!
That’s a really great point. :slight_smile:

As I look around through my webCoRE, I remember that I changed over to using STAYS instead of WAIT for this exact reason in my motion-triggered lighting pistons a long time ago.

Are there any other contexts in which it might matter which one we use?

#4

Well i’m not a coder or Webcore expert just so you know:))) still learning big time…\

WAIT, is ussualy used to pause the piston from running. Because a piston runs top to buttom in one go and doesn’t go back to top unless the triggers and/or conditions are TRUE.
STAYS, is checking a certain device (switches, bulbs etc)

ie: I use wait when I want my piston to pause to be continued running after countdown.
if i have a lot going on in a piston I add WAIT 5 seconds between commands. So that signal issues won’t effect my real life situation.

IF X changes to Y
Then 
With a, b, c, 
Turn OFF
WAIT 5 seconds
With d, e, f
Turn OFF
Wait 5 seconds
With g, h, i
Turn OFF

If i did this instead,

IF X changes to Y
then 
With a,b,c,d,e,f,g,h,i
do Turn OFF

I might get inconsistent results.

STAYS I use when I need to check on a device or a failsafe method

IF front door lock stays UNLOCKED for 2 minutes
Then do this do that

or

IF light bulb X is STAYS on for 15 minutes (which is not supposed to)
Then
Do turn OFF light bulb X
#5

This is great.
Yes. I do all of this as well, for the exact reasons you identified.
It’s very helpful, though, to hear it laid out like you did here.

As with many other people on the webCoRE and SmartThings forums over the years (I don’t like to list them for fear of unintentionally leaving some out, but I suspect you know who I mean), thoughtful, relevant, patient, humble interactions like this with you here enable me to take specific, targeted knowledge which I may have already used in certain limited applications and turn it into general principles that I’ll be able to apply more broadly in the future.

So, thanks again. :slight_smile:

#6

If you consider:

if SWITCH1 changes to on
then
  wait 3 hours
  do something
endif

If SWITCH 1 changes to on, the piston will schedule a timer to wake it up in three hours. If the piston is fired again during those three hours the trigger condition will now be false so by default the wake up will be cancelled (in practice it still wakes up, but with nothing to do). That makes it quite a vulnerable thing.

You can, of course, set TCP to ‘never cancel’ for the wait so the piston will wake up and ‘do something’ regardless of what happens.

If you want to find the middle ground, where the ‘do something’ will happen unless the switch is turned off, you can add an ‘OR SWITCH1 is on’ to the conditional (or if a trigger isn’t needed, just make it a conditional rather than a trigger in the first place). That way the wait won’t be cancelled unless the switch is turned off.

As for

if SWITCH1 stays on for 3 hours
then
  do something
endif

That is an interesting beast. It is a trigger in the sense that the default behaviour is to automatically subscribe to changes in the switch. However the comparison used to evaluate the trigger is actually identical to ‘is on’ so if SWITCH1 is already on the comparison does return true. I would best describe it as acting like:

if SWITCH1 is on  (set to always subscribe)
then
  wait 3 hours
  do something
endif

AND it also immediately returns false and executes any else block and any code following the endif.

So there is no pause to the flow of the piston as there is with the WAIT example, and also the wake up is a little more resilient.

I am sure I have got some of the fuzzy details wrong.

#7

@orangebucket
Hey, sorry…I didn’t mean to ignore your last response here.
I just got caught up in other stuff.
I will still be circling back around to this one eventually, and will go through what you said a couple more times when I do. :slight_smile: