Why

Most DIY access control projects I've seen let the device decide. A fingerprint module does the matching itself and talks to the ESP over a plain, unauthenticated UART, or a reader checks a card and sends the command that opens the lock. It's relatively easy to get to that wiring and make the device say "match is OK". A few modules do encrypt that link, but the key sits in the ESP's flash, and the same ESP still opens the door, so owning the ESP still means owning the door.

This project turns that around: the reader in front of the door is deliberately dumb.

The idea

Hardware

What I test on now: an ESP32-S3 on Wi-Fi with a PN532 V3 NFC module on SPI (with its IRQ line, which matters for latency), an LED ring for feedback, and a Pixel 10 as the phone.

Planned: a bare FPC1020AM fingerprint sensor, a flex-cable version that comes with the bezel already built in. The lesson from my first boards: the chip drives the finger through a metal bezel, and without one the frames are pure noise. A keypad for PINs may or may not make it onto the board, but support for it in the software is planned either way.

Firmware

An ESPHome external component (ESP32, ESP-IDF) that keeps one WebSocket to the server and relays what the reader captures. Its protocol core has no ESPHome dependency, so it is tested on a host with sanitizers and a fuzzer. The measured time from a phone entering the field to the verdict on the reader is about 245 ms.

Server

A Dockerized ASP.NET server (.NET 10) with SQLite. It verifies credentials, applies the policy, and serves the admin UI (Vue, English and Ukrainian) on its own port, which the reader subnet cannot reach. Administrators log in with a password and an authenticator code, and every change is written to an audit log.

Status

Works

In progress

Next

Later