'Do Every' piston running every 3 seconds

[Robin]

You could also add a 3rd block:

Every 3 weeks
DO
nothing
end every

This should then keep the subscriptions below the current 25 day bug and prevent looping.

[lflorack]

Just to clarify, your original piston will run thru the code whenever Switch 37 turns on or off.
(which could theoretically be hundreds of times a day)

Switch 37 is a virtual switch called “Cooling Season Flag”. It normally turns on once a year and off once a year - either automatically via the Auto On/Auto Off code blocks, (i.e., seasonally April and October 1st) or via manual activation (ST, Action Tiles or Alexa) of the Cooling Flag switch. I’m not so worried about what the piston will do seasonally. I was mostly concerned about the manual activity and what it’d possibly do in the variable change section after the Auto on/off sections. I’ll have to think further to determine whether it’s possible for those actions to cause an out-of-sync condition. Anyway, that was the distinction I put those restrictions in place for.

My suggestion below will only run thru the code twice a year… PERIOD

That’s correct - when run completely without ‘manually’ activating the “Cooling Season Flag”. The piston was written to handle the seasonal automatic change-over from/to cooling season but also the manual actions too. Again, I’ll have to think if the change you suggested would actually cause the issue I raised above when ‘manually’ activating switch 37.

[lflorack]

The reason those are there is so my TStatSetTime variable doesn’t get multiple adjustments in the same direction (+ or -) - making it hours out of sync. Those restrictions prevent that issue.

@WCmore

I ran some tests to ensure that the removal of the restrictions wouldn’t cause the issue I described above. The piston ran fine and the variables I was worried about were also fine.

As I described in my earlier response, Switch 37 is a seasonal virtual switch for Cooling Season (on or off) and will only be toggled twice annually. So, it wasn’t the cause of any looping. The looping for this piston is strictly the result of the ‘too far out’ bug. BUT, it does certainly streamline the piston!

Thank you again.

[WCmore]

No problem. Glad to help

[ipaterson]

As of this morning I noticed a change in this behavior. My test pistons are either scheduling correctly for > 25 days in the future or triggering early (but just once). That behavior seems like perhaps ST has applied a fix and it just hasn’t spread to all of the load balanced servers yet.

However, now people are having issues with short waits not firing.

Pistons with waits failing

Please continue in the topic that you started here, announcement threads are not an appropriate place to debug issues that are not related to the release. Can you post a snapshot of your piston or of a simplified piston that shows the same behavior?

[lflorack]

As of this morning I noticed a change in this behavior. My test pistons are either scheduling correctly for > 25 days in the future or triggering early (but just once). That behavior seems like perhaps ST has applied a fix and it just hasn’t spread to all of the load balanced servers yet.

I looked at all of my existing ‘Do Every’ pistons and none of them are currently looping. So, I created a new test piston with two ‘Do Every’ blocks and it functioned properly the first time - i.e., scheduled itself for the appropriate date and time and stopped.

Thank you for your efforts on this!

However, now people are having issues with short waits not firing.

That’s not good. I’ll have a look at my pistons and see if there’s an issue with any of them. If I do, I’ll post in the thread you linked.

[ipaterson]

Thank you for confirming!

[lflorack]

@ipaterson

Over the last week or so, many ‘Do Every’ pistons are looping every three seconds or so again. Just like previously.

[ipaterson]

[fieldsjm]

Something similar is happening to one of my pistons except I am using IF Date and TIme happens block. The next expected date has scheduled correctly, though it isn’t until 9/3, however piston is unintentionally executing every 3 seconds Has anyone else experienced this recently?

Edit: I added an extra line that forces it to run daily as a check. It scheduled successfully for tomorrow’s check and has stopped executing every 3 seconds.

[WCmore]

It scheduled correctly though the next run isn’t until 9/3

Without seeing a piston, this sounds normal to me.
(depending on your code, of course)

---

On the other hand, if it’s not the date you expect, perhaps try focusing on the code that schedules that job.

---

Edit:

Sorry, blonde moment… I just realized that you’re confirming the unintentional 3 second looping.

Please carry on…

[lflorack]

Edit: I added an extra line that forces it to run daily as a check. It scheduled successfully for tomorrow’s check and has stopped executing every 3 seconds.

I’m the OP of this thread… You’ve got the right idea. The only way I was able to stop the every-3-second-looping was to add a ‘Do Every’ [NoOp] weekly or so. After I and others researched it, we found that the 3-second loop only shows up if the next scheduled date is 25 or more days out. So, daily scheduling is a bit of overkill . Anything less than approximately three weeks should be sufficient.

Here’s an example snippet of one of my ‘corrected’ pistons:

[fieldsjm]

Thanks, I’m just shocked that this is still a problem two years later

[dejavux2]

Was this ever resolved? I’m having this issue with one of my pistons. Funny thing is, that it didn’t always do this. This started sometime in the last two weeks.

