As an Amazon Associate I earn from qualifying purchases. This post contains affiliate links to low-cost accessories; using them costs you nothing extra and helps keep this site independent.
A smart home that turns lights on when you walk in and off when you leave feels like magic — right up until the automation quietly stops firing. The device still responds when you tap it manually, so nothing looks broken, but the routine that was supposed to run at sunset does nothing, the motion light stays dark, and you are left flipping switches like it is 2005. This is one of the most frustrating failure modes in the whole hobby precisely because everything appears to be working. This guide is a systematic fix: a trigger-type reliability matrix so you know which automations are fragile by nature, an eight-step diagnostic order to find the break fast, and a table of the specific causes behind each symptom.
First, understand why automations fail differently than devices
When a device fails, it is obvious — the bulb will not turn on, the lock will not respond. When an automation fails, the device is usually fine; what broke is the chain of events that was supposed to command it: a trigger that did not fire, a condition that silently blocked it, a controller that is no longer running the logic, or a cloud service that quietly went away. Because the device still works on demand, people waste hours “fixing” a device that was never broken. The mental shift that solves most automation problems is this: stop testing the device and start testing the trigger. The device is the last link in the chain and almost never the culprit.
The trigger-type reliability matrix
Not all automation triggers are created equal. Some are rock-solid; others are inherently flaky and will fail intermittently no matter how well you build them. Knowing which is which tells you where to look first and, more importantly, which triggers to avoid for anything critical.
| Trigger type | Reliability | Common failure cause | Good for |
|---|---|---|---|
| Time / schedule (e.g. sunset, 7:00am) | Very high | Wrong time zone, DST, controller clock drift | Anything predictable; the most dependable trigger. |
| Motion sensor | High (if placed well) | Cooldown timeout, poor placement, dead battery | Hallways, closets, bathrooms. |
| Contact sensor (door/window) | Very high | Dead battery, magnet gap too wide | Entry-triggered scenes. |
| Presence / geofence (phone location) | Low–medium | Phone battery optimization killing location, GPS drift, permissions | Nice-to-have arrival scenes, never critical ones. |
| Device state (e.g. “when TV turns on”) | Medium | Cloud polling lag, integration breakage | Convenience chains. |
| Voice command | High (when online) | Cloud outage, renamed device, misheard phrase | On-demand, not unattended. |
| Sun-based (sunrise/sunset offset) | Very high | Wrong location set in controller | Lighting that tracks daylight. |
| Multi-condition (motion AND after dark) | Medium | One condition silently false; hard to debug | Precise scenes, but harder to troubleshoot. |
The single most important row is presence/geofencing, because it is the trigger people most want to be reliable (lights on when I get home!) and the one that is inherently least reliable. Phone location is subject to battery-optimization features that kill background location, GPS drift that fires the geofence early or late, and permission changes that silently disable it after an app update. If an arrival automation is flaky, the geofence is almost always the reason — and the fix is often to stop relying on it for anything you would be upset to lose.
The eight-step diagnostic order
When an automation stops firing, resist the urge to rebuild it blindly. Work this order top to bottom — it is arranged so the most common, easiest-to-check causes come first, and each step rules out a whole class of problems.
| Step | Check | What it rules out |
|---|---|---|
| 1 | Is the automation actually enabled? (toggles get switched off by accident or by updates) | The single most common cause: a disabled routine. |
| 2 | Run it manually from the app. Does the action fire? | Separates a broken action from a broken trigger. |
| 3 | Is the trigger device online and responsive? Check its last-seen time. | A dead/offline sensor that can no longer fire the trigger. |
| 4 | Check the trigger’s battery (sensors) and signal strength. | Weak battery/signal causing missed events. |
| 5 | Review conditions: time window, “only when dark,” presence, device-state gates. | A condition silently blocking an otherwise-firing automation. |
| 6 | Check time zone, location, and DST on the controller. | Schedule/sun triggers firing at the wrong time or not at all. |
| 7 | Look for a recent app/firmware/integration update or account change. | An update that reset, renamed, or unlinked something. |
| 8 | Check the controller/hub itself and any cloud service status. | The brain not running the logic, or a cloud outage. |
Ninety percent of stuck automations are caught by steps one through five, and step two is the master key: if the manual run works, the action and device are fine and your problem is the trigger or a condition — steps three through six. If the manual run also fails, the problem is downstream in the device or its connection, and you are troubleshooting the device, not the automation.
Symptom-to-cause reference table
Once you have localized the problem with the diagnostic order, this table maps the specific symptom to its usual root cause and fix.
| Symptom | Most likely cause | Fix |
|---|---|---|
| Automation never fires, manual run works | Trigger not firing (disabled, offline sensor, or condition blocking) | Steps 1, 3, 5: re-enable, check sensor, review conditions. |
| Fires at the wrong time | Time zone / DST / wrong location | Set correct time zone and home location on the controller. |
| Motion light works then stops for minutes | Sensor cooldown / blocking timeout | Shorten the sensor’s re-trigger interval; check “off delay.” |
| Arrival scene unreliable | Geofence / phone location killed by battery optimization | Exempt the app from battery optimization; grant “always” location. |
| Worked until yesterday, now dead | App/firmware update or account/device rename | Re-link integration; confirm device names still match the automation. |
| Fires manually but not on schedule | Controller clock drift or schedule running in cloud during outage | Restart hub; move schedule to a local controller. |
| Intermittent, no pattern | Weak signal to trigger device; mesh gap | Add a repeater; relocate the sensor or a mesh node closer. |
| Multi-condition scene never runs | One condition permanently false (e.g. “sun below horizon” with wrong location) | Test each condition alone; fix the false one. |
The five causes behind almost every stuck automation
Step back from the tables and the same handful of root causes account for the overwhelming majority of cases. Internalize these and you will diagnose most problems in under a minute.
- The automation got disabled. Boringly common. Updates, accidental toggles, and “pause” buttons switch routines off, and nobody notices until they fail to fire. Always check this first.
- The trigger device went offline or lost battery. A sensor that dropped off the network or ran its coin cell down cannot fire anything. The device did not break loudly; it went quiet.
- A condition is silently blocking it. “Only when nobody is home,” “only after sunset,” “only if the TV is off” — any one of these being unexpectedly true or false stops the whole thing with no error.
- Something updated. An app update reset a permission, a firmware update renamed a device, an account change unlinked an integration. “It worked until yesterday” almost always means something changed yesterday.
- The controller or cloud is not running the logic. A hub that rebooted and did not resume, or a cloud service that had an outage, means the brain simply is not executing your automations even though every device is fine.
Fixing the flaky motion light
Motion automations deserve their own section because they are the most common and the most misdiagnosed. The classic complaint — “the light comes on, then won’t come on again for a while” — is almost never a broken sensor. It is the sensor’s cooldown (also called re-trigger interval or blind time): to save battery, most motion sensors refuse to report new motion for a set period after they last fired, often 30 to 180 seconds. If your automation’s “off” delay is shorter than the cooldown, the light turns off and then the sensor ignores you standing right in front of it until its timer resets. The fix is to make the light’s off-delay longer than the sensor’s cooldown, or to shorten the cooldown if the sensor allows it. The other frequent motion problem is placement: sensors detect motion crossing their field of view far better than motion coming straight at them, so a sensor aimed down a hallway works beautifully while one pointed at a doorway you walk directly toward misses you half the time. Mounting height and angle matter more than the sensor’s spec sheet.
If a specific room’s motion has always been marginal, the cheapest reliable upgrade is usually a second, better-placed sensor rather than fiddling with one badly aimed unit; a small Zigbee motion sensor placed to catch cross-traffic transforms a flaky hallway automation into a dependable one.
Fixing the unreliable arrival automation
The “turn on the lights when I get home” automation is the one people most want and most often give up on, and it is worth understanding exactly why it fails. Phone-based presence relies on your phone reporting its location to your smart-home app in the background, and modern phones aggressively suppress background activity to save battery. The result is a geofence that fires late (you are already inside in the dark), early (lights come on while you are still at the store), or not at all (the app was starved of location). The reliable fixes, in order: exempt the smart-home app from battery optimization so it can keep updating location; grant it “always” location permission rather than “while using”; and widen the geofence radius so GPS drift near the boundary does not cause misfires. For genuinely reliable arrival detection, many people abandon phone geofencing entirely in favor of a physical trigger — a contact sensor on the front door or garage that fires the “I’m home” scene the moment the door opens. It is not as clever as knowing your phone crossed a boundary, but it is dramatically more dependable, and dependability is the whole point. A door contact sensor is a couple of dollars and turns an unreliable geofence scene into one that just works.
When an update breaks everything at once
If a whole batch of automations dies simultaneously, you are not looking at eight separate failures — you are looking at one shared dependency that changed. The usual suspects are a controller or hub firmware update that reset settings or did not fully resume afterward, an app update that revoked a permission or changed how integrations authenticate, or an account/service change that unlinked a connected platform. The diagnostic is quick: ask “what do all the broken automations have in common?” If they all use the same trigger device, that device is the problem. If they all live on the same hub, restart and re-check the hub. If they all touch the same connected service (a voice assistant, a cloud integration), re-link that service. Mass failure is actually easier to fix than a single mysterious one, because the shared cause narrows it down fast — resist the urge to rebuild them one by one before you have found the common thread.
Building automations that do not break
The best troubleshooting is the kind you never have to do. A few design habits make automations dramatically more durable.
- Prefer high-reliability triggers. Use time, sun, contact, and well-placed motion for anything you care about. Reserve geofencing and device-state chains for nice-to-haves.
- Run the logic locally. Automations executed on a local hub survive internet and cloud outages; cloud-run routines do not. Put critical logic on a controller in your house.
- Keep device names stable. Renaming a device in one app can silently break automations that reference the old name. Name things well once and leave them.
- Avoid over-conditioning. Every extra condition is another silent point of failure. Add the fewest conditions that achieve the goal, and test each one alone.
- Give critical automations a manual fallback. A physical switch or button that does the same thing means a broken automation is an annoyance, not a crisis.
- Keep sensor batteries fresh. A low-battery sensor is a leading cause of silently missed triggers. Replace proactively and keep spares on hand.
Keeping a small stock of the right sensor batteries turns the most common cause of flaky automations — a quietly dying coin cell — into a thirty-second swap instead of an evening of confused debugging.
Conditions: the silent saboteurs
Conditions are where the trickiest automation failures hide, because unlike a dead sensor they produce no error and leave no trace — the automation simply decides not to run and says nothing. A condition is any gate you attach to an automation: “only after sunset,” “only when I am home,” “only if the temperature is below 70,” “only on weekdays.” Each one is a little test that must be true for the action to fire, and each one is a place where the automation can silently fail if the test is unexpectedly false.
The most common condition trap is the time-of-day or sun condition with a misconfigured location. If your controller thinks it is in the wrong city or time zone, “after sunset” resolves to the wrong moment — sometimes hours off — and a lighting automation that “never runs” is actually running faithfully at 2am when the controller believes the sun has set. The second trap is presence conditions: “only when nobody is home” combined with flaky geofencing means the automation thinks someone is home when the house is empty, or vice versa, and blocks accordingly. The third is stale device-state conditions: “only if the TV is off” fails when the integration reporting the TV’s state has broken and is returning a stale or unknown value.
The debugging technique for conditions is simple and reliable: remove them all, confirm the automation fires, then add them back one at a time until it stops. The condition you just added is the culprit. It is tedious, but it is the only way to catch a silently-false gate, and it beats staring at logic that looks correct on paper.
| Condition type | How it silently fails | Quick test |
|---|---|---|
| Time / sun-based | Wrong location or time zone shifts the window | Check controller location; temporarily widen the window. |
| Presence (“nobody home”) | Geofence reports wrong occupancy | Check the presence entity’s current state directly. |
| Device state (“if X is off”) | Integration returns stale/unknown value | Look at the referenced device’s reported state. |
| Numeric (“below 70°”) | Sensor reading drifted or unit mismatch (C vs F) | Verify the sensor’s current value and unit. |
| Day-of-week | Runs on a schedule you forgot excludes today | Confirm the day list includes the current day. |
When the hub reboots and does not come back right
Your hub is the brain that runs local automations, and like any computer it occasionally reboots — after a firmware update, a power blip, or a manual restart. Most of the time it resumes cleanly, but sometimes it comes back with automations disabled, a drifted clock, or devices that have not fully reconnected, and the result is a batch of routines that quietly stop firing. This is worth its own recovery routine because it looks alarming (lots of things broken at once) but is usually quick to fix.
After any hub reboot, do three checks. First, confirm the clock and time zone are correct, because a hub that lost its time will fire schedule and sun automations at the wrong moment or not at all. Second, confirm your trigger devices are reconnected — a hub reboot can leave sensors in a limbo state where they show as present but are not actually reporting, so check last-seen times and trigger one manually. Third, confirm the automations are still enabled, since some platforms pause routines during an update and do not always re-enable them. A quick smart plug with a scheduled restart on a hub that tends to lock up can even automate the reboot itself — though a hub that needs regular reboots is telling you it is time to look at heat, power, or a replacement.
Timing, latency, and race conditions
Some automations fire but do the wrong thing because of timing, and these are the hardest to spot because there is no failure to see — just an occasional wrong outcome. A few patterns recur. Cloud polling lag: a device-state trigger that depends on the cloud noticing a change can lag by seconds to minutes, so “when the TV turns on, dim the lights” happens a beat too late to feel magical. Race conditions: two automations that both react to the same event can fight, one turning a light on while the other turns it off, with the winner varying run to run. Overlapping timers: a motion-on automation and a separate schedule-off automation can collide, leaving a light in the wrong state depending on which fired last. The fixes are to prefer local triggers over cloud-polled ones for anything time-sensitive, to consolidate conflicting logic into a single automation with clear priority rather than two that race, and to make sure “on” and “off” halves of a behavior live in one place so they cannot contradict each other.
Platform quirks worth knowing
While the diagnostic order is universal, a few behaviors differ enough across platforms to be worth flagging so you know they are normal rather than bugs. Some ecosystems pause automations during firmware updates and re-enable them afterward — but not always cleanly, so a post-update check is wise. Some platforms run certain automations in the cloud and others locally without making it obvious which is which, so behavior during an outage can be inconsistent within the same home. Some voice-assistant routines depend on the exact device name, so renaming a light in one app quietly breaks the voice routine that referenced it. And some platforms impose a minimum interval between an automation’s runs to prevent loops, which can look like a trigger being ignored when it is actually being rate-limited. None of these are faults to fix so much as behaviors to account for — knowing they exist saves hours of chasing a “bug” that is really a documented quirk.
A worked example: the sunset lights that stopped
To see the method in action, walk through a real-shaped case. The complaint: living-room lights that used to come on at sunset now do nothing, but tapping them in the app works fine. Applying the order: step one, the automation is still enabled — rule that out. Step two, a manual run turns the lights on — so the action and devices are fine, and the problem is the trigger or a condition. Step three, there is no trigger device here (it is a sun-based schedule), so skip to conditions and timing. Step five and six: checking the controller, its location was reset to a default city three time zones away during a recent update, so “sunset” now resolves to the middle of the afternoon when the room is already bright and any “only when dark” condition blocks the light — and later, at the real local sunset, the automation has already “run” for the day. The fix: correct the controller’s home location and time zone. One setting, and the automation returns to firing at the actual sunset. This is the payoff of the systematic order: the manual-run test instantly moved the search away from the (perfectly healthy) lights and toward the trigger, and the location check — a step people almost never think of — was the whole answer.
Signal strength: the trigger that is there but unheard
An underrated cause of intermittent automations is a trigger device that is technically online but sitting at the ragged edge of radio range, so some of its events reach the hub and some do not. This produces the maddening “works sometimes” pattern with no obvious logic to it. A motion sensor in a far corner, a contact sensor on a detached garage, a device separated from the hub by a brick wall or a run of ductwork — each can report reliably enough to look connected while dropping a meaningful fraction of its messages.
The tell is intermittency without pattern: the automation fires most of the time, misses occasionally, and you cannot reproduce the miss on demand. If steps one through six of the diagnostic order come up clean and the failures are random, suspect signal. The fixes are all about shortening the radio path: add a mains-powered device (a smart plug or bulb) between the sensor and the hub to act as a mesh repeater, relocate the sensor a little closer or away from metal and masonry, or move the hub itself to a more central spot. Mesh protocols like Zigbee, Z-Wave, and Thread heal and route around weak links automatically once there is a repeater in the gap, so a single well-placed mains device often fixes a whole cluster of flaky far-room automations. A cheap mains-powered Zigbee smart plug dropped halfway between a distant sensor and the hub is the classic one-device fix for a mesh dead zone.
A maintenance routine that prevents most failures
Automations do not usually break from a single dramatic event; they erode from small neglected things — a battery that slowly died, a name that got changed, an update that quietly reset a setting. A light quarterly routine catches almost all of it before it becomes a mystery to debug.
- Battery sweep. Check the battery level of every sensor and replace anything below about 20%. Low battery is the number-one cause of a trigger that stops firing without warning.
- Last-seen audit. Scan your devices for any that have not reported in a while. A sensor that has gone quiet is a trigger that is no longer working, even if it still shows in the app.
- Automation roll-call. Glance through your automations and confirm each is still enabled. Toggles get flipped by updates and accidental taps more often than you would think.
- Name check. After any device rename, search your automations and voice routines for references to the old name and update them.
- Outage rehearsal. Once in a while, confirm your critical automations run locally by testing them with the internet disconnected but the local network up.
Fifteen minutes a quarter spent on this routine is the difference between a smart home that quietly keeps working and one that accumulates silent failures until half your automations are dead and you have no idea when they died. The failures that are hardest to debug are the ones you discover months after the cause, so catching them close to the event — a fresh battery, a just-renamed device — is worth far more than the time it takes.
Knowing when to simplify instead of fix
Finally, a word on restraint. Some automations are flaky because they are trying to be too clever — a chain of five conditions, a geofence, and a cloud-polled device state, all of which must align for a light to turn on. Every layer you add is another silent point of failure, and past a certain complexity the honest move is not to debug it but to simplify it. Ask what the automation is really for: if it is “lights on when I get home,” a door contact sensor firing a simple scene is more reliable than an elaborate presence-and-condition construction, and you will never troubleshoot it again. If it is “hallway light at night,” motion plus a sun condition beats a five-part logic tree. The most dependable smart homes are not the most sophisticated ones; they are the ones built from the smallest number of reliable triggers doing clearly-defined jobs. When an automation keeps breaking, that is often the system telling you it is too complicated for the value it delivers — and the best fix is a simpler design, not a cleverer patch.
Frequently asked questions
Why did my smart home automation suddenly stop working? The most common causes are the automation getting disabled, the trigger device going offline or low on battery, a condition silently blocking it, or a recent app/firmware update that reset or renamed something. Run the automation manually first: if the action fires, the problem is the trigger or a condition, not the device.
Why does my motion light turn on but not stay reliable? Almost always the sensor’s cooldown (re-trigger interval), which makes it ignore new motion for 30–180 seconds after it last fired. Make the light’s off-delay longer than the cooldown, or shorten the cooldown if your sensor allows, and check that the sensor is placed to catch motion crossing its view rather than coming straight at it.
Why is my “arrive home” automation unreliable? Phone geofencing is inherently flaky because phones suppress background location to save battery. Exempt the app from battery optimization, grant “always” location, widen the geofence, or switch to a physical trigger like a door contact sensor for dependable arrival detection.
My automations worked yesterday and stopped today — what changed? Something updated. Look for an app update, a hub/firmware update, or an account/device rename. If many automations broke at once, find the shared dependency — a common trigger device, hub, or connected service — and fix that one thing rather than each automation.
Should I run automations in the cloud or locally? Locally, whenever the automation matters. A local hub keeps schedules and triggers firing during internet and cloud outages; cloud-run automations stop the moment the connection or the vendor’s servers go down.
How do I stop automations from breaking so often? Prefer reliable triggers (time, sun, contact, good motion), run logic on a local hub, keep device names stable, minimize conditions, keep sensor batteries fresh, and give critical automations a physical fallback.
Can a weak battery cause an automation to fail even if the device still shows online? Yes, and it is one of the most deceptive cases. A sensor low on battery can still report as connected while dropping or delaying the events that fire your automation, producing intermittent misses with no obvious cause. If a trigger device is more than a year old and its automation has turned flaky, replace the battery before troubleshooting anything else — it is the cheapest and most common fix.
The bottom line
A stuck automation is maddening because nothing looks broken — and that is exactly the clue. The device still works; what failed is the chain that was supposed to command it. Run it manually to split the trigger from the action, then walk the eight-step order from the most common cause (a disabled toggle) to the rarest (a controller not running the logic). Nine times in ten it is a disabled routine, an offline or low-battery sensor, a silently blocking condition, or something that updated yesterday. Build with reliable triggers, run critical logic locally, keep names stable and batteries fresh, and leave a physical fallback on anything you would hate to lose — and your automations will go back to feeling like magic instead of a mystery.
About this guide: the reliability rankings and diagnostic order reflect the failure patterns that recur across mainstream smart-home platforms and sensor types, organized from most to least common cause. Specific behaviors — cooldown lengths, permission names, update effects — vary by device and platform; use the diagnostic order to localize the problem in your own setup, then apply the matching fix from the symptom table.