Automatic barrier / gate
A whitelisted plate fires plate.allowed; wire the direct callback URL to a barrier opener and known vehicles get in without a fob or a guard.
All Studio apps
Vision & CCTV
License Plate Recognition
LPR · ALPR
Read license plates off any live camera, match a whitelist/blacklist and act in real time.
The problem
A gate, a barrier or a parking entrance runs on knowing which vehicle just arrived. Commercial ALPR is a licensed black box; LPR does the same job on open-source models you own, deduplicates the reads so an idling car does not spam you, and hands the verdict to whatever you already run — a barrier controller, an alerting system, a parking log.
Use cases
Watchlist alerts
A blacklisted plate fires plate.denied (blacklist wins over whitelist), so a flagged vehicle raises an alert with a snapshot the moment it appears.
Parking & drive-through log
Every read is deduped, timestamped, snapshotted and logged to per-plugin SQLite — a plate-level record of what came and went for a lot or a drive-through.
How it works
Input
Live HLS from the gate camera
A worker pulls the app's live stream over HLS and samples a few frames a second — plenty for a vehicle stopping at a barrier.
Detect
fast-alpr, then normalize & dedupe
YOLOv9-t plate detection + ONNX OCR (fast-alpr, MIT). Each read is normalized (case/separators stripped), deduped within a window and matched to your whitelist/blacklist.
Signed callback
detected / allowed / denied
The verdict flows through the app's HMAC-signed callbacks (+ MQTT) and, optionally, straight to a direct callback URL such as a barrier opener.
Your system
Recent reads + your action
A recent-reads table with snapshots and list badges lands in the dashboard tab; your system opens the gate, raises the alert, or files the record.
Events it emits
Declared in the plugin manifest and relayed through the app's HMAC-signed callbacks (webhook + MQTT). Anything a worker tries to emit that is not on this list is rejected — no core-event spoofing.
plate.detected
plate.allowed
plate.denied
Scope & limits
- Open-source models only (fast-alpr / fast-plate-ocr, MIT) — no proprietary ALPR engine and no per-plate cloud fees.
- It reads plates in view of the camera; it does not resolve a plate to a registered owner — that lookup is your system's job.
- 2 fps is plenty for a vehicle stopping at a barrier; free-flow lanes need 4–8 fps and roughly one core per camera.
Minimum requirements
- CPU inference (onnxruntime, default detector + OCR) at gate resolution: ~60–120 ms per sampled frame on one modern core, so a single core sustains ~4–8 fps; the default 2 fps uses about a quarter to a half of a core.
- RAM: ~400–600 MB. Disk: ~20 MB cached models + snapshots (~100–200 KB each). ARM (Pi 4/5 class) runs ~2–4× slower — use the 256 detector at 1–2 fps.
- GPU optional: only needed for many cameras per host or high sample rates, never for a single gate.
Numbers are the plugin authors' honest measurements, not marketing. GPU is optional on every vision plugin except where noted.
Runs as a full app
Every Studio app is a first-class application, not a config modal — and it does not have to live inside StreamHub.
Full-page dashboard view
Opens as its own page inside the tenant app — zones, live panels, history and settings on one surface, not squeezed into a dialog.
Its own database
Keeps its state in a dedicated per-app SQLite database — reads, alerts, occupancy and evidence rows — that you own and can query.
Exportable bundle
Download the app as a self-contained bundle — worker, Dockerfile, compose and an env template — to self-host on your own infra and extend, talking back over the REST API and signed webhooks.
Have cameras or streams to put to work?
Tell us what you are monitoring and we will scope the right apps, wire them into your systems and run them with you. The software is open source — the deployment and operation is what we do.