+0ms	╔Received event [Home].time = 1606543200000 with a delay of -4262651811ms
+132ms	║RunTime Analysis CS > 23ms > PS > 41ms > PE > 68ms > CE
+135ms	║Runtime (58002 bytes) successfully initialized in 41ms (v0.3.110.20191009) (134ms)
+137ms	║╔Execution stage started
+138ms	║╚Execution stage complete. (2ms)
+140ms	║Setting up scheduled job for Sat, Nov 28 2020 @ 1:00:00 AM EST (in 4262651.67s), with 1 more job pending
+149ms	╚Event processed successfully (150ms)
10/9/2020, 5:55:45 PM +655ms
+1ms	╔Received event [Home].time = 1606543200000 with a delay of -4262654345ms
+133ms	║RunTime Analysis CS > 22ms > PS > 59ms > PE > 52ms > CE
+137ms	║Runtime (58002 bytes) successfully initialized in 59ms (v0.3.110.20191009) (134ms)
+138ms	║╔Execution stage started
+139ms	║╚Execution stage complete. (2ms)
+141ms	║Setting up scheduled job for Sat, Nov 28 2020 @ 1:00:00 AM EST (in 4262654.205s), with 1 more job pending
+147ms	╚Event processed successfully (146ms)
10/9/2020, 5:55:42 PM +102ms
+1ms	╔Received event [Home].time = 1606543200000 with a delay of -4262657898ms
+108ms	║RunTime Analysis CS > 24ms > PS > 40ms > PE > 43ms > CE
+111ms	║Runtime (58002 bytes) successfully initialized in 40ms (v0.3.110.20191009) (109ms)
+112ms	║╔Execution stage started
+114ms	║╚Execution stage complete. (1ms)
+115ms	║Setting up scheduled job for Sat, Nov 28 2020 @ 1:00:00 AM EST (in 4262657.783s), with 1 more job pending
+129ms	╚Event processed successfully (129ms)
10/9/2020, 5:55:39 PM +354ms
+0ms	╔Received event [Home].time = 1606543200000 with a delay of -4262660647ms
+183ms	║RunTime Analysis CS > 48ms > PS > 81ms > PE > 55ms > CE
+187ms	║Runtime (58002 bytes) successfully initialized in 81ms (v0.3.110.20191009) (186ms)
+188ms	║╔Execution stage started
+190ms	║╚Execution stage complete. (2ms)
+193ms	║Setting up scheduled job for Sat, Nov 28 2020 @ 1:00:00 AM EST (in 4262660.454s), with 1 more job pending
+200ms	╚Event processed successfully (201ms)
10/9/2020, 5:55:36 PM +297ms
+151ms	╔Received event [Home].time = 1606543200000 with a delay of -4262663704ms
+285ms	║RunTime Analysis CS > 190ms > PS > 53ms > PE > 42ms > CE
+288ms	║Runtime (58005 bytes) successfully initialized in 53ms (v0.3.110.20191009) (136ms)
+289ms	║╔Execution stage started
+290ms	║╚Execution stage complete. (2ms)
+292ms	║Setting up scheduled job for Sat, Nov 28 2020 @ 1:00:00 AM EST (in 4262663.412s), with 1 more job pending
+301ms	╚Event processed successfully (301ms)
10/9/2020, 5:55:33 PM +325ms
+0ms	╔Received event [Home].time = 1606543200000 with a delay of -4262666675ms
+139ms	║RunTime Analysis CS > 31ms > PS > 61ms > PE > 47ms > CE
+142ms	║Runtime (58002 bytes) successfully initialized in 61ms (v0.3.110.20191009) (141ms)
+143ms	║╔Execution stage started
+144ms	║╚Execution stage complete. (1ms)
+146ms	║Setting up scheduled job for Sat, Nov 28 2020 @ 1:00:00 AM EST (in 4262666.53s), with 1 more job pending
+154ms	╚Event processed successfully (154ms)
10/9/2020, 5:55:30 PM +255ms
+0ms	╔Received event [Home].time = 1606543200000 with a delay of -4262669745ms
+151ms	║RunTime Analysis CS > 29ms > PS > 70ms > PE > 52ms > CE
+154ms	║Runtime (58002 bytes) successfully initialized in 70ms (v0.3.110.20191009) (153ms)
+155ms	║╔Execution stage started
+156ms	║╚Execution stage complete. (1ms)
+158ms	║Setting up scheduled job for Sat, Nov 28 2020 @ 1:00:00 AM EST (in 4262669.588s), with 1 more job pending
+165ms	╚Event processed successfully (165ms)
10/9/2020, 5:55:27 PM +270ms
+0ms	╔Received event [Home].time = 1606543200000 with a delay of -4262672731ms
+165ms	║RunTime Analysis CS > 36ms > PS > 79ms > PE > 51ms > CE
+168ms	║Runtime (58002 bytes) successfully initialized in 79ms (v0.3.110.20191009) (167ms)
+169ms	║╔Execution stage started
+171ms	║╚Execution stage complete. (1ms)
+172ms	║Setting up scheduled job for Sat, Nov 28 2020 @ 1:00:00 AM EST (in 4262672.558s), with 1 more job pending
+181ms	╚Event processed successfully (181ms)

[lflorack]

As far as I know, this issue - which I believe is an ST issue, still persists. The good news is that the solution/work around that I mentioned about three posts back, prevents the 3-second cycling.

[dejavux2]

How do I add the “No Operation” piece? I can’t seem to find it. Thank you.

[Pantheon]

Click on “Add a new statement” in your piston.
Click “Add an action”
Click “Add a task”
Click the drop down…

[dejavux2]

Thank you! I was looking right past it.