Smart home devices should work without the internet

AI;DR: I wrote the first draft, AI helped me edit and rewrite it, and I made the final pass. The rules, setups, and talks are my own.

TLDR; If a light switch in my house needs someone else’s server to work, it doesn’t go in. That has been rule one for ten years of home automation, and the other rules I follow grew out of it. Below are the rules and why I keep them, followed by both talks I’ve given on this, slide by slide.

The cloud is the weak link

Hardware you pay for once shouldn’t stop working because a company changed its plans. It happens anyway. My Nest integration worked until Google broke the API. A Samsung fridge shows a TLS certificate error on its own screen. A Camp Chef grill controller needs Wi-Fi to tell you the temperature.

I still use cloud services where they help, including Alexa and a handful of AWS services. They’re add-ons, though. The logic that runs the house lives on hardware I own: Tasmota firmware on ESP boards, an MQTT broker, and Node-RED on a Raspberry Pi. When the internet goes out, the house keeps working.

The rules

These came out of the first talk and got restated in the second:

1. No internet, no problem. Anything core to the house has to work with the internet unplugged.
2. Don’t remove the old way while introducing the new one. A wall switch taped in the on position so a smart bulb keeps power is what happens when you skip this.
3. Be agile. Rooms get used differently and people move in and out, so everything has to be cheap to change.
4. Check your automations. I once had four scheduled triggers all pointing at the same garden pump.
5. Exceptions must be exceptional. I can break a rule, but only for a reason I’d still defend six months later.

These came after year five, once more people lived in the house:

6. A cloud device needs an API with logs, or it doesn’t get installed. I won’t run a black box in my house.
7. Configuration lives in one place instead of five vendor apps.
8. People get more than one way in: an app, Alexa, a QR code, or an NFC tag.
9. Any sequence of actions that keeps repeating becomes a routine.
10. Devices talk pub/sub over MQTT instead of point to point.
11. No batteries unless the device can go a year or more between changes. A dead battery on a door sensor at 2am is how you end up outside in the cold.

The build I get asked about most is the Tasmota sprinkler controller. It runs on these rules and shows up in both talks, along with the garage door automation that has been running just as long.

Talk One: Home Automation

Nobody needs any of this. I do it because I like building things that work in the background, and every automation is a small puzzle with a real payoff when it’s solved.

This is the backdrop for the whole talk. Phones, laptops, tablets, thermostats, and locks all talk to clouds that may or may not be up when you need them. Connectivity is fine. Just know what you’re opting into before you plug it in.

Most people start here with a thermostat, a plug, and a lock, and that’s a fine place to start. Each one ships with its own app and its own account.

Every device you add lands somewhere on this triangle. A cloud camera is cheap and convenient, and you pay for it with privacy. A switch I flash myself takes more setup time, and in return I can integrate it with anything. I figure out where a device lands before it goes in the cart.

Someone (often me) automates a light and then has to tape the wall switch on so the smart bulb always has power. If you’ve ever walked into a room and the switch did nothing, this is why.

The better fix for the taped switch is an in-wall Wi-Fi switch like this one. The wall switch keeps working the normal way and I still get a hook to automate. It takes more work to install than a smart plug, but nobody has to retrain their hand.

Rule one, and the one I don’t bend on. If the internet goes down, my lights still turn on.

Home automation is never done. Rooms get used differently, people move in and out, and new devices show up. Whatever you build has to be cheap to change.

The garage cooling flow starts from a manual trigger and checks whether the door is closed. From there it opens the door, waits, flips the fan on, or sends a notification if cooling is already running. It’s a small flow and it has kept the garage from baking more than once.

The door sensor and reed switch both report into a transform step that sets a global garage-closed flag and logs to Grafana. Below that is the chart from a few real days: 21 opens, with spikes showing when each one happened. Most people skip this part, and it’s the part that tells me whether I left the garage open without opening an app.

Four scheduled triggers all point at the same pump node. It’s easy to end up with five automations fighting over one device. Every so often I look at the flow and ask whether they still make sense together.

I’ve broken every one of these rules plenty of times. They’re guidelines.

Here are three ways to say “event in, action out.” Node-RED is my main tool. Alexa routines and IFTTT-style community applets cover the cases where I don’t want to build something from scratch.

MQTT is what keeps the pieces decoupled. The temperature sensor publishes and doesn’t care who’s listening. A phone and a backend system can both subscribe to the same topic, and the sensor needs no extra logic. The sprinkler controller in the Tasmota post is built on the same pattern.

The Sonoff Mini is small enough to hide inside the fireplace’s existing wiring. The flow lets either the dashboard or Alexa flip it. It makes the “memorable automations” list later because a fake fire you can turn on by voice makes a good party trick.

