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.
Going to see how long it takes them to fix it on their own, knowing that they do this year after year
More interested to see if the firmware upgrade today turns device health back on automatically.
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
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:
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.