The Automation I Use Every Single Day

Last winter, our heating ran for 41 straight hours because a single $9 contact sensor died and nobody noticed. The smart thermostat kept “waiting for the house to be empty” before lowering the setpoint, the empty signal never came, and we burned roughly $18 of gas heating an apartment nobody was in. That failure taught me more about home automation than three years of tinkering combined.

This is not a roundup of gadgets we read about. This is the small set of automations that have run, every single day, for the better part of two years across a three-bedroom home with 47 connected devices. Some I would rebuild on day one of any new house; a few I tore out and never missed.

The point is simple: I want to show you which daily routines actually earn their keep, what hardware they depend on, what each one costs, and where they break. If you are deciding what to buy first, I would rather you copy a working system than collect a drawer of orphaned hubs like I did.

What “every single day” actually means

There is a difference between automations that fire constantly and automations that matter. My motion-triggered hallway light fires about 60 times a day; my “house is empty, shut everything down” routine fires twice. The second is worth ten times more, because it saves money, prevents the heater-stuck-on disaster, and removes a decision I would otherwise make while half-asleep.

So when I say daily, I mean routines anchored to the rhythm of an ordinary day. Morning. Leaving. Arriving. Night. Add presence detection underneath all four, sensors as the nervous system, and voice as the manual override, and you have the whole machine. Everything else is decoration. Get it right and the house feels like it is on your side; get it wrong and you are the person waving your arms at a sensor that timed out 90 seconds ago.

The four routines, ranked by how much I’d miss them

Here is the honest ranking after two years, rebuilt from my own logs, counting how often each routine ran and how often it actually changed something I cared about.

Notice that the flashiest one, the morning routine that reads me the weather like a tiny butler, is the one I would build last. It is delightful, and also the one I could lose tomorrow without consequence.

The Leave routine: the one that pays the mortgage on the rest

If you build exactly one automation, build this one. When the last person leaves, the house transitions to “away” mode and does five things: drops the thermostat by 6 degrees, turns off every non-essential light and outlet, locks the deck and front doors, confirms the garage is closed, and arms the perimeter sensors.

The trigger is presence, which we will get to later, because it is where most people’s automations fail. For now, assume the house knows when it is empty.

What it replaced

Before this routine, leaving involved a mental checklist I performed badly. Did I lock the deck door? Is the iron off? I would get three blocks away, doubt myself, and either turn around or spend the day anxious. The away routine deleted that entire category of worry. The house tells me exactly what it did: “Away mode: 9 devices off, 2 doors locked, garage confirmed closed, thermostat set to 64°.” That confirmation is the single most valuable notification I receive.

The numbers that made it worth building

In the first full quarter after I tuned the thermostat setbacks, the gas bill dropped 19% versus the same quarter the previous year, weather-normalized. That is real money: about $34 a month in winter. Lighting and standby-power savings are smaller but constant, around $7 a month by my smart-plug logs.

The away routine also prevented one genuinely bad event last year. A space heater in the home office was left running; the empty-house routine cut power to that outlet automatically, with the energy log showing it drawing 1,420 watts at the moment it was killed. I do not want to think about what eight unattended hours of that would have meant.

The hardware underneath it

The brain is a local hub running on a small always-on mini PC. The reason it is local, not cloud, matters enormously and I will defend that choice in its own section.

For power control, I standardized on energy-monitoring smart plugs so I can see exactly what each appliance draws and prove the savings are real. If you want to start measuring before you start automating, a set of energy monitoring smart plugs with per-outlet reporting is the cheapest way to find out where your standby watts are hiding. I found a “fully off” entertainment center still pulling 31 watts. That is $40 a year doing nothing.

The locks are the other load-bearing piece: a leave routine that does not reliably lock the door is worse than no routine, since it teaches you to trust a thing that fails.

The lock problem, and why it took three tries

My first smart lock failed to actuate about 1 in 25 times. That sounds rare. It is not: at one lock event per day, that is a failed lock roughly every three and a half weeks, and you never know which day it is. After the second time I got the “front door still unlocked” alert at 11pm and had to drive back, I rebuilt the whole approach.

What “reliable” actually requires

Three things made the difference. First, a deadbolt with a properly aligned strike plate, because most “the motor jammed” failures are mechanical, not electronic. Twenty minutes with a chisel widening the strike dropped the jam rate by more than half on its own.

Second, local control over a low-latency radio rather than cloud-routed commands. My average lock-command-to-confirmed-locked time went from about 2.8 seconds (cloud) to under 400 milliseconds (local mesh). The routine waits for confirmation before sending the “all done” notification, and a slow lock makes the house feel laggy.

