Built to order

IoT LPG Cylinder Level Monitor with Refill Booking Alerts

This project weighs a domestic LPG cylinder continuously with a 50 kg load cell read by an ESP32 through an HX711 amplifier, converts the weight into a gas-level percentage, estimates days remaining from the household's average consumption, and fires low-level alerts with a one-tap refill-booking reminder on a companion web dashboard. The build covers the weighing platform hardware, the ESP32 firmware with tare and calibration, and the dashboard with a 30-day usage chart. Suitable for B.E./B.Tech final-year projects in Electronics, Electrical and IoT & Embedded.

IoT LPG Cylinder Level Monitor with Refill Booking Alerts — project thumbnail preview
More project photos (2)

The problem

Most households discover the cylinder is empty the moment the burner dies mid-cooking. Lifting the cylinder to guess the gas left is the common workaround, and it is unreliable — a 14.2 kg domestic cylinder's steel body weighs roughly 15 kg on its own, so "feels half" is mostly imagination. This project solves the problem the engineering way: it weighs the cylinder. A 50 kg single-point load cell sits under a steel weighing platform; an HX711 24-bit ADC digitises the tiny strain-gauge signal; an ESP32 turns raw weight into gas remaining by subtracting the stored tare, and estimates days remaining from the household's rolling average consumption. When the level crosses the alert threshold (20% default, configurable to 10%), the dashboard fires a low-level alert and a one-tap button sets a refill-booking reminder. A local 16x2 LCD shows live weight and status on the rig itself, so the sensing chain is demonstrable without a phone or browser.

How it works

  1. The LPG cylinder stands on a steel platform supported by a 50 kg single-point load cell; the load cell's four wires feed the HX711 amplifier module.
  2. The ESP32 reads the HX711 at gain 128 (channel A), applies moving-average filtering, and converts counts to kilograms using the two-point calibration factor from the buyer's calibration run.
  3. On first use the buyer stores the tare (empty cylinder weight, typically ~15 kg for a 14.2 kg domestic cylinder) in flash; gas remaining = total weight − tare.
  4. Gas percentage = gas remaining ÷ refill size; the firmware tracks the daily weight drop as a rolling average and computes days remaining = gas remaining ÷ average daily use.
  5. The ESP32 wakes from deep sleep every 15 minutes, takes a reading, serves the local dashboard over Wi-Fi, updates the 16x2 LCD, and sleeps again.
  6. When the level crosses the alert threshold, the dashboard banner fires and latches the event into the refill-alert log until a refill (weight jump) clears it.
  7. The "Book refill" button sets a booking reminder with the distributor details; a weight jump back near full marks the refill as completed in the log.

Tech stack:

  • ESP32 (Arduino framework)
  • 50 kg single-point load cell · HX711 24-bit ADC module
  • Steel weighing platform (fabricated)
  • 16x2 LCD (I2C)
  • HTML/CSS/JavaScript companion dashboard (single-file)
  • Deep-sleep power cycling · moving-average filtering
  • Wi-Fi (dashboard + optional MQTT)
Parameter Value
Load cell 50 kg single-point, strain gauge (datasheet)
ADC HX711 24-bit, gain 128 (channel A), ~10 SPS (datasheet)
Microcontroller ESP32, Arduino framework
Cylinder sizes 14.2 kg domestic / 5 kg / 19 kg (configurable)
Typical tare Approximately 15 kg for a 14.2 kg domestic cylinder (expected)
Weight resolution Approximately 10 g after filtering (design target)
Reading cycle Every 15 min, deep sleep between (expected)
Alert thresholds 20% default, 10% option (configurable)
Local display 16x2 LCD (I2C), weight + status

