So one of my pistons with waits is working this morning. I do see a difference in the logs between that one and the one that’s not working. This one that’s working has a Trace log that requests a wake up and an info log that sets up a scheduled job:
This one does not work. It has the same trace log requesting a wake up but it’s missing the info log setting up a scheduled job:
We have a few @ST_Staff members here who may get the notification about this change affecting scheduling and take action, but otherwise community.smartthings.com is the best place to reach out since others outside of webCoRE are likely experiencing similar problems. The only topic I see so far that is possibly related is Platform timeouts a lot now from 13 hours ago. I would start by replying on that topic with as much detail as you can muster. ST would need to know which shard you are on (the URL you get redirected to after signing in at account.smartthings.com).
@ST_Community_Devs does anyone have time to whip up a smart app to test this so that an example can be provided that does not rely on webCoRE? If this is a scheduling problem it should boil down to inconsistent behavior of runIn() with short timeframes, whereas before and confirmed to be resolved as of today we were having trouble with schedules > 25 days in the future.
Just for reference here, I am on the https://graph-na02-useast1.api.smartthings.com/ shard.
The latest reply in the SmartThings community topic suggests that it is definitely a related issue, for anyone that did not see the earlier link we are also discussing this over here:
I am having some very similar problems with some of my pistons. I created similar rules in both Smart Things and in Smart Rules. Both seemed to execute close to the expected times. My problems also started immediately after I updated to the latest revision. The pistons had been working fine up until that point.
Yesterday’s updates over at ST killed off CoRE as well until we get a few code tweaks out. Seems like a java version update has taken out a number of smart apps. Possibly a contributing factor in these scheduling issues.
“We upgraded major versions of Groovy yesterday for executing SmartApps and DeviceTypeHandlers, which included some rather major changes to the language.”
Seems like their changes have affected quite a few SmartApps 
… would’ve been nice to alert developers 
The ‘wait’ issue seems to have been resolved as of about an hour ago. Will do more confirming tests in the AM.
I’m seeing the same, was testing time scheduled and waits to compare between webCoRE and SmartRules but everything was running on time.
The piston I posted above is still not working correctly. Same exact issue as before.
Thanks. I think there’s either a different problem happening now or something wrong with the piston itself then. I created a new piston with a simple wait and it’s working. The one posted above still has the same problem. The glaring issue I see is the trace log that says its requesting a wake up, but there’s no info log that shows it’s setting up a scheduled job. See post 11 for screenshots. Quick Facts also shows Never for next scheduled.
I tried duplicating the piston, same issue. Also tried recreating from scratch, also same issue.
Dug a little deeper. It’s specific to the TCP Cancel on Piston State Change. If I remove that setting from my switch block tasks, the waits work correctly.
Piston snapshot:
Now if I leave TEP set as-is and remove TCP:
So…the question is, is there a problem with my logic in the piston, or is this a bug?
I’d suggest its your use of 'changes to inactive ’ instead of ‘is inactive’
‘Changes to’ only remains true for about 20 seconds after changing, after which it reverts to false waiting for the next change to occur. Piston reverting to false will cancel your 60 second waits.
Try using ‘is inactive’ as this will only get cancelled if the device changes again.
I’ll give that a shot when I get home later. Looking at the logs though, is it normal for the trace log to show that it’s requesting a wake up, but the info log to not show setting up a scheduled job? What was concerning to me was that it looked like the tasks after the wait were never scheduled in the first place, rather than being scheduled and subsequently canceled. That’s why I was asking if it was possibly a bug.
I don’t thing waits have ever been listed as a scheduled job… that’s more for timers and the like.
If you go back to the main dashboard you should however see a countdown timer next to the piston, counting down from 60.
They do show as a scheduled job, see the working and non-working screenshots I posted above.
