Smart Lights Not Following Sunrise Sunset Settings: How to Fix It
Quick Answer
The most common reason smart lights ignore sunrise/sunset schedules is that the automation is using the wrong location or time source. This usually happens after a phone location permission change, a hub/app update, switching accounts, moving homes, changing time zones, or when the “home” location inside the smart home app doesn’t match your real address. If the system thinks you’re in a different city (or can’t access location at all), sunrise and sunset times will be wrong or the automation won’t trigger.
A close second is that the lights are not consistently “reachable” at the scheduled moment. Even if the schedule is correct, WiFi bulbs may miss the command during brief router/mesh roaming events, and Zigbee/Matter setups can fail if the hub/bridge is offline or the device is routed through a weak repeater.
Do these three checks first: (1) In the app, confirm the Home/Location address and time zone are correct and that the automation is set to “Sunrise/Sunset” for that location. (2) Check device status at the time it should run—if the bulb shows “offline/unreachable,” fix connectivity before changing schedules. (3) Temporarily create a test automation for “1 minute from now” to prove the device can receive commands; if that works, the issue is almost always location/time or automation configuration.
Why This Happens
Sunrise/sunset automations are not stored as simple “turn on at 7:00 PM” timers. They depend on a calculated event time that comes from your configured location, time zone, and the automation engine (cloud, hub, or controller). If any part of that chain is wrong or inconsistent, the automation can trigger at the wrong time or not at all.
Common technical causes that directly affect sunrise/sunset behavior include:
1) Incorrect home location or time zone in the smart home ecosystem. If X happens (sunset triggers hours early/late) → it usually means the system is calculating sunset for a different location or time zone than your home.
2) Location permission changes on the phone used to set up the home. If this test works (manual control works, but sunrise/sunset doesn’t) → the issue is likely that the automation engine can’t access the location it needs, or it’s using a default location.
3) Automation engine mismatch (cloud vs hub vs controller). Some ecosystems calculate sunrise/sunset in the cloud, others on a hub/bridge, and some (Matter controllers) may calculate locally. If the hub/controller is offline at the trigger time, the event may not fire even though the schedule looks correct in the app.
4) Conflicts between multiple automations, scenes, or “adaptive lighting” features. If X happens (lights briefly turn on then immediately change/turn off) → it usually means another rule is overriding the sunrise/sunset action.
5) Device reachability at trigger time. WiFi bulbs can miss a command during router reboots, ISP outages, or mesh steering. Zigbee devices can miss commands if the mesh route is weak or the hub is busy/offline.
Real-world scenario: You changed internet providers and replaced the router. The lights still work manually, but sunrise/sunset stopped. The new router changed the network behavior (different DHCP timing, different multicast handling, different mesh steering), and at the same time your smart home app lost precise location permission after an OS update. The automation now calculates sunset for a default location and sends the command when the bulbs are briefly unreachable.
Common user mistake: Setting the automation to “At a specific time” and assuming it will automatically track seasonal sunrise/sunset changes, or selecting “Sunset” but leaving the home location blank or set to an old address.
Overlooked technical cause: Daylight Saving Time and time zone drift. If the hub/controller time is wrong (or the ecosystem account has the wrong time zone), sunrise/sunset offsets can be applied incorrectly, making the automation look “close” but consistently wrong by 1 hour.
Most Likely Causes in Real Homes
1) Home address/time zone in the app is wrong or reverted to a default location after an update.
2) Location permissions are disabled or set to “Approximate,” causing incorrect sunrise/sunset calculations.
3) Hub/bridge/controller was offline at trigger time (Hue bridge, Zigbee hub, Matter controller, or the phone/tablet acting as a controller).
4) Conflicting automations/scenes (including “away mode,” “do not disturb,” “adaptive lighting,” or another app controlling the same bulbs).
5) Bulbs/devices show as offline/unreachable intermittently, especially on WiFi bulbs or weak Zigbee meshes.
Step-by-Step Fix
-
Confirm the automation is truly set to Sunrise/Sunset (not a fixed time) and check offsets.
What to do: Open your smart home app (Hue, TP-Link, Google Home, Alexa, Apple Home, SmartThings, or the manufacturer app). Find the automation/routine. Verify it is set to “Sunrise” or “Sunset” and note any offset like “30 minutes before sunset.” Confirm the correct days are selected and that the automation is enabled.
What the result means: If it was set to a fixed time, it will drift seasonally and appear “wrong.” If an offset is present, it may be doing exactly what it was told.
If it fails: Change it to Sunrise/Sunset explicitly, remove offsets for testing, save, and retest with a near-term trigger (some apps allow a “Run now” or preview time).
-
Verify Home location and time zone inside the ecosystem (not just on your phone).
What to do: In the app’s Home settings, confirm the home address/location and time zone. If the app supports a “home map pin,” ensure it’s placed correctly. If you have multiple homes/locations, confirm you’re editing the correct one. Then check the phone’s date/time settings are set to automatic time zone.
What the result means: If the home location is wrong, sunrise/sunset times will be calculated for the wrong place. If the time zone is wrong, the automation may be consistently off by hours or exactly 1 hour.
If it fails: Correct the address/pin and time zone, save, then disable and re-enable the automation to force a refresh. If the app shows a “preview” of next sunrise/sunset, confirm it matches local reality.
-
Check location permissions for the app and controller device.
What to do: On the phone/tablet that manages the home, check the smart home app’s permissions. Ensure Location is allowed (and not blocked), and if there is a “Precise location” option, enable it for testing. Also check any OS-level privacy settings that restrict location in the background.
What the result means: If location is blocked or approximate, the app may not update the home location correctly, or it may rely on an old/default location. This can break sunrise/sunset calculations even when manual control works.
If it fails: Turn permissions on, reopen the app, and re-check the home location. If the ecosystem supports it, set the address manually rather than relying on phone GPS.
-
Run a “1 minute from now” test automation to separate scheduling problems from connectivity problems.
What to do: Create a temporary automation that turns one affected light on (or changes brightness) one minute from now. Keep it simple: one device, one action. Watch the device status in the app during the test.
What the result means: If this test fails, the issue is likely device reachability, hub/controller availability, or permissions—not sunrise/sunset calculation. If it succeeds, the device can be controlled and the problem is likely location/time zone or an automation configuration conflict.
If it fails: Go to the next step and focus on device status and network/hub availability before adjusting sunrise/sunset settings further.
-
Check device status (“reachable/offline”) and fix power and controller availability first.
What to do: In the app, look for “offline,” “unreachable,” or delayed status updates. Confirm the wall switch controlling the light is left on (smart bulbs must have constant power). For hub-based systems, confirm the hub/bridge/controller shows online and its status lights indicate normal operation.
What the result means: If the light is often offline, it may miss the sunrise/sunset command. If the hub/controller is offline at the trigger time, automations may not run even if schedules are correct.
If it fails: Leave the switch on and use app/voice control instead. If a hub is involved, power cycle it (see next step). If only one bulb is offline, move to the group/sync steps later.
-
Do a clean power cycle sequence (controller first, then network, then lights).
What to do: Unplug the hub/bridge/controller for 20 seconds and plug it back in. If you use a router/mesh, reboot the main router (and allow it to fully come online). Then, in the app, confirm devices return to “online.” Avoid rapid on/off toggling at the wall switch.
What the result means: This clears stuck automation engines, stale network sessions, and hub communication issues that can prevent scheduled commands from being delivered.
If it fails: If devices still show offline, continue with the WiFi band/mesh test for WiFi bulbs or the mesh strength test for Zigbee devices.
-
For WiFi bulbs: verify the WiFi band and mesh behavior (2.4 GHz stability matters).
What to do: Check the bulb’s requirements in the app/device info. Many WiFi bulbs require 2.4 GHz. If your router uses a single combined network name for 2.4/5 GHz, the phone may be on 5 GHz while bulbs are on 2.4 GHz, which can cause setup and discovery issues in some homes. If you have a mesh system, test by temporarily placing the bulb closer to the main router (or temporarily powering it in a nearer lamp) and see if it stays online reliably.
What the result means: If the bulb becomes stable when closer to the main router, the problem is usually weak signal, mesh roaming quirks, or the bulb connecting to a distant node. That instability often shows up as missed scheduled events.
If it fails: Try locking the bulb to a closer access point if your system supports it, or relocate the mesh node/router for better coverage. Then re-test the “1 minute from now” automation.
-
For Zigbee hub systems: run a mesh strength test by checking repeaters and device placement.
What to do: If only certain lights miss sunrise/sunset, note their distance from the hub/bridge and what’s between them (brick, metal, mirrors, appliances). Ensure the hub is centrally located and not hidden behind a TV or inside a cabinet. After relocating the hub (if possible), give the Zigbee network time to settle so routes can rebuild.
What the result means: If moving the hub improves reliability, the automation was likely firing but the command wasn’t reaching the device consistently. Zigbee is a mesh; weak routes can cause intermittent misses that look like “schedule problems.”
If it fails: Re-test with one light near the hub. If that one works reliably but distant ones don’t, the issue is mesh coverage, not sunrise/sunset settings.
-
Check group/room behavior and synchronization (group vs individual device control).
What to do: If the automation targets a room/group, verify all bulbs are still members of that group and that the group name hasn’t changed. Run the automation against a single bulb as a test. Then run it against the group.
What the result means: If a single bulb works but the group fails, the issue is likely group configuration, permissions, or a stale group reference after a rename/move. If the group works but one bulb doesn’t, that bulb is likely offline or out of sync.
If it fails: Remove the problem bulb from the group and re-add it, then re-save the automation. If the app supports it, rebuild the room/group.
-
Look for automation conflicts (scenes, adaptive lighting, away mode, or another app controlling the same lights).
What to do: Check all apps that can control the lights (manufacturer app, voice assistant app, home platform app). Temporarily disable other lighting automations, especially ones that run around the same time (evening scenes, “arrive home,” “good night,” adaptive lighting, or motion-based rules). Watch what happens at the next trigger time.
What the result means: If the sunrise/sunset automation starts working after disabling another rule, you have a conflict. If lights change state immediately after triggering, another automation is overriding it.
If it fails: Keep only one “source of truth” for sunrise/sunset (one app/platform), and remove duplicates. Then re-enable other automations one by one to find the rule that conflicts.
-
Use a hotspot isolation test to confirm whether the home network is the blocker (WiFi bulbs/controllers).
What to do: If feasible, temporarily connect the controlling phone and one WiFi bulb/controller to a phone hotspot (or a guest network) and run the “1 minute from now” test. This is a diagnostic step, not a permanent setup.
What the result means: If it works on the hotspot but fails on your normal network, the issue is likely local network behavior (router settings, isolation between bands, multicast handling, or mesh steering), not the sunrise/sunset concept itself.
If it fails: Return devices to the normal network and focus on router/mesh settings that affect local device reachability, then re-test scheduling.
-
Force a schedule refresh: duplicate the automation, then delete the original.
What to do: Some ecosystems keep a cached schedule. Create a new sunrise/sunset automation with the same actions, save it, and disable the old one. After the new one works once, delete the old one.
What the result means: If the new automation works, the original schedule may have been corrupted or stuck after a location/time change.
If it fails: Move to Advanced Troubleshooting to check account sync, firmware, and controller roles.
Advanced Troubleshooting
This section is only needed if basic fixes fail.
Account or cloud sync problems
If sunrise/sunset automations are stored in the cloud, a partial account sync can cause rules to display correctly but not execute. If X happens (automation shows enabled on one phone but missing or different on another) → it usually means account sync is incomplete. Sign out and back in on the controlling app, then confirm the home location and automation list refreshes. If multiple household members manage the same home, confirm everyone is using the same home and account context.
Network issue that affects scheduling delivery (only when devices are reachable intermittently)
If your “1 minute from now” test fails randomly, focus on reliability rather than sunrise/sunset math. Check whether the router reboots nightly, whether the ISP has brief dropouts around the trigger time, or whether the mesh is steering devices between nodes. If this test works (bulb stays online for hours and responds instantly) → the issue is less likely the network and more likely configuration or conflict.
Firmware/software causes
Outdated firmware on bulbs, hubs, or bridges can cause missed schedules, especially after DST changes or platform updates. Update firmware for the hub/bridge and the bulbs (when supported), and update the controlling app. If updates are available but stuck, power cycle the hub and try again.
Configuration conflicts: groups, scenes, permissions, and controller roles
Matter and multi-platform homes can have more than one controller (for example, multiple phones, speakers, or hubs). If two controllers both manage automations, you can end up with duplicated or conflicting rules. Also check that the automation has permission to control the specific device (some platforms allow per-device control permissions). If X happens (only some bulbs follow sunrise/sunset) → it usually means group membership, permissions, or a controller that can’t reach part of the device set.
When to Reset or Replace the Device
A soft restart is simply power cycling the hub/bridge/controller and, if needed, turning the light off and on using the app (not repeated wall-switch toggling). Try this first because it does not erase settings.
A factory reset should be considered when the device repeatedly goes offline, refuses firmware updates, or won’t accept a fresh automation even after location/time zone and conflict checks. Be aware of what you lose: factory reset typically removes the bulb from rooms/groups, deletes local calibration, and may require re-pairing to a hub/bridge and rebuilding automations. If your ecosystem stores automations in the cloud, you may still need to re-link the device to those rules.
Replace the device if it overheats, smells hot, flickers excessively even when controlled manually, or has visible damage. In those cases, stop using it and replace it rather than trying to force it to follow schedules.
How to Prevent This in the Future
Keep the “home location” set manually in the smart home platform so sunrise/sunset calculations don’t depend on a phone’s GPS permissions. After moving, changing time zones, or changing phones, immediately verify the home address and time zone and then toggle automations off/on to refresh schedules.
Maintain stable device reachability: keep smart bulbs powered (leave the wall switch on), place hubs/bridges centrally, and avoid hiding them behind dense electronics or inside cabinets. For WiFi bulbs, aim for consistent 2.4 GHz coverage where the bulbs are installed, and avoid frequent router reboots during evening hours when sunset routines typically run.
Manage automations deliberately. Use one primary app/platform as the “source of truth” for sunrise/sunset lighting. Avoid duplicates across multiple apps, and document what each automation does. After adding new scenes or adaptive lighting features, verify they are not scheduled to run at the same time as sunrise/sunset rules.
Plan for power outages: after an outage, check that the hub/controller is online and that the correct home location is still set. If your lights have a “power restore behavior” setting, configure it so lights don’t end up in an unexpected state that triggers other automations.
Keep firmware and apps updated, especially around seasonal time changes. If you notice a consistent one-hour shift, check time zone and DST settings first before rewriting automations.
FAQ
Why do my lights follow the schedule some days but not others?
Intermittent behavior usually points to reachability or an automation conflict. If the bulb or hub is offline at the trigger moment, it can miss the command. If another routine runs around the same time, it may override the sunrise/sunset action. Use the “1 minute from now” test and check device status history (if available) to see whether the device was reachable when the automation should have run.
My sunset time is wrong by exactly one hour. What does that mean?
An exact one-hour difference is most often a time zone or Daylight Saving Time mismatch on the hub/controller or in the home settings of the platform. Confirm the home time zone in the smart home app and ensure the controller device is set to automatic time and automatic time zone.
Misconception: If my phone shows the right location, the smart home app must be using it.
Not always. Many ecosystems store the home location separately, and sunrise/sunset calculations may use the saved home address, not your phone’s current GPS. Also, if location permission is blocked or set to approximate, the app may not update the home location correctly. Always verify the home address/pin inside the smart home platform settings.
Do WiFi bulbs need the internet for sunrise/sunset schedules?
It depends on where the automation runs. Some systems run sunrise/sunset schedules in the cloud, which requires internet at the trigger time. Others run locally on a hub/controller. If manual control works locally but schedules fail during ISP outages, your schedules are likely cloud-based.
Only one bulb in a room ignores sunrise/sunset. Why?
That usually means the bulb is intermittently offline, not actually included in the group/room targeted by the automation, or it is linked to a different controller/account. Test the automation against that single bulb, verify it appears “online,” and remove/re-add it to the room/group so the automation targets it correctly.
There’s a strange kind of relief in seeing the whole thing laid out—like dropping a heavy bag you didn’t realize you’d been carrying. The noise fades, and what’s left feels oddly straightforward.
It won’t fix every day on command, but it changes the temperature of the room. After that, the problem just sits there, no longer buzzing in the background like it owns the place.








