Why Smart Home Devices Should Work Without the Internet

Every few months another connected gadget reminds its owner who really controls it. A fridge throws a certificate error on its own screen. A grill controller refuses to show the temperature unless it can reach Wi-Fi. A thermostat integration that worked for years stops overnight because the vendor changed its API. Spencer Kittleson, a developer who writes about home automation, has turned these failures into a design principle: if the internet goes down, the house keeps running.

Rule one, and what grew out of it

Kittleson has followed this rule for roughly ten years, and says his other rules grew out of it. Core functions such as lights, locks and the garage door run on hardware he owns: Tasmota firmware on ESP boards, an MQTT broker, and Node-RED running on a Raspberry Pi. Cloud services are still in the mix, mainly Alexa and a few AWS pieces, but they are treated as one more way to flip a switch, never the only way. If Alexa is unreachable, the wall switches and a wall-mounted dashboard still work.

The companion rules are just as practical:

• Do not remove the old way of doing something while adding the new one. If a household member tapes a wall switch on so a smart bulb keeps power, the design has failed.
• Keep everything cheap to change, because rooms and residents change.
• Audit automations periodically. He once found four scheduled triggers all firing the same garden pump.
• Allow exceptions only for reasons you would still agree with six months later.

After more people moved into the house, he added a second batch: cloud devices must offer an API with logs or they are not installed, configuration should live in one place instead of five vendor apps, and there should be several ways in, such as an app, voice, a QR code or an NFC tag. Devices should communicate over MQTT publish/subscribe rather than point to point, and battery-powered gear must last a year or more between changes.

The open-source stack behind it

The tooling is familiar to anyone who follows self-hosted projects. Tasmota replaces vendor firmware on cheap ESP-based switches and relays, exposing them locally. MQTT decouples producers from consumers, so a temperature sensor can publish readings without caring whether a phone, a dashboard or a backend is listening. Node-RED holds the logic, Grafana charts what is happening, and Telegram handles notifications, with Python or JavaScript filling gaps that do not fit in a flow.

The pattern is useful in practice. A garage flow checks whether the door is closed before opening it and running a cooling fan. Door and reed sensors feed a shared "garage closed" flag and log to Grafana, which makes it easy to alert when the door was left open. A single cheap tablet by the thermostat replaced a pile of vendor apps for locks, lights and the garage.

For hardware, he favors in-wall Wi-Fi switches over smart bulbs and plugs. The switch still behaves like a normal switch, so nobody in the house has to change habits, yet it can still be automated.

Why it matters for developers

The argument is less about privacy purism than about failure modes. A cloud API can be deprecated, a company can shut down a service, and a certificate can expire on a device you cannot update. Local control turns those events from outages into non-events. It also keeps the system inspectable: when every device speaks MQTT and logs to a place you control, debugging is possible, which is rarely true of a sealed vendor app.

There are trade-offs, and the author is candid about them. Flashing and wiring your own devices takes longer than buying plug-and-play products, and he describes parts of the setup as a bit hacky. He frames the whole project as a hobby rather than a necessity.

What to watch

The broader industry is moving toward local-first standards, with protocols that let devices talk on the home network without a vendor round trip. Meanwhile, the number of connected appliances keeps growing, and so does the list of ways they can stop working. The practical takeaway for builders is a simple test before buying anything: unplug the router and see what still works. If the answer is "the things that matter," the design is sound.