NFC Smart Attendance.

Project Overview

Tap a card to check in — instant, accurate, tamper-resistant attendance for offices, schools and events, logged automatically to the cloud.

Attendance is still, absurdly often, taken on paper or by calling out names — slow, error-prone, easy to fake (a friend signs you in), and a chore to tally. Yet almost everyone already carries a tap-able credential — an NFC card or phone — and the technology to read it instantly is cheap. This project builds an NFC attendance system: you tap your card on a reader, and your presence is recorded instantly, accurately and automatically, logged to the cloud. It replaces a tedious, unreliable ritual with a one-second tap.

The mechanics are simple and robust. Each person has an NFC card (or phone) with a unique ID; an NFC/RFID reader (e.g. PN532 or MRC522) reads that ID on a tap; the system looks it up, records a timestamped attendance entry (who, when, in/out), gives immediate feedback (a beep and a name/green light so the person knows it registered), and syncs the log to a central store. A real-time clock and reliable logging ensure entries are correctly timed and never lost, even if the network is briefly down.

The value is attendance that is instant, accurate and tamper-resistant: no queues of name-calling, no illegible sign-in sheets, no manual tallying, and a clear audit trail. It works for offices (staff time and access), schools and colleges (class attendance), and events (check-in). It is honest about its bounds — a card proves the card was tapped, not who tapped it, so buddy-punching is mitigated but not eliminated without a second factor (PIN/photo/biometric), and NFC cards themselves should be handled with basic security. But as a fast, reliable, cloud-logged tap-to-attend system, it turns one of the most tedious and fudged administrative tasks into a frictionless, trustworthy one.

What this project does

• Records attendance on an NFC card/phone tap
• Reads a unique card ID and looks up the person
• Logs a timestamped entry (who, when, in/out)
• Gives immediate feedback (beep, name, green light)
• Syncs the log to a central/cloud store reliably
• Provides an accurate, tamper-resistant audit trail
• Replaces slow, fakeable paper/roll-call attendance

Real-World Applications

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

Features & Capabilities

• NFC/RFID tap-to-attend
• Timestamped in/out logging (RTC)
• Immediate user feedback
• Reliable local logging + cloud sync (offline-safe)
• Duplicate/debounce handling
• Optional second factor (PIN) against buddy-punching
• Honest about card-not-person and NFC security

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• NFC/RFID reading (PN532/MRC522) of card IDs
• Timestamped logging with an RTC
• Reliable local logging + cloud sync (offline-safe)
• Debounce/duplicate handling and user feedback
• Basic NFC security and second-factor considerations

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: ₹10,955, 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 310.2 mA. With a 1.5× design margin the supply should deliver at least 500 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x with the ESP32 board package 3.x (or PlatformIO on VS Code). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

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

• Connect the NFC/RFID reader (SPI or I2C) to read card IDs on a tap.
• Add an RTC for accurate timestamps independent of network time.
• Add clear feedback — an OLED name/green light and a beep — so people know the tap registered.
• Log locally and sync to the cloud so entries survive a network blip.
• Mount the reader at a comfortable tap height at the entry point.

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

Attendance is a small task done badly at enormous scale. Paper sign-in sheets and verbal roll-calls are slow, produce illegible or error-prone records, must be tallied by hand, and are trivially fakeable — a friend signs you in, a name is called and answered for someone else. The irony is that the fix is already in everyone's pocket or wallet: a tap-able NFC credential. Reading it takes a fraction of a second and cheap hardware, so the design goal is simply to make presence register on a tap — instant, accurate, and logged automatically — replacing the ritual with a one-second action.

The mechanism rests on NFC/RFID identification. Every NFC card or phone carries a unique identifier; a reader energises a nearby card and reads that ID over a very short range (which is a feature — you must deliberately tap, not merely walk past). The system maps the ID to a person and records the event. The short range and unique ID make the interaction crisp and unambiguous: one tap, one identified person, one entry. This is the same technology behind contactless payment and access cards, applied to the specific job of marking who is present.

What turns a reader into a trustworthy attendance system is doing the surrounding jobs reliably. Each entry must be accurately timestamped — hence a real-time clock, so the record does not depend on network time and is right even offline. The person needs immediate feedback — a beep and their name or a green light — so they know it registered and do not tap repeatedly or walk off unrecorded. The log must be reliable: written locally first and synced to a central/cloud store, so a brief network outage never loses an entry. And the system must handle the mundane realities — debouncing a card held too long so it does not log ten times, distinguishing in from out, and rejecting unknown cards. These unglamorous details are the difference between a demo and something an office or school can actually rely on.

