Unchanged Piston that is meant to loop every 5 mintues randomly stops running?

[chadbaldwin]

For reference, this is what’s experiencing the problem:

Household tasks - automated nagging via Amazon echo, and Google Assistant

TL;DR Using voice only actions, you can queue up a list of to-do items. It then nags you every 5 minutes via Echo, to get that item done. Once you have completed the item…you can let it know either by voice, or by pushing a button of your choosing. So this is a sort of work in progress. However, it is working perfectly so far. I’ve added some extra bells and whistles over time and I will likely be modifying this quite a bit over the next few weeks as I perfect it…and also as I clean up the log…

1) Give a description of the problem
I have a piston that is set to run every 5 mintues as long as a particular variable is populated…I haven’t touched the piston in at least a month or so. All of a sudden, the piston now just decides to stop running. It’s supposed to be looping…but it will randomly just stop, and I have to go in and start it back up again. It worked great for 2 months?

2) What is the expected behaviour?
Piston loops every 5 minutes and never stops until it’s told to stop, or the variable is cleared.

3) What is happening/not happening?
It’s stopping on it’s own, and can’t figure out why.

4) Post a Green Snapshot of the piston

5) Attach logs after turning logging level to Full
NOTE: Since this isn’t something I can easily recreate, I did not have full logging on at the time this happened. However, I do have this…The piston was running every 5 minutes like it’s supposed to, and then randomly stopped at 9:15AM…then for some reason it ran at 9:22AM with a trigger of [Home].execute? Then it stopped running after that until I noticed that it wasn’t running and manually kicked it off using the ifttt trigger.

4/22/2020, 11:43:45 AM +841ms
   +0ms ╔Received event [Home].ifttt = ChoreQueueRepeat with a delay of 74ms
 +121ms ║Piston Start
+2164ms ║Announcing Queue Item: Feed the dogs
+2377ms ║Setting up scheduled job for Wed, Apr 22 2020 @ 11:48:48 AM PDT (in 299.996s)
+2388ms ╚Event processed successfully (2388ms)

4/22/2020, 9:22:01 AM +403ms
   +0ms ╔Received event [Home].execute = recovery with a delay of 84ms
 +150ms ║Piston Start
 +207ms ║Piston End
 +210ms ╚Event processed successfully (210ms)

4/22/2020, 9:15:09 AM +151ms
   +0ms ╔Received event [Home].time = 1587572110606 with a delay of -1456ms
+2277ms ║Announcing Queue Item: Feed the dogs
+2525ms ║Setting up scheduled job for Wed, Apr 22 2020 @ 9:20:11 AM PDT (in 299.996s)
+2532ms ╚Event processed successfully (2532ms)

4/22/2020, 9:10:08 AM +120ms
   +0ms ╔Received event [Home].time = 1587571809503 with a delay of -1384ms
+2196ms ║Announcing Queue Item: Feed the dogs
+2491ms ║Setting up scheduled job for Wed, Apr 22 2020 @ 9:15:10 AM PDT (in 299.996s)
+2498ms ╚Event processed successfully (2498ms)

[chadbaldwin]

Thanks, I’ll check it out! I have a feeling this isn’t the issue, but may still be a good read to stay up to date.

The current version of my piston executes another piston to perform the announcement. That “announcement piston” does multiple things…it sends me a push notification to my PC and phone using the “Join” android app. It announces on my echos via Echo Speaks. And it also has the ability to send SMS, as of now, SMS is off by default.

When this problem occurs, the logs for the piston stop completely and my push notifications stop going out as well, not just echo notifications. So it seems this is a problem with the piston stopping to run for no particular reason.

[orangebucket]

You have a ‘recovery’ in there. For whatever reason, your piston hasn’t received the timer event to make it run after a ‘wait’ and a recovery routine has spotted this and fired the piston so it can try and recover. It can’t.

Missed timers shouldn’t happen, but do. This week all my motion sensors have been regularly getting stuck on active because the device handlers use a timer event handler to reset motion and it hasn’t been running. It isn’t normally that bad but the occasional missed event isn’t unusual.

Your piston design is just particularly vulnerable to this.

[chadbaldwin]

That explanation makes sense as to what’s causing the piston to stop.

It’s weird that this all of a sudden became a problem in the last week when it’s been fine for 2 months. I guess I’ll have to redesign the piston to be more resilient. Perhaps I’ll make it time of day based rather than schedule based…Maybe enable/disable the piston based on whether the variable is populated, and as long as it’s enabled, it executes every 5 minutes. That way if something does get messed up, it will just run again at the next 5 min interval.

That could also resolve another known issue. Currently, if you try to edit the piston while it has a pending schedule, that will clear the schedule, and you have to remember to kick it off again using one of the triggers.

[WCmore]

That way if something does get messed up, it will just run again at the next 5 min interval.

This is how I achieve this… A single line piston keeps the timing regular, and the complex piston is the one being executed. Even if there is an issue with the complex piston, it will fire again like clockwork.

---

For the record, this piston was last edited over two years ago:

and it is still running within a minute of the original time slot:

(after over 200,000 executions!)

---

Considering all the updates, reboots, power outages, plus 4 time changes over two years and nearly a quarter of a million executions, I find a one minute variance to be kind of impressive.

---

Note:

I continued to edit the “complex” piston many times over the past two years, but the timing never changed, since the timing piston was not touched.