RFID Attendance System with ESP32 — Architecture, Edge Firmware & Flutter App

01 — The Problem With Biometric Attendance

The facility we worked with operated on fingerprint biometric readers, physical registers, and Excel workbooks. This created four distinct failure modes that compounded each other:

• Biometric failure in harsh environments: Dust, moisture, and high humidity caused fingerprint scanners to fail repeatedly. Gate check-in throughput degraded to 8–12 seconds per worker — creating severe congestion during shift turnovers when hundreds of workers arrive simultaneously.
• Overnight shift miscalculations: Legacy tracking software anchored shift cycles to calendar days. Shifts crossing midnight were fragmented into two dates, requiring manual HR reconciliation every cycle.
• Manual payroll cycles: Administrative staff spent up to 4 business days per month manually auditing timecards, reconciling overtime, resolving half-days, and cross-checking leave slips.
• Zero asset traceability: High-value industrial tools and safety gear were signed out on paper clipboards — no chain of custody, no live inventory visibility, no accountability.

02 — Solution Architecture

The design principle was commodity hardware with custom intelligence — avoiding proprietary vendor lock-in at every layer. Standard off-the-shelf RFID readers are paired with custom ESP32 edge firmware and modern cloud architecture built on open protocols.

[ Physical Scanners ]
  13.56 MHz HF / 125 kHz LF RFID Readers
           |
     (Wiegand-26 / UART)
           ▼
[ Edge Gateway Layer ]
  ESP32 / Raspberry Pi
  (Edge Debounce & Local SQLite Queue)
           |
    (MQTT over TLS · Port 8883)
           ▼
[ Ingestion & Cloud Broker ]
  Enterprise MQTT Broker ──► Redis Distributed Lock & Cache
           |
           ▼
[ Core Processing Engine ]
  Event-Driven Microservices
  (Shift State Engine & Payroll Automation)
           |
      ┌────┴────┐
      ▼         ▼
[ PostgreSQL ]     [ TimescaleDB ]
  Relational         Append-Only
  Master Data        Telemetry Events
  (Profiles,         (Audit Logs,
  Shifts, Rules)     High-Volume Scans)
      └────┬────┘
           |
    (WebSockets & Secure REST)
           ▼
[ Flutter UI Layer ]
  Android / iOS Mobile Apps
  & Wall-Mounted Tablet Dashboards

03 — RFID Ingestion Pipeline

Every attendance event follows the same deterministic path from card tap to database commit:

Physical Capture

Readers detect passive cards via 13.56 MHz HF (ISO 14443 / MIFARE) or 125 kHz LF (EM4100) frequencies and stream the card UID over standard Wiegand-26 wiring. The Wiegand protocol is decades old, universally supported, and lets us swap readers from any manufacturer without firmware changes.

Edge Packaging & Local Debounce

The ESP32 gateway reads the Wiegand data line and immediately applies a 3-second hardware debounce — suppressing echo reads when a card lingers near the antenna. The microcontroller then packages the scan into a signed JSON payload:

{
  "terminal_id": "GATE_A_01",
  "card_uid": "A3F2B1C9",
  "timestamp_us": 1725684923847291,
  "seq": 48291,
  "hmac_sha256": "e3b0c44298fc1c149afb..."
}

The HMAC-SHA256 signature uses a pre-shared key burned into the ESP32 secure storage (eFuse) at provisioning. This prevents replay attacks and unauthorized terminal injection — a common vulnerability in naive RFID deployments that skip message authentication.

Transport Security

Edge nodes maintain persistent mutual TLS connections via MQTT on port 8883. The ESP32 holds a device certificate issued by our internal CA. Cellular LTE/4G and Wi-Fi provide automatic failover — if the primary connection drops, the gateway queues events locally in SQLite and flushes with exponential backoff once connectivity recovers. Zero events are lost during network interruptions.

04 — Concurrency, Deduplication & Storage

High-volume shift turnovers produce burst traffic. When 200 workers arrive at shift start, the system must handle simultaneous scans without duplicate attendance records. We enforce an end-to-end deduplication pipeline:

Distributed Concurrency via Redis

Atomic SETNX locks on incoming card UIDs prevent multi-threaded duplicate ingestion during cluster bursts. When a card UID arrives, the broker attempts to set a Redis key with a 5-second TTL. If the key already exists — the scan is a duplicate and is dropped before reaching the database. This eliminates race conditions at the application layer without database-level locking overhead.

A 5-minute state window validates repeated taps against active shift states — flagging unauthorized or accidental double entries without dropping telemetry data.

Dual-Database Architecture

Two databases handle fundamentally different data shapes:

• PostgreSQL — relational master data: employee profiles, compensation tiers, pay grades, assigned shifts, and leave accruals. Standard ACID guarantees for mission-critical records.
• TimescaleDB (Hypertables) — append-only, high-frequency time-series telemetry. Hypertables partition scan events by time, making range queries across millions of historical records instant. Payroll calculations that previously took 4 days now run in minutes against this optimized schema.

05 — Cross-Platform Flutter Interface

A single Flutter codebase powers both personal mobile devices (floor managers) and dedicated wall-mounted factory tablets (live headcount displays). Two form factors, one codebase, zero duplication.

Offline-First Resilience

When factory WiFi drops — and it will — the Flutter client falls back to an encrypted local SQLite queue. Events are processed locally and synchronized using exponential backoff retry once connectivity recovers. Floor managers never see a broken UI during network interruptions.

Real-Time Operations Display

WebSocket streams push live workforce events directly to Flutter clients — headcount, active workstations, shift transitions, and unauthorized area alerts with sub-second latency. Floor managers see live data without pulling or refreshing.

06 — Operational Modules

07 — Results — 90 Days in Production

Measured across a 350-worker deployment over 90 days of production operation:

08 — Engineering Takeaways

Filter Noise at the Edge — Not the Cloud

Hardware-level signal bounce must be filtered directly on the microcontroller gateway before pushing to message brokers. Every duplicate that reaches the cloud costs compute, network, and storage. A 3-second debounce on the ESP32 eliminates the majority of duplicates before they leave the device — preserving cloud resources for business logic that actually matters.

Anchor Shifts to Schedules, Not Calendar Dates

Forcing timestamp records into strict 00:00 calendar day boundaries breaks overnight shift tracking. Shift definitions must evaluate against logical state windows and schedule IDs — a shift that starts at 22:00 and ends at 06:00 is a single logical unit, regardless of what the calendar says. This sounds obvious until you inherit legacy software that doesn't do it.

Decouple Hardware from Software via Open Protocols

Designing around open protocols (Wiegand for RFID readers, MQTT for transport) means any standard reader can be swapped within minutes without touching firmware. Proprietary terminals create permanent vendor dependency — price increases, discontinued support, and feature limitations you can't work around. Open protocols give you options.

09 — Technology Stack

Mobile & Tablet

Edge Computing

Messaging & Transport

Data & Realtime

Summary

Enterprise-grade workforce automation does not require multi-thousand-dollar proprietary terminals. By combining standard RFID hardware, ESP32 edge intelligence, an MQTT event broker, and a unified Flutter front-end, the facility converted manual sign-offs into a single automated operational pipeline — lowering infrastructure costs while establishing full auditability across workforce attendance and asset tracking.

The three decisions that made the biggest difference: filtering noise at the edge before it hits the cloud, anchoring shift logic to schedule state instead of calendar dates, and choosing open protocols that keep hardware replaceable. These aren't clever tricks — they're the difference between a system that works in production and one that breaks under real conditions.