Should a workshop gadget have a physical maintenance mode?

I built a Raspberry Pi workshop air-quality monitor with an e-ink display and a small local web dashboard. The unresolved part is what happens when it is installed behind a shelf and I inevitably need to repair or reconfigure it.

I’m leaning toward a physical maintenance trigger: hold a button or fit a jumper during boot, then get diagnostics and an option to clear or rotate the Wi-Fi credentials. But I don’t want to casually expose a UART login shell. Raspberry Pi treats the UART hardware and serial console separately, and the latter can provide a login shell. Network connection profiles may also contain secrets.

So my current idea is a deliberately awkward recovery mode: physical presence, limited diagnostics, one-time authorization, an audit entry, and automatic return to locked operation. For a personal workshop that seems more useful than maximum lockdown. Would you include that path, or disable debugging interfaces once deployed?

I would include recovery, but not as “jumper equals root shell.” Physical access is already a meaningful privilege, and a UART login can expose more than diagnostics. Make the jumper unlock a recovery application that requires a one-time code, then keep the serial console disabled by default.

The distinction between UART and the serial console is the important bit. I’d leave UART available for a controlled peripheral or diagnostic channel and keep the login shell off. Debug output plus a documented recovery image gets you most of the value without making the header a permanent back door.

I’d document the exact maintenance procedure as part of the device, not just in a repository. NIST’s lifecycle guidance is sensible here: restrict access, explain maintenance, and provide a way to restore an authorized secure configuration. “There is a button somewhere” is not a procedure.

A device that cannot be repaired is just e-waste with a nicer enclosure. Give me the jumper. Just don’t label it “press for magic” and assume nobody will find it.

Clearing Wi-Fi credentials deserves careful wording. It may remove the active profile, but it is not automatically secure erasure of every copy in logs, backups, history, or snapshots. I’d prefer credential rotation plus a clear indication that recovery mode was entered.

The physical action is also a useful consent boundary. A button held during boot communicates “someone is standing here and intends to maintain this device,” unlike a dashboard toggle that could be triggered remotely. The interface should make the consequences obvious before it wipes or rotates anything.

For this kind of monitor, I’d design for offline recovery first. A local diagnostic page over a temporary maintenance network, with no normal Wi-Fi credentials loaded, may be easier to explain than UART commands. UART can remain the last-resort path for when the network stack is broken.

Timeouts are good, but don’t mistake them for authentication. If the mode stays enabled until reboot, someone can simply keep power applied. I’d require the physical trigger on every entry and make the privileged operation one-shot.

Think about the future owner, even if the current owner is you. Six months later, the person holding the device will remember “there’s a reset somewhere,” not the architecture. A visible maintenance label and a short recovery card could prevent more trouble than another clever safeguard.

I’m less worried about the workshop scenario than the precedent. Hobby projects get copied, installed in offices, and forgotten. If the pattern is “physical access means unrestricted shell,” that habit travels badly. Build the safer default now, even if the first deployment is low-risk.

Add a maintenance indicator to the e-ink screen and log the last entry time. Support problems become much easier when the device can say “recovery mode active” instead of appearing dead. Also write down how to exit it; operational details beat elegant circuitry.

One implementation caution: the exact UART routing depends on the Raspberry Pi model and configuration. I would avoid documentation that says “connect to these pins” universally. The broader principle is solid, but the hardware instructions need a model-specific check.

In a shared or public installation I would lock this down more aggressively. The threat model changes when “physical access” includes contractors, visitors, or a stolen device. For a private bench monitor, recoverability wins; for deployed equipment, document who is authorized and how that is verified.

My compromise would be: physical trigger enables read-only diagnostics immediately, while credential changes require a separate one-time authorization step. That preserves experimentation and fault-finding without making the most sensitive action the easiest one.