Atlas 03 of 07
securecam
A camera that recognises faces at a door, and the reasoning about why the lock stays disabled.
- 540
- Tests
- 31 / 32
- Acceptance criteria met
- 0
- Unlocks sent
What it does
A doorway camera that detects motion, recognises enrolled faces, and turns what it sees into a notification worth reading. The door-lock integration is written and deliberately disabled. The reasoning about why is the more useful half of the project.
- Watches without recording everything
- Motion opens a short window; recognition runs inside it. A camera that records continuously is a different and much worse object to own.
- Recognises enrolled faces
- Detection and embedding on-device, matched against a local enrollment set. Frames never leave the recogniser: an observation carries a name and a score, never pixels.
- Decides when to interrupt you
- Debounce, cooldown and severity, so one person arriving is one notification rather than forty. Most of the engineering is in *not* sending things.
- Refuses to open the door
- The lock path exists, is tested, and is off. Face recognition without anti-spoofing is defeated by a photograph, and a door is not the place to find that out.
What it runs on
A Pi 4 in the official case, the camera loose on its ribbon. Drag to turn it. Switch to the planned case to see what changes.
- Board Raspberry Pi 4, 4 GB Raspberry Pi 4, 4 GB The CPU is the binding constraint, so faces are found on a 640 × 480 frame and recognition runs only inside a motion window.
- Camera Camera Module 3 NoIR Camera Module 3 NoIR No infrared filter, so it sees at night. Day and night get separate thresholds and separate enrolments.
- Cable 15-pin camera ribbon 15-pin camera ribbon The camera has exactly one owner: one process holds the sensor and publishes every stream from it.
- Enclosure Official Pi 4 case Aluminium heatsink case Planned Sustained recognition heats the board. A case that is itself a heatsink sheds that heat instead of holding it.
- Cooling Official case fan Two fans on the heatsink Planned A board that cannot shed heat throttles, and a throttled board misses the frames a vote needs.
Demo
Play the visit
Under two seconds from first motion to one notification. Pick who comes to the door, then play it or drag along the timeline. One of them is a photograph.
Drawn, not recorded. The scores are made up to show the rule.
Who comes to the door
Samples: every third frame
Sampling starts when a face is found.
What happens
How it works
Day and night
Motion detection, face recognition, and notifications, on a Pi at a door. Runs day and night, which means two sets of thresholds and separate enrolments under infrared, because recognition accuracy drops on monochrome footage.
The decision worth reading
The door lock is implemented, tested, and disabled by default. The software works. It stays off because a camera that opens a door can be defeated by a photograph, and until there is an anti-spoofing answer the honest posture is that this is a notifier that happens to have an actuator attached.
That is not caution for its own sake. The failure mode of a face-recognition lock is not “it does not open”. It is “it opens for the wrong person”, silently, once.
Testing
540 passing
The whole pipeline runs on a laptop against a webcam or a video file, so recognition logic is tested without a Pi. The parts that cannot be faked are listed as unverified rather than assumed.
What the tests defend
- Recognition is decided by temporal voting rather than a single frame: one lucky frame must never decide an identity. The tests describe the disagreement cases directly.
- Every unlock and every denial is audited. The tests that matter most are the ones for the requests that were refused.
Built with
- Vision
- OpenCVYuNetSFacepicamera2
- Service
- PythonFastAPIasyncioSQLite
- Hardware
- Raspberry Pi 4Camera Module 3 NoIR