Designing automations that people do not turn off
Most automations are disabled by a human, not by a bug. Design against the human, not the edge case.
Why automations get turned off#
They are almost never turned off because they failed. They are turned off because they succeeded at the wrong moment: the light went out while someone was reading, the hallway lit up at 3am, the thermostat set back while someone was working from home.
That produces a design constraint most automation tutorials skip. The goal is not cleverness, it is that the automation is never worse than no automation. Something that helps most of the time and infuriates people occasionally gets deleted, because the occasional case is what they remember.
Rule 1: the fail-safe principle#
Never leave the house in a state a human cannot fix with a switch they can find in the dark.
Every automated space should degrade gracefully through three levels:
| Level | What is working | What must still be possible |
|---|---|---|
| Normal | Everything | Automations and voice |
| Hub or internet down | Devices powered, radios fine | A wall control turns the light on |
| Total device failure | Nothing smart works | A dumb path to light in the room |
Concretely, this rules out several popular patterns:
- Smart bulbs on a wall switch people use. The bulb is only reachable while it has power, so a flipped switch takes it offline, breaks the automation and shows it as unresponsive. Either put a wireless control over the switch so it cannot be flipped, or use a smart switch with dumb bulbs. Smart lighting that stays compatible and smart switches, dimmers and the neutral wire cover both paths, including US boxes with no neutral.
- Motion-only lighting with no manual control. If the only way to light a room is to move in a way the sensor notices, anyone sitting still is in the dark with no recourse.
- Automations that turn things off with no way to say "not now". Every off action needs a suppression path.
- A single hub as the only route to anything safety-adjacent. Heat, water, egress and locks should all work without your automation platform. What still works when the internet goes down is the device-by-device version.
Rule 2: why motion lighting annoys people, and the fix#
Motion lighting is the most-installed and most-disabled automation in the smart home. The mechanism is worth stating precisely, because the usual advice ("increase the timeout") is only half right.
Passive infrared sensors detect movement, not occupancy. They fire on a change in infrared across their zones, and a person reading, watching television, typing or sitting on a call produces very little of that. Human stillness routinely exceeds several minutes, so a light with a 2 minute timeout turns off on someone who is very much still in the room. They then wave at the ceiling, which is the exact moment an automation loses a household's trust.
A second mechanism makes it worse. Most PIR sensors go blind for a period after reporting motion, to save battery, with values from tens of seconds to a few minutes that are often configurable. So even a person who does move may not re-trigger the sensor before the timeout expires.
The fixes, in order of how much they help:
- Reset the timer on every motion report, and set the timeout longer than plausible stillness for that room. Hallway: 2 to 3 minutes, because nobody sits in a hallway. Bathroom: 10 minutes minimum. Living room or office: motion-only lighting is the wrong tool.
- Fade before you cut. Dim to 20 percent for 30 seconds before turning off. Someone still in the room moves, the sensor re-triggers, and the light comes back up before it ever went dark. This one change converts most complaints into non-events.
- Use presence sensing, not motion, where people sit still. mmWave presence sensors detect breathing-scale movement and hold occupancy through stillness. They also see through some interior walls, trigger on ceiling fans, curtains and pets, and are usually mains-powered rather than battery. Sensors: motion, contact, temperature, leak covers the classes.
- Add conditions that make the automation modest. Only below a lux threshold, only when the lights were not manually set, and never above a low brightness at night.
- Sequence contact and motion. A door opening followed by motion is a strong arrival signal. Motion with no preceding door event, in a room already occupied, is often a pet or a draft.
Rule 3: timeouts and state, not triggers and events#
Most fragile automations are fragile for the same structural reason: they act on an event that happened once, and there is no way to recover if that event is missed.
Events get missed. A battery sensor's report can be lost, a Thread device can be re-parenting, a cloud round trip can time out, a hub can be mid-restart. If your logic is "when the door closes, turn off the porch light", one missed close event leaves the porch light on all night and nothing ever corrects it. State-based logic recovers on its own, because it re-evaluates.
Practical translations:
- Turn off N minutes after the last motion, rather than when motion clears. Cleared-motion events are exactly the ones that go missing.
- Give every "on" an owner and an expiry. Whatever turned a device on should be responsible for turning it off, with a maximum duration.
- Add a reconciliation pass. A periodic check such as "at 2am, if any exterior light is on and nothing is scheduled, turn it off" catches everything your event logic missed.
- Make actions idempotent. Running the same automation twice should produce the same result. "Toggle" is the enemy of this; "set to on" is not.
- Handle late. Automations do run late, and where the seconds go is measurable per hop. Automations run late walks through the chain.
Rule 4: manual override#
The moment a person touches a physical control they have expressed an intention that outranks your automation. Systems that do not model this end up fighting their owner, and the owner wins by unplugging something.
The pattern that works: detect the manual action (a switch press, a button, a state change you did not command), set an override flag for that room with a duration (thirty minutes is a good default, until the next scheduled transition is better), have every automation that touches the room check the flag first, and clear it explicitly on a schedule, on prolonged vacancy, or with a "resume automatic" control people can trigger.
Distinguishing commanded state from manual state is the hard part and depends on the platform. Local platforms that see the device's own state changes can compare what they last commanded with what the device reports. Cloud platforms often cannot. Where detection is unreliable, use an explicit override control instead: a button, a scene, or a long press meaning "leave this room alone".
Presence detection, honestly#
Presence is where automations promise most and disappoint most. Every method trades false positives against false negatives, and none is reliable enough to gate anything that matters.
| Method | Good at | Fails at | Reasonable use |
|---|---|---|---|
| Phone GPS geofence | Knowing you left the neighborhood | Arrival timing, apartments, battery saver, boundary jitter | Pre-warming, "everyone out" setbacks |
| Wi-Fi association | Fast, definite arrival | Departure: phones sleep and drop association at home | Arrival triggers, with a second signal |
| Bluetooth or BLE beacons | Room-level proximity | Range varies with bodies and walls, sticky results | Nudges, never gating |
| mmWave presence sensor | Finding a still person in a room | Pets, fans, curtains, thin walls | Keeping lights on while someone sits |
| Door contact plus motion | Cheap, definite entry events | Cannot count people | Deciding a room became occupied |
| A button or NFC tag | Perfectly accurate | Requires a human action | Explicit "I am home" or guest mode |
Three rules follow from that table. Combine methods for anything you care about: GPS for the coarse state, Wi-Fi or a door contact for the transition, because a single source will be wrong regularly. Bias the consequences of being wrong: lights on with nobody home is cheap, heat off with someone home is expensive, and a door unlocked on a false positive is unacceptable, which is why arrival-based unlocking is a bad idea no matter how good your detection feels. Never make presence the only path: whatever it enables must also be reachable by a switch, a button or a phrase.
Testing an automation before you trust it#
- Notify only. For the first few days, have the automation send a notification instead of acting. You will learn how often it would have fired at times you did not expect. This single step eliminates most bad automations before anyone else sees them.
- Test at the real hour. Something that behaves perfectly at 2pm can be intolerable at 6am, because brightness, noise and tolerance are all different.
- Test the failure path. Turn off the hub, turn off the internet, take the battery out of the sensor. If the answer is "leaves the house in a bad state", go back to rule 1.
- Test double firing. Trigger it twice in quick succession. If the second run undoes or compounds the first, your actions are not idempotent.
- Test the override. Touch the wall switch mid-automation. If it fights back, fix that before anything else.
- Test with the skeptic. Let the least enthusiastic person in the house live with it for a week and ask what annoyed them. They decide whether the automation stays.
Automation ideas ranked by how well they survive#
| Automation | Survival | Why |
|---|---|---|
| Leak sensor to alarm and notification | Very high | No timing judgment, no false-off |
| Sunset exterior lights, sunrise off | Very high | Predictable, no sensing, no ambiguity |
| Bathroom motion, 10+ minute timeout, dim warning | High | Long timeout removes the annoyance case |
| Door left open reminder after 5 minutes | High | Advisory rather than controlling |
| "Everyone out" setback with a wide geofence | Medium | Errs toward comfort on return |
| Hallway motion with a 2 minute timeout | Low | Human stillness exceeds the timeout |
| Presence-based door unlocking | Very low | Security consequence on a false positive |
The shape is consistent: automations that add information or act on unambiguous physical events survive. Automations that guess about people, then act on the guess by removing something, do not.
Automation editors are lists of names, so naming and room structure that survives 100 devices comes first. If automations fire correctly but slowly, the cause is architectural, and local vs cloud control explains the five places a command can be processed. Whether they run at all during an outage depends on the platform, one of the main axes in the seven platforms compared.
What is a good motion sensor timeout?
It depends entirely on the room, because the constraint is human stillness. Hallways and closets tolerate 2 to 3 minutes. Bathrooms need at least 10. Rooms where people sit, read or watch television should not use motion for turning lights off at all, because someone will always outlast the timer. Whatever value you pick, reset it on every new motion report and dim before turning off.
Why do my motion lights turn off while I am still in the room?
Because passive infrared sensors report movement, not presence, and most of them also go blind for a period after reporting to save battery. If you sit still longer than the timeout, or you move during the sensor's blind interval, the light turns off. Increase the timeout, add a dim-then-off warning, or replace the PIR sensor with an mmWave presence sensor in rooms where people are stationary.
How do I stop an automation overriding what I just did manually?
Set an override flag when a manual action is detected, have every automation that touches that room check the flag, and expire the flag after a fixed period or at the next scheduled transition. If your platform cannot tell a manual change from a commanded one, add an explicit control instead: a button or scene that means "leave this room alone for an hour".
Is phone location good enough for smart home automations?
For convenience, yes. For anything with a consequence, no. Geofences are unreliable near the boundary, phones in battery saver report late, and apartment buildings compress the useful radius. Use location for comfort decisions that are cheap to get wrong, never as the sole trigger for locks or security changes.
Should automations run locally or in the cloud?
Locally, if the platform offers it, because a cloud-run automation stops when your internet or the vendor does. Google's global outage on 18 August 2026 lasted about twelve hours and left Nest hubs unresponsive. Local execution also cuts latency, since a cloud round trip adds hops that you can measure. Where your platform sits on that axis is covered in local vs cloud control.
Primary sources
Specification and vendor documentation we checked while writing this page. Where a claim depends on firmware behaviour rather than a published spec, the page says so inline.