Visitor Management Kiosk.

Project Overview

A self-service check-in kiosk: scan a QR invite, capture a photo, print a badge, notify the host — and keep a searchable digital visitor log instead of a paper book.

The paper visitor book at a reception desk is a security and privacy mess: illegible, unsearchable, exposing every visitor's details to the next person who signs in, and useless in an actual emergency when you need to know who is in the building. A visitor management kiosk replaces it with a fast self-service flow — a visitor scans a QR code from their invitation, the kiosk captures their photo, prints a badge, notifies their host that they have arrived, and records the visit in a searchable digital log. It speeds up reception, looks professional, and — done thoughtfully — actually improves both security and privacy over the book it replaces.

The core flow is designed around pre-registration and QR codes. A host invites a visitor in advance; the system issues a unique QR code (emailed to the visitor) that encodes their invitation. At the kiosk, the visitor scans it, the kiosk validates it against the expected-visitors list, captures a photo for the badge and the log, prints a time-stamped badge, and pushes an instant notification to the host so they can come to reception. Walk-in visitors are handled by a short manual form. Check-out is equally simple, so the log always reflects who is actually in the building — the thing the paper book never gets right.

The design treats visitor data as the personal data it is. Photos and details are stored access-controlled with an explicit retention policy (kept for the security/audit purpose, then purged), each visitor sees only their own flow (not the previous signer's details), and the system is built for legitimate reception and safety use — including an accurate "who is on site" roster for evacuations. It is honest about scope: it is a reception and logging tool, not an identity-verification or access-control system by itself (a QR code proves an invitation, not an identity, and the kiosk should pair with door access where security demands it), and photo capture is for badges and the visit record, not covert surveillance. But as a fast, professional, privacy-respecting replacement for the sign-in book — with QR check-in, photo badges, host notifications, and a searchable, emergency-ready visitor log — it does a genuinely useful job that a paper book simply cannot.

What this project does

• Checks visitors in by scanning a pre-issued QR invitation
• Captures a photo for the badge and the visit record
• Prints a time-stamped visitor badge
• Notifies the host instantly that their visitor has arrived
• Keeps a searchable digital visitor log (and a live on-site roster)
• Handles walk-ins with a short manual form and check-out
• Stores visitor data access-controlled with explicit retention

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• QR-based pre-registered check-in (fast, professional)
• Photo capture for badges and the visit log
• Instant host notification on arrival
• Searchable digital log + live "who is on site" roster
• Per-visitor privacy (no exposed previous entries)
• Retention/access controls on personal data
• Honest scope: reception/logging, not identity/access control

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• QR generation/validation and a check-in flow
• Camera photo capture and badge printing
• Host notification and a searchable log/roster
• Touchscreen UI for self-service
• Privacy-aware data handling (retention/access)

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹20,000, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 4800 mA. With a 1.5× design margin the supply should deliver at least 7200 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Raspberry Pi OS Bookworm (64-bit) + Python 3.11 + VS Code Remote-SSH. Anything newer normally works; anything older may lack the board definitions used here.

• Flash Raspberry Pi OS (64-bit) with Raspberry Pi Imager; pre-configure Wi-Fi, hostname and SSH in the Imager settings so the board comes up headless.
• Update first: sudo apt update && sudo apt full-upgrade -y, then reboot.
• Work inside a virtual environment — python3 -m venv ~/venv && source ~/venv/bin/activate. Bookworm blocks system-wide pip install by design.
• Enable the buses you need with sudo raspi-config → Interface Options (I²C, SPI, Serial, Camera).
• Develop over VS Code Remote-SSH so you edit on your laptop but run on the Pi.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Use the camera for both photo capture and QR scanning to keep the hardware simple.
• Store the visitor database and photos on access-controlled local storage; treat them as personal data.
• Connect to the network for host notifications and (optional) central log sync.
• If gating a turnstile/door, drive it via the ESP32/relay only after a validated check-in — but pair with real access control for security.
• Position the camera for a clear, well-lit badge photo and comfortable QR presentation.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

A visitor kiosk is fundamentally a workflow-and-records system, and its value over a paper book comes from three properties the book cannot provide: speed and professionalism at reception, an accurate live record of who is on site, and privacy for each visitor's data. Designing it well means optimising the common path (an expected visitor arriving), handling the exceptions gracefully (walk-ins, check-out), and treating the data it accumulates with the care that personal data demands.

The efficient common path is built on pre-registration and QR codes. Rather than making a visitor type their details at the desk, the host registers them in advance and the system issues a unique QR code that encodes (or references) the invitation. At the kiosk the visitor simply scans; the system validates the code against the expected-visitor list, pulls up the pre-entered details, and the visitor confirms rather than types. This is fast, error-free and professional. The QR is best treated as a reference/token the backend validates (so it can be checked for validity, expiry and single-use) rather than a blob of personal data printed on a page — which is both more secure and more private. Walk-ins fall back to a short manual form, and the whole flow ends with a photo (for the badge and the visit record), a printed badge, an instant host notification, and a log entry.

The on-site roster is the quietly important feature. Because the system records check-in and, crucially, check-out, it always knows who is currently in the building — which the paper book, where people rarely sign out, never does. That roster is exactly what a fire evacuation or a security incident needs: an accurate, instantly-available list of the visitors on site and who they are visiting. Making check-out as frictionless as check-in (scan the same badge, or a host confirms departure) is what keeps the roster honest and therefore useful when it matters.

Finally, the kiosk is designed around privacy and honest scope, because it handles sensitive data and could easily be built carelessly. Each visitor interacts with a fresh flow that shows only their own information — never, as the paper book does, the previous ten visitors' names and companies on the same open page. Photos and details are stored access-controlled, visible only to authorised reception/security staff, with an explicit retention policy that keeps records for the legitimate security/audit period and then purges them, so the system does not silently accumulate a permanent database of everyone who ever visited. And the scope is stated plainly: it is a reception and logging tool, not identity verification or access control on its own — a QR proves an invitation exists, not who is holding it, and the photo is for a badge and a record, not facial surveillance — so where genuine security is required, the kiosk is paired with proper door access and ID checks. Built this way, it delivers everything the sign-in book fails at: fast, professional check-in; an accurate, emergency-ready roster; and better, not worse, privacy for the people it records.

The maths behind it

QR as a validated token

Invitation → token T (random, unguessable), emailed as a QR.
At the kiosk:

  valid(T) = T ∈ expected AND not_expired(T) AND not_used(T)

QR references the record (server-side), it does NOT carry the
personal data itself → more secure and private.

Accurate on-site roster

roster = { v : checked_in(v) AND NOT checked_out(v) }

Accuracy depends on frictionless check-OUT. The roster is the
emergency/evacuation list the paper book never gets right.

Retention / access

store visit records access-controlled; purge on schedule:

  keep record while now − visit_time < RETENTION
  visible only to authorised staff
  each visitor sees ONLY their own flow (no prior entries)

Minimise personal data; do not accumulate it beyond purpose.

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Build the kiosk

   Assemble the touchscreen, camera (for photo + QR scan) and badge printer in a reception stand, driven by the Pi with access-controlled local storage.

   Position the camera for a clear photo and comfortable QR presentation, with good lighting.

2. Set up the check-in backend

   Create the expected-visitor list and QR-token validation, the visit database (access-controlled), and the host-notification path.

3. Configure privacy and integrations

   Set retention and access controls; ensure each visitor sees only their own flow; optionally integrate a turnstile/door (paired with real access control).

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Validate the QR and run the flow

   Scan the QR, validate the token (expected, not expired, not used), pull the pre-registered details, capture a photo, print the badge, notify the host and log the visit.

   pythoncheckin.py Copy Download

   import time
   
   def validate_qr(token, db):
       inv = db.get_invitation(token)
       if inv is None:                     return None, "unknown code"
       if inv.expired():                   return None, "code expired"
       if inv.used:                        return None, "code already used"
       return inv, "ok"
   
   def check_in(token, camera, printer, notifier, db):
       inv, reason = validate_qr(token, db)
       if inv is None:
           return prompt_walk_in()          # fall back to a short manual form
       photo = camera.capture()             # for badge + record
       visit = db.create_visit(inv, photo=photo, time=time.time())
       printer.print_badge(visit)           # time-stamped badge
       notifier.notify_host(inv.host, inv.visitor_name)   # instant arrival alert
       db.mark_used(token)                  # single-use token
       db.roster_add(visit)                 # live on-site roster
       return visit
   
   def check_out(badge_id, db):
       db.roster_remove(badge_id)           # keep the roster accurate
       db.close_visit(badge_id, time=time.time())

   def validate_qr(token, db):The QR is validated server-side against the expected list, expiry and single-use, so it functions as a secure token rather than a blob of printed personal data.

   return prompt_walk_in()An invalid or absent code gracefully falls back to a short manual walk-in form rather than a dead end.

   notifier.notify_host(inv.host, inv.visitor_name)The host is notified instantly on arrival, the key convenience that replaces someone phoning around to find them.

   db.roster_add(visit)Every check-in updates the live on-site roster, the accurate who-is-here list that a paper book never maintains.

   def check_out(badge_id, db):Frictionless check-out keeps the roster honest, so the evacuation/emergency list stays correct.

2. Enforce privacy and retention

   Store photos/details access-controlled, show each visitor only their own flow, and purge records past the retention window automatically.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

#!/usr/bin/env python3
"""
Visitor Management Kiosk — Raspberry Pi

QR-based self-service check-in with photo capture, badge printing, host
notification, and a searchable, access-controlled visitor log with a
live on-site roster. Reception/logging tool — not identity/access control.
"""
import time
from camera import Camera          # photo + QR decode
from printer import BadgePrinter
from notify import HostNotifier
from db import VisitorDB

RETENTION_DAYS = 30

class Kiosk:
    def __init__(self):
        self.cam = Camera()
        self.printer = BadgePrinter()
        self.notify = HostNotifier()
        self.db = VisitorDB()          # access-controlled storage

    def validate(self, token):
        inv = self.db.get_invitation(token)
        if not inv:            return None, "unknown code"
        if inv.expired():      return None, "code expired"
        if inv.used:           return None, "already used"
        return inv, "ok"

    def run_once(self):
        self.reset_ui()                # fresh flow — no prior visitor's data
        token = self.cam.scan_qr(timeout=30)
        if token:
            inv, reason = self.validate(token)
        else:
            inv = self.walk_in_form()  # short manual entry for walk-ins

        if inv is None and token:
            return self.show(reason)   # invalid code message

        photo = self.cam.capture()     # badge + record photo
        visit = self.db.create_visit(inv, photo=photo, ts=time.time())
        self.printer.print_badge(visit)
        self.notify.host(inv.host, inv.visitor_name)   # instant arrival alert
        if token: self.db.mark_used(token)
        self.db.roster_add(visit)      # accurate on-site roster
        self.show(f"Welcome, {inv.visitor_name}. {inv.host} has been notified.")

    def check_out(self, badge_id):
        self.db.close_visit(badge_id, ts=time.time())
        self.db.roster_remove(badge_id)

    def housekeeping(self):
        self.db.purge_older_than(RETENTION_DAYS)       # enforce retention

if __name__ == "__main__":
    k = Kiosk()
    while True:
        k.run_once()
        k.housekeeping()

Configuration & Calibration

Configuration steps

• Set the retention period and access controls on the visitor database and photos.
• Configure QR-token validation (expiry, single-use) and the host-notification channel.
• Configure the badge template and printer, and the walk-in form fields.
• Set UI reset behaviour so no visitor sees another's details.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. QR/camera

   Verify reliable QR scanning and clear, well-lit photo capture at the kiosk's ergonomics; adjust camera position/lighting.

2. Flow timing

   Confirm the end-to-end check-in (scan → photo → badge → notify) is fast and the walk-in fallback is short.

3. Roster accuracy

   Test check-in and check-out and confirm the on-site roster stays accurate; make check-out easy.

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

The kiosk confirms check-in and notifies the host; reception sees a searchable visitor log and a live on-site roster.

{
  "visitor": "A. Sharma",
  "company": "Acme",
  "host": "R. Patel",
  "checkin": "2026-07-27T10:04:12",
  "checkout": null,
  "badge": "V-20260727-014",
  "photo": "/secure/photos/014.jpg"
}

A check-in record with a printed badge and an instant host notification; the on-site roster lists everyone currently checked in but not out — the accurate emergency list the paper book never provides.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Keep the common (QR) path to a few seconds; pre-registration removes typing at the desk.
• Store photos efficiently and access-controlled; enforce retention to bound storage.
• Notify hosts asynchronously so the visitor is not kept waiting.
• Reset the UI quickly between visitors for throughput and privacy.
• Pin the hot loop to one core with taskset and leave the others free for the OS.
• Prefer MJPEG over raw YUY2 when capturing from USB cameras — the decode cost is far lower than the USB bandwidth cost.
• Log to a tmpfs RAM disk and flush to the SD card once a minute; per-sample SD writes are what kills cards.
• Run the service under systemd with Restart=always so a crash never means a dead deployment.
• For battery builds use deep sleep between samples: an ESP32 drops from ~160 mA awake to about 10 µA asleep, which is the difference between days and months of runtime.
• Profile before optimising — print micros() deltas around each stage and fix the slowest one first.

Safety Precautions

• Visitor photos and details are personal data — access-control them, set retention, and show each visitor only their own flow.
• It is a reception/logging tool, not identity verification or access control; pair with real door access/ID checks where security requires it.
• Keep an accurate on-site roster for emergencies, and make it available to those responsible for evacuation.
• Comply with local data-protection law (consent, notices, retention).
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Keep the expected-visitor/host directory current.
• Check camera, printer and consumables; test the flow regularly.
• Review retention/access settings and purge as policy requires.
• Reconcile the roster (auto-close stale check-ins) so it stays trustworthy.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Rotate the microSD card annually and keep an image of the working system. Cards used as loggers wear out silently.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add self-service pre-registration and calendar integration for hosts.
• Add NDA/sign-off capture during check-in where required.
• Add optional face-match to the badge photo for return visitors (privacy-reviewed).
• Integrate with access control and evacuation systems for a complete flow.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add connectivity — an ESP32 and an MQTT publish turn a local gadget into something you can graph, alert on and analyse over months.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Visitor management systems — overviewReference
2. QR codesReference
3. Data protection and retention (GDPR principles)Reference
4. Reception/evacuation roster best practiceHSE
5. Raspberry Pi camera (picamera2)Raspberry Pi