TL;DR
Get the latest gadgets delivered free with Prime
- Fast, free delivery on millions of items
- Prime Video, Amazon Music and more included
- Member-only deals all year
A home automation report argues that essential smart-home functions should keep working when the internet or a vendor service fails. Its author describes a local setup built around Tasmota, MQTT, Node-RED and a Raspberry Pi, while retaining cloud services such as Alexa as optional controls.
A home automation builder says essential smart-home functions should not depend on internet access, describing a household system designed to keep running through an outage or a vendor service failure, a goal shared by many smart home automation devices. In a report published by Do Code That Matters in October 2026, Spencer Kittleson outlines a setup using hardware he owns and local software, with cloud services such as Alexa kept as optional ways to control devices.
Kittleson says the rule has guided his home automation for about 10 years: lights and other core devices should work with the internet unplugged. His system uses devices running Tasmota firmware, an MQTT message broker, Node-RED automation software and a Raspberry Pi, alongside the kind of centralized coordination offered by smart-home hubs. The report describes these as components of his own installation, not as a tested standard or a recommendation from an independent research group.
Cloud services remain part of the setup, but Kittleson says Alexa is one control option, not the only one, as with other Amazon Echo smart-home devices. He says wall switches and a wall dashboard remain available if Alexa is unavailable. His other design rules include keeping a familiar manual control when adding automation, storing configuration centrally, and using more than one way to trigger an action, such as an app, voice command, QR code or NFC tag.
The report gives examples of failures that shaped the approach. Kittleson says a Nest integration stopped working after Google changed its API. He also cites a Samsung refrigerator that displayed a TLS certificate error and a Camp Chef grill controller that required Wi-Fi to show its temperature. These are examples from his experience; the report does not establish how often such failures occur across smart-home products.
Keeping Basic Controls Available
For households, internet dependence can turn a connected device into a less useful one when a broadband connection, cloud platform or vendor integration is unavailable. Kittleson’s approach prioritizes local control and a physical fallback, so a light or switch can remain usable without an online account or remote service.
The trade-off is that local systems can take more effort to build and maintain. Kittleson describes programming and managing his own equipment, checking automations, and reviewing connections between devices. That makes his setup an individual example rather than proof that a locally managed system is simpler, cheaper or more reliable for every household. His central point is narrower: buyers should know which functions stop working if a vendor’s service does.
Products Worth Considering

Jackery Solar Generator 1000 V2 with 100W Solar Panel, 1024Wh LiFePO4 Battery

Samsung Galaxy Tab A9+ 11-Inch Android Tablet, 64GB, Graphite

Bose QuietComfort Headphones (2nd Gen), Wireless Over-Ear Noise-Cancelling Headphones, Black
As an affiliate, we earn on qualifying purchases.
How the Local Setup Works
Kittleson’s report describes a system in which devices can send messages through MQTT without needing to know which other components will use them. Node-RED handles automation flows, while the Raspberry Pi runs local services. One example is a sprinkler controller built around an ESP board running Tasmota; another is a garage setup that checks whether a door is closed before running a fan.
He also emphasizes keeping ordinary controls in place. A smart bulb can become inconvenient if a wall switch is taped in the on position to preserve power to the bulb. Kittleson favors an in-wall smart switch that retains its usual function while allowing automation. He says the system should be inexpensive and flexible enough to change as rooms, occupants and routines change.
The report is based on Kittleson’s talks and personal projects, including a sprinkler controller and garage-door automation. It does not compare products or measure service reliability across manufacturers. Its contribution is a set of practical rules drawn from one household’s experience, including checking for conflicting automations and requiring logs for cloud-connected devices.
“No internet, no problem.”
— Spencer Kittleson, Do Code That Matters
Limits of One Household’s Experience
The report does not provide independent tests of the setup, quantify how often internet or vendor outages disrupt smart-home devices, or compare the cost and maintenance burden of local and cloud-based systems. It also does not specify how every device behaves during a power failure, a local network failure or a failure of the Raspberry Pi that runs key services.
Some examples, including the Nest API change and the refrigerator certificate error, are described by Kittleson from his own experience. The report does not give dates, product models or additional documentation for each incident. It is also not clear whether the same local-control options are available across all product lines or markets. Readers should treat the account as a builder’s principles and examples, not a guarantee that any particular product will work offline.
Check Offline Features Before Buying
Kittleson does not announce a new product, formal standard or planned rollout. The practical next step for readers is to check device documentation and test which functions remain available without internet access, including whether local controls work when an app or vendor service cannot connect.
For people building more involved systems, his report points to ongoing maintenance as part of the work: retain manual controls, review automations for conflicts, and keep configuration and logs accessible. Whether manufacturers will offer broader local operation is not addressed in the report. For now, the account leaves the choice with buyers and builders: decide which functions must remain available and avoid making a cloud service the sole route to them.
Key Questions
What does it mean for a smart-home device to work offline?
It means the device can carry out at least its core functions without connecting to an internet service. The exact functions depend on the product; a device may still need local power or a working home network.
Does Kittleson avoid cloud services entirely?
No. He says he uses Alexa and some AWS services, but keeps them as optional controls rather than the only way to operate essential devices.
What local tools does his system use?
The report names Tasmota firmware on ESP boards, an MQTT broker, Node-RED and a Raspberry Pi. These are components of Kittleson’s own setup, not a single packaged system.
Does the report prove that local smart homes are more reliable?
No. It describes one person’s experience and design rules, but does not provide comparative reliability tests or outage statistics.
What should buyers check before choosing a smart device?
Check which features work without internet access, whether a physical control remains available, and what happens if the manufacturer’s app, cloud service or integration stops working.
Source: docodethatmatters.com
