Unmanned Store Face Access
Face unlock for a door nobody staffs.
Unlock the door with a face, reject photos and screen replays, and keep opening when offline. The face library is managed in the cloud, and every unlock is recorded.
Advanced60minVision & Video AI
Reusable Site Templates
A door nobody stands behind, a roster that keeps changing, and a record someone may read back.
Unmanned or lightly staffed retail
Convenience-store staff entrances, back stockrooms, night self-service shops. Change the roster in the console and devices fetch it.
Shared offices and campuses
Co-working floors, incubator entrances. People change weekly and enrolment is self-service.
Equipment rooms and cabinets
Server-room doors, switchrooms, parcel-locker back doors. The record matters more than throughput.
Not a fit: doors where failing to open is itself an incident, and doors where letting the wrong person in is severe. The lock runs on its own supply, thresholds need calibrating on the installed camera, and the reference face weights are licensed for non-commercial research only.
How it works
At the door a reCamera Pro recognises on its own, or an existing IP camera feeds a reComputer recognition host. Either way a relay drives the door controller you already have.
At the door sits either an existing IP camera with a reComputer behind it, or an all-in-one reCamera that recognises faces by itself. Both routes end at a dry contact into the existing door controller, and the lock never runs on the compute board's supply. The cloud holds the versioned face library, console and broker beside the unlock path; a device that loses it keeps opening with the last library it loaded.
Cameras
Two ways in, and the wall usually decides which:
- You already have IP cameras. Point the access host at the RTSP stream; one host can serve several doors.
- You don't. reCamera Pro and the standard reCamera carry the sensor and the accelerator in one unit. The standard reCamera runs detection, liveness and matching in its own process, so no recognition container is installed.
Framing is a prerequisite. Mount at roughly face height so a face fills a usable part of the frame where people stop. Backlit doorways and glass reflections are the usual failures, so set the threshold from a sweep on the installed camera.
Recognition Host
This decides how the software is installed, and it differs more between routes than accuracy does.
| Recognition host | Where recognition runs | What gets installed |
|---|---|---|
| reCamera Pro | On the camera, beside its existing face-recognition app | A set of Python modules copied by hand — no package manager on the device |
| Standard reCamera (SG2002) | On the camera, in its own native process | A small daemon that pulls the library and publishes events |
| reComputer Industrial J20 | In containers, against an existing RTSP stream | Containers over SSH |
| reComputer J30 / J40 / R2000 | In containers, against an existing RTSP stream | Containers over SSH |
Thresholds on both reCamera units are shipped defaults; calibrate them on your own site.
Door Control Output
The relay switches the lock, and the software only decides when. Where the relay sits is a wiring choice:
- Beside the recognition device — a GPIO on reCamera Pro, or an opto-isolated output on the J20. Nothing on the network sits between a face and the lock.
- On an MQTT relay node — used by the standard reCamera, which has no usable header pin, or when the host is away from the door. Here broker availability is door availability.
The lock runs on its own 12/24 V supply. Active level, pulse width, relay contact and fail mode have no defaults and are set per installation; the bundled broker configuration is plaintext and for a bench only.
The data interface is listed under What You Get below.
How well it works
What the admin sees and operates in the browser console — access records, the face library and the door itself.
Measured results
Measured on reCamera Pro running the access app: a replayed 1280x720 clip at 12.5 fps, liveness on. p50, p95 in brackets.
| What the door gets | Typical | Device |
|---|---|---|
| Face to unlock signal, 1 000-person library | 0.66 s (0.68) | reCamera Pro |
| Unregistered person let through | 0 of 40 | reCamera Pro |
| Phone-screen or still-screen replay let through | 0 of 60 | reCamera Pro |
The unlock signal is the relay trigger pin driven to its active level, 24 of 24 runs, 12 per library size; relay and lock response time is not included. A 10-person library gives 0.62 s.
In the screen rows the library template was built from the attack clip, so the face on the screen is an enrolled person.
Recognition and liveness accuracy depend on the face model and your own enrolment images. The reference face weights are licensed for non-commercial research only; per-run conditions are in the engineering wiki.
What you get out of it
Once deployed, these topics and endpoints are the whole interface.
| Topic / endpoint | Payload | Retained |
|---|---|---|
access/v1/events (MQTT 8883, QoS 1) | One JSON per decision, allowed and denied alike: person or anonymous id, score, threshold, liveness, decision and reason, door action, face library version, model hash | No |
access/v1/status/{device_id} (MQTT 8883) | 30-second heartbeat: actuator health, library version, liveness loaded; offline via last will | Yes (last will) |
access/v1/commands/{door_id} (MQTT 8883) | unlock, hold_open, lock, each with a unique id, issue time and TTL; never retained, so a reconnect cannot open the door by itself | Never |
access/v1/receipts/{command_id} (MQTT 8883) | Final state of one command; a replayed command gets this receipt instead of a second unlock | No |
access/v1/relay/{relay_id}/set and /state (MQTT 8883) | MQTT-relay routes only; state reports the contact, not whether the door is open | set no, state yes |
GET /v1/facedb/current, /v1/facedb/{version} (HTTP 8080) | Face library distribution — two endpoints, no push, resumable downloads | — |
/api/events, /api/devices, /api/persons, /api/audit/verify (HTTP 8088) | Console API with three roles: viewer reads, operator unlocks, admin enrols | — |
| Dry contact on the relay | The physical output every route ends at; the door controller wires its input to it | n/a |
Before the first successful sync the device has no library and denies with its own reason, not as a non-match. A new library takes effect within the poll period, 30 s by default. Put the console behind TLS; the service refuses to start with no access token configured.
Porting It to Your Own System
The reusable unit is the chain a versioned, signed dataset from the cloud → pulled and checked on the device → switched in one step → a decision written to a tamper-evident log → a physical contact. Only two links are bound to face access: what the dataset contains, and what the policy checks before closing the contact.
| Layer | What porting costs you |
|---|---|
| Versioned distribution — polling, resumable download, per-file checks, signature, one-step switch, deletion barrier | reuse as-is |
| Actuator settings — active level, pulse width, contact type, fail mode | reuse as-is |
| Command checks — exact fields, unique id, expiry, replay protection, receipts | reuse as-is |
| Tamper-evident audit log and the console's three roles | reuse as-is |
| Clock correction from the server, for devices without a real-time clock | reuse as-is |
| What the dataset contains and how it is matched | replace for the new application |
| The policy evaluated before the contact closes | rewrite for the new application |
Same-shape uses: licence-plate barriers, badge-plus-face turnstiles, tool cribs and equipment cabinets, vending and locker doors.
Where this shape does not fit
- Doors where a failure to open is itself a safety event. Fire egress and anything a code officer signs off; the design has no certification.
- High-throughput turnstiles. The 30-second poll and single-shot pulse are built for a door someone walks up to, not a stream of people.
- Treating "the door did not open" as "the person was not authorised". A closed door can also mean a framing, network or relay fault, so the log is the record.
How to deploy
Tell us about your site — we work out the hardware, then you connect the data and follow the steps.
Existing Camera
Is there a camera at this door already?
Or compare them yourself: preset specificationsDeployment Guide · 60min →
| Setup | Role | Device | Qty |
|---|---|---|---|
| A. reCamera Pro at the Door | Cloud Host | Cloud / On-Prem Host | 1 |
| Door Camera | reCamera Pro | 1 | |
| Relay | Grove Relay | 1 | |
| B. reCamera PoE | Cloud Host | Cloud / On-Prem Host | 1 |
| Door Camera | reCamera 2002 | 1 | |
| Relay | Grove Relay | 1 | |
| C. Standard reCamera (2002 / 2002w) | Cloud Host | Cloud / On-Prem Host | 1 |
| Door Camera | reCamera 2002 | 1 | |
| Relay | Grove Relay | 1 | |
| Relay Node | XIAO ESP32-S3 / reComputer R1000 Series(either one) | 1 | |
| D. AI Host with Your Existing Cameras | Cloud Host | Cloud / On-Prem Host | 1 |
| Access Host | reComputer J20 Series (Jetson Xavier NX) / reComputer J40 Series (Jetson Orin NX) / reComputer J30 Series (Jetson Orin Nano) / reComputer R1000 Series(either one) | 1 | |
| Camera | RTSP / IP Camera | 1 | |
| Relay | Grove Relay | 1 | |
| MQTT Relay Node (only when the host is not at the door) | reComputer R1000 Series / XIAO ESP32-S3(either one) | 1 |
| Preset | Camera | Recognition host | Unlock path | Liveness |
|---|---|---|---|---|
| A. reCamera Pro at the door | The device's own sensor | Same device | Local GPIO → relay | Enforced (Silent-Face) |
| B. Standard reCamera | The device's own sensor | Same device, native process | No usable header pin, so MQTT → relay at the gateway | On-camera texture liveness with blink fusion, thresholds uncalibrated |
| C. AI host with your existing cameras | Existing RTSP camera | reComputer J20 / J30 / J40 / R1000 | Host's opto-isolated DO or a Grove Relay; an MQTT relay node when the host is not at the door | Enforced (Silent-Face) |
All three presets also need a relay rated for the lock with a separate 12/24 V lock supply, and a cloud or on-prem Docker host for the face library, console and broker (amd64 or arm64 Linux, no GPU).
Difficulty is rated advanced, with about 60 minutes budgeted per door; the reCamera Pro steps are manual.
FAQ
On reCamera Pro, yes — recognition, liveness and the decision happen at the door, using the last face library loaded. The network carries library updates, events and remote commands, not the unlock. The standard reCamera is the exception: its relay sits at the gateway, so the unlock needs the broker.
Both depend on the face model you deploy and your own enrolment images. On reCamera Pro, 0 of 60 phone-screen or still-screen replays were let through in testing. The shipped threshold is a starting point; set it from a sweep on the installed camera.
On reCamera Pro, face to unlock signal is 0.66 s p50 with a 1 000-person library, not counting relay and lock movement. Face library activation (p50 491.6 ms on a standard reCamera) is a different measure and is not a door-opening time.
No to both. A lock draws 300 mA to 1 A while a GPIO or opto-isolated output carries milliamps, and the relay is what isolates the compute board from the controller's input. Every preset ends at the relay's contact, with the lock on its own 12/24 V supply.
The device polls the cloud, downloads a newer version in chunks, checks every file and the signature, and only then switches over. Any failure keeps the previous version; tampered and wrongly signed libraries were both rejected on hardware, and an interrupted download resumed.
No. Removing a person creates a new version and records the deletion, and a rollback to any version that still contains them is refused. The audit log is append-only, so an edited past decision is caught by the console's verify function.
Not without replacing the face model. The code is Apache-2.0, but the reference detection and embedding weights are for non-commercial research only, and replacing them means rebuilding every face library version. The liveness model is Apache-2.0 and usable commercially.
The standard reCamera runs liveness, but its thresholds are uncalibrated defaults, so sweep them on site before a street door. A setup on the RKNN backend has no liveness check and does not suit a street-facing door.
Didn't find your answer?
Contact Us
We Are Glad to Be Your Hardware Partner !