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 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
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
| Gear | Purpose | Buy |
|---|---|---|
| HiLetgo ESP8266 NodeMCU board (3 pack) | Wi-Fi microcontroller that runs Tasmota | Amazon |
| SSD1306 OLED screen | Status display for the sprinkler state | Amazon |
| Inkbird SSR-40DA solid state relay | Switches the 24 VAC sprinkler valve | Amazon |
| BME280 sensor | Temperature, humidity and pressure | Amazon |
| 24 VAC power supply | Powers the sprinkler valve | Amazon |
Lights, switches and plugs
| Gear | Purpose | Buy |
|---|---|---|
| Martin Jerry smart dimmer switch (Tasmota pre-flashed) | Wall light switch that runs Tasmota out of the box | Amazon |
| Martin Jerry humidity fan switch | Runs the bathroom fan when humidity gets too high | Amazon |
| Sonoff S31 smart plug | Power watchdog for the cable modem | Amazon |
| Serial-to-USB adapter | Connects an ESP8266 to your PC for flashing Tasmota | Amazon |
Garage door
| Gear | Purpose | Buy |
|---|---|---|
| Raspberry Pi 3 | Runs Docker and the web API | Amazon |
| SunFounder 2-channel 5V relay module | Simulates the button press to toggle the door | Amazon |
| LiftMaster wired control panel (78LM, replaces the 41A5273-1) | Bypasses the anti-tamper wiring | Amazon |
Around the house
| Gear | Purpose | Buy |
|---|---|---|
| GL.iNet Flint 2 router (GL-MT6000) | Runs OpenWrt and an MQTT broker locally | Amazon |
| Cheap tablet | Mounted on the wall as the dashboard | Amazon |
| Lefant robot vacuum | Cleans the floors | Amazon |
A couple years ago we moved from a home built in 1970 to a relatively much more modern home built in 2001. With this came a number of benefits, such as Cat5 Ethernet drops in several rooms, which have enabled me to grow and expand my home network and smart home goals.
Realistically do people need more than 4 per day? I don’t know. All I know is that when programming the old one I would always feel like “man I just need one more time setting to get this how I want it.”
.jpg)
Cuttle design
Cuttle design
Comments (0) Trackbacks (0) Leave a comment Trackback