Daylight Savings Time (Spring 2018)

Yup, my automations didn’t set home to ‘Home’ mode based on sunup. I see it say ‘sunup’ in the activity feed, but related to that, my ‘good morning’ routine is to set home to ‘Home’ mode. and once again… DST changes strike again.

Same here plus a few other things. Thank you for staying on topic instead of policing my spelling.

1 Like

You can prefer whichever you like, but the fact remains that in this hemisphere it is commonly referred to as “daylight savings”. We having checking and savings accounts here and with the hour taken into account, it goes into savings. Color vs colour :slight_smile:

And you can thank Ben Franklin for this confusing and useless function in the first place. DST will be eliminated in the next decade.

3 Likes

How is this still an issue? Cursory Google search shows SmartThings having issues as far back as 2014 with this. W.t.f.

2 Likes

My sunrise Routines are still running an hour early. 24 hours after time change. Hub was already rebooted yesterday.

Cloud servers clocks been updated with correct time?

Is there a way to see my hub’s “time”? I can’t find it in the app. And yes, my automations are all off by an hour, too.

Has anybody affected by this issue raised a ticket to ST.
Everybody appears to be scratching around with no resolution.
Would be interesting to hear what ST have to say.
I’m in the UK so unaffected. At the moment…

1 Like

In IDE, you can see your timezone setting and sunrise / sunset times under Location.

Under Hubs you can see reported activity which is in utc.

Nothing I’m investing more time into. Just an observation I made for others who end up seeing the same behavior. I’m sure it’s their servers haven’t been updated. Could be the fault of Y2K :joy:

We could be on a server in a state that doesn’t observe dst. :joy:

So, you’re saying the answer is No?

Sunrise and sunset times and Z activity time don’t readily tell me what time the hub thinks it is at its location.

G.

Not a direct setting that displays time. But you can list events under locations and that will show the last event and the current time in your locale. You can fire off a routine and then list events and see if your time is current. I’m betting that your time will display just fine.

It’s either ST or AWS servers.

You could try going into the ST app on your phone.
Go into settings.
Click on the map.
Resave your location.
Might straighten things up.
Failing that, raise a ticket to ST.
Tagging @jody.albritton. Perhaps you can ask the right people your end.

Time is correct and current in IDE when listing events. Routines are firing 1 hour early (550am versus 650am) a day after dst change.

I appreciate what the issue is.
I’m just making suggestions that might straighten things up. Who knows. Has anyone tried it?
Nobody seems to want to raise a ticket to ST.

1 Like

Nah. My gps and arrival / departure routines are working fine so no need to reset this and break something else. This could cause Zigbee or Z-Wave to break. :joy:

Going to see how long it takes them to fix it on their own, knowing that they do this year after year :slight_smile:

More interested to see if the firmware upgrade today turns device health back on automatically.

1 Like

Just a note: DST issues still exist.

I’d be happy to raise a ticket, but I have access to nothing that could prove the issue exists.

Under CoRE automation, my heater didn’t kick on yesterday, but is today.

Under WebCoRE automation, my kid’s nightlight didn’t turn on yesterday.

Under WebCoRE automation, my plant lights didn’t kick on today, but were set to do so an hour after the correct time (Sunrise, or 0725 was instead set to turn on at 0825).

If it is only CoRE and webCoRE pistons where you are seeing the issues then it is not caused by ST. Pistons generally set their schedules from the previous run of those pistons but they should correct themselves when they run again after the time change. If not, you should report the issue on the webcore forum :slight_smile:

2 Likes

For the first time since I started using CoRE and now webCoRE, I did not have DST <> EST changeover issues this year. I believe this is because of the changes I made as described below.

I am currently using two different methods to end having to manually pause and restart each affected piston after DST <> EST (for me) changeovers. Both methods seem to work. I haven’t settled on which is better so I currently have both methods running. Each takes a somewhat different approach.

Method One pauses each timed piston and then restarts it so that it recalculates next-run times based on the changed time:

Method Two uses a NO OPeration task embedded into each desired piston. When the circled portion of this piston runs, it also causes the piston to recalculate the next-run times based on the updated time:

Hope this helps!

When I went to bed, my WebCoRE pistons were still off by an hour. When I woke up, everything was finally synced up.

-SR

That’s pretty normal for CoRE/webCoRE. Next-run tasks are scheduled at the end of any piston activity. So, if pistons schedule next-run tasks prior to a daylight time switchover, those piston will be off one hour during their next run. However, anything that triggers the piston to reevaluate will use the then current time to set the schedule for the next-run events.

So, if you’re willing to wait a day, daily pistons will fix themselves (time-wise) after just one day of being out of sync. If you have things that you’d rather not wait that day to resync, you can use one of the two methods I posted above to fix the next-run time.