For a while now, it seems that the timing of some of my pistons have been affected (failures) by daily or even more frequent 10 second or longer load spikes. See the following webCoRE statistics graph:
If it makes a difference, this is one of the pistons (I have three of these - almost the same) that seems to now fail 30% of the time now sometimes more. It/they were flawless before. I don’t believe it’s the piston’s fault, but rather the system delays.
In what way is the piston failing? Only what leaps out at me is that the changes triggers are only evaluated between AMTime and PMTime. A change is evaluated by comparing the value in the current event to a cached value, and that value only seems to be cached if the trigger is evaluated. That means if any of the attributes changes outside of the time range the piston might get confused when it comes to evaluating the triggers.
The AM/PM times are not an issue and are functioning as intended. One of the three very similar pistons I’m using does not have the AM/PM time variables in it and the issue I’m describng happens in that piston too.
The delays are causing 10,000ms+ semaphore - which becomes too long and the piston just stops. The normal outcome of this is that the light normally turns on but does always not turn off. A further indication is that, since the piston stops functioning, the Boolean variables get out of sync.
I have three pistons for three different rooms that are pretty much the same as each other . Until the ST switch to the new app, they ran without error for many, many months.
As a follow up to my initial post, after the recent (Jan 14th) ST disruption, my system - and specifically the pistons discussed here, started running much better again. So, I looked at the webCoRE statistics chart. Note that after the 14th, the timing spikes have disappeared - coinciding with the pistons running perfectly again. Also, compare the chart below to the one I originally posted (1st post above).
Whatever ST fixed, seems to have worked for this issue.