Third, the part people skip: a verify-and-retry step. The routine does not just send “lock.” It sends “lock,” waits 600ms, reads the state back, and if it is not confirmed locked, retries up to three times before escalating to a push notification. That single bit of logic took my real-world lock reliability from roughly 96% to something I have not seen fail in 14 months.

If you are shopping, prioritize locks that report state back over a local protocol rather than ones that only accept commands. A smart deadbolt with Matter and local state reporting is the difference between an automation you trust and one you double-check, and double-checking defeats the purpose.

Lock buying checklist

Here is the exact checklist I now use before buying any lock for any automation. I learned each line the hard way.

1. Does it report state, or only accept commands? (State reporting is mandatory.)
2. Does it work over a local radio, or only the cloud? (Local, always.)
3. Can the physical key still work if every battery and bridge dies?
4. What is the battery life under daily auto-lock? (Mine: about 5 months on AAs.)
5. Does it have a manual jam recovery you can do without tools at midnight?
6. Will it fail unlocked or fail locked on power loss, and which do you want?

Number 6 surprises people. I want my lock to fail in its last commanded state, not to spring open or seize shut. Read the spec sheet, because manufacturers bury this and it is the most important safety behavior of the device.

The Night routine: boring, and the one I’d defend hardest

At 11:15pm, the house begins to wind down. Lights dim to 20% over four minutes rather than snapping off, the thermostat shifts to its sleep setpoint, the deck and front doors lock and verify, a quiet check confirms the garage and windows, and a single notification summarizes anything that needs my attention.

It does roughly what the leave routine does, minus the “drop the heat aggressively” part, because we are home. And it is the automation I would fight to keep.

Why the slow dim matters more than I expected

I originally had the lights just turn off at bedtime. It felt abrupt and hostile. A four-minute fade changed the feel of the whole home, and it doubles as a useful signal: when the living room starts going amber, everyone knows it is time to head up, without anyone having to be the bedtime enforcer.

The data that justifies it

I went back through six months of door logs. The deck door was left unlocked overnight 31 separate times before the night routine, caught by spot checks. After the routine went live, it has been auto-locked and verified every single night, 184 nights running, with three retry events logged and zero failures that reached me. That is the quiet value of automation: the elimination of a recurring small risk that depends on a tired human remembering a boring task at the moment they are least capable of it.

Sensors that make night mode trustworthy

The night routine needs the real state of the house, which means contact sensors on the doors that matter and a way to confirm the garage. I run small magnetic contact sensors on five doors and windows, chosen specifically because they report instantly and run for over a year on a coin cell.

The detail that matters: pick sensors on a low-power mesh protocol, not WiFi, or you will be changing batteries constantly and flooding your router. A handful of Thread or Zigbee door and window contact sensors cost less than a nice dinner and they are the literal nervous system of every “is the house secure” routine you will ever build. Mine have averaged 14 months per coin cell.

Presence detection: the part everyone gets wrong first

Every routine above depends on the house knowing who is home. This is the single hardest problem in residential automation, and where I wasted the most time and patience. I have run four different presence systems. Here is what I learned.

The phone-GPS trap

The obvious approach is phone location: when your phone leaves a geofence around the house, you are away. It is simple, it is free, and it is unreliable enough to make you hate automation.

My logs are brutal on this. Pure phone-geofence presence gave me a false “you left” event about 2–3 times a week, usually when a phone’s GPS drifted while sitting on the kitchen counter. Each false trigger meant the heat dropped and the lights shut off while we were sitting right there, and nothing makes a household revolt against your hobby faster than the lights going off during dinner. It also failed the other direction: arriving home, the geofence sometimes did not register for two or three minutes.

What actually works: layered presence

The system that finally became reliable layers signals and trusts the combination, not any single one.

The rule that fixed everything: the house never declares itself empty on GPS alone. It requires the door to have opened, then closed, then no motion anywhere for a confirmation window, and all known phones off the home WiFi. Stack those, and false “empty” events went from several a week to one in nine months.

The presence node trick

The cheapest reliability upgrade I made was adding small Bluetooth presence detectors near the entry and in the main living areas. They catch a phone the instant it comes in range, making arrival feel instant instead of laggy, and they confirm “still home” so GPS drift can never wrongly empty the house.

These do not need to be expensive. People build them from tiny dev boards, but if you would rather buy, a couple of Bluetooth presence sensors for room detection near the front door and bedroom turned my arrival routine from “wait three minutes” into “lights on before the door is fully open.”

