Built to order

IoT Smart Manhole Cover Monitor with Displacement and Gas Alerts

This project builds an IoT monitor mounted on a manhole cover that watches two hazards: cover displacement or opening (theft, flooding, accidents) and sewer gas build-up (methane, hydrogen sulfide). An ESP32 with a tilt/shock sensor and MQ-series gas sensors reads levels, sounds a local buzzer, shows status on an LCD, and pushes alerts with the cover's location over Wi-Fi to a monitoring dashboard. It ships as an assembled prototype with firmware, wiring documentation and the full viva kit. Suitable for B.E./B.Tech final-year projects in IoT & Embedded, Electronics and Electrical.

IoT Smart Manhole Cover Monitor with Displacement and Gas Alerts — project thumbnail preview
More project photos (2)

The problem

Open or displaced manhole covers cause fatal accidents every year, and sewer gas build-up — methane and hydrogen sulfide — kills sanitation workers silently. Municipal monitoring of covers is practically nonexistent in most Indian cities: inspections are manual and infrequent. This project builds the missing sensing layer as a student-buildable prototype: a ruggedized monitor box that bolts to the underside of a manhole cover, detects tilt/displacement with an accelerometer or tilt switch, sniffs gases with MQ-series sensors, and reports over Wi-Fi with a local buzzer and LCD for on-site status. The engineering substance is in the threshold logic — distinguishing a real gas hazard from sensor drift, and a real cover movement from vibration — plus the low-power design thinking for a device that must live underground.

How it works

  1. The monitor unit is fixed to the underside of the manhole cover; on power-up the gas sensors warm up and the ESP32 establishes a baseline reading.
  2. An accelerometer/tilt switch continuously watches the cover's orientation; gas sensors are sampled on a schedule between low-power sleeps.
  3. When tilt exceeds the configured threshold (cover opened or displaced) the buzzer sounds, the LCD flags COVER OPEN, and a displacement alert with the cover's location tag is pushed over Wi-Fi.
  4. When methane or H2S readings cross their alert thresholds for a confirmed duration, a gas-hazard alert is raised the same way, with the measured levels included.
  5. All events — displacements, gas alerts, sensor baselines — are logged with timestamps to the monitoring endpoint for the dashboard view.
  6. On site, the LCD shows live gas levels and cover status so maintenance crews can read conditions without opening the cover.

Tech stack:

  • ESP32 (firmware, Wi-Fi, sensor reading, alert logic)
  • MQ-4 methane sensor, MQ-136 hydrogen sulfide sensor
  • Tilt switch / accelerometer (displacement sensing)
  • 16×2 LCD, buzzer (local indication)
  • Arduino framework firmware
  • HTTP/MQTT alert endpoint + event log dashboard
  • IP-rated enclosure, battery + solar-charging provision
Parameter Value
Controller ESP32 dev board (Wi-Fi, deep-sleep support)
Gas sensors MQ-4 (methane, 300–10,000 ppm per datasheet), MQ-136 (H2S, per datasheet)
Displacement Tilt threshold configurable; design target ±10° from baseline
Alert thresholds Gas alert levels configurable; set during buyer-run calibration (design target: methane alert above ~1,000 ppm equivalent)
Local output 16×2 LCD (gas levels + status), buzzer alarm
Power Battery pack with sleep scheduling; solar-charging provision documented
Connectivity Wi-Fi to monitoring endpoint (HTTP/MQTT)

Project features

  • [Displacement detection] Tilt/shock sensing on the cover: opening, tilting beyond the threshold angle, or shock from impact raises an immediate alert.
  • [Sewer gas sensing] MQ-4 (methane) and MQ-136 (hydrogen sulfide) sensors with calibrated alert thresholds; the firmware distinguishes genuine build-up from warm-up drift.
  • [Local alarm] Buzzer plus 16×2 LCD showing live gas readings and cover status for on-site inspection.
  • [Wi-Fi alerts] ESP32 pushes displacement and gas alerts with device ID and location tag to the monitoring endpoint; events are logged with timestamps.
  • [Battery-aware design] Sleep scheduling between readings and solar-charging provision documented for long field deployment thinking.
  • [Buyer-run calibration procedure] Step-by-step sensor warm-up, baseline and threshold-setting procedure the buyer performs on their own build — no invented "measured" figures.
  • [Enclosure & mounting design] IP-rated enclosure concept and under-cover mounting arrangement documented in the build guide.

What is included

  • Assembled monitor prototype (ESP32, sensors, LCD, buzzer, enclosure)
  • Complete firmware source with threshold logic and alert code
  • Wiring diagrams and bill of materials with exact part numbers
  • Buyer-run calibration & threshold-setting procedure
  • Mounting and enclosure design documentation
  • Project report PDF (background, sensor theory, system design, firmware logic, testing procedure)
  • PPT presentation for final review
  • Viva Q&A preparation document (MQ sensor chemistry, calibration, power budgeting, threshold design)

