ESP32-Based Energy Monitoring and Audit Dashboard for a Polytechnic Workshop (Python + pandas)

ESP32-Based Energy Monitoring and Audit Dashboard for a Polytechnic Workshop answers a question every principal asks and nobody can answer: where does the electricity bill actually go? The project instrumented our own polytechnic workshop — lathe, drilling machine, welding bay and the general lighting circuit — with split-core CT clamps and a voltage sensor read by an ESP32, which computes true RMS voltage, current, real power and cumulative kWh per machine.

Each ESP32 posts its readings over the workshop's Wi-Fi to a small Python server (Flask) that stores them in SQLite. A pandas-based analysis layer and a Streamlit dashboard then turn the raw stream into the audit: load profiles per machine, consumption during off-hours (the wastage nobody sees), power-factor behaviour of induction motors, and cost estimates using the polytechnic's actual LT tariff per kWh from its electricity bill. The audit itself is written up in a Jupyter notebook, with Git tracking every change — exactly the AI&ML-pathway toolchain the C-20 curriculum teaches.

Safety and honesty are designed in: the CT clamps clip on outside the insulation and never break the circuit, the rig runs on low-voltage sensing electronics, and every measurement is calibrated and cross-checked against a plug-in energy meter. The result is an intermediate project with a real deliverable — a workshop energy audit with numbers a decision-maker can act on.

A polytechnic workshop's electricity use is visible only as one undifferentiated monthly bill. Nobody can say which machine consumed what, when consumption actually happens, or how much energy is wasted by equipment left on after hours. Without that breakdown, saving measures are guesses, and the college cannot teach energy auditing with real data from its own plant. The problem is the absence of affordable per-machine metering and analysis. What is needed is a low-cost monitoring system that measures each machine's voltage, current, real power and energy non-invasively, stores the readings centrally, and analyses them into a proper energy audit — load profiles, wastage quantification and cost attribution — using the Python data tools the curriculum already teaches.

Abstract

Polytechnic workshops run motors, welders and lighting for hours with no per-machine metering; the only feedback is one monthly bill for the whole campus. This project builds a distributed energy-monitoring system: ESP32 nodes with CT clamps measure per-machine consumption, a Python server stores the data, and a pandas-driven dashboard converts it into an actionable energy audit — load profiles, off-hours wastage, power-factor behaviour and cost breakdowns at the polytechnic's own tariff.

Introduction

Energy audits in India are formalised by the Bureau of Energy Efficiency, but a professional audit costs far more than a polytechnic can justify for one workshop. Yet the data needed for a basic audit — current and voltage over time — is measurable with a few hundred rupees of sensors and the microcontroller interfacing skills the C-20 curriculum teaches. Building the audit ourselves also makes it a genuine engineering exercise: sampling, RMS computation, calibration, data pipelines and analysis, each defensible in the viva.

Existing System

• The workshop shares one campus meter; the bill arrives monthly with no machine-level or time-of-day breakdown.
• Machines are switched off by habit, not by schedule, and nobody knows how much a lathe left idling or lamps left burning overnight actually costs.
• Any checking is done occasionally with a clamp meter — a snapshot with no history.
• Limitations: no per-machine kWh, no load profile, no quantified wastage, no data to prioritise saving measures.

Proposed System

• Sensing: a split-core SCT-013 CT clamp per monitored circuit (never breaking the wire) and a ZMPT101B for the supply voltage, read by the ESP32's ADC.
• Metering firmware: sample both channels at about 1 kHz, compute true RMS voltage, current, real power (instantaneous product method) and cumulative kWh; batch and post readings to the server every minute as JSON over HTTP.
• Server: a Flask API that validates and stores readings in SQLite; a seed script generates demo data for offline demonstration.
• Analysis: pandas and NumPy resample the stream into hourly/daily profiles; a Jupyter notebook computes machine-wise costs at the polytechnic's tariff, off-hours consumption, and the top savers list.
• Dashboard: a Streamlit app showing live power, machine-wise kWh, load profiles and the audit summary, with CSV export.
• Calibration: every channel is cross-checked against a plug-in energy meter across resistive and motor loads, and the errors are recorded.

Feasibility Study

