Classroom Occupancy Counter with Live Display using IR Sensors (Arduino, Python)

Classroom Occupancy Counter with Live Display is a deliberately scoped, fully buildable mini-project that answers a question every department asks: how many people are inside that room right now? Labs are capped by bench strength, exam halls by seating, and reading halls by safety norms — yet the number on duty is maintained by guesswork or a register nobody updates.

The unit mounts two IR reflective sensor modules across the door frame, a few centimetres apart. An Arduino Uno watches the two beams; because a person entering breaks the outer beam before the inner one, and a person leaving breaks them in the reverse order, the firmware's small state machine decides direction from the sequence of beam breaks, not from a single trip — so it can tell entering from leaving. A 16x2 I2C LCD by the door shows OCC 47/60 in real time; when the count reaches the room's capacity, a buzzer and red LED signal that the room is full, and a green LED marks safe occupancy. Every entry and exit event is sent over USB serial to a Python (pyserial) logger that timestamps it with the PC clock and appends to a CSV file; a small report script summarises a week's footfall per classroom.

The engineering is honest and achievable: sensor tuning, debounce timing, an order-detecting state machine, non-volatile count storage, and a documented walk-trial that measures how accurate the unit really is. Everything uses parts already sitting in most college component stores.

College departments enforce occupancy limits — bench strength in labs, seating in exam halls, safety limits in reading rooms — using a door register and occasional manual headcounts. The count is never current, staff cannot see when a room is over capacity without walking to it, there is no record of room usage patterns, and power cuts or forgetting to update the register silently destroy whatever accuracy it had. There is no budget for commercial people-counting systems, and camera-based counting raises privacy objections in hostels and classrooms.

There is a need for a simple, low-cost, privacy-free occupancy unit that counts people through a single door with plain IR sensors, distinguishes entering from leaving, shows the live occupancy against the room's rated capacity where everyone can see it, alarms the moment the room is full, and keeps a timestamped log that a department can review at the end of the week.

Abstract

Departments cap lab, library and exam-hall occupancy but have no live way to enforce or observe it. This project builds a door-mounted counter that detects each person with a pair of IR reflective sensors, decides direction from the order in which the two beams are broken, displays live occupancy against capacity on an LCD, alarms at full capacity, and logs every event to CSV via a Python serial logger. A one-week classroom trial measured counting accuracy and documented the failure cases.

Introduction

A typical department runs 10–20 rooms with rated capacities between 30 and 120. The existing controls are manual: a register at the lab door that is filled in for the first batch and forgotten, an invigilator counting heads twice during an exam, and no data at all for library or reading-hall usage. When the HOD asks "how many students were in Lab 204 during the 11 o'clock hour?", nobody can answer. The unit in this project makes that answer a glance at a screen outside the door.

Existing System

• A paper register or a warden's rough headcount, updated irregularly; the number drifts from reality within an hour.
• Overflow situations (extra students in a lab session) are discovered only when a supervisor happens to visit.
• Limitations: no live number, no history, no alarm, and no evidence to settle disputes about batch sizes or lab usage hours.

Proposed System

• Sensing: two IR reflective modules across the door frame, 12 cm apart, tuned with their onboard potentiometers to trip at about 25 cm.
• Direction logic: a five-state firmware state machine (idle → outer → both → inner → commit) interprets the beam-break order; a 600 ms inactivity timeout returns it to idle so a half-detected passage never corrupts the count.
• Display and alarm: LCD shows occupancy and capacity; reaching capacity triggers a buzzer and red LED, cleared only when someone leaves.
• Persistence: the count is saved to the Arduino's EEPROM periodically, so a power cut does not reset it to zero.
• Logging: every committed event goes over USB serial; the Python logger stamps it with the PC clock and appends date, time, room, event, count rows to CSV, with a weekly summary script on top.

Feasibility Study