Limitations & prerequisites

  • Gas readings are indicative, not laboratory-grade: MQ sensors drift with temperature and humidity, which is why the calibration procedure is part of the deliverable.
  • Alert thresholds are design targets set during the buyer's own calibration — no measured detection figures are claimed before that run.
  • Wi-Fi range limits underground deployment; the enclosure sits near the surface and LoRa is documented as the upgrade path (future scope).
  • Battery life depends on sampling schedule and solar input; the report gives the power-budget calculation rather than a measured endurance figure.
  • This is a hazard-indication prototype, not certified safety equipment.

Frequently Asked Questions

What two hazards does it monitor?

Cover displacement (theft, flood washout, accidental opening) via tilt/shock sensing, and sewer gas build-up (methane via MQ-4, hydrogen sulfide via MQ-136) — the two causes of most manhole-related deaths.

How does it alert?

Three ways: a local buzzer and LCD for anyone on site, plus a Wi-Fi alert with the cover's location tag pushed to the monitoring endpoint, where every event is timestamp-logged.

How are the gas sensors calibrated?

MQ sensors need warm-up and baseline setting. The deliverable includes a buyer-run procedure: warm up, record clean-air baseline, set alert thresholds, and verify with the documented test method — on the student's own build.

Won't vibration from traffic cause false displacement alerts?

The firmware requires tilt to persist beyond the threshold angle (design target ±10°) rather than reacting to momentary shocks, and the threshold is configurable. The report discusses this filtering.

Can it run on battery underground?

It uses ESP32 deep-sleep between scheduled readings, and the enclosure design includes a solar-charging provision. The report documents the power-budget calculation; measured endurance is not claimed.

Is this project suitable for a final-year project?

Yes — for IoT & Embedded, Electronics and Electrical programs. It combines sensor interfacing, threshold/decision logic, wireless alerts and power-aware design around a genuine civic problem. Suitable for B.E./B.Tech final-year projects in IoT & Embedded, Electronics and Electrical.

Components & software requirements
  • ESP32 (firmware, Wi-Fi, sensor reading, alert logic)
  • MQ-4 methane sensor, MQ-136 hydrogen sulfide sensor
  • Tilt switch / accelerometer (displacement sensing)
  • 16×2 LCD, buzzer (local indication)
  • Arduino framework firmware
  • HTTP/MQTT alert endpoint + event log dashboard
  • IP-rated enclosure, battery + solar-charging provision
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 abstract (PDF)

Related guides

All guides
Blueprint-style technical illustration of an ESP32 development board at the centre, with sensor nodes, data-flow arrows and a circuit-brain motif representing an AI agent reasoning and sending decisions back.Engineering students building IoT or embedded final-year projects who want to add local AI agent behaviour with ESP32, MQTT and a small language model.

AI Agents on ESP32: Agentic IoT Final-Year Projects

An agentic IoT system observes, reasons, acts, remembers and explains. On ESP32 that means a split architecture: the chip senses and acts while a small local model (Ollama on your laptop) reasons over MQTT — a full LLM needs gigabytes of RAM the chip doesn't have. This guide covers three working patterns (host-reasoned agent, on-device tinyML on ESP32-S3, and a hybrid of both), plus Wi-Fi CSI presence sensing, parts and budget for India, code shapes, and honest limits to state in your report.

Read guide
Technical illustration of three electronic control units linked by a twisted-pair CAN bus cable carrying signal pulses between them.Electronics, E&TC, IoT and robotics students who keep hearing “CAN bus” in EV, automotive and industrial project ideas and want to understand it properly before wiring anything

CAN Bus Basics for Students: How ECUs Communicate

CAN bus is the shared network that lets dozens of controllers in a car, EV or robot communicate over two wires. This guide explains message IDs, arbitration, the physical layer, frame structure, error handling and CAN FD, then walks through building a working two-node bench network with an ESP32 and a transceiver.

Read guide
Illustration of a quadcopter drone build showing labeled parts including frame, motors, propellers, ESCs, flight controller, and battery.B.E./B.Tech Electronics, Mechanical, and Computer Science students planning to build a quadcopter drone who need to select compatible parts without wasting money on mismatched

Drone Build: Parts Selection Guide

Picking drone parts that actually work together is a sizing problem, not a shopping problem. This guide walks the compatibility chain — frame to props to motors to ESCs to battery — with the thrust math, firmware choices, LiPo safety, and the bench-test order that prevents disasters.

Read guide
Get a quotation