Automations that misfire and how to fix them

When a light comes on at three in the morning or a fan starts when nobody is home, the automation is often doing exactly what it was built to do, just not what you intended. Many misfires come from one of four causes: two rules fighting over the same device, time settings that are wrong, a device reporting a state that no longer matches reality, or a trigger that fires more often than expected. Finding the cause is much faster than guessing, so start with the record of what happened.

Tracing a misfire works best as a methodical process. Note the time it happened, check the activity history, identify the rule that ran, then compare its trigger and conditions with what you expected. Each cause leaves a different pattern in the history, such as a rule that runs twice in a row, a run at a fixed offset from the expected time, or a device that reports a state it no longer holds.

Check the activity history first

Most home apps keep a log of device events and automation runs. Open the history for the time of the misfire and look for the event that started it. Was it a sensor report, a time trigger, a device changing state, or a manual command from a phone or voice assistant? The log often answers that within a minute. If it shows no trigger at all, the action may have come from another rule, a scene, or a device's own built-in schedule.

Keep the log in view for the next steps. Many misfires are only visible there, because a device's current status shows where it ended up but not how it got there. Note the sequence of events in the few minutes before the misfire, since two events that look unrelated are often connected.

Find overlapping rules

Overlapping rules are a frequent cause. Two automations may control the same light, with one turning it on at dusk and another turning it off at a set time, and they can fight each other when the times are close. A loop is a related problem, and it happens when each rule's action fires the other rule's trigger. For example, suppose one rule turns a hallway light off a few seconds after it comes on, and a second rule turns the light on a few seconds after it goes off. The light then flickers until one of the rules is changed. A similar loop can form when a rule sets a fan's speed each time the fan reports a new power reading, and the fan reports again after every change. Check every rule that touches the device in question, including routines and scenes that can run automations indirectly.

To fix overlap, decide which rule should own the device, then remove or narrow the other one. For a loop, disable one of the two rules first, since that breaks the cycle at once. Then add a condition that checks the device's current state, so a rule acts only when the device is not already where it wants to be. Avoid having two rules set the same device to opposite states on the same trigger, since the final result depends on whichever rule runs last.

Check time zones, sunset times and daylight saving

Time-based rules depend on the time zone and location set in the home app and sometimes on the hub itself. A hub with the wrong time zone runs schedules an hour or more away from the intended time. Sunrise and sunset triggers use the location coordinates, so an incorrect address can move a sunset light noticeably.

Daylight saving changes can also cause an hour-long offset. A hub or device set to a fixed offset from UTC, such as UTC minus five hours, does not adjust when the clocks change, while a named time zone such as Eastern Time does. A device whose clock is not syncing automatically can show the same problem. The fix is to select the named time zone for your location in the hub's settings, and to turn on automatic time on each device that offers it, so the clock follows the change without manual adjustment.

Go straight to these settings when a misfire happens at a consistent offset from the expected time. A rule that runs an hour early or late often points to a time zone or daylight saving issue rather than a broken rule. Confirm the home address is correct, the time zone matches where you live, and any schedule meant to follow the clock is written with that in mind. For a sunset rule, compare the sunset time shown in the app with a trusted local source.

Watch for stale device states

A device state is what the app believes the device is doing. If a device lost its connection while it was in a particular state, the app may keep showing the old state until the device reports again. A rule that checks whether a plug is off may act on a plug that is actually on, or the reverse. This can happen after a power cut or a Wi-Fi drop, and it can produce repeated commands that appear to have no effect.

Fix stale states by asking the device for its current status, which you can often do by opening its detail page or power cycling it. Reconnect any device that shows as offline. If one device keeps reporting the wrong state, remove it from the rule, test it separately and add it back only when it reports correctly. Rules that depend on device state are more fragile than rules that react to a sensor event, so switch to an event-based trigger where the setup allows it.

Change one thing at a time

After you find the cause, change only one thing and watch the next few days. If you adjust the trigger, the condition and the time all at once, you will not know which change solved the problem. Record each change in your notes with the date, so you can roll back if a new problem appears. Once the rule behaves, consider simplifying it, because a shorter rule with fewer conditions is easier to debug the next time something goes wrong.

If the cause still does not show after these checks, disable the rule for a day and watch whether the misfire continues. A rule that is switched off cannot be the source of a misfire, so the result quickly narrows the search to other rules, schedules or devices.