Problem making a simple time based event

#1

1) Give a description of the problem
Made a simple piston, I want to power off a switch if I am away for an extended period of time. I’ve chosen 20 hours for this condition. So far its been running around 8 hours after I leave, but doesn’t seem to be counted from Away.
2) What is the expected behaviour?
I want to make sure the counter will reset if I am away for less then 20 hours, but happen to be away again at 20 hours from the first exit

3) What is happening/not happening?
It doesnt seem to be counting time properly, but I am not sure really

**4) Post a Green Snapshot of the piston![image|45x37]37%20PM

5) Attach logs after turning logging level to Full
The log is empty

#2

I think you need to get rid of your outer ‘if’. ‘stays away’ starts counting from 0 (when it changes to away) and is a trigger. With these nested like this I don’t think it will do anything, When it changes, stays away will not be true. When you stay away for 20 hours, it will run from top to bottom and ‘changes’ will not be true. The ‘stays’ will always reset if the value goes to something else. It only starts counting when the value changes to what it is supposed to track.

#3

35%20PM

That makes sense. I was looking for some sort of trigger and then a while command, but I guess stays should cover that. I will try this out and see how it goes. Thanks for your help

Strangely it would run, but seemed very arbitrary amount of time

#4

The ‘stays’ comparison is an odd thing. It is a trigger in the sense that it will cause your piston to subscribe to the location. However it is actually evaluated more like doing:

If location mode is away
Then
  Wait 20 hours
  [Execute your 'then' block]
Endif

The difference is that it does the above in the background, as it were, and immediately returns false.

Although the ‘changes to’ was probably redundant in your original piston as far as automatic triggering of the piston goes, I can’t see why it wouldn’t have worked. There isn’t a counter involved, it is just a wakeup timer set for twenty hours time relying on the usual mechanisms to cancel it when no longer required. You can usually look at the piston and see how long is left in the wait.

#5

Just a heads up. I have been having timing (wait) problems since mid April 2020 after a SmartThings platform update. Specifically, I had a piston (watchdog) that was called via an endpoint from a remote site. Every 3 minutes the piston was called which had a wait 5 minute statement. If the piston wasn’t called again within the five minute window the wait would expire and send out an SMS message.

The problem (which occurs randomly) is when the piston executes the wait, it doesn’t get set in Scheduled jobs (timeHandler) so what happens is the piston will wait forever (in the webCoRE dashboard you will see the time counter counting up instead of down). The webCoRE “Recovery” should eventually catch it and restart the piston but I am not sure if the recover starts the wait from the beginning or not. . To my knowledge this issue has never been fix. I am putting this out here in case you still have the same problem after you modify your piston. BTW, it doesn’t matter if you use the actual “wait” statement or you have it as “stays Away for…”, both set a scheduled timeHandler event. orangebucket’s way is just a cleaner and easier way of writing the piston.