The whole sprinkler build fits on one slide: the relay and ESP module in the enclosure, the 3D board render, the Tasmota UI with BME280 sensor readings, the Node-RED schedule feeding the pump, and the finished PCB layout. The sprinkler post has the full writeup, including why I picked Tasmota over custom firmware.

The recap slide is the whole talk in five lines. I break the first one (don’t introduce a new way while removing the old way) carelessly more often than the others, and I regret it every time. The last one keeps the other four honest. “I was in a hurry” doesn’t count as exceptional.

The highlight reel: lights that blink when my heart rate is too low, sprinklers that skip watering if rain is coming, a garage that opens when my phone shows up but the car doesn’t, light and water for an indoor garden, an air quality sensor that kicks on a fan, backyard landscaping lighting, living room LED strips that shift between warm and cool, washer and dryer notifications based on power usage instead of a vendor app, 3D printer status lights, AC and heating monitoring, and a pile of AWS services (Alexa, Polly, S3, IoT, Cognito) stitched together along the way. The Nest integration gets a eulogy: “until Google broke the API.” Every home automation person writes that sentence eventually.

That was talk one. Almost everything on the “memorable automations” slide later picked up a new failure mode or got replaced, which is why there’s a sequel.

Talk Two: Home Automation, The Sequel

Enough time passed between the two talks that I had a different list of problems to talk about.

More devices means more decisions made without me in the loop. That’s a little unsettling, though mostly harmless.

First, a quick pass back through what talk one covered.

Same slide as before, with more icons on it now.

Everyone else is living this too. A fridge’s smart display throws a TLS certificate error. A grill controller needs Wi-Fi to tell you the temperature. Someone taped a note to a pole about an internet-connected printer they forgot to log out of. These are real devices.

These are the must and should rules from talk one with slightly tighter wording. I restated them because part of the audience hadn’t seen the first talk.

The rules stayed the same. The conditions they had to survive got harder.

A lot of my original setup assumed one person lived in the house. When that stopped being true, I had to patch a single-user system into a multi-user one, and the next few slides are what that looked like.

More people means more foot traffic and more physical keys to manage. Longer trips away raised the stakes on anything that could fail without anyone noticing. A water flooding scare is what finally got me to take leak and presence detection seriously.

Same joke with a new rule set. The first rules came after year one. These came after year five.

These are rules 6 through 11 at the top of this post. I wrote them after the house went from one person to several.

Next up are the concrete builds, which is my favorite part of any talk.

A motor-and-PVC-pipe rig for outdoor lighting, a UV grow light clipped onto a houseplant, and a UV strip under the cabinets for passive sanitizing. Each one solves a small, specific problem, and that’s where home automation earns its keep.

Same sprinkler slide as talk one. It’s back because it’s one of the few builds that never needed a rewrite.

A sensor that sits on a credenza, a robot vacuum that does the floors without anyone asking, and an AirGradient kit I assembled from a CO2 sensor, a particulate sensor, and a microcontroller, with its own small dashboard. The air quality kit has given me the most peace of mind of anything here.

This dashboard has replaced more apps in the house than anything else. It has a garage door toggle, a side door unlock, a front lock toggle, all lights on or off, brightness sliders, a coffee bar color picker, and a warm-to-cool slider for the living room. It all runs on one cheap tablet mounted next to the thermostat, so nobody has to dig through five apps.

The ambient lighting behind the TV is tied into the same automation system instead of having its own remote. It’s a small change with a big quality-of-life payoff.

Smart locks came out of the “more people, more keys” problem from a few slides back. The newer lock takes a password, the app, a keycard, or a mechanical key, so everyone in the house can use whatever they’re comfortable with.

The next few slides are the parts bin, for anyone who wants to build this themselves.

The ESP32 D1 mini handles anything custom. The smart plug is the off-the-shelf shortcut when I don’t need custom. The Pi 4 runs Node-RED and Grafana.

LED strips for ambient lighting, power transistors for higher-current loads, and small relay modules so a microcontroller can switch mains voltage safely.

The rest of the bin: a resistor assortment, color-coded wire so I can trace a circuit later, and a capacitor kit for smoothing and timing.

Node-RED handles flow logic and Grafana gives me visibility. Tasmota is the firmware on anything I flash myself, Telegram sends notifications, and Python or JavaScript fills in the glue code that doesn’t fit cleanly into a flow.

