More project photos (2)
The problem
Parking lots in malls, campuses and housing societies fill and empty all day, and drivers waste fuel and time circling floors hunting for a free bay. Knowing each bay's status at a glance — from a display at the entrance or a phone on the same network — removes that guesswork. This project builds exactly that as a student-buildable prototype: LM393 IR obstacle sensors, one per bay, detect whether a vehicle is present; an ESP32 reads the sensors, debounces the transitions in firmware and publishes retained per-slot MQTT messages over Wi-Fi; and a web dashboard renders every bay's status live with counts, an occupancy bar and an event log. It is a complete sense–publish–visualize IoT loop, small enough to build on a breadboard yet architecturally honest enough to discuss in a viva.
Opens the dashboard to find a free bay before driving in.
Follow the working sequence
How it works
- Each LM393 IR obstacle module is fixed over one parking bay; its on-module potentiometer sets the detection threshold within the datasheet 2–30 cm range, and its OUT pin goes HIGH when a vehicle reflects infrared back.
- The ESP32 samples every OUT pin once per 100 ms; a state change is accepted only after three consecutive consistent reads (debounce), rejecting sensor flicker.
- On each confirmed change the firmware publishes a retained MQTT message to
parking/slot/<n>/state(payload 0 for free, 1 for occupied) on a local Mosquitto broker over Wi-Fi. - The gateway also publishes
parking/gw1/statuswith an MQTT last-will, so the dashboard visibly marks the node offline if the ESP32 drops. - The dashboard subscribes to the topic tree over MQTT-over-WebSocket and flips the matching bay tile between FREE and OCCUPIED, updates the free/occupied counts and the occupancy bar.
- Every arriving message is appended to the timestamped event feed, showing the exact topic and payload for each slot change.
- On boot the ESP32 republishes current states, and retained messages on the broker mean a freshly opened dashboard shows the last-known state immediately.
Tech stack:
- ESP32-WROOM-32 (Wi-Fi 802.11 b/g/n)
- Arduino IDE with ESP32 core
- LM393 IR obstacle sensor modules
- MQTT · Mosquitto broker
- PubSubClient
- AsyncWebServer
- HTML · CSS · JavaScript dashboard
- Wi-Fi 802.11 b/g/n
| Parameter | Value |
|---|---|
| Controller | ESP32-WROOM-32, dual-core 240 MHz |
| Sensors | 4× LM393 IR obstacle modules (base 4-bay build; firmware supports up to 12) |
| Detection range | 2–30 cm, adjustable via on-module potentiometer (datasheet) |
| Sensor supply | 3.3–5 V DC (datasheet) |
| Sensor output | Digital OUT — HIGH when an obstacle is detected |
| GPIO (base build) | 32, 33, 34, 35 (digital inputs) |
| MQTT topics | parking/slot/ |
| Poll interval | 100 ms; 3-sample debounce before state change |
| End-to-end state-flip latency | Design target: under ~1 s (network-dependent) |
| Slot-state reporting accuracy | Design target: ≥95% correct reporting after buyer-run calibration — not a measured claim |
| Power | 5 V USB supply; expected typical draw ≈ 500 mA |
| Dashboard | Single-file HTML/CSS/JS; any modern browser |
Project features
- [Per-bay IR vehicle detection] One LM393 IR obstacle sensor per bay detects vehicle presence within its adjustable 2–30 cm range (datasheet value), driving a digital OUT pin the ESP32 reads directly.
- [Debounced state logic] Firmware samples each sensor every 100 ms and requires three consecutive consistent reads before registering a change, so flicker and sensor noise never flip a bay.
- [MQTT retained-state publishing] Each confirmed change is published to
parking/slot/<n>/statewith payload 0/1 as a retained message, plus aparking/gw1/statusgateway topic with MQTT last-will for offline detection. - [Live availability dashboard] A single-file HTML/CSS/JS dashboard renders a bay map that flips FREE/OCCUPIED in real time, with free/occupied counts, an occupancy bar, node uptime and Wi-Fi RSSI.
- [Timestamped MQTT event feed] Every topic and payload that crosses the broker appears in a scrolling feed log on the dashboard — excellent for demonstrating the pipeline during reviews.
- [Reserved-bay handling] Any bay can be flagged reserved in the dashboard config; reserved bays are excluded from availability counts.
- [12-bay expandable firmware] The base build ships with 4 bays on GPIO 32–35; the firmware maps up to 12 bays across GPIO 2, 4, 12–15, 25–27 and 32–35 for a larger model lot.
What is included
- Working 4-bay hardware prototype with model parking base, ESP32 and wired IR sensors
- Complete ESP32 firmware (sensor polling, debounce, MQTT publishing, topic scheme)
- Dashboard HTML file with bay map, counts, occupancy bar and MQTT event feed
- Circuit/wiring documentation and GPIO map
- Buyer-run sensor calibration procedure (potentiometer + firmware threshold)
- Project report PDF (background, architecture, methodology, MQTT design, calibration)
- PPT presentation for final review
- Viva Q&A preparation document (IR sensing, MQTT semantics, debounce rationale, Wi-Fi vs cloud trade-offs)
Limitations & prerequisites
- IR modules detect any reflective object — a hand over the sensor reads as occupied; this is presence detection, not vehicle classification.
- Detection range is limited to the datasheet 2–30 cm and the sensor is tuned for the indoor model lot; sunlight and mirrors can interfere outdoors.
- The build runs on the local Wi-Fi network — remote access from outside needs a cloud broker, offered as customization.
- ≥95% correct slot reporting is a design target, stated honestly; the buyer calibrates the threshold on their own rig and the report documents the procedure.
- It is an academic prototype, not a commercial parking system — no number-plate recognition, payment or barrier control.
- If Wi-Fi drops, updates pause until reconnect; the MQTT last-will marks the gateway offline on the dashboard so the failure is visible.
Frequently Asked Questions
Which controller and sensors does the project use?
An ESP32-WROOM-32 reads four LM393 IR obstacle sensor modules — one per bay — through digital GPIO pins 32–35 in the base build. Firmware debounces the readings and publishes them over MQTT; the expandable build maps up to 12 bays across additional GPIOs.
Does it need an internet connection?
No — the dashboard, the Mosquitto MQTT broker and the ESP32 all run on the local Wi-Fi network, so the demo works fully offline from the internet. Internet access is needed only if you want cloud-based remote monitoring, which is an optional customization.
Will it work in a real outdoor parking lot?
As shipped, no: IR sensors are tuned for the indoor model lot and sunlight or reflective surfaces can cause false readings. Outdoor deployment needs weather-resistant sensing (ultrasonic or magnetic loop), listed in the report's future scope.
How is occupancy accuracy handled?
Occupancy is a presence/no-presence digital decision per bay, not a measurement, so accuracy means correctly reporting each bay's state. The ≥95% figure is a design target stated honestly, achieved through the on-module threshold adjustment plus a buyer-run calibration procedure included with the build — no measured accuracy is claimed.
Is this project suitable for a final-year project?
Yes — for Electronics, Electrical and IoT & Embedded programs. It demonstrates sensor interfacing, digital signal conditioning, MQTT topic design, retained messages and last-will semantics, and a live web dashboard: a complete IoT pipeline from hardware to screen.
Suitable for B.E./B.Tech final-year projects in Electronics, Electrical, IoT & Embedded.
Components & software requirements
- ESP32-WROOM-32 (Wi-Fi 802.11 b/g/n)
- Arduino IDE with ESP32 core
- LM393 IR obstacle sensor modules
- MQTT · Mosquitto broker
- PubSubClient
- AsyncWebServer
- HTML · CSS · JavaScript dashboard
- Wi-Fi 802.11 b/g/n
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.
Download free synopsis (PDF)
Enter your name and email — the synopsis PDF downloads immediately. We may send occasional project updates; no spam, unsubscribe anytime.