The Arrive routine: small, and disproportionately delightful

When presence confirms I am home, especially after dark, the entry light comes up to a warm 40%, the thermostat returns to a comfortable setpoint, and if my hands are clearly full (a long press on a button by the door, or a voice command) the door unlocks for me.

I deliberately do not auto-unlock purely on presence. That is a security decision: presence is good enough to turn on a light, not to open my front door without an explicit intent signal. Know the difference between “comfortable to be wrong about” and “must be right about,” and put security in the second bucket.

The hands-full problem

The real win of the arrival routine is groceries-and-a-toddler ergonomics. Before, coming home with both arms loaded meant setting things on the porch, fishing for keys, and fighting a lock in the dark. Now a single press of a weatherproof button by the door, or a phrase to the entry speaker, runs the whole welcome sequence. I measured it once: old way, about 38 seconds of fumbling on a bad night; new way, about 9 seconds. That does not sound like much until it happens every day for two years while you are tired and it is raining.

Why I pre-warm, not just turn on

A subtle thing the arrival routine does: if presence detects I am near home but not yet inside (the outer geofence, the slow GPS signal I distrust for “empty” but trust for “approaching”), it nudges the thermostat back toward comfort early, so by the time I am in the door the house is already recovering. This only makes sense once the basics are rock solid; do not build pre-warming on a flaky presence system.

The Morning routine: the fun one I’d build last

At 6:40 on weekdays, the bedroom lamp begins a slow sunrise fade from zero to 70% over fifteen minutes. As it brightens, the thermostat lifts to the daytime setpoint so the house is warm before anyone’s feet hit the floor. When motion confirms I am up and in the kitchen, the entry speaker gives a 20-second brief: time, weather, and the first calendar item.

I love this routine, and I also ranked it dead last in value: it is comfort and theater, not risk reduction or savings. But the simulated sunrise genuinely changed how I wake up.

The sunrise that actually works

A single lamp doing a slow fade is fine. What made it work was a warm-to-cool color shift, not just brightness. The light starts deep amber, like an actual sunrise, and drifts toward a cooler daylight tone as it brightens, which cues your body better than white light.

For this you want bulbs with real tunable color temperature and smooth low-end dimming, because a bulb that can only do 10% steps will stutter and a bulb that can only do warm white will not give you the wake-up cue. A set of tunable white smart bulbs with sunrise dimming is the one place in the morning routine I would not cheap out, because the whole point is a smooth, gradual transition and cheap bulbs visibly stair-step.

The brief that I almost deleted

The spoken morning brief was nearly a casualty. The first version read too much: full forecast, every calendar item, traffic, news. It was exhausting before coffee, so I cut it to three things and a hard 20-second cap. The lesson generalizes: automations that talk should say less than you think.

Voice: the manual override, not the main interface

People assume voice is the centerpiece of a smart home. In mine, it is the escape hatch: how I override the automation when it is wrong, or do the rare thing the routines do not cover. It is the manual control, not the system.

Why I demoted voice

I tracked my own voice commands for a month. 71% were things a good automation should have handled without being asked: turning on a light I had just walked under, setting a temperature the schedule should have known. Every one was a small failure of the automated system, not a feature of voice. The remaining 29% were genuine ad-hoc requests, like “set a 12-minute timer” or “turn off the bedroom fan.” Those are what voice is actually good at.

So my design rule is: if I find myself using voice to do the same thing at the same time every day, that is a bug. It means an automation should exist and does not.

Local voice and the privacy line

I moved to a locally-processed voice setup for the common commands, both for speed and because I am not thrilled about an always-on microphone streaming my kitchen to the cloud. Local processing made simple commands faster (a light toggle responds in well under a second) and meant routine commands never leave the house. If privacy matters to you, look for voice hardware that can run offline for the basics, which is both faster and easier to defend to a skeptical housemate than a device that phones home for every “turn off the lights.”

The case for local-first, learned the hard way

I want to make the architectural argument explicitly, because it underpins everything above and is the decision I would most strongly urge a beginner to copy.

The day the internet went down

Our internet was out for six hours last spring after a construction crew cut a line up the street. During those six hours, a cloud-dependent smart home becomes a pile of dumb plastic: lights that only respond to a cloud command do not respond, and the thermostat schedule that lives on someone else’s server stops adjusting.

My house barely noticed. The hub is local, the radios are local, the automations run on hardware in my own closet. Motion still triggered lights and the night routine still locked the doors and verified them. The only thing I lost was the weather in the morning brief, which genuinely needs the internet, and losing the weather is survivable.