• Technical: all sensing, display and logic is elementary digital interfacing of the kind taught in the microcontroller lab; the only subtle part — direction detection — is a small, well-testable state machine. No cloud, no networking, no camera, so there is no privacy impact.
• Economic: the bill of materials is about ₹1,300, one-time, largely from the department store; the laptop that logs data already exists.
• Operational: mounting is two brackets and a velcro-fixed LCD at the door; the unit runs from a 9 V adapter. Accuracy is honestly reported: our walk trials and the documented limitation for two people crossing abreast (mitigated by sensor spacing and mount height) are part of the report, not hidden.

In scope

• One doorway up to about 1.5 m wide, two-way foot traffic, single Arduino node.
• Live occupancy display, configurable capacity (set in firmware or via a menu button), full-room alarm.
• CSV event log on a connected laptop and a weekly summary per classroom.
• Walk-trial accuracy measurement with published results.

Out of scope (v1)

• Identification of individuals — the unit counts people, never recognises them (no camera, no biometrics).
• Multiple doors per room or syncing several units; networked dashboards and mobile apps.
• Counting vehicles or extremely wide gates; outdoor mounting in rain.
• The known edge case of two or more people crossing exactly abreast is documented and mitigated, not solved — it is reported as a measured error term.

The team used the Iterative (Incremental) SDLC model: four increments, each ending in something that works and can be demoed to the guide. For a first hardware build this beats the waterfall model, because sensor behaviour (IR range, debounce time) can only be learned by touching real hardware, and every increment absorbs that learning.

Testing approach: unit tests for each sensor (toggle the module's LED by crossing its beam at varying distances and angles); integration tests for the state machine using scripted beam sequences (outer-then-inner, inner-then-outer, outer-only, both-at-once); system-level walk trials with a written protocol (single person, two abreast, person with a backpack, quick entry-exit); and a one-week acceptance trial whose logged counts are compared against a manual tally kept by the lab instructor. Every test case is recorded as ID, input, expected, actual, result.

The system is a small, fully inspectable chain: sense → decide → show → log. Two IR reflective modules face each other across the door frame at waist height, 12 cm apart, each pulling its output low when a reflection is seen. The Arduino Uno polls both outputs every 10 ms — polling, because interrupt-plus-debounce logic for two channels is easier to reason about and verify as a state machine. The committed event updates the count, drives the LCD, the buzzer and the LEDs, and emits one serial line. A Python logger on the lab laptop adds the PC timestamp and appends to CSV; a separate script turns the week's CSV into a per-hour footfall summary. There is deliberately no network in v1: the unit must work with the laptop unplugged.

flowchart TD
  P["Person at door"] --> S1["IR sensor A (outer, Arduino D2)"]
  P --> S2["IR sensor B (inner, Arduino D3)"]
  S1 --> SM["Arduino Uno ATmega328P: 5-state direction state machine (C firmware)"]
  S2 --> SM
  SM --> LCD["16x2 I2C LCD: OCC 47/60"]
  SM --> AL["Buzzer + green/red LED capacity alarm"]
  SM --> EE["EEPROM count persistence + reset button"]
  SM -->|USB serial 9600 baud| PY["Python pyserial logger on laptop"]
  PY --> CSV["occupancy_log.csv (date, time, room, event, count)"]
  CSV --> WK["Weekly footfall summary script"]

The serial protocol is one line per event — EVT,IN,47 or EVT,OUT,46 — which makes the logger trivially simple and the log human-readable in any editor, an intentional choice for a first project.

• Multi-door units linked over ESP-NOW or RS-485 to one department dashboard, with per-room live status.
• Identity-free analytics: peak-hour footfall and room-utilisation reports that help the department timetable lab batches without tracking any individual.
• HVAC/light interlock: drive the room's lights or AC only when occupancy is above a threshold, as an energy-saving extension.
• Exam-hall mode: a stricter two-threshold configuration (warning at 90% capacity, alarm at 100%) with an entry lockout log.
• Battery backup and a Real-Time Clock so the unit keeps logging timestamps with the laptop fully disconnected.