A local recognition event.
A connected attendance system.
An attendance system has to connect what happens at a physical device with what an administrator can actually see.
Greetly brings those two sides together: a Raspberry Pi handles camera input and face recognition; Supabase stores attendance records; a Next.js dashboard presents updates and device telemetry.
The public repository supplies the implementation evidence for this case study. It is a project walkthrough, not an independently validated deployment or performance benchmark.
Six steps. One connected system.
Try me — scroll or choose a stage.Try me — tap a stage to follow the event.
Frames stay local. Only the recognition event moves onward.
The Pi reads camera frames locally. The frame stays at the edge for the recognition step.
The Pi reads camera frames locally. The frame stays at the edge for the recognition step.
OpenCV prepares grayscale face regions on the Raspberry Pi. Local processing avoids sending a continuous video stream to the dashboard.
The current Python script matches faces with an LBPH recognizer. A per-person cooldown suppresses repeated attendance writes.
The edge script sends attendance records through the Supabase client. A local queue in the script supports retrying writes.
An attendance record is stored in attendance_logs, connecting the identified student to a timestamp and attendance status.
The dashboard subscribes to database updates through Supabase Realtime, bringing the recorded event into the administrator’s view.
The current Python script uses OpenCV’s LBPH recognizer and grayscale face regions on the Raspberry Pi. The web interface receives records instead of needing a continuous camera feed.
Source distinction: the README mentions face_recognition; the inspected implementation uses OpenCV LBPH.
The script keeps a per-person timestamp and checks the configured cooldown before another attendance write. Repeat detections can provide local feedback without adding another cloud record.
A local write queue in the edge code supports retrying attendance submissions. This is evidence of retry handling, not a guarantee of lossless delivery under every failure mode.
Camera state, local display feedback and hardware telemetry belong to the same system. The repository documents a systemd kiosk service so the process can start at boot.
The README documents repository-connected Vercel deployment and Cloudflare DNS for the public domain. Production settings and availability have not been independently audited.
The useful part is the connection between layers.
A camera event touches local compute, identity, duplicate handling, network delivery, database state and interface updates. A polished dashboard cannot compensate for an unreliable path between those layers.
Next questions include evaluating recognition under varying conditions, failure recovery, tighter device permissions and observability. These are engineering questions to investigate, not completed improvements being claimed.
CONTENT REVIEWED / 30 SEP 2026 · SOURCE MAY EVOLVE