The design is honest about the one thing NFC attendance cannot do on its own: a card proves that the card was tapped, not who tapped it. This mitigates casual fakery (it is harder and more deliberate than answering a roll-call for a friend) but does not eliminate buddy-punching — handing your card to a colleague — without a second factor, such as a PIN, a photo prompt, or a biometric, which the system can add where the stakes justify it. It is also honest that NFC cards and their IDs deserve basic security hygiene (they can be cloned if treated carelessly), and that the attendance log is personal data to be protected. Within those honest bounds, the system delivers exactly what attendance has always wanted to be: fast enough that no one minds, accurate enough to trust, tamper-resistant enough to be fair, and automatic enough to need no tallying — a tedious, fudged chore turned into a frictionless tap.

The maths behind it

Tap → identified entry

read card UID  →  person = lookup(UID)

  if person unknown:  reject
  else: entry = { person, time (RTC), in/out }

Unique UID + short range → one deliberate tap, one entry.

Debounce / in-out

Ignore repeats of the same UID within a debounce window:

  if now − last_tap[UID] < DEBOUNCE:  ignore
  else: toggle/record in-or-out; last_tap[UID] = now

Stops a held card logging many times.

Reliable, tamper-resistant logging

log locally FIRST (never lose an entry)
  then sync to cloud when connected

Card proves the CARD, not the person:
  buddy-punching mitigated, not eliminated
  → optional 2nd factor (PIN/photo/biometric) for assurance.

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 reader with clock and feedback

   Connect the NFC/RFID reader, add an RTC for accurate timestamps, and add clear feedback (OLED name/green light + beep) at a comfortable tap height.

2. Identify, debounce and log reliably

   Map the card UID to a person, debounce repeat taps, record a timestamped in/out entry, and log locally before syncing.

3. Sync to the cloud and report

   Sync entries to a central/cloud store (offline-safe) and provide attendance reports.

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. Read a tap, identify and log a timestamped entry

   On a tap, read the card UID, look up the person, debounce repeats, and record a timestamped in/out entry with immediate feedback.

   cppattendance.ino Copy Download

   const uint32_t DEBOUNCE_MS = 3000;    // ignore repeats within 3 s
   
   struct Person { const char* name; bool present; uint32_t lastTap; };
   
   // Look up a card UID -> person (unknown returns nullptr).
   Person* lookup(const char* uid){ return registry_find(uid); }
   
   void onTap(const char* uid){
     Person* p = lookup(uid);
     if (!p){ feedback("Unknown card", RED); return; }   // reject unknown
   
     if (millis() - p->lastTap < DEBOUNCE_MS) return;     // debounce held card
     p->lastTap = millis();
   
     p->present = !p->present;                            // toggle in/out
     logEntry(uid, p->name, rtcNow(), p->present ? "IN" : "OUT");  // timestamped
     feedback(p->name, GREEN);                            // confirm the tap
   }

   if (!p){ feedback("Unknown card", RED); return; } // reject unknownAn unrecognised card is rejected with clear feedback, so only registered people are logged.

   if (millis() - p->lastTap < DEBOUNCE_MS) return; // debounce held cardDebouncing stops a card held on the reader from logging many entries — a mundane but essential detail.

   p->present = !p->present; // toggle in/outThe entry distinguishes in from out, so the record reflects actual presence over the day.

   logEntry(uid, p->name, rtcNow(), p->present ? "IN" : "OUT"); // timestampedEach entry is timestamped from the RTC, so records are accurate independent of network time.

2. Log reliably and sync to the cloud

   Write each entry locally first so none is lost, then sync to the central/cloud store when connected, and provide reports.

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.

/* ═══════════════════════════════════════════════════════════════
   NFC Smart Attendance — ESP32 + NFC reader + RTC

   Tap a card to record instant, accurate, timestamped attendance
   (in/out), with immediate feedback, reliable local logging and cloud
   sync (offline-safe). A card proves the CARD, not the person — add a
   second factor where buddy-punching matters.
   ══════════════════════════════════════════════════════════════════ */

#include <MFRC522.h>
#include <Preferences.h>

MFRC522 reader(5, 22);
const uint32_t DEBOUNCE_MS = 3000;

struct Person { String name; bool present; uint32_t lastTap; };

Person* lookup(const String& uid);            // registry (id -> person)
String  rtcNow();                             // accurate timestamp
void    feedback(const String& msg, int col); // OLED + beep + LED

