IoT Air Quality Monitor with Mobile Alerts

Cheap "air quality" gadgets usually report a single meaningless number from an uncalibrated gas sensor. This monitor is built differently. A PMS5003 laser-scattering sensor measures real PM2.5 and PM10 particle concentrations — the pollutants health agencies actually regulate — while an MQ-135 reports total gas/VOC trends and a BME280 provides temperature and humidity for context and compensation. An ESP32 computes the AQI from PM2.5/PM10 using the standard breakpoint formula, publishes readings over Wi-Fi via MQTT, and a dashboard renders live values, AQI gauge, 24-hour pollutant graphs and a color-coded health category. When the AQI crosses into unhealthy bands, a mobile push alert goes out with the measured values. The listing states sensor realities honestly: the PMS5003 is a real particle counter (not a guess), the MQ-135 is qualitative, and calibration means side-by-side comparison with a reference, not factory claims.

1. The PMS5003's fan draws air through its laser chamber; scattered-light pulses are counted into PM1.0/PM2.5/PM10 concentrations.
2. The ESP32 reads the MQ-135 (analog gas trend) and BME280 (temperature/humidity/pressure) alongside the particle data.
3. Firmware computes the AQI from PM2.5 and PM10 using the standard breakpoint formula and assigns the health category.
4. The readings are published over Wi-Fi via MQTT to the cloud backend at a configurable interval (design target: 60 s).
5. The dashboard renders the live AQI gauge, pollutant trend graphs, 24-hour history and the health-category banner.
6. When the AQI crosses a configured threshold, the alert service pushes a mobile notification with the measured values; thresholds and the MQ-135 burn-in procedure are part of the setup guide.

Tech stack:

• ESP32 development board
• PMS5003 laser PM2.5/PM10 sensor
• MQ-135 gas sensor (qualitative trend)
• BME280 temperature/humidity/pressure sensor
• MQTT broker + cloud dashboard (web)
• Mobile push alert service
• Arduino IDE (C/C++ firmware)

• [Laser PM sensing] PMS5003 measures PM2.5 and PM10 by laser scattering — real particle counting, with fan-driven intake like reference-grade monitors.
• [Proper AQI computation] AQI is computed from PM2.5/PM10 using the standard breakpoint formula in firmware, with the standard color-coded health categories.
• [Gas trend sensing] MQ-135 reports total gas/VOC trends for context; presented honestly as qualitative, not as a certified gas concentration.
• [Environmental compensation] BME280 temperature, humidity and pressure readings accompany every sample for context and humidity-compensation reasoning.
• [Live dashboard] Current AQI gauge, pollutant graphs, 24-hour history and health-category banner, served as a working dashboard alongside the hardware.
• [Mobile push alerts] Configurable AQI thresholds (e.g. crossing into "Unhealthy") trigger push notifications carrying the measured PM values.
• [Burn-in and placement guidance] The deliverable documents the MQ-135 burn-in period and correct sensor placement — the practical details that make or break air sensing.

• Working air-quality node prototype (ESP32, PMS5003, MQ-135, BME280)
• Complete firmware source code (PM reading, AQI computation, MQTT telemetry, alert logic)
• Cloud pipeline + working dashboard (live AQI, graphs, alert log) demonstrated with the prototype
• Circuit and wiring documentation with burn-in and placement guidance
• Component list with ratings
• Buyer-run comparison procedure (side-by-side check against a reference station/app)
• Project report PDF (air-quality background, PM sensing and AQI theory, methodology, test procedure)
• PPT presentation for final review
• Viva Q&A preparation document (laser scattering, AQI formula, MQ-135 limits)
• Setup and demonstration guide

• The MQ-135 is a qualitative gas-trend sensor, not a calibrated gas analyzer — it is presented as context, never as a certified concentration.
• The PMS5003 is a real particle counter but a consumer-grade one; readings should be compared side-by-side with a reference during the buyer's own check, not treated as regulatory data.
• Humidity affects optical particle readings; the BME280 data is provided for context, and the report documents the limitation honestly.
• The MQ-135 needs a documented burn-in period (design target: 24–48 h powered) before readings stabilize.
• Alerts need internet on the node and the phone; outages queue nothing.