So, when does the system change in the fall after DST? Because this morning (when that was supposed to happen) my wake up lights went off based on the old time and woke everyone up an hour early.
Why the hell can’t this be fixed? I’ve noticed people complaining about this for years.
And then, how do I know when it will be updated or will I have to shift all of my routines 1 hour to accommodate?
It would help to know what you are using the control the lights. webCoRE piston? ST App? That’s the only way to know what the problem is. The issue is that the task was scheduled before the change and that wasn’t rescheduled after the DST adjustment since everything shifted to 1 hour earlier when the clocks changed (scheduling is done of off epoch time which doesn’t change for DST).
So, what app are you using to control the lights?
So, you are doing this via a “ST Classic App” routine? It is likely that will never get updated as ST has moved on to the new app. So, if you continue to rely on that, you would have to adjust it after the Time Change at 2am. But this would only be on the one day because it is going to schedule it for the correct time on Monday. So, if you didn’t have this routine run at a specific time on Sundays, this wouldn’t be a problem. This is why they chose to do it on Sunday mornings…most folks don’t have to work on Sundays.
I’m using the ST classic app on android.
I agree that (if it’s at all App related) the classic app won’t be fixed to resolve this since the focus is on the new app. I kinda think it’s NOT app related but rather part of the underlying Groovy system - that’s also being replaced with the new system. As i’m sure you know, the real issue is that future automation ‘runs’ are calculated as an amount of time from ‘now’ when the most recent run is completed. So, when the clock changes during daylight and standard time changovers, the pre-calculated times are off by an hour. Again, although this issue could be fixed in the base system coding, I doubt they’ll do it since it’s being replaced.
In my case, I use WebCoRE for all of my automations. It has the same issue - because it relies on the same base structure. However, I take care of it by forcing each affected piston to recalculate it’s next run schedule after the 02:00 switchover time. Since doing that, I no longer have any issues with mistimed events during daylight time <> standard time changeovers
In the OP’s case unfortunately, I am unaware of any method to do something similar for routines.
When I say “app” I mean smart app, not Classic vs new. Any app that preschedules events is going to be off after the time change. You can’t schedule when Routines schedules those events so you can’t fix it. THAT’S why I asked how he was setting up this routine.
However, I also think that building a rescheduling routine into any scheduling piston is a little overkill as well. If you simply had all your scheduling functions run at 3am, the problem would never occur.
I originally started adding recalculation logic (nightly NoOps) to my timed pistons. Although some of that coding still remains, I stopped doing that and wrote a single new piston that pauses/resumes and thereby recalculates, all of my timed pistons. This new piston only runs twice annually on switchover days.
Since i can’t fix the ST platform, this is a good compromise/workaround as far as I’m concerned.
The simple program (turn on and set color of bulb at specific time and day of the week) was based on the “smart lighting” smart app within the classic app. The same program shows up in the new smartthings app.
Under the right circumstances, that could work.
I am using the latest version of the ST app. My automatons (or apps as they are now called with respect to lighting) that are triggered relative to sunset were delayed today. From the above discussion I can’t tell if this will automatically be remedied tomorrow (Monday), or if there is something else that I need to do. Any help would be greatly appreciated.
Everything should be OK for tomorrow without any actions on your part.
What’s interesting is that everything that hinges on an actual time, like 5pm, works just fine, it’s Only the automations that’s are relative to sunset that are off by an hour.
Sigh. I have a Smart Lighting automation that turns some outside lights on at sunset. This evening (Monday evening) it fired 12 minutes late!
If I look at the Location events log in the IDE, I see “it is sunset” logged at 5:46pm CST, which is correct. It’s not until 5:58pm CST that I see all the APP_COMMAND events from the Smart Lighting SmartApp.
Looking at device history in the new STSC app, it looks like the automation fired at 5:58pm Sunday night as well.
Since this is my only sunset-relative automation, I opened it and resaved it. The relative time field was blank for some reason, I set it to 0. FWIW, I used to schedule this at sunset plus 10 minutes but changed to zero offset a few weeks ago.
It seems like there was a place to view the time the task is scheduled. I thought I saw it last time we had a DST boundary. But I’m not finding it now.
My sunrise and sunset events from WebCoRE haven’t triggered at all in days. Be happy with late.
As an old software developer, I find WebCore to be an interesting hack but not something I care to become dependent on.
So far my needs are super simple so Smart Lighting has been sufficient.
Unfortunately the native app has its limitations. I’ve got pretty complex pistons setup, like if my three year old uses the button in his room to turn his light on after bed I get a notification, but don’t get notified otherwise. I could do it through the new app but I’d have tons of routines to get it to work.
Yep. I see all kinds of clever, complicated automations here that are far beyond what Smart Lighting and other local execution options are able to do.
My needs are simple and, so far, are limited to control of lighting via smart switches. I’m kind of obsessively sticking to local execution. Tried using the custom DTH for my Zooz switches but the delay for cloud execution was too annoying.
I may evolve to more kinds of monitoring and thus more complex automation needs someday. But not yet.
Interesting. Everyone’s needs and concerns are certainly different, but for me, very few of my automations are simple enough for native apps. Examples:
The examples above and the benefits derived are much more important to me than local execution. Honestly, I’ve really not had many issues with cloud execution - especially over the last year or so. I’m hopeful that the new ST system will be even more stable going forward (we’ll see of course). If that includes more local processing, that’ll be good too. But if it’s either more power and flexibility OR local processing, the power and flexibility wins.
Again, this is nothing against your choice to stay very simple and local. I just wouldn’t be able to do it with the loss in power and flexibility - unless the stability became much worse than it’s been. As @JDRoberts says, choice is good!