Is webCoRE slow this morning (16 September, 2019)?

#52

The issues may be resolved now…

#53

It seems to be fixed!

#54

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.

#55

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.

#56

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)
#57

My presence sensor pistons failed to execute for both me and my wife this morning.

Location Mode change Piston stopped working
#58

Oops, yep, my mode stuff is driven by presence.

#59

Yes. Same here. Same problems as last week.

#60

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!!

#61

No go for me this morning, triggered recovery for mode change via presence.

#62

Same here. It’s the same pistons as last week. Presence and mode changes

#63

I’ve noticed this problem has returned for me as well. It’s not as bad but it’s definitely back.

#64

Ditto. Issues with presence and modes cleared up for 2 days, but they’re back.

#65

Same here. Issues with just about all pistons, even those fired by a virtual switch do not work.

#66

Same here. This morning my Work piston failed to fire just as it did last week.

#67

Looks like back to normal again…

#68

This a repost from many days ago on the ST forum. I too have been having many issues.
I think yesterday and today have been ok but I will scrutinize all my Pistons that have Location daily; these seem to be the ones that were failing or half running.

Over the last 2 weeks all my Good xxx have been either executing, executing only 50% of the piston or not running at all no matter how many times I tell it to execute. Good Bye, I’m Back and Good night seem to be the worse now. All the other pistons work fine but it appears that anything with “Location” mode change is affected.
These pistons were solid for 2 years and now all this random execution; if at all.
Any suggestions would be appreciated.

Logs show partial execution or the snippet below…

I seem to get a lot of this which I’m not sure what it indicates:
18/09/2019, 18:26:06 +879ms
+1ms +Received event [Home V2].time/recovery = 1568856366872 with a delay of 5ms
+2162ms ¦RunTime Analysis CS > 1989ms > PS > 95ms > PE > 80ms > CE
+2166ms ¦Runtime (50094 bytes) successfully initialized in 95ms (v0.3.10f.20190822) (2161ms)
+2167ms ¦+Execution stage started
+2169ms ¦+Execution stage complete. (1ms)
+2179ms +Event processed successfully (2180ms)
18/09/2019, 18:25:55 +131ms
+0ms +Received event [Home V2].time/recovery = 1568856355127 with a delay of 3ms
+156ms ¦RunTime Analysis CS > 31ms > PS > 65ms > PE > 60ms > CE
+159ms ¦Runtime (50091 bytes) successfully initialized in 65ms (v0.3.10f.20190822) (157ms)
+160ms ¦+Execution stage started
+161ms ¦+Execution stage complete. (1ms)
+162ms +Event processed successfully (163ms)

#69

This usually means there was too much congestion in your home network or ST hub… By the time the “recovery” kicked in, I suspect the original conditions were no longer true.

#70

I have very little traffic, most of the 25Meg is free all the time; no kids at home anymore :slight_smile: This is the first time in 4 years I have had this message.
Today I still have pistons failing but it’s always on a piston with Location mode.
It almost looks like it does whatever percentage of work in the piston until it encounters the Location change then it dies and the rest of the commands go unexcuted.

#71

Maybe you could confirm your thoughts by putting the “location mode change action” last and see if everything before it fires. Just a thought