How to Fix Smart Home Schedules After Daylight Saving Time

If a smart home schedule broke right after daylight saving time, start with the symptom, not the reset button. An exactly one-hour shift usually points to a timezone or DST-rule problem. A routine that never ran may have targeted an hour that did not exist in spring, or one that repeated in fall. A single bad plug schedule while routines still work is a different failure from every automation in one ecosystem moving together.

For the U.S. 2026 change, daylight saving time began on March 8 and ends on November 1; at fall-back, clocks move back at 2:00 a.m., the 1:00–1:59 hour repeats, and the day is effectively 25 hours long in locations that observe DST.[1][2] That matters because smart-home systems do not all ask the same clock at the same moment.

The “internet time is correct” test is not enough

A device can have the correct network time and still run a schedule at the wrong local time. NIST’s time service explanation is the clean dividing line: NTP broadcasts UTC, and it does not send daylight-saving-time data; the operating system or firmware on the receiving device must apply the local timezone and DST rules.[1]

That is why “the router is online” and “the phone clock is right” do not clear the smart-home app, hub, or device firmware. UTC may be fine. The conversion from UTC to your local wall-clock schedule may be the part that failed.

Narrow the failure before changing anything

Do three quick checks before deleting routines. They preserve evidence, and they keep you from rebuilding the wrong part of the system.

1. Compare one device schedule with one rules-engine routine. If a plug’s built-in schedule moved by one hour but a broader automation still fired correctly, the device schedule is suspect.
2. Compare local and cloud execution labels if your ecosystem exposes them. A local rule surviving while a cloud rule drifts points away from the bulb and toward the automation layer.
3. Check whether the routine was scheduled inside the dangerous hour: 2:00–2:59 a.m. on spring-forward day, or 1:00–1:59 a.m. on fall-back day in places that observe DST.

If you have logs, screenshots, or “last ran” timestamps, save them before recreating anything. Once a routine is deleted, the most useful clue is usually gone.

Fix path by failure mode

1. Device clock did not resync

This is the best fit when one device is wrong and the rest of the home is behaving. The device may still be online, but its local clock, timezone, location, or firmware conversion has not caught up.

• Open the device in its native app, not only in Apple Home, Google Home, Alexa, or another controller.
• Check the home location and timezone if the app exposes them.
• Update the app and the device firmware.
• Power-cycle the device after the update if the clock still appears stale.

For TP-Link Kasa and Tapo, the official current path is more specific: update the app and firmware, re-sync device time through location/time settings, and, if schedules still do not work, change router DNS to Google DNS addresses 8.8.8.8 and 8.8.4.4.[3]

2. Schedule engine has stale timezone or DST rules

This is the likely mode when schedules inside one app move together, especially if manual control still works. The device can turn on and off. The schedule calculation is the stale part.

Do not start by factory-resetting a bulb, plug, or hub. First force the smallest recalculation the app allows: update, location/time sync, disable and re-enable the schedule, or delete and recreate only the affected schedule. The goal is to make the scheduler rebuild its next-run time from current rules.

A Wyze community thread is a useful warning sign for this mode: users documented Wyze plug schedules shifting by one hour at DST changes from November 2022 through March 2025, while Rules-engine schedules stayed correct.[4] That pattern does not prove every Wyze DST issue is the same bug, and it is not a vendor-confirmed fix note. It does mean that a recurring one-hour plug-schedule shift should not be treated as careless setup.

3. Cloud automation did not re-evaluate

This is the fit when the device clock is fine, manual control is fine, and local automations survive while cloud-labeled automations miss the change. Recreating the automation is often the smallest useful action because it forces the platform to calculate a fresh trigger.

Aqara users documented a sharp version of this pattern in October 2025: CLOUD-labeled automations failed to follow DST while LOCAL automations worked; deleting and recreating the automation rebuilt it as LOCAL, though users also reported that it could later revert to cloud and fail again at the next change.[5] SmartThings users documented a related workaround after a 2021 DST change, where a Smart Lighting automation using sunset +45 minutes was fixed by deleting and re-adding the automation.[6]

The practical order is simple: duplicate the rule’s conditions in a note, delete only the affected automation, recreate it, and watch the next scheduled run. If the platform shows execution location, prefer the local version for time-critical lighting and safety-adjacent routines, but do not assume every cloud routine is fragile. The useful distinction is whether this particular routine recalculated after the clock change.

4. Job aimed at a skipped or duplicated hour

A fixed-time automation scheduled for 2:00 a.m. on spring-forward day may not be late. It may have had no valid wall-clock time to run. In a Home Assistant Core issue from the 2025 spring-forward change, a 2:00 a.m. automation did not run because that hour did not exist; the issue was closed as “not planned.”[7]

The fix is not to make the scheduler “try harder” at an impossible local time. Move critical jobs outside the skipped hour. For spring-forward, avoid 2:00–2:59 a.m. For fall-back, avoid 1:00–1:59 a.m. if running twice would be harmful.

Home Assistant users have also reported time-of-day sensor problems after DST where a restart was needed, but that thread should be treated as a community workaround rather than a universal rule.[8] If a restart fixes a derived time sensor, it still does not mean a factory reset was necessary.

Ecosystem-specific fix cards

Status labels below are intentionally conservative. “Confirmed” means the fix is supported by official vendor documentation or by a directly documented project issue. “Workaround” means users documented the pattern and fix, but it is not a vendor-confirmed repair path. “Investigating” means the pattern is useful for diagnosis, but should be rechecked before treating it as a settled platform fix.

TP-Link Kasa / Tapo — Confirmed

Use TP-Link’s order before deleting devices: update the Kasa or Tapo app, update device firmware, sync location/time, then change router DNS to 8.8.8.8 and 8.8.4.4 if schedules, timers, or Away Mode still fail.[3]

