'Do Every' piston running every 3 seconds

verified
execution

#24

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.


#25

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.

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.


#26

@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.


#27

No problem. Glad to help


#28

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.


#29

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!

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.


#30

Thank you for confirming!


#31

@ipaterson

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


#32

logo-smartthings-symbol-2018


#33

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?
image

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.


#34

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…


#35

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:


#36

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