Long delays in piston execution

[wgmcg]

I’ve noticed graphs that look like this in several pistons lately. What could be causing it? intermittently I see very long delays in piston execution. Could this be caused by running recovery too frequently?

[dville]

Off topic question: Where are you getting these charts from?

[wgmcg]

The charts come from the webcore “statistics” section of each piston.

[restauffer]

Any luck on this issue? I have the same delays on a piston and in the logs, when this happens, I see the piston running over and over always starting with “…execute = Recovery with a delay of…” This is a piston that has worked daily for almost a year so it is not something that changed in the piston itself.

[ipaterson]

Here is another recent issue regarding piston timeouts

One Last Hail Mary

All my pistons that use “when time happens daily at…” are failing. They fire about 1-2 minutes late and the “time happens daily” condition evaluates false. Things I’ve noticed: When my pistons were working, my log files used to show [Home].time when they executed based on “time happens daily”. Now, when they fire late, they are triggered by [Home].execute This is always followed by {Home].time/recovery within 15-20 seconds. The [Home].time/recovery trigger still evaluates false for my “time h…

This is most likely a ST platform issue. Are there any pistons that exhibit this behavior 100% of the time while others continue to trigger fine? The earlier report seemed to be related to date-based triggers like “time happens daily at …”

[dville]

My issue was resolved because the Fortrezz MIMO 2+ zwave device I was using was taking too long to acknowledge automation actions.
I created a virtual switch used ST SmartLighting local automation to have the MIMO relay mirror the status of the virtual switch and my WebCore scripts using this relay have run great ever since.