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.
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 Super J30 / Super J40 / R1000 | 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 host GPIO on reComputer. 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 detailed in Engineering Wiki · Unmanned Store Face Access.
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.
Configure yours
Tell us about the door — we work out the hardware.
Existing Camera
Is there a camera at this door already?
Configure yours
Tell us about the door — we work out the hardware.
On-Device — reCamera Pro
Recognition, liveness, the decision and a GPIO pulse into the relay's opto-isolated trigger — all in one device at the door. The relay's `COM`/`NO` contact is the whole output; wire it to your door controller's input, add a separate 12/24 V lock supply on the controller side, and any amd64/arm64 Docker host for the face library service, the console and the broker. Console enrolment does not produce a library usable on this device; enrol on the device itself.
硬件/物料名称 数量 型号/SKU 说明 reCamera Pro 2GB 1 100092895 - Grove - Relay 1 103020005 - On-Device — reCamera 2002 HQ PoE
Recognition, liveness and the decision run on the camera; the unlock is a pulse from baseboard header D1 into the relay's opto-isolated trigger, so the door never depends on the network or the broker. Power and network both arrive on the PoE cable. The relay's `COM`/`NO` contact is the whole output — wire it to your door controller's input, add a separate 12/24 V lock supply on the controller side, and any amd64/arm64 Docker host for the face library service, the console and the broker.
硬件/物料名称 数量 型号/SKU 说明 reCamera 2002 HQ PoE 8GB 1 100029708 - Grove - Relay 1 103020005 - Standard reCamera — Gateway Relay via XIAO
The standard reCamera already detects, embeds, judges liveness and matches in one native process, so this package installs no recognition container and pulls no RTSP off the camera. What it adds is a daemon that pulls the versioned library and maps the camera's native result stream onto the event contract. The relay sits at the gateway on a XIAO ESP32-S3, so the unlock crosses the network and broker availability is door availability. Upstream's default here is a XIAO 1-Channel Relay add-on (SKU 114993555, driven directly by the XIAO's GPIO); it has no cataloged accessory family yet, so the Grove Relay below is the documented substitute — wired to the same XIAO GPIO. Add the separate 12/24 V lock supply on the door controller's side and a Docker host. Thresholds ship as defaults; calibrate them on site.
硬件/物料名称 数量 型号/SKU 说明 reCamera 2002 8GB 1 102991894 - XIAO ESP32-S3 relay node 1 113991114 - Grove - Relay 1 103020005 - Standard reCamera — Gateway Relay via R1000
Same as the XIAO gateway option — no recognition container, no RTSP pull, just a daemon that pulls the versioned library and maps the camera's native result stream onto the event contract. Here the relay hangs off a reComputer R1000 instead, which writes the unlock as a point on the gateway through its own point-command path — useful when the site already runs an R1000 for other Modbus/BACnet IO. The unlock still crosses the network, so broker availability is door availability. Add the separate 12/24 V lock supply on the door controller's side and a Docker host. Thresholds ship as defaults; calibrate them on site.
硬件/物料名称 数量 型号/SKU 说明 reCamera 2002 8GB 1 102991894 - reComputer R1000 Series (R1024-10, relay node) 1 113991294 - Grove - Relay 1 103020005 - reComputer Super J3011 — Relay at the Host
For a door that already has a camera. reComputer Super J3011 pulls the existing RTSP stream, runs recognition and liveness in containers, and drives the relay's trigger from a host GPIO at the door. The relay's `COM`/`NO` contact is the whole output — wire it to your door controller, add the separate 12/24 V lock supply on the controller side and a Docker host for the cloud side (library service, console, broker).
硬件/物料名称 数量 型号/SKU 说明 reComputer Super J3011 1 114110312 - Grove - Relay 1 103020005 - reComputer Super J3011 — MQTT Relay via XIAO
For when the box that runs recognition is nowhere near the door, or one box serves several doors. reComputer Super J3011 pulls the existing RTSP stream and runs recognition and liveness in containers, away from the door. The unlock travels over MQTT to a XIAO at the door, which drives this relay's `COM`/`NO` contact and ends the pulse from its own firmware timer, so a dropped packet cannot leave the contact closed. Broker availability is door availability. Add the separate 12/24 V lock supply on the door controller's side and a Docker host.
硬件/物料名称 数量 型号/SKU 说明 reComputer Super J3011 1 114110312 - XIAO ESP32-S3 relay node 1 113991114 - Grove - Relay 1 103020005 - reComputer Super J3011 — MQTT Relay via R1000
For when the box that runs recognition is nowhere near the door, or one box serves several doors. reComputer Super J3011 pulls the existing RTSP stream and runs recognition and liveness in containers, away from the door. The unlock travels over MQTT to a R1000 at the door, which writes the unlock as a Modbus point rather than a direct GPIO pulse. Broker availability is door availability. Add the separate 12/24 V lock supply on the door controller's side and a Docker host.
硬件/物料名称 数量 型号/SKU 说明 reComputer Super J3011 1 114110312 - reComputer R1000 Series (R1024-10, relay node) 1 113991294 - Grove - Relay 1 103020005 - reComputer Super J4012 — Relay at the Host
For a door that already has a camera. reComputer Super J4012 pulls the existing RTSP stream, runs recognition and liveness in containers, and drives the relay's trigger from a host GPIO at the door. The relay's `COM`/`NO` contact is the whole output — wire it to your door controller, add the separate 12/24 V lock supply on the controller side and a Docker host for the cloud side (library service, console, broker).
硬件/物料名称 数量 型号/SKU 说明 reComputer Super J4012 1 114110314 - Grove - Relay 1 103020005 - reComputer Super J4012 — MQTT Relay via XIAO
For when the box that runs recognition is nowhere near the door, or one box serves several doors. reComputer Super J4012 pulls the existing RTSP stream and runs recognition and liveness in containers, away from the door. The unlock travels over MQTT to a XIAO at the door, which drives this relay's `COM`/`NO` contact and ends the pulse from its own firmware timer, so a dropped packet cannot leave the contact closed. Broker availability is door availability. Add the separate 12/24 V lock supply on the door controller's side and a Docker host.
硬件/物料名称 数量 型号/SKU 说明 reComputer Super J4012 1 114110314 - XIAO ESP32-S3 relay node 1 113991114 - Grove - Relay 1 103020005 - reComputer Super J4012 — MQTT Relay via R1000
For when the box that runs recognition is nowhere near the door, or one box serves several doors. reComputer Super J4012 pulls the existing RTSP stream and runs recognition and liveness in containers, away from the door. The unlock travels over MQTT to a R1000 at the door, which writes the unlock as a Modbus point rather than a direct GPIO pulse. Broker availability is door availability. Add the separate 12/24 V lock supply on the door controller's side and a Docker host.
硬件/物料名称 数量 型号/SKU 说明 reComputer Super J4012 1 114110314 - reComputer R1000 Series (R1024-10, relay node) 1 113991294 - Grove - Relay 1 103020005 - reComputer R1000 — Relay at the Host
For a door that already has a camera. reComputer R1000 pulls the existing RTSP stream, runs recognition and liveness in containers, and writes the unlock as a point on its own GPIO/relay output at the door. The relay's `COM`/`NO` contact is the whole output — wire it to your door controller, add the separate 12/24 V lock supply on the controller side and a Docker host for the cloud side (library service, console, broker).
硬件/物料名称 数量 型号/SKU 说明 reComputer R1000 Series (R1024-10, access host + relay) 1 113991294 - Grove - Relay 1 103020005 - reComputer R1000 — MQTT Relay via XIAO
For when the box that runs recognition is nowhere near the door, or one box serves several doors. reComputer R1000 pulls the existing RTSP stream and runs recognition and liveness in containers, away from the door. The unlock travels over MQTT to a XIAO at the door, which drives this relay's `COM`/`NO` contact and ends the pulse from its own firmware timer, so a dropped packet cannot leave the contact closed. Broker availability is door availability. Add the separate 12/24 V lock supply on the door controller's side and a Docker host.
硬件/物料名称 数量 型号/SKU 说明 reComputer R1000 Series (R1024-10, access host + relay) 1 113991294 - XIAO ESP32-S3 relay node 1 113991114 - Grove - Relay 1 103020005 - reComputer R1000 — MQTT Relay via R1000
For when the box that runs recognition is nowhere near the door, or one box serves several doors. reComputer R1000 pulls the existing RTSP stream and runs recognition and liveness in containers, away from the door. The unlock travels over MQTT to a R1000 (a second, separate R1000 from the one running recognition) at the door, which writes the unlock as a Modbus point rather than a direct GPIO pulse. Broker availability is door availability. Add the separate 12/24 V lock supply on the door controller's side and a Docker host.
硬件/物料名称 数量 型号/SKU 说明 reComputer R1000 Series (R1024-10, access host + relay) 1 113991294 - reComputer R1000 Series (R1024-10, relay node) 1 113991294 - Grove - Relay 1 103020005 -
Or compare them yourself: preset specificationsDeployment Guide · 60min →
Hardware Equipment List by Preset
| 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 J30 Series (Jetson Orin Nano) / reComputer J40 Series (Jetson Orin NX) / 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 |
Technical Specifications & Implementation Comparison
| 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 Super J30 / Super J40 / R1000 | Host GPIO 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 !