Built to order

IoT Forest Fire Early Warning Node with Smoke Sensing

This project builds a solar-powered LoRa sensor node that watches a forest patch for the two earliest signatures of a fire — smoke and abnormal heat. An MQ-2 smoke sensor and a DHT22 temperature-humidity sensor report every few minutes over a long-range LoRa link to a gateway, which forwards the data to a dashboard mapping every node, showing live gauges and history, and raising an early-warning alert when smoke or temperature crosses a configurable threshold. The demo ships as a multi-node network with the full sensor-to-alert chain working. This is an educational prototype demonstrating

IoT Forest Fire Early Warning Node with Smoke Sensing — project thumbnail preview
More project photos (2)

The problem

Forest fires spread fastest in their first minutes, yet most forest patches have no continuous sensing — discovery still depends on patrols, towers or bystanders. An always-on, solar-powered node that reports smoke and heat anomalies over kilometres of forest with no cellular or Wi-Fi coverage is the practical answer, and LoRa fits that link exactly. This project builds a remote LoRa sensor node carrying an MQ-2 smoke sensor and a DHT22 temperature-humidity sensor, powered by a small solar panel with battery backup. Nodes report on a configurable interval to a LoRa gateway, which forwards readings to a dashboard that maps each node, shows live gauges and history charts, and raises early-warning alerts when smoke or temperature crosses user-configured thresholds. The deliverable is demonstrated as a multi-node demo network with the full sensor-to-alert chain working: real uplinks, a real alert banner, and a timestamped event log. It is an educational prototype — it demonstrates long-range IoT sensing and threshold-based alerting, and it is explicitly not a certified fire-safety or fire-detection system.

How it works

  1. The ESP32 wakes on a timer, powers the MQ-2 and DHT22, and samples smoke (analog voltage) plus temperature and humidity.
  2. Readings are packed into a compact LoRa payload with the node ID and battery voltage, then transmitted on 433 MHz at the configured spreading factor.
  3. The gateway's LoRa receiver decodes the packet and forwards it over Wi-Fi to the dashboard backend.
  4. The dashboard updates the node's map marker, gauges and history chart, and logs the reading with a timestamp.
  5. If smoke or temperature exceeds the configured threshold for the configured number of consecutive readings, the alert state is raised.
  6. On alert, the dashboard shows the warning banner, the gateway buzzer sounds, and notifications are queued to the configured recipients.
  7. Between readings the node returns to deep sleep, stretching the solar-charged battery across cloudy days.

Tech stack:

  • ESP32 (node controller + gateway controller)
  • SX1278 LoRa modules, 433 MHz ISM
  • MQ-2 smoke/gas sensor, DHT22 temperature-humidity sensor
  • 5 V solar panel, 18650 Li-ion battery, TP4056 charger
  • Arduino (C++) firmware
  • Gateway dashboard: HTML, CSS, JavaScript
Parameter Value
Smoke sensor MQ-2; datasheet detecting scope 300–10,000 ppm (combustible gas/smoke), heater 5 V ±0.1, warm-up ~24 h; output analog, mapped to an uncalibrated ppm estimate
Temperature / humidity DHT22: −40 to 80 °C (±0.5 °C), 0–100% RH (±2% RH typical); sampling ≤ 0.5 Hz (datasheet)
LoRa radio SX1278, 433 MHz ISM; TX +20 dBm, sensitivity −148 dBm at SF12 (datasheet); range ≈ 2–5 km rural line-of-sight (design target, terrain-dependent)
Controller ESP32, 240 MHz dual-core; deep-sleep between readings
Power 5 V 1 W solar panel; 3.7 V 2600 mAh Li-ion (expected); TP4056 charging; ≈ 3–5 days autonomy without sun (design target)
Uplink interval Configurable; default 10 min
Alert logic N consecutive threshold breaches (configurable, default 3) → early-warning alert
Gateway output LoRa receiver → Wi-Fi dashboard, local buzzer, configurable notifications

