Should a home gadget still work when the cloud disappears?

I built a small Pi Zero 2 W sensor with a BME280, an Inky wHAT e-ink display, and a Mosquitto broker on the same home network. The display shows temperature and humidity, and the broker is deliberately local. During a brief internet outage, the numbers kept updating, which felt more useful than I expected.

The awkward part is authentication and recovery. If the Wi-Fi changes, or I forget the broker password, remote access is easier than explaining to future-me how to find the Pi, inspect NetworkManager, restore the connection, and recreate the client settings. Offline resilience is not free; it creates a maintenance burden in documentation and local protocols.

I’m leaning toward “meaningfully useful without cloud or auth,” even if that makes setup less polished. Do other makers design for graceful offline operation, or consider cloud dependence acceptable for the convenience?

I’d separate cloud failure from authentication failure. A local broker can keep the sensor path alive, but if every client needs a remote identity provider, you have recreated the outage locally. The minimum test should be: unplug WAN, reboot the Pi, and still read the last good value.

For a display-only device, offline operation seems like the reasonable default. It does not need to solve sync, history, or remote control during an outage; it just needs to show the latest locally available reading. Scope matters more than ideology here.

I’m wary of treating “no authentication” as resilience. Keep local credentials, document where they live, and make recovery possible without exposing the broker to the internet. Convenience often quietly turns into a much larger attack surface.

The customer version of this is less philosophical: people tolerate cloud dependence until the one day they need the device most. I’d pay a setup-cost premium for local basics, while keeping cloud access as an optional convenience layer.

Your outage observation establishes that this particular local path continued working under those conditions. It does not establish that every MQTT setup will. That distinction is important, but your test is still a useful acceptance criterion for the project.

The documentation is part of the product, whether we like it or not. I’d put a laminated card next to the Pi: hostname, broker address, service restart command, and recovery path. If that feels excessive, the design probably is not maintainable.

There’s also a human-factors win in the e-ink screen. Someone can glance at it without opening an app or remembering which account owns the dashboard. Offline usefulness is visible; the cloud dependency usually is not until it breaks.

A thermometer that needs a login is already losing the plot. Remote graphs and notifications can be cloud features. The number on the wall should not require a subscription, a token refresh, and favorable weather for the provider’s servers.

I’d accept cloud dependence for a hobby gadget if the failure is honest and reversible. The problem is not needing the service; it is having no local mode, export path, or documented reset when the service changes.

This is where “works offline” becomes an operational promise. Write down the recovery steps while the build is fresh, then ask someone else to follow them. If they cannot, your resilience mostly exists in your memory.