Here’s the garage flow today. The door sensor and reed switch feed a transform into Grafana and a global closed state. Toggle nodes publish straight to Tasmota command topics. Notifications fork to a Telegram sender and an audio chime, and a light-on counter resets at midnight. The editor tabs across the top (Lights, Sensors, Garage, Sprinkler, NFC Tags, Door Lock Security) show how much has grown since the single garage cooling flow in talk one.

I check this dashboard when I want to know if everything is okay. Humidity, temperature, dew point, pressure, and gas readings are on one side, and energy usage, door opens, and on-status history are on the other. I built it because I got tired of guessing.

Dashboards and Grafana panels work for me. Everyone else in the house just wants the light on.

Here’s the “multiple ways to interact” rule in hardware. The wall tablet is for whoever is standing near it. NFC tags and a QR code give a tap-to-trigger shortcut, and the Echo Dot is for anyone who would rather talk to the house.

Last section: the tools I use to build and debug all of the above.

A soldering iron for permanent connections, a 3D printer for enclosures and brackets you can’t buy, a multimeter for when something isn’t working, and a precision screwdriver kit for devices the manufacturer didn’t want opened.

That’s both talks, ten-plus years apart. The rules barely changed between them, while the list of problems they had to handle kept growing.

A third talk is coming, and this one is built around agentic use cases. The same rules still apply when an AI agent is the one flipping the switches, and I expect a few new ones once it is.

What readers told me

When I shared the “no internet, no problem” rule on LinkedIn, I asked for the most pointless internet dependency people had found in a device. Dozens of people answered, and the answers were better than the post. Here is what stood out.

Everyone has one

Most examples were basic functions locked behind an app, an account, or a server:

• A fridge whose temperature can’t be changed because of a bug in the manufacturer’s phone app.
• A TV that can’t even switch inputs when the internet is down, and another that has to be signed in before it works as a plain HDMI monitor. One reader’s older smart TV has dead apps but still works as a regular TV, which is how a device should fail.
• A heating system whose app doesn’t work from the local network.
• A kitchen vent and a dishwasher that need the internet even when you control them from Home Assistant.
• A smart plug that can’t be set up on an isolated network.
• Noise-cancelling headphones that search for a Bluetooth device forever, so you can’t just turn on the noise cancelling.
• Synthesizers and MIDI keyboards that need a cloud login for first use or firmware updates.
• A meat thermometer that only worked through its app and stopped working when the company went out of business.

The meat thermometer bothers me most. The hardware outlived the company, and it stopped working anyway.

Rules readers added

• Offline first, online as a bonus. A device should work on its own and use the internet for extras. Connectivity is great. Depending on it is the problem.
• Treat every third-party dependency as a risk. APIs change, so plan a local fallback or a clear degraded mode. One mobile developer put it this way: the core action works offline or from cache, and only the nice-to-have extras wait for a connection.
• Decide what must work offline. My answer: turning things on and off, temperature and safety controls, and anything a guest has to use without learning an app. As one reader said, if a visitor can’t turn something on or adjust the temperature without an app account, the design has failed.
• Clean up when you throw things away. Remove a connected printer from your account first. An abandoned connected device can be an easy way in for an attacker.

Practical tips

• Use local protocols. One reader recommends Zigbee and Z-Wave over Wi-Fi: fewer problems, and a switch that doesn’t need the cloud tends to behave the same year after year. Another uses Zigbee for the smart plugs that can’t be set up without internet.
• Old Nest thermostats have a way out. No Longer Evil is open source firmware for Nest Gen 1 and Gen 2 thermostats.
• Smart TVs can be tamed. Reset the TV and never connect it to the network, and the input problem goes away.
• Remote access is the cost of staying local. I use Tailscale on the router and keep the individual devices off the tailnet. One reader ran OpenVPN on OpenWrt, which worked but felt clunky, and is now trying Tailscale.
• There’s a gap to fill. One reader said they would happily pay for a pre-built, open “works with everything” Raspberry Pi image with MQTT. DietPi and OpenWrt come close and have a small footprint, but you need some understanding to get going.
• Right to repair is the bigger fight. Readers pointed to the right-to-repair movement and groups like the FULU Foundation, which work to keep companies from locking you out of what you bought.

Counterpoints

Connectivity isn’t the villain. A connected meat thermometer lets you watch the game while the steak cooks. The same reader also had an oven decide to update its software in the middle of cooking, which is the other side of it. One reader pointed out the business model behind all of this: companies would rather sell you a service than a product. Another skips connected appliances entirely and keeps only computers and phones online.

Devices I’ve used

(This section has Amazon affiliate links. If you buy through them, I may earn a small commission at no extra cost to you.)

These are the parts from my home automation builds, grouped by project.

Sprinkler controller

Lights, switches and plugs

Garage door

Around the house