Some more reports here:
And numerous reports of General ST instability going on:
Yes. ST placed a rate limit on webCoRE because some pistons started executing like crazy because of the DST. I don’t know what the rate limit is, looks like 0, as none of my pistons execute at all. But will try to get this fixed. Not sure how quick I can get someone to react, it’s still early morning on the west coast.
Hey, at least the time change worked fine this year, unlike last year, ST got something right
To the question posted a bit above, do I recall that you are working with ST to get this app officially supported?
Thanks Adrian for all you do
Rick
Quick dirty fix. Please update to 0fc to get it back working. Thank you and sorry for the trouble.
I’m new to webCoRE and it looks like I picked a bad day to start transitioning from basic ST automations. Can someone provide a little more details behind how to “update 0fc”? I haven’t a clue what that is. Otherwise, I’ll wait a couple days to implement.
So here’s what I think happened. I am using UTC time throughout webCoRE (a common approach in the telecom industry) to avoid any DST issues. So when you’re piston runs at 9pm on Saturday before the DST and it is scheduled to run at 9pm on Sunday after the DST, I will work in UTC times, meaning the delta time between the two time points will be 25 hours. So I do a runIn in 25 hours (the request is already DST adjusted) - SmartThings was not “adjusting” it to DST before, it seems that they added a fix this year that will adjust that runIn time with DST. This is most likely because some programmers and most DYI users would not be aware of what DST entails and would just send the unadjusted runIn time. Which now may explain why some apps worked fine this time around. But it seems that broke webCoRE I’ll see with ST what exactly happens and I’ll do some experiments simulating DST to see what exactly happens. Until then, ST will most likely remove the rate limit at some point - it affects certain versions of webCoRE - when they start their working schedule - it’s Sunday early morning there, so I would not expect anyone to be available to really dig in and fix the issue. This seems to have been an emergency fix last night and ST was kind enough to let me know - I did have a message explaining the problem and the fix.
I just finished updating and everything is working better. BUT. I have logging on for one of my pistons and it looks like it’s displaying 1 hour behind. I.E. If I want it to sent an email at 4am it is showing the wake up time for 3am. Anyone else seeing this?
╔Starting piston… (v0.2.0fc.20171105)
+671ms ║╔Subscribing to devices…
+927ms ║╚Finished subscribing (261ms)
+969ms ║Comparison (time) 33318752 happens_daily_at (time) 0 = false (3ms)
+984ms ║Cancelling statement #12’s schedules…
+993ms ║Requesting time schedule wake up at Sun, Nov 5 2017 @ 11:00:00 PM EST
+1029ms ║Comparison (time) 33318816 happens_daily_at (time) 14400000 = false (1ms)
+1032ms ║Cancelling condition #4’s schedules…
+1034ms ║Cancelling statement #4’s schedules…
+1036ms ║Requesting time schedule wake up at Mon, Nov 6 2017 @ 3:00:00 AM EST
+1038ms ║Cancelling condition #1’s schedules…
+1080ms ║Setting up scheduled job for Sun, Nov 5 2017 @ 11:00:00 PM EST (in 49481.132s), with 1 more job pending
+1105ms ╚Piston successfully started (1102ms)
My next scheduled piston is for 25 minutes to sunset and it is scheduled to run at 5:07:00 PM which is correct. However, I’m in AZ and our time doesn’t change for DST so that may be why my piston times are correct.
Thanks Boxfan… I have a piston that runs 1 hours before sunset and it’s next scheduled time is also correct. (4:06pm and sunset is 5:05pm) . It looks like it’s a issue with my “happens daily at” .
I checked my morning routine and it’s Next scheduled is 5am where the piston is set to 6am.
On the road here. Just updated on my phone. Some 1/2 hr later i got a email i should have seen some 6 hrs ago. Not able to debug here. CET