Project features

  • [Weight-based gas level] A 50 kg single-point load cell under a steel platform measures total cylinder weight; firmware subtracts the tare (empty cylinder weight) and divides by the refill size (14.2 / 5 / 19 kg) to report gas percentage.
  • [Days-remaining estimate] Daily consumption is learned as a rolling average of the weight drop, and the dashboard converts remaining gas into an estimated days-left figure with a predicted refill date.
  • [Low-level alerts] When the level crosses the configured threshold (20% default, 10% option), the dashboard banner turns critical and the event is logged to the refill-alert history until the cylinder is refilled.
  • [One-tap refill reminder] A "Book refill" button sets a refill-booking reminder and records it in the alert log, so the workflow from low gas to booked refill is demonstrable in one click.
  • [HX711 + ESP32 firmware] 24-bit ADC at gain 128 on channel A, moving-average filtering for stability, deep-sleep wake every 15 minutes, tare stored in flash, two-point calibration through the buyer's own weight procedure.
  • [Live web dashboard] Cylinder fill graphic, gas remaining in kg, days-left counter, total/tare weights, 30-day usage chart with alert-threshold line, node status (battery, Wi-Fi RSSI, load-cell state) and configurable alert thresholds.
  • [16x2 LCD readout] Live weight and STABLE/ALERT status on the hardware itself, so the prototype is demonstrable standalone.

What is included

  • Weighing platform prototype (load cell, steel plate, HX711, ESP32, 16x2 LCD, wiring)
  • ESP32 firmware source (tare, two-point calibration, filtering, deep-sleep cycle, dashboard server)
  • Companion web dashboard (single-file HTML/CSS/JS, the GasWatch demo)
  • Load-cell calibration procedure for the buyer
  • Project report PDF (background, load-cell/HX711 theory, methodology, circuit diagrams)
  • PPT presentation for final review
  • Viva Q&A preparation document (strain gauges, HX711, ADC resolution, calibration, deep sleep)

Limitations & prerequisites

  • This is a MONITOR only: it never actuates the cylinder valve and cannot shut off gas — no valve-control hardware or firmware is included.
  • It is NOT a gas-leak detector and does not replace one; it measures weight, not gas concentration in air.
  • Weight resolution of ~10 g is a design target achieved after filtering and the buyer's own two-point calibration — it is not a measured claim until the calibration run is done on the built unit.
  • Accuracy depends on the cylinder standing undisturbed on the platform; moving or leaning the cylinder during a reading skews that sample.
  • The days-remaining estimate assumes consumption near the recent average; a sudden change (festival cooking, guests) makes the estimate drift until the average relearns.
  • Wi-Fi range limits where the dashboard is reachable; there is no GSM/SMS fallback in the standard build.
  • Deep-sleep cycle means readings are 15 minutes apart by design — this is not a real-time safety system.

Frequently Asked Questions

How does it know how much gas is left without opening the cylinder?

It doesn't measure gas directly — it weighs the cylinder. Gas remaining = total weight minus the tare (empty cylinder weight). Since only the gas is consumed, the weight drop equals gas used.

What does the calibration involve?

A two-point procedure: place a known weight on the platform (a water bottle of known mass works) and enter the reading, repeat at a second weight, and the firmware computes the scale factor. It takes about ten minutes.

Can it work with a 5 kg or 19 kg cylinder?

Yes — the cylinder size is a dashboard setting (14.2 / 5 / 19 kg) and the tare is re-stored for whichever cylinder sits on the platform.

Does it actually book the refill with the gas agency?

No. The "Book refill" button sets a booking reminder and logs the event; completing the booking on the agency's app or IVR is the user's step. Direct agency API integration is listed as future scope.

Is it safe to put electronics under a gas cylinder?

The rig is a passive weighing platform — no sparking relays, no mains voltage near the cylinder, and the ESP32 runs on low-voltage DC. The unit never touches the valve or regulator.

Is this project suitable for a final-year project?

Yes — for Electronics, Electrical and IoT & Embedded programs. It combines sensor interfacing (strain gauge + 24-bit ADC), embedded firmware, calibration methodology and a companion dashboard in one demonstrable system. Suitable for B.E./B.Tech final-year projects in Electronics, Electrical and IoT & Embedded.

Components & software requirements
  • ESP32 (Arduino framework)
  • 50 kg single-point load cell · HX711 24-bit ADC module
  • Steel weighing platform (fabricated)
  • 16x2 LCD (I2C)
  • HTML/CSS/JavaScript companion dashboard (single-file)
  • Deep-sleep power cycling · moving-average filtering
  • Wi-Fi (dashboard + optional MQTT)
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