Should a home sensor have a physical forget button?

I built a Raspberry Pi workshop assistant that samples a couple of local sensors and keeps a short diagnostic buffer. I’m considering adding a physical “forget” control: cut sensor power immediately, invalidate the buffer, and stop collecting even if the system is frozen. The downside is obvious—one accidental press could destroy the evidence needed to diagnose a flaky sensor or corrupted service.

A GPIO button is easy enough, but a GPIO-triggered shutdown is not the same as electrically disabling every sensor. Abruptly removing power can also risk filesystem corruption. I’m leaning toward a guarded long-press that disables sensors first, then lets the system clear its accessible local buffer. I would document that as deletion, not guaranteed forensic erasure from flash storage.

Would you implement this in hardware, software, or both? Concrete designs and counterarguments welcome.

Both, but with different promises. Hardware should guarantee “the sensors are no longer powered”; software should handle buffer invalidation. Calling either one a complete erase is too strong, especially on flash storage. I’d make the physical control a guarded long-press and expose its state in the local interface.

I’d avoid making the button directly yank power from the Pi. Sensor power isolation plus a service signal gives you a chance to close files cleanly. The failure mode where the forget button corrupts the very system that records its result is not theoretical engineering elegance; it’s just annoying.

The guard may be more important than the mechanism. People understand a red physical switch, but “hold for eight seconds” is easy to forget and hard to discover. I’d use a prominent button, a visible status LED, and a short confirmation window—unless the threat model specifically demands instant action.

The wording matters. “Forget” sounds like universal erasure, while your implementation may only clear the accessible buffer. That distinction belongs on the device, not buried in documentation. A trustworthy control can still be useful without making a claim the storage medium cannot support.

Software-only is sufficient for my low-risk builds, because I want the system to stop collection without losing its operational state. For anything physically sensitive, I’d add a separate sensor-power cutoff. Keeping the two actions distinct seems cleaner than pretending one button can solve collection, deletion, and shutdown simultaneously.

Counterargument: a purge control can create false confidence. Someone presses it, sees a light go out, and assumes every trace is gone. I’d still build the local stop function, but label it “stop and clear buffer,” publish the storage assumptions, and reserve “erase” for a much narrower claim.