The Face Detection Door Lock project was upfront about a real limitation: face detection alone unlocks for anyone in frame, not a specific person. This project takes the opposite approach -- an actual credential, verified against enrolled fingerprints, with the ESP32-CAM's job reduced to logging a photo of every access attempt rather than making the access decision itself. That division of labor matters: the R307 fingerprint sensor handles authentication, because that's what it's actually built and tested for, while the camera handles the visual audit trail, which is what it's good at. Neither component is asked to do the other's job.
Hardware Needed
Components
6 itemsNeed these parts? Get this build sheet by email
Parts list with buy links, plus new builds as they're published. By subscribing you agree to our Privacy Policy. Unsubscribe anytime.
Why a Dedicated Sensor, Not a Camera-Based Approach
It's worth explaining this choice directly, since a camera-equipped board might seem like it should handle fingerprint matching visually rather than needing a separate sensor. Optical fingerprint sensors like the R307 don't work by taking a regular photo and comparing images -- they use specialized optics and onboard processing specifically tuned to capture ridge detail at the resolution and consistency fingerprint matching actually requires, then run the matching algorithm on a dedicated onboard chip, not the ESP32 itself. The R307 does its own image capture, minutiae extraction, and template comparison internally, and just reports a match or no-match result back over a serial connection.
This is meaningfully more reliable than attempting fingerprint-like matching through the ESP32-CAM's general-purpose camera, which isn't designed for the close-range, consistent-lighting, high-detail capture that accurate fingerprint matching depends on. The two sensors are doing fundamentally different jobs, which is exactly why this project uses both rather than trying to make one do double duty.
Wiring the Fingerprint Sensor
The R307 communicates over UART -- a serial connection, not I2C or SPI -- which on the ESP32-CAM means sharing pins carefully, since the board's primary hardware serial is already used by the FTDI connection during programming.
| R307 Pin | ESP32-CAM Pin | Notes |
|---|---|---|
| VCC | 5V | Sensor needs 5V, not 3.3V |
| GND | GND | Common ground |
| TX | GPIO 14 (SoftwareSerial RX) | Sensor's TX connects to the ESP32's RX for this connection |
| RX | GPIO 15 (SoftwareSerial TX) | Sensor's RX connects to the ESP32's TX for this connection |
Using SoftwareSerial on GPIOs 14 and 15, rather than the board's hardware UART, keeps the fingerprint sensor's communication separate from the FTDI programming connection -- both can coexist without conflict this way, since the hardware serial stays free for flashing and Serial Monitor debugging.
⚠️ Warning
GPIOs 14 and 15 are shared with the SD card interface on this board. If the project also needs onboard microSD storage in addition to the fingerprint sensor, an external SD module on different pins, or dropping SD storage in favor of logging over WiFi instead, avoids the conflict.
Enrolling a Fingerprint
Before the system can recognize anyone, each authorized fingerprint needs enrolling -- a one-time process per person that captures multiple scans of the same finger to build a reliable template:
The two-scan requirement isn't redundant -- it's how the sensor builds a template robust enough to match reliably later, accounting for the natural slight variation in finger placement and pressure between scans. A single scan produces a template that matches far less reliably in everyday use than one built from two consistent captures.
Verifying a Fingerprint and Triggering the Lock
Once enrolled, checking an incoming fingerprint against stored templates and acting on a match is the core loop of the whole system:
fingerFastSearch() checks the newly scanned print against every stored template and returns which one matched, along with a confidence score -- that ID is exactly what gets baked into the logged photo's filename, so a later review of the access log ties each entry back to a specific enrolled person, not just an anonymous "someone unlocked it" event.
Building an Access Log
Saving a photo per access event, as the code above does, is only half of a genuinely useful log -- the other half is being able to review who accessed the door and when, without pulling the SD card and manually cross-referencing filenames. A simple web endpoint listing recent access events, similar to the file-browser pattern from the Photo Capture guide, makes this reviewable from a browser:
This turns the SD card's raw file listing into an actual reviewable log, browsable from any device on the network -- who accessed the door, when, and a photo confirming it, without needing physical access to the card itself for routine review.
False Accept and False Reject Rates
Worth understanding both failure modes of fingerprint matching before relying on this for anything important, since neither is a "bug" -- they're inherent trade-offs in how the underlying matching threshold is tuned.
| Term | Meaning | Practical impact |
|---|---|---|
| False Reject | An enrolled, legitimate fingerprint fails to match | Frustrating -- try again, usually succeeds on a cleaner placement |
| False Accept | An unenrolled fingerprint incorrectly matches an enrolled template | The security-relevant failure -- rare on the R307 at default settings, but not zero |
The R307's default matching threshold favors a low false accept rate at the cost of an occasional false reject -- meaning it's tuned to be cautious about granting access, which sometimes means a legitimate user needs a second attempt. That's the right trade-off for a security-oriented use case, and it's adjustable in the library if a specific deployment genuinely needs a different balance, though loosening it in the direction of fewer false rejects also increases the false accept rate, which isn't a trade worth making lightly.
Powering the Combined System
Camera, fingerprint sensor, and lock mechanism together draw meaningfully more current than any single component alone, and it's worth budgeting for the combined peak rather than checking each part's draw in isolation:
| Component | Typical draw | Peak scenario |
|---|---|---|
| ESP32-CAM (camera + WiFi active) | 180-250mA | Higher briefly during WiFi connection |
| R307 fingerprint sensor | 60-120mA during an active scan | Brief spike during image capture |
| SG90 servo | 100-250mA while moving | Higher still under mechanical load or if the latch binds |
Summed at worst case, that's comfortably over 500mA during the moment of an actual access event -- servo moving, camera capturing, sensor having just finished its scan, WiFi possibly still active from a recent log upload. A 5V 2A (2000mA) supply gives real headroom above that peak; a 5V 1A supply that seemed adequate testing each component separately can brown out precisely during a real access attempt, which is the worst possible moment for a reliability problem to surface.
Physical Tampering and Backup Access
Every electronic lock, this one included, has a failure mode worth planning for rather than discovering during an actual lockout: what happens if the board loses power, crashes, or the sensor fails entirely. Relying purely on fingerprint access with no fallback means a single point of failure between "system working normally" and "nobody can get in."
A physical key override -- a standard mechanical lock cylinder alongside the electronic mechanism, not replaced by it -- is the simplest and most reliable backup, and it's worth treating as a requirement rather than an optional extra for anything beyond a low-stakes cabinet or drawer. For the servo-latch mechanism specifically, confirming the mechanical design allows manual override (a key-turned cam that can physically retract the latch independent of servo position) before finalizing the mount is worth checking during the build, not after a lockout has already happened.
Enclosure and Sensor Placement
The R307's optical window needs to stay clean and reasonably free of scratches to maintain match quality over time -- mounting it flush in a panel cutout with the window itself exposed, similar to how the camera lens is handled in other projects in this series, works well. Unlike the camera, the fingerprint sensor doesn't need to be weatherproofed if it's mounted at an interior-facing point (inside a door frame rather than fully outdoor-exposed), which is worth considering during placement if avoiding a fully sealed enclosure simplifies the build.
Common Mistakes
Wiring the fingerprint sensor to the same pins the SD card interface uses. GPIOs 14 and 15 are shared -- if both SD storage and the fingerprint sensor are needed, plan pin allocation carefully or use an external SD module on different pins.
Enrolling with only a single scan instead of two. This produces a template that matches unreliably in everyday use -- always complete the full two-scan enrollment process.
Storing fingerprint templates only in the sensor's own memory with no backup. The R307 stores templates onboard, and a sensor swap or reset can lose them -- for anything beyond casual home use, consider periodically backing up template data via the library's upload/download functions.
Assuming a false reject means the system is broken. An occasional failed match on a legitimately enrolled finger is expected behavior at the sensor's default security-favoring threshold, not a sign of malfunction.
Powering the servo and fingerprint sensor off the same rail as the camera without checking total current draw. Camera, sensor, and servo together can exceed what a marginal power supply provides, especially during the brief current spike of an actual unlock event -- size the supply for the combined peak load, not just the idle draw.
Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
| Sensor not detected / library init fails | Wiring swapped (TX/RX not crossed) or wrong baud rate | Confirm sensor TX → ESP32 RX and sensor RX → ESP32 TX; default baud is usually 57600 |
| Enrollment always fails at the second scan | Finger repositioned too differently between scans | Keep the same finger angle and pressure across both enrollment scans |
| Matches inconsistently for an enrolled finger | Sensor window dirty, or finger placement varies significantly | Clean the sensor's optical window; encourage consistent, full-finger placement |
| Servo doesn't move on a successful match | Servo power issue, separate from the match logic itself | Confirm servo has its own adequate power feed, not sharing a marginal rail with camera and sensor |
| Access log shows entries but photos won't open | SD write interrupted, or capture failed silently | Add error checking around the esp_camera_fb_get() and file write calls to catch and log failures explicitly |
Frequently Asked Questions
How many fingerprints can the R307 store? Typically up to 1000-3000 templates depending on the specific model and firmware revision -- comfortably more than a household or small office needs.
Is the fingerprint data itself stored as an actual image? No -- the sensor stores a mathematical template derived from ridge minutiae points, not a reconstructable image of the fingerprint itself, which is both more storage-efficient and more private than storing raw scan images.
Can this be combined with the keypad two-factor approach from the door lock project? Yes -- fingerprint plus PIN as a genuine two-factor system is a natural extension, requiring both a successful fingerprint match and a correct PIN within a short window before granting access, similar in structure to the face-plus-PIN pattern covered in the Face Detection Door Lock guide.
What happens if the fingerprint sensor fails or gets damaged? The system fails closed by default in the code above -- no match result means no grantAccess() call, so a failed sensor results in nobody being able to get in via fingerprint, not an accidental unlock. Worth planning a physical backup key or override for exactly this scenario before relying on this as a primary access method.
Can enrolled fingerprints be transferred between two R307 sensors? Yes -- the library supports downloading a stored template from one sensor and uploading it to another, which is useful for replacing a failed sensor without re-enrolling every authorized person from scratch, though it does add a bit of extra code beyond the basic enroll/match flow covered here.
Does the sensor work with wet, dry, or dirty fingers? Optical sensors like the R307 are somewhat more tolerant of minor dirt or moisture than capacitive sensors found in phones, but very wet or very dry skin still measurably reduces match reliability -- worth mentioning to anyone enrolling if their work regularly involves either condition.
Testing the Full System Before Trusting It
Before relying on this as an actual access control system, it's worth deliberately exercising every path -- not just the happy-path successful match -- to confirm the whole chain behaves the way it's supposed to:
Steps
- 1Enroll at least two different fingers and confirm both match independently before adding more
- 2Test a deliberately unenrolled finger and confirm it correctly reports no match rather than a false accept
- 3Confirm the access log correctly records the right fingerprint ID alongside each logged photo
- 4Disconnect WiFi entirely and confirm local matching and lock-triggering still work, since authentication happens on the sensor itself, not over the network
- 5Simulate a sensor failure by disconnecting it and confirm the system fails closed -- no unintended unlock -- rather than defaulting open
- 6If a physical key override exists, confirm it actually works and isn't just a decorative cylinder
Where to Go Next
For the servo-versus-solenoid lock mechanism choice referenced throughout this guide, see the Face Detection Door Lock project's comparison section. For general SD card storage and file-serving patterns, Photo Capture & microSD Storage covers that in more depth.