void logLocal(const String& uid, const String& name,
              const String& ts, const char* dir){
  // write to local storage FIRST so an entry is never lost
  appendLog("{\"uid\":\"" + uid + "\",\"name\":\"" + name +
            "\",\"t\":\"" + ts + "\",\"dir\":\"" + dir + "\"}");
}

void syncCloud(){
  if (!wifiUp()) return;                       // offline: keep local, sync later
  for (auto& line : pendingLogLines()) cloudPost(line);   // aggregate/report
  clearSynced();
}

void onTap(const String& uid){
  Person* p = lookup(uid);
  if (!p){ feedback("Unknown card", RED); return; }        // reject unknown
  if (millis() - p->lastTap < DEBOUNCE_MS) return;         // debounce
  p->lastTap = millis();

  p->present = !p->present;                                 // in/out
  logLocal(uid, p->name, rtcNow(), p->present ? "IN" : "OUT");  // reliable
  feedback(p->name + (p->present ? " IN" : " OUT"), GREEN); // confirm
}

void setup(){ reader.PCD_Init(); rtcInit(); wifiConnect(); }

void loop(){
  if (reader.PICC_IsNewCardPresent() && reader.PICC_ReadCardSerial()){
    onTap(uidString(reader.uid));             // deliberate tap -> one entry
    reader.PICC_HaltA();
  }
  syncCloud();                                // opportunistic sync
}

Configuration & Calibration

Configuration steps

• Configure the NFC reader, the card-UID→person registry, and the RTC.
• Configure debounce timing and in/out logic.
• Configure local logging and cloud sync (offline-safe).
• Optionally configure a second factor (PIN) against buddy-punching.

Calibration procedure

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

1. Read reliability

   Verify consistent reads at the intended tap distance and speed; tune reader placement.

2. Time accuracy

   Set and verify the RTC; confirm timestamps are correct offline.

3. Logging/sync

   Confirm entries log locally and sync correctly, including after an offline period.

Network Architecture & Connectivity

Communication protocol

Readers log taps locally and sync entries to a central store; multiple readers/doors roll up into one attendance record.

Message contract between the device and the broker.

Cloud platform configuration

A central store aggregates entries across readers/sites into attendance reports and audit trails.

Dashboard setup

Attendance reports (who/when/in-out), per person and per day, with an audit trail.

Mobile app integration

Attendance summaries and alerts (e.g. absence) for admins/teachers.

Security considerations

• Protect the attendance log — it is personal data.
• Handle NFC cards/IDs securely; a card proves the card, not the person.
• Add a second factor where buddy-punching matters.

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

Instant, timestamped attendance entries with feedback, logged locally and synced to the cloud for reporting.

{
  "uid": "04A2B1C3",
  "name": "R. Sharma",
  "t": "2026-07-28T09:02:14",
  "dir": "IN",
  "synced": true
}

A one-second tap recorded R. Sharma present at 09:02:14 — accurate, timestamped and synced; no roll-call, no sheet, no tallying.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Read reliably on a deliberate tap; debounce held cards.
• Timestamp from an RTC so records are accurate offline.
• Log locally first, then sync — never lose an entry.
• Give immediate feedback so taps are not repeated or missed.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• Batch several samples into one MQTT publish. Radio time, not CPU time, dominates the energy budget.
• Set the MQTT keep-alive to a value that matches your reporting interval so the broker does not churn reconnections.
• 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.

Safety Precautions

• A card proves the card was tapped, not who tapped it — add a second factor where buddy-punching matters.
• The attendance log is personal data — secure it and limit access.
• Handle NFC cards/IDs with basic security; they can be cloned if treated carelessly.
• Mount the reader safely and accessibly at the entry point.
• Lithium cells vent and burn when abused. Only use protected cells or a proper BMS, never charge below 0 °C, and never leave a charging pack unattended on a wooden desk.
• 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 card registry current (joiners/leavers).
• Verify RTC time and reader reliability periodically.
• Confirm local-log and sync integrity, including after outages.
• Review the log/access for privacy and correctness.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Log pack voltage. When resting voltage after a full charge drops below about 4.0 V, the cell is near end of life — replace it.
• Keep the broker and dashboard containers patched, and rotate device credentials at least once a year.
• 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 a second factor (PIN/photo/biometric) against buddy-punching.
• Add multi-door/site aggregation and access control.
• Add absence/late alerts and timesheet integration.
• Support phone NFC/wallet credentials.
• 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 over-the-air firmware updates so you never have to physically reach a deployed node again.
• 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. Near-field communication (NFC)Reference
2. RFIDReference
3. Time and attendanceReference
4. Buddy punchingReference
5. MFRC522 / PN532 readersNXP