This piston was working fine for nearly two years...now not working

[Eric182]

Thank you. Shard is NA01

[Paul1964]

Hi,

I think I may be seeing the same issue. I’m seeing the recovery message in the log, and a piston that used to work went inconsistent. I’ve changed the code to not use a wait now, and it works although it still seems to “wake up” several mins late and shows its recovered.

I’m on Shard EU01

[eibyer]

Getting some weird events on timers and presence issues also. I’m on the original graph.api. I will have to turn on logs and find some of the funky stuff.

Edit: This was from my presence changing to away last night…

7/22/2019, 6:17:39 PM +396ms
+0ms ╔Received event [Home].time/recovery = 1563844659391 with a delay of 5ms
+132ms ║RunTime Analysis CS > 22ms > PS > 49ms > PE > 61ms > CE
+135ms ║Runtime (48172 bytes) successfully initialized in 49ms (v0.3.108.20180906) (134ms)
+136ms ║╔Execution stage started
+137ms ║╚Execution stage complete. (2ms)
+138ms ╚Event processed successfully (138ms)

[ipaterson]

No news yet but I will keep the thread updated.

[ipaterson]

SmartThings is looking into this and the related issues that others have reported this week, hold tight for now.

[ipaterson]

I was asked to get an update on NA01 – are these timeouts still affecting you now, @Eric182?

[Eric182]

Give me until Friday to observe them for certain. No issues today though.

[ipaterson]

@Paul1964, though it seems like NA01 may be fixed others are still having related issues on EU01. Would you please check whether waits and wake ups are still running late for you?

[Paul1964]

I’ve just had a look at the log for my dishwasher cycle monitor from yesterday. It seems to have shown a delay of 10 secs after a 10min wait (power stays less than 0.6w for 10 mins) Previously it had a delay of around 2 mins. There’s also no mention of recovery, so hopefully its fixed?

I’ll check my washing machine cycle piston next time it runs. This previously worked fine and then stopped working. The dishwasher piston is similar, but I changed the way it works when they both started playing up.

[Eric182]

I’m going to say it’s Friday now. Everything is back to normal here. Thanks Ian

[Eric182]

@ipaterson I’m seeing the same issues again…as back in July

The same pistons are doing it again. I haven’t changed anything.

Does it have to do with this? By the way: I never updated to the latest version. I’m still on version 0628

Conditions evaluating incorrectly

I think he means the problem is with the " 49914fee05dd0ba22460bac202289976" itself. I wish I would have copied more of what was happening in mine, because Time was showing in very long numbers at the time, longer than usual (something like “59865452158746625412654268715815425425”). Too bad I didn’t think to copy it.

[WCmore]

The log showing “recovery” is likely because there was a lot of commotion in your house at the time this piston was supposed to run… By the time the recovery kicked in, I bet the conditions were no longer true, so nothing was executed.

Just an educated guess…

[Eric182]

I appreciate the input and I know you’re very active and helpful on this forum, but if you read this entire thread, This is a piston that’s been rocksteady for 2 years now. Back in June, it started giving me issues by not executing when it was supposed toexecute. (/recovery error/wait error. )

Ian fixed something on the backend and/or contacted Smartthings for a fix. Then it went back to working OK. Now it’s happening again. The following thread is also related.

I’m going to monitor for a few more days maybe a week. Just to make sure it wasn’t a 1 time occurrence

Wait() seems to trigger recovery every time - broken (for a while now)

I can vouch for @jgroves discovery. I have had a few pistons with “waits” that were rock solid for two years start to go wonky on me recently- like in the last 10 days or so. In fact, I’ve been keeping an eye on this forum and ST forum lately to see if anybody was posting anything about this. I couldn’t have been the only one. @jgroves Did you create this piston as an example to show people the problem with the wait? Because I have functional pistons with “waits” that this is happening to.

[ipaterson]

I’ll try to ping the SmartThings dev who looked into this last time. I don’t think anything was done to fix it but he was able to see from error logs that the ST platform was highly stressed and performance slowly recovered.

[Eric182]

Thank you.

[WCmore]

This is a piston that’s been rocksteady for 2 years now. Back in June, it started giving me issues by not executing when it was supposed toexecute

Here is an analogy:
I can drive the same car, 7 days a week… and sometimes there will be awful traffic slowing me down. Even without the piston changing, the other factors pays a huge roll on the timeliness & reliability…

… or as Ian said so eloquently:

the ST platform was highly stressed

---

Edit :
The reason why I chose the phrase, “lot of commotion in your house” is because the main time the ST platform gets highly stressed is when there’s a lot of commotion in the house, LOL

[WCmore]

Let me say this another way:
When a piston sometimes succeeds, and sometimes fails… (under the exact same circumstances), the issue usually lies in other piston(s) or other forms of home networking chatter.

Heck, even heavy downloading can seriously impact my SmartHome’s speed & reliability…

[Eric182]

Can’t suck sludge through a 1 cm straw as fast as you can with water. I get it. I understand that. Perhaps An option could be to rebuild the piston to several smaller ones. Time will tell.

[WCmore]

Perhaps An option could be to rebuild the piston to several smaller ones

I am a huge fan of this strategy… as well as avoiding loops, keeping only one trigger per piston, and insuring that only one piston fires at each event… All four of these goals of mine are for the purpose of keeping the “highway” open and clear.

---

To be completely honest, I am really looking forward to the future where our hubs can better handle multi-threaded processing…

[WCmore]

FWIW, I usually aim for the smallest amount of code processing the least number of times…
(and then completing it’s tasks quickly & efficiently)

I find overall, this makes a giant impact on speed & reliability…