Project features

  • [Smoke plus climate sensing] An MQ-2 smoke/gas sensor and a DHT22 temperature-humidity sensor are sampled together on every reading, so abnormal heat confirms a smoke event instead of one signal triggering alone.
  • [LoRa long-range uplink] An SX1278 LoRa radio (433 MHz ISM) carries readings to the gateway from kilometres away — no Wi-Fi or cellular coverage needed in the forest patch.
  • [Solar-powered node] A 5 V solar panel charges a Li-ion battery through a TP4056 module, and the ESP32 sleeps between readings, targeting multi-day autonomy without sun (design target).
  • [Gateway dashboard] The dashboard maps every node, shows per-node gauges for smoke/temperature/humidity/battery, 24-hour history charts, configurable thresholds and a timestamped alert event log.
  • [Threshold early-warning alerts] User-set smoke and temperature limits; a configurable number of consecutive breaches raises an alert banner, sounds the gateway buzzer and queues notifications.
  • [Configurable without reflashing] Node ID, uplink interval and alert thresholds are set in firmware configuration, so tuning for the demo needs no code rebuild.
  • [Field calibration procedure] A documented baseline procedure records ambient smoke levels and sets thresholds above the noise floor — no detection accuracy is invented or claimed.
  • [Viva-ready documentation] Report with LoRa link budget, sensor datasheets, threshold design rationale and the limitations stated plainly, plus PPT and Q&A.

What is included

  • Sensor node prototype (ESP32 + SX1278 LoRa + MQ-2 + DHT22, solar-powered)
  • LoRa gateway receiver prototype with buzzer output
  • Node and gateway firmware (Arduino/C++) with documented configuration
  • Gateway dashboard web app (node map, gauges, history, thresholds, event log)
  • Wiring diagram and enclosure guidance
  • Field calibration and threshold-setting procedure document
  • Project report PDF (LoRa link design, sensor datasheets, alert logic, honest limitations)
  • PPT presentation for final review
  • Viva Q&A preparation document (LoRa modulation basics, MQ-2 sensing principle, power budgeting)

Limitations & prerequisites

  • This is an educational prototype, not certified fire-safety equipment — it must not be presented or used as a real fire-detection or life-safety system.
  • The MQ-2 senses smoke crudely; it is not calibrated to any fire standard, and dust, vehicle exhaust or nearby cooking smoke can trigger false alerts.
  • No detection accuracy or detection-range figure is claimed — alert thresholds are set by the buyer-run baseline procedure in the calibration document.
  • LoRa range of 2–5 km is a design target; hills, dense canopy and antenna placement reduce it, and coverage is not guaranteed.
  • Battery autonomy of 3–5 days without sun is a design target, not a measured figure; it depends on panel size, sunlight and uplink interval.
  • The gateway needs Wi-Fi to serve the dashboard and send notifications; a node cannot raise an alert if its LoRa link to the gateway is down.
  • The dashboard demo ships with simulated data for the viva demonstration; live readings appear when the hardware is connected.

Frequently Asked Questions

Is this a certified fire-alarm system?

No. It is an educational prototype that demonstrates long-range IoT sensing and threshold-based early-warning alerting. It must not be described or deployed as certified fire-safety or life-safety equipment.

How does the MQ-2 detect smoke, and how accurate is it?

The MQ-2's heated sensing element changes resistance in the presence of smoke and combustible gases; the module outputs an analog voltage the ESP32 reads. It is a crude indicator, not a calibrated measurement, so no detection accuracy is claimed — the calibration document walks through recording an ambient baseline and setting thresholds above it.

How far can the sensor nodes be from the gateway?

The design target is 2–5 km in open rural terrain with line of sight (SX1278 datasheet: +20 dBm TX, −148 dBm sensitivity). Forest canopy and hills reduce real range; the report includes a link-budget calculation you can rerun for your site.

What powers the node in the forest?

A 5 V solar panel charges a Li-ion battery through a TP4056 module, and the ESP32 deep-sleeps between readings. Multi-day cloudy-weather autonomy is a design target; the power budget in the report shows how uplink interval trades against it.

What exactly happens when smoke crosses the threshold?

The reading must breach the threshold for a configurable number of consecutive uplinks (default 3). Then the dashboard raises an alert banner on the node, the gateway buzzer sounds, and notifications are queued to the configured recipients — the full chain is demonstrated live.

Is this project suitable for a final-year project?

Yes — for IoT, Embedded Systems and Electronics programs. It combines embedded sensing, LoRa wireless communication, solar power budgeting and a dashboard application, with honest, well-documented limitations. Suitable for B.E./B.Tech final-year projects in IoT, Embedded Systems and Electronics.

Components & software requirements
  • ESP32 (node controller + gateway controller)
  • SX1278 LoRa modules, 433 MHz ISM
  • MQ-2 smoke/gas sensor, DHT22 temperature-humidity sensor
  • 5 V solar panel, 18650 Li-ion battery, TP4056 charger
  • Arduino (C++) firmware
  • Gateway dashboard: HTML, CSS, JavaScript
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