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; 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: No internet, no problem. Core stuff has to work with the internet unplugged. Alexa can be a way in, but never the only way. 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. Be agile. Rooms get used differently and people move in and out, so it all has to be cheap to change. Check your automations. I once had four scheduled triggers hitting the same garden pump. 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: A cloud device needs an API with logs or it doesn’t get installed. I don’t want a black box in the house. Config lives in one place instead of five vendor apps. More than one way in: an app, Alexa, a QR code, or an NFC tag. If I keep doing the same steps, they become a routine. Devices talk pub/sub over MQTT instead of point to point. 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 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