'Do Every' piston running every 3 seconds

execution
verified
#1

1) Give a description of the problem
The piston functionally works fine, except - due (I think) to the ‘Do Every’ April 1st and October 1st statements, this piston is running every 3 seconds (See logs)

2) What is the expected behavior?
I expect it to run if the date is one of the ‘Do Every’ dates or if ‘Switch 37’ (a virtual switch that indicates it’s cooling season or not)

3) What is happening/not happening?
It’s running every 3 seconds and doing nothing. I have other ‘Do Every’ pistons that are seemingly structured the same way but they don’t exhibit this issue.

4) Post a Green Snapshot of the pistonimage

untitled
untitled.png1178×1264 255 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)

This log is from webCoRE. Nothing shows up in IDE.

image
image.png539×742 27.6 KB

Thanks for any insights…

Pistons with waits failing [TCP piston state change]
Pistons with waits failing [TCP piston state change]
Time-based pistons ran 1 hour early today
#2

Same behavior here, this is a great observation and absolutely a bug. I moved to the bug reports category and will take a look for the next release. You should probably pause that piston or disable the on statements until it can be fixed.

#3

Thanks Ian! I have paused the two auto, date-based code blocks while waiting for the fix. The manual switch change functions remain available meanwhile.

#4

@webCoRE_Minions I’ve noticed in trying to figure out this bug today that I can schedule the piston to wake up on Sep 7 which works as expected, but any date after Sep 8 fails by scheduling the piston for an immediate run. This cutoff is about 25 days from now; it seems implausible that events could not be scheduled more than 25 days in the future. Everything looks correct when setting up the schedule but SmartThings runs the piston again within a few seconds.

Any ideas what else could be going on here? Currently my plan is to wait until tomorrow to see if I still cannot schedule events past Sep 7 or if the cutoff has moved to Sep 8.

#5

Beats me… but must be a recent change somewhere as I’ve had pistons scheduled over a year in advance, and I know others have to.

Will test on my test setup to see if I can replicate on the EU shard.

#6

I can schedule things well into the future with Hubitat but on ST it just loops immediately… looks like an issue on ST’s side.

It’s not executing the action though, just receives a time event, does nothing about it except rescheduling (for the correct time) and then immediately runs again in a loop.

#10

I concur regarding a recent change. The piston that’s displaying this issue is the most recent one that I’ve written. I also have a number of other pistons that, although not exactly the same, employ similar scheduling of a seasonal event that are even further out - and they are running fine. It IS odd that one piston is a problem when others are not. One of the obvious differences is when they were written or maybe even updated.

#11

Today I can schedule through Sep 8 while Sep 9 does not work (Sep 7 and 8 yesterday) so this issue seems to involve a rolling ~25 day window. I escalated this to SmartThings support to see what is going on and will keep this thread updated with any news.

#12

@ipaterson

If it helps at all, I have a similar Piston with its next scheduled event on Halloween. I most recently modified/saved it on July 23rd. Although I didn’t notice it at the time, the logs show that it exhibited the same looping issue as the one I posted above for about two days (until a little after midnight on July 25th) - and then it just stopped looping. It’s now running fine (no looping). Very odd.

I have another one with events around the Christmas holidays that is also running fine. It was last modified in May. Unfortunately, I have no current logs.

#13

@ST_Staff I have confirmed this behavior in a smart app outside of webCoRE after receiving a generic “contact the webCoRE team” response from ST support. The runIn function that is used to schedule a wake up no longer works when greater than 25 days in the future and instead immediately triggers the specified action.

So I’m seeing runIn 2073600, logSomething (24 days) behave correctly, while runIn 2160000, logSomething (25 days) logs immediately. In the case of webCoRE the action is rescheduled since it fired too soon, which means the piston fires about every 3 seconds. Based on the conversation above, this will go on for a day or two until either the schedule sets properly or ST stops waking the smart app.

#14

Maybe tell them you are the WC team!

#15

Ha well yes I did originally but it’s the general problem of eyes glazing over when a third party is mentioned I suppose. Was not the correct channel to get this resolved but I figured I would give it a shot. Adrian had also planned to get some eyes on it.

#16

@ipaterson

Thank you for your continued efforts on this. :+1: I’m almost inclined to I unpause my seasonal ‘Do Every’ loops and let them loop for a few days until they stop - because even the ones that are no longer looping, will start looping again anyway once they need to reschedule and it’s 25+ days out . I have a number of seasonal ‘Do Every’ pistons.

Update: I’m more than inclined. I did it :wink:

#17

As I posted above, I un-paused my ‘Do every’ sections of my code. As expected, the Piston started looping every 3 seconds - but it stopped looping after about 10 hours this time, instead of the 2+ days I saw in the past. Not sure what that means, but thought I’d pass it along. It’ll be interesting to see how this and my other ‘Do every’ pistons handle timing thresholds in the future.

Update: I’ve had to update another piston with a do Every loop in it. It again exhibited the continuous every-three-second looping we’ve seen before. This time it stopped looping in 12 hours.

#18

@ipaterson

Now that this is a known issue, I have been observing things more often and have noticed that several of my seasonal ‘Do Every’ pistons will start looping every 3-4 seconds whenever one of the piston’s variables or triggers change. They then loop for a number of hours and then stop - only to start again when something changes. I gotta believe that this is occurring quite often without being observed but it’s causing an unneeded drain on the ST infrastructure.

Do you know of an update on any progress?

#19

I have not received any response from ST staff, earlier today I asked minions to push the issue.

#20

@lflorack

This won’t fix the bug, but if you delete the highlighted lines below, it WILL stop your loops completely:

temp

#21

Thank you for your suggestion.

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.

Also, I have other Do Every/seasonal pistons without those type of restrictions that still loop. Here’s one of them:

download
download.png1178×1904 213 KB

#22

Thank you again!

#23

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)
temp

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

I cannot visualize how this suggestion would impact ANYTHING negatively.
If the switch is off when April 1st comes around, it turns it on.
If the switch is already on when April 1st comes around, then it will do nothing