Smart home devices should work without the internet — Do Code That Matters

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; Nothing core in my house depends on a vendor’s server. If the internet goes down, the house keeps running. That’s been rule one for about ten years, and my other rules came out of it. This post has the rules, then both talks I’ve given on home automation, slide by slide.

Why local

My Nest integration worked until Google broke the API. That’s the failure I plan around now. The talks have a few more: a Samsung fridge showing a TLS certificate error on its own screen, and a Camp Chef grill controller that needs Wi-Fi to show you the temperature.

Everything that matters runs on hardware I own. That’s Tasmota on ESP boards, an MQTT broker, and Node-RED on a Raspberry Pi. I do use some cloud services, mostly Alexa and a few AWS ones. Alexa is just another way to flip a switch. If it’s down, the wall switches and the wall dashboard still work.

The rules

From the first talk, restated in the second:

1. No internet, no problem. Core stuff has to work with the internet unplugged. Alexa can be a way in, but never the only way.
2. Don’t remove the old way while adding the new one. If someone tapes a wall switch on so a smart bulb keeps power, I skipped this rule.
3. Be agile. Rooms get used differently and people move in and out, so it all has to be cheap to change.
4. Check your automations. I once had four scheduled triggers hitting the same garden pump.
5. Exceptions must be exceptional. I can break a rule, but only for a reason I’d still agree with six months later.

Added 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 don’t want a black box in the house.
7. Config lives in one place instead of five vendor apps.
8. More than one way in: an app, Alexa, a QR code, or an NFC tag.
9. If I keep doing the same steps, they become a routine.
10. Devices talk pub/sub over MQTT instead of point to point.
11. No batteries unless they last a year or more between changes. Nobody wants to swap a door sensor battery at 2am.

The build I get asked about most is the Tasmota sprinkler controller. It’s in both talks, and so is the garage door setup, which has been running about as long.

Talk One: Home Automation

Nobody needs any of this. I like building things that just work in the background, and each automation is a small puzzle.

Everything talks to a cloud now: phones, laptops, thermostats, locks. Those clouds may or may not be up when you need them, so know what you’re signing up for before you plug something in.

Most people start here: a thermostat, a plug, a lock. Each has its own app and account.

Every device lands somewhere on this triangle. A cloud camera is cheap and easy, and it costs you privacy. A switch I flash myself takes longer to set up, but I can hook it into anything. I figure out where a device lands before I buy it.

Someone (often me) automates a light, then has to tape the wall switch on so the smart bulb keeps power. If a switch in a room ever did nothing, this is why.

The better fix is an in-wall Wi-Fi switch. The switch still works like a normal switch and I can still automate it. It’s more work to install than a smart plug, but nobody has to change their habits.

Rule one: if the internet goes down, my lights still turn on.

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

The garage cooling flow starts from a manual trigger and checks if the door is closed. Then it opens the door, waits, and turns on the fan. If cooling is already running, it just sends a notification. Small flow, but 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. It’s easy to skip reporting/alerting. This can alert me if the garage was left open, which is useful when I accidentally leave it open.

Four scheduled triggers all hit the same pump. It’s easy to end up with automations fighting over one device, so every so often I check whether they still make sense together.

I’ve broken all of these plenty of times, so they’re more like guidelines.

Three ways to do “event in, action out.” Node-RED is my main tool. Alexa routines and IFTTT-style applets cover the stuff I don’t want to build myself.

MQTT keeps things decoupled. The temperature sensor publishes and doesn’t care who’s listening, so a phone and a backend can both subscribe without the sensor doing anything extra. The sprinkler controller in the Tasmota post works the same way.

A Sonoff Mini fits inside the fireplace wiring, and the dashboard or Alexa can flip it. A fake fire you can turn on by voice is a good party trick.

The whole sprinkler build: 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. It’s a bit hacky but I love it :D

The whole talk in five lines. The one I break most is the first, don’t introduce a new way while removing the old one, and I regret it every time. The last one stops me from breaking the others for no good reason. “I was in a hurry” doesn’t count.

That was talk one. Most of the “memorable automations” later broke in some new way or got replaced, so there’s a sequel.