For Kasa, TP-Link’s documented path includes Kasa app > Me > Settings > Location and Time > Sync Location.[3] After syncing, check the next scheduled run time rather than only toggling the plug manually; manual control does not test the schedule engine.

Wyze plugs — Investigating

The clue to look for is split behavior: built-in plug schedules move by one hour, while Rules-engine schedules remain correct. That is the pattern users reported across multiple DST changes from November 2022 through March 2025.[4]

If that matches your home, move the affected on/off timing into a rule rather than relying on the plug’s own schedule, then update firmware when Wyze offers it. Do not wipe the plug first; the reported pattern points to where the time is computed, not to a corrupted device record.

Aqara — Workaround

If an Aqara automation is labeled CLOUD and missed the DST adjustment, copy its conditions, delete it, and recreate it. The cited Aqara forum guide says this can rebuild the automation as LOCAL, which users found followed DST correctly.[5]

After recreating it, check the execution label again. The same guide warns that an automation can revert to cloud later, so this is a workaround with a follow-up check, not a one-time cure for every future clock change.[5]

SmartThings Smart Lighting — Workaround

For a SmartThings automation such as sunset plus an offset, delete and re-add the affected automation if it broke immediately after a DST change. In the cited SmartThings thread, a sunset +45 minute Smart Lighting automation was fixed this way after the 2021 DST transition.[6]

Recreating the one automation is a smaller and better test than resetting the hub. If the new rule calculates the correct next run, the stale object was the problem.

Home Assistant — Confirmed for skipped-hour behavior; cautious for restart workarounds

If a Home Assistant automation was set for 2:00 a.m. on spring-forward day and did not run, move it. The reported issue was closed “not planned” because the local 2:00 a.m. hour did not exist during that transition.[7]

For time-of-day sensors that appear wrong after DST, a restart has been reported as a workaround in the Home Assistant community.[8] Treat that as a targeted restart of the automation platform, not as permission to rebuild entities or wipe integrations.

Honeywell VisionPRO older thermostats — Confirmed exception

Older thermostats are the case where turning off automatic DST can be the official fix. Honeywell Home says some older VisionPRO thermostats use pre-2007 DST dates; because those tables are no longer valid, the support guidance is to disable automatic DST adjustment and change the clock manually.[9]

This is not the right fix for modern systems that can receive updated timezone rules. It is an older-device exception: when the built-in rule table is permanently wrong, manual clock control is safer than trusting the automatic adjustment.

Google Home / Google Assistant — Investigating

Do not follow a Google-specific DST reset recipe unless you can verify it in current Google documentation or reproduce it safely. For now, isolate the layer: check whether the wrong schedule lives in Google Home, in the device’s native app, or in another hub that Google is merely controlling.

Alexa — Investigating

For Alexa, first determine whether the routine itself is wrong or whether Alexa is triggering a device whose own native schedule is also wrong. If only the device-native schedule drifted, fix it in that device’s app. If only the Alexa routine drifted, disable and re-enable or recreate that routine before unlinking skills or resetting hardware.

What not to reset

A factory reset is usually the most expensive way to force a clock recalculation. It can remove pairing, room assignments, scenes, schedules, voice-assistant links, and carefully tuned automations. Use it only after the vendor’s documented path fails, or when a support document specifically says the device record must be rebuilt.

The smaller resets are usually enough: sync location, update firmware, power-cycle one device, restart the automation service, or recreate one stale automation. Each one tests a clock layer. A full reset erases the evidence before it proves anything.

Pre-check before the November 1, 2026 fall-back

Do this before the U.S. fall-back if you have lights, plugs, thermostats, locks, cameras, or energy routines that run overnight. The risky window is the repeated 1:00–1:59 a.m. hour.[1][2]

• Move critical routines out of 1:00–1:59 a.m. for fall-back night.
• Update smart-home apps, hub firmware, and device firmware before the weekend of the change.
• Confirm your home location and timezone in each ecosystem that owns schedules.
• For TP-Link Kasa/Tapo, run the documented location/time sync if schedules have been unreliable.
• For Aqara and similar systems that show local/cloud execution, check which important automations are cloud-labeled.
• For Home Assistant, avoid fixed jobs in the repeated hour if duplicate execution would create a problem.
• Screenshot important automations before the change, so recreating one stale rule does not become a full rebuild.

References

1. Daylight Saving Time (DST), NIST, https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst
2. When Is Daylight Saving Time?, The Old Farmer’s Almanac, https://www.almanac.com/content/when-daylight-saving-time
3. Tapo and Kasa Schedule, Timer or Away Mode Not Working, TP-Link, July 1, 2026, https://www.tp-link.com/us/support/faq/2689/
4. Daylight Savings Time/Standard Time problem Wyze Plug, Wyze Forum, https://forums.wyze.com/t/daylight-savings-time-standard-time-problem-wyze-plug/246922
5. Guide to solving DST issues, Aqara Forum, October 2025, https://forum.aqara.com/t/guide-to-solving-dst-issues/130820
6. Smart Lighting App and Automation Problems with Time Changes, SmartThings Community, https://community.smartthings.com/t/smart-lighting-app-and-automation-problems-with-time-changes/226277
7. Automation scheduled to run at 2AM fails to execute after Daylight Savings Time change, Home Assistant Core GitHub, https://github.com/home-assistant/core/issues/140771
8. Times of Day sensor wrong after Daylight Savings Time, Home Assistant Community, https://community.home-assistant.io/t/times-of-day-sensor-wrong-after-daylight-savings-time/547801
9. All New VisionPRO Thermostats, Honeywell Home, September 2, 2025, https://www.honeywellhome.com/blogs/support/all-new-visionpro-thermostats-4