I agree with all of you. And it’s all kinds of pistons. Not just ones with virtual switches.
Rock steady pistons that I haven’t touched for 1-2 years. I’m giving it a few days before I move some of my less complicated stuff over to Smart lighting in the new ST app. …Which I hate to do. I am OCD and I like to have everything in webCoRE.
hate to tell you but I have also been having some of the same issues with some of my Smart Lighting rules … sometimes they fire, sometimes they do not
Have you Recently started having problems? During this recent spell of sluggishness? Or have you always had problems with smart lighting?
In other words is it the whole ST platform? I’m pretty sure it is, it’s up on their status page
Oh, no - not at all! I was agreeing with you. Sorry my wording was unclear and for the misunderstanding.
I am also having trouble with pistons not executing when SmartThings routines are activated. “I’m Back” is one of them. I also have a “Work” routine which isn’t firing a piston either when activated.
I’ve also been having problems this week with my pistons working. Most of the ones I’m having problems with involve WIFI devices such as LIFX bulbs or Ecobee thermostats. The integration with zigbee and z-wave devices seems to mostly be working.
2nd-ed (?) on the possible issue of new state being stored and able to be referenced. My issues these past couple of days have been open close notifications that continue to run the open notification loop while they in fact have been closed already. Piston either skipped or missed the closed part possibly due to this issue. Simply having the piston tested resolves the issue by it now reading the current state and finishing.
I’ve taken some time to write a more robust version of one of my newly failing pistons. It now loops until the desired results are met or it reaches (5) attempts without success. This effort essentially had no discernable impact on succesful completions. The piston continues to miss actions, comparisons and many times simply fails to even start running at all. IDE logs still show the following error:
error java.util.concurrent.TimeoutException: Execution time exceeded 20 app execution seconds:.
Something on the ST side is eating cycles.
As we can see from the status page, the Groovy platform is still in bad shape. This has the potential to affect anything using the platform – webCoRE, other smart apps, device handlers, anything that runs off-hub and/or reports to the cloud. Personally I don’t think it’s worth spending time to find workarounds since even the simplest automations could fail due to everyone’s automations failing and attempting recovery. All of those actions are vying for limited compute power on the cloud platform, so there may be no logical patterns to be found in the failures.
This is a storm and it will blow over eventually. One would hope that SmartThings is still willing and able to temporarily autoscale the Groovy platform to deal with activity spikes following outages, but that is probably a financial decision at this point, mostly out of the hands of the ST tech team.
If anyone wants to “do their part” in helping it pass more quickly, the best thing we can do is disable our non-essential high-overhead automations. If a piston is running every minute and doesn’t really need to, consider disabling it until the storm passes. We all have the opportunity to slightly relieve the platform load.
I just tried a temporary contact and smartapp I set up to test this issue. It was only working 10% to 20% of the time over the last 3 days. I’ve tried it 20+ times now and the smartapp received the event every time and successfully made the webhook call to my web server.
I also just had a delivery arrive and my driveway motion sensor triggered alexa to talk both using Echo Speaks and WebCore. The MQTT SmartApp received the event and successfully made its way to the bridge on my side which triggered a python script to e-mail me 3 stills from my driveway camera. The same happened successfully when my front porch motion detector detected the mail lady at the porch. Over the last 3 days, this also only worked 10% to 20% of the time.
I’m keeping my fingers crossed that the problem is resolved.
Looking good so far… my presence pistons updated at lunch time. Will keep an eye on my aquarium pistons tonight as that and my presence ones are the main ones affected.
Mine started acting up again last night around 7PM PST. The weird thing is it only affects my power strip that is used in my aquarium and my mode events. My log from this morning…
9/23/2019, 6:55:45 AM +218ms
+1ms ╔Received event [Home].time/recovery = 1569246945218 with a delay of 0ms
+148ms ║RunTime Analysis CS > 36ms > PS > 53ms > PE > 58ms > CE
+150ms ║Runtime (48170 bytes) successfully initialized in 53ms (v0.3.108.20180906) (149ms)
+151ms ║╔Execution stage started
+152ms ║╚Execution stage complete. (1ms)
+153ms ╚Event processed successfully (153ms)My presence sensor pistons failed to execute for both me and my wife this morning.
Everything worked for me this morning. The pistons fired based on presence changes and the modes were set correctly. Hopefully, this was not just a one time fluke!!