Talk Two: Home Automation, The Sequel

Enough time passed between the talks that I had a new list of problems.

More devices means more decisions made without me. It’s a little unsettling but mostly harmless.

Same slide as before, with more icons.

Everyone else is dealing with this too: a fridge showing a TLS certificate error, a grill controller that needs Wi-Fi to show the temperature, and a note taped to a pole about an internet-connected printer someone forgot to log out of.

The same rules from talk one, worded a bit tighter, since part of the audience hadn’t seen the first talk.

The rules stayed the same, but what they had to survive got harder.

My setup assumed one person lived in the house. When that changed, I had to patch a single-user system into a multi-user one. The next few slides are how that went.

More people meant more foot traffic and more keys, and longer trips away meant things could fail with nobody around to notice. A water flooding scare finally got me to take leak and presence detection seriously.

Same joke, new rules. The first set came after year one, these after year five.

These are rules 6 to 11 at the top of the post, written after the house went from one person to several.

Now the builds, my favorite part.

A motor and PVC pipe rig for outdoor lighting, a UV grow light clipped to a houseplant, and a UV strip under the cabinets for sanitizing.

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

A sensor that sits on a credenza, a robot vacuum that runs on its own, and an AirGradient kit I put together from a CO2 sensor, a particulate sensor and a microcontroller, with its own dashboard. The air quality kit gives me the most peace of mind of anything here.

This dashboard replaced more apps than anything else: garage door, side door unlock, front lock, all lights on or off, brightness, a coffee bar color picker, and warm-to-cool for the living room. It’s one cheap tablet next to the thermostat, so nobody digs through five apps.

The lights behind the TV run through the same system instead of their own remote.

The smart locks came out of the more-people-more-keys problem. The newer one takes a password, the app, a keycard or a regular key, so everyone uses what they’re comfortable with.

The parts bin, for anyone who wants to build this.

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 for the logic, Grafana to see what’s happening, Tasmota on anything I flash, Telegram for notifications, and Python or JavaScript for glue code that doesn’t fit in a flow.

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

This is the “is everything okay” dashboard: humidity, temperature, dew point, pressure and gas on one side, and energy use, door opens and on-status history 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.

The “more than one way in” rule in hardware: the wall tablet for whoever is standing there, NFC tags and a QR code to tap, and an Echo Dot for anyone who would rather talk to the house.

The tools I build and debug all of this with.

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, five years apart. The rules barely changed between them, but the list of problems kept growing.

A third talk is coming, built around agentic use cases. The same rules should hold when an AI agent is the one flipping the switches, and I expect to add a few.

What readers told me

I shared the “no internet, no problem” rule on LinkedIn and asked for the most pointless internet dependency people had found in a device. Dozens of people answered. A Hacker News thread added more. Here’s what came back.

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, with the internet for extras. A device should do its main job on its own.
• Treat every third-party dependency as a risk. APIs change, so plan a local fallback or a clear degraded mode. One mobile developer works the same way: the core action works offline or from cache, and only the extras wait for a connection.
• Decide what must work offline. My answer is 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.
• A stricter version of my first two rules: everything core works with the Wi-Fi or the automation server shut down, and smart features never take away the dumb ones. The wall switch should control the light directly and let automation flip it. A switch that only sends a request to the automation fails. That reader says my sprinkler controller fails this bar too. The only sprinkler controller they’d found with a local API and full control on the device itself was RainMachine, which is gone.
• 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, because 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.
• Let an LLM find the firmware. One reader buys the cheapest hardware that does the job, ignores reviews that complain about the app, and asks an LLM for local-first custom firmware once it arrives. That has worked for their switches, a thermostat, an air quality monitor, a thermometer, and a window fan. They’d have paid about 2.5x for hardware that was local out of the box.
• 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 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. Another wanted a hub that ships with the house, like a water heater or a router. Home Assistant sells hub hardware that’s close to that.
• 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 has real uses. 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. One reader pointed out the business model behind all of this: companies would rather sell you a service than a product. Another expects the shift away from internet-connected devices to come from resilience worries rather than consumer complaints, since enough connected homes make a target. And one skips connected appliances entirely, keeping 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