That day converted me permanently. A home automation that depends on a vendor’s cloud depends on that vendor’s uptime, business model, and decision not to discontinue the product. I have had two cloud-only devices bricked by companies sunsetting their servers, fine hardware that became e-waste because a server somewhere got turned off.

Local vs cloud, the honest tradeoff

The honest cost of local-first is the upfront effort: you set up a hub, learn a bit, occasionally read documentation. In exchange you get a house that does not stop working because of a problem you cannot see or fix. After two years, I consider that trade obviously correct.

What it all actually cost

Let me be concrete about money, because vague “smart home” articles love to skip this. Here is roughly what the load-bearing parts cost me over two years, not counting the devices I bought, regretted, and abandoned.

That is roughly $785 over two years for the part of the system I would actually rebuild. The savings (gas setbacks, killed standby loads, one prevented space-heater incident I refuse to price) have, by my own conservative accounting, already exceeded that. Your mileage depends heavily on your energy rates and how leaky your old habits were.

The money I wasted, so you don’t have to

For honesty’s sake, here is the regret pile: a cloud-only thermostat that got worse after a firmware update and lost a feature I bought it for; a “smart” garage opener that needed its own app and cloud and would not talk to anything; a drawer of WiFi bulbs that hammered my router and died young; and about $200 of single-purpose gadgets that did one cute thing and then sat unused.

The pattern in every regret: it was cloud-locked, single-vendor, or solved a problem I did not have. The pattern in every keeper: it spoke a local, open protocol and slotted into a routine I used daily. Buy for the routine, not the gadget.

The sensors I added later that quietly changed everything

The four routines above are the skeleton. But somewhere in the second year, a handful of sensor additions moved the house from “automated” to “anticipatory.” They are cheap, and they fix problems you do not realize you have until they are gone.

Motion sensors, and the timeout war

My first motion-triggered lights were maddening. They would shut off while I was standing perfectly still reading a recipe, plunging the kitchen into darkness mid-chop. The default 60-second timeout assumed I was always moving, and I am not.

The fix was longer timeouts in low-activity rooms and, crucially, mmWave presence sensors in the two rooms where I sit still. Unlike a passive infrared sensor that only sees movement, an mmWave sensor detects that a warm body is present even when motionless, and the kitchen-goes-dark problem vanished the day I installed one. The tradeoff is that they are fussier to tune; after an evening adjusting sensitivity and distance gates, false triggers dropped to maybe one a week.

For rooms where people sit and read, work, or watch TV, a good mmWave sensor stops the lights betraying you mid-task. For hallways and closets, cheaper passive infrared is preferable, because you want the lights off the instant the space is empty.

The leak sensor that earned its keep in one night

I almost did not buy water leak sensors. They felt like paranoia hardware. Then one ran in the basement at 2:14am and a push notification woke me to a water heater weeping from a fitting. I caught it at a quarter-inch of standing water instead of, by my plumber’s estimate, the several inches it would have reached by morning. That one $15 sensor very plausibly saved me a four-figure repair, and it is the single best return-on-investment device in the house. I now run six, under every sink and appliance that could leak.

My full sensor inventory, ranked by value

Here is the complete sensor list with my honest verdict on each, after living with all of them daily.

The pattern that emerges every time I look at this table: the cheapest sensors deliver the most value, and the expensive flashy devices deliver the least. A drawer of $12 sensors does more for daily life than any single premium gadget I own.

Where these automations still break, honestly

I would be doing you a disservice if I made this sound seamless. Two years in, there are still failure modes I have not fully solved.

Guests confuse the system

Presence detection is built around known phones. A house full of guests whose phones the system does not recognize can confuse the “is anyone home” logic, especially if all the residents step out while guests stay. I have a manual “guest mode” override I trigger by voice, which freezes the away logic for a set window, but it is a patch. The deeper issue is that presence detection answers “are known people here,” not “is anyone here,” and those are different questions.

Batteries die silently, and that is dangerous

Every sensor runs on a battery, and a dead battery is invisible until it causes a failure. The heating disaster that opened this article was, at root, a dead contact-sensor battery the system did not flag loudly enough. I now run a battery-health check that alerts me when any device drops below 20% and escalates again below 10%, and it has caught at least a dozen sensors before they failed. If you build nothing else for maintenance, build a low-battery alert. It is the difference between a managed system and a time bomb.

Firmware updates can break working setups