• Technical: the measurement chain uses skills from the C-20 pathway — Python for the server and analysis, Jupyter and Git for the audit workflow — plus straightforward ESP32 interfacing; all software is free and runs on the lab PC.
• Economic: about ₹2,000–₹2,500 of hardware (often less if the department owns a reference meter), no recurring cost, and realistic saving potential: even 1 kWh/day of identified wastage is over ₹2,000 a year at typical LT tariffs.
• Operational: clamps install in minutes without an electrician, the dashboard runs in a browser, and the audit notebook regenerates itself whenever new data arrives.

In scope

• One workshop with up to four monitored circuits (lathe, drilling machine, welding bay, lighting), one ESP32 node with two CT channels in the base build and a second node optional.
• Continuous monitoring during working hours, a server and dashboard on the lab PC, calibration records, and a written audit with tariff-based costs.
• Demo mode: a seed script generates a realistic month of data so the system can be demonstrated anywhere without the workshop.

Out of scope (v1)

• No control or automatic switching of machines — the project measures and advises; it does not actuate.
• No three-phase motor metering (welding bay is monitored as a single-phase approximation; three-phase metering is future work).
• No cloud deployment or mobile app; the server runs on the department PC. No billing-grade accuracy claim — the system is an audit instrument, calibrated against but not replacing the utility meter.

The project follows an iterative model across the 16-week C-20 slot, with each increment ending in something demonstrable and every review backed by the weekly diary.

Testing approach: unit tests (pytest) cover the pure functions — RMS and power computation vectors, tariff calculations, off-hours classification — while the firmware is verified against reference loads and the plug-in meter (expected vs measured, recorded as error percentages). The full pipeline is tested end-to-end with the seed data before live deployment, and every module carries the name of the member who built it for individual accountability.

The system has three tiers: measurement nodes, a server pipeline and an analysis/dashboard layer, connected over the workshop Wi-Fi.

flowchart LR
  M1["Lathe (CT 1)"] --> S["ESP32 node: 1 kHz sampling"]
  M2["Drilling machine (CT 2)"] --> S
  V["ZMPT101B voltage tap"] --> S
  S -->|"RMS, real power, kWh"| W["Wi-Fi JSON POST every 60 s"]
  W --> API["Flask API with validation"]
  API --> DB[("SQLite readings DB")]
  NB["Jupyter + pandas + NumPy"] -->|"reads"| DB
  NB --> AUD["Audit: profiles, costs, wastage"]
  D["Streamlit dashboard"] -->|"reads"| DB
  D --> CSV["CSV export"]

Measurement node. Each CT clamp feeds a burden resistor; a bias network lifts the signal to mid-rail so the ESP32's ADC sees the full AC waveform. Firmware samples voltage and current together at about 1 kHz, multiplies the instantaneous pairs and averages to get real power, and derives Vrms, Irms and power factor — the same mathematics a commercial meter performs, done openly so we can defend every step.

Server. The Flask API validates each JSON payload (machine id, timestamp, Vrms, Irms, watts, kWh, pf), rejects malformed rows, and appends to SQLite. The schema is deliberately small:

erDiagram
  MACHINE ||--o{ READING : logs
  MACHINE {
    int id PK
    string name
    string circuit
    real tariff_per_kwh
  }
  READING {
    int id PK
    int machine_id FK
    datetime ts
    real vrms
    real irms
    real watts
    real kwh_cumulative
    real pf
  }

Analysis and dashboard. pandas resamples readings into hourly and daily frames; the audit notebook computes machine-wise kWh and rupees, flags off-hours consumption, and plots load profiles with Matplotlib. Streamlit serves the same frames live. Everything — firmware configs, server, notebook — lives in one Git repository with each member committing their own modules, and pytest guards the arithmetic: the RMS and cost functions are tested against hand-calculated vectors before any real data is trusted.

• Three-phase metering for heavier machines using a dedicated energy-metering IC, opening up the compressor and the main panel.
• Control pilot: a relay node that can switch the lighting circuit on a schedule, turning the audit's findings into automatic savings.
• MQTT and a lightweight broker instead of HTTP POST, with retained messages for resilience.
• A cloud or college-server deployment with a month-on-month savings tracker and email summaries to the HOD.
• Anomaly detection on the load profiles — a motor drawing more current than its own history is a maintenance warning.
• Extension to the whole building with multiple nodes and a floor-plan heatmap of consumption.