Twice, a device update changed behavior I depended on. Once a thermostat lost a scheduling feature; once a bulb changed how it reported its color state and broke a scene. This is the dark side of connected devices: a thing that worked yesterday can behave differently today because a vendor pushed code. My defense is to disable automatic firmware updates on the load-bearing devices and update them manually, one at a time, so I can pin a regression to a specific change.

A day in the life, end to end

Let me stitch it together into a single ordinary Tuesday, because the routines do not live in isolation; they hand off to each other across the day.

At 6:40am the bedroom begins its amber sunrise while the furnace lifts the house from its 64-degree overnight setback toward 69. By the time motion in the kitchen confirms someone is up, the lights are already comfortable and the entry speaker delivers its 20-second brief.

Around 8:10, the last person leaves. The door opens, closes, motion goes quiet, and every known phone drops off the home WiFi. After the confirmation window, the house declares itself empty: nine devices power down, the thermostat drops to 62, both doors lock and verify, the garage confirms closed, and a single notification summarizes it. The forgotten space heater is cut at the outlet, 1,420 watts saved.

The house sits dark and quiet and cheap all day. Leak and contact sensors stand guard, and nothing fires, which is exactly right.

At 5:50pm a Bluetooth node near the entry catches an approaching phone and the pre-warm nudges the thermostat back toward comfort. By the time the door opens at 5:58 with arms full of groceries, a press of the entry button brings the lights up to a warm 40% and unlocks the door.

At 11:15pm the night routine begins its slow four-minute fade. The thermostat settles to its sleep setpoint, the doors lock and verify one final time (184 nights running, zero failures reaching me), and the house powers down for the night, having handled four routines and dozens of sensor events without a single human having to remember a single boring task.

That is the whole machine. Unglamorous, reliable, and quietly indispensable.

How to build this yourself, in order

If you are starting from nothing, do not buy the fun stuff first. Build the skeleton in the order that gives you reliability before delight. Here is the sequence I would follow if I had to start over today.

1. Get a local hub. Everything else hangs off this. Resist any device that cannot be controlled locally.
2. Add contact sensors to the doors that matter. Cheap, fast, and they unlock the security routines.
3. Solve presence properly. Layer WiFi presence plus a couple of Bluetooth nodes. Do not trust GPS alone.
4. Build the Leave routine. Thermostat setback, lights and plugs off, locks verified. This is your highest-value automation.
5. Build the Night routine. Same skeleton, gentler, runs once a day, eliminates the unlocked-door risk.
6. Add the Arrive routine. Entry light and comfort recovery on confirmed presence. Keep auto-unlock behind an explicit intent.
7. Add energy-monitoring plugs. Now that things turn off, measure what you saved. The data is motivating.
8. Only now, the Morning routine. Sunrise fade and a short brief. Pure comfort, build it last.
9. Add voice as override. If you are using voice for daily repeated tasks, go back and automate those instead.

Do them in that order and every step makes the house meaningfully better the day you finish it. Do them out of order, building the morning butler before the leave routine, and you will have a delightful house that still lets you leave the deck door unlocked all night.

The reliability rules I’d attach to all of it

A few rules apply to every routine, learned from every failure above:

• Always verify, then retry. A command sent is not a thing done. Read the state back.
• Never declare “empty” on a single signal. Stack presence signals before you cut the heat.
• Put security behind explicit intent. Lights on presence, locks on intent.
• Prefer slow transitions. Fades feel premium and double as gentle signals.
• Keep voice as the exception. Repeated voice commands are bugs disguised as features.
• Measure before and after. Energy logs turn “I think it helped” into “it saved $34 a month.”

The honest verdict after two years

The smart home that lives in magazine spreads is the wrong goal. The smart home worth building is boring on purpose. It locks the door you forgot, lowers the heat in the house you left, brings the lights up so you do not fumble with groceries in the dark, and reads you three things in the morning before politely shutting up.

The expensive lesson, the one that started with a $9 sensor dying and 41 hours of wasted heat, is that reliability is the entire product. A flashy automation that works 96% of the time is worse than a plain one that works 100%, because it teaches you to stop trusting your own house. Everything I kept, I kept because it never lies to me.

If you take one thing from this, take the order of operations. Skeleton before decoration. Verify before trust. Local before cloud. Routines before gadgets.

Your next action

Pick the single routine that would remove the most worry from your day, almost always the Leave or Night routine, and build only that one this week. Buy a local hub, two contact sensors for your most-forgotten doors, and nothing else yet. Get it firing reliably, watch the confirmation notifications for a week, and only then decide what to add next. The house that quietly handles one thing perfectly will teach you more than a closet full of half-configured gadgets ever could.