Smart Energy Meter.

Project Overview

A single whole-home meter that not only shows real-time consumption but disaggregates it into appliance-level insights — telling you what is using power, from one measurement point.

A conventional meter gives you one number: total consumption. It cannot tell you that the geyser is your biggest cost, that a fridge is failing and drawing more each week, or that something is left on overnight. Sub-metering every circuit is expensive and invasive. This project takes a smarter route: a single whole-home meter that measures the total, and then disaggregates that total into appliance-level insights using the technique called non-intrusive load monitoring (NILM) — inferring which appliances are running, and how much each is using, from the aggregate signal at one measurement point.

The foundation is accurate real-time whole-home measurement — real power, energy and power factor from a CT clamp or meter module on the incoming supply. On top of that sits the disaggregation: appliances have characteristic signatures in the aggregate power signal — a heating element switches on as a clean rectangular step of a specific size, a motor draws an inrush spike then settles, an electronic device has its own pattern — so when the total power steps up by ~2 kW in a rectangular fashion, that is very likely the geyser turning on. By detecting these on/off events and matching their signatures to known appliances, the meter attributes the total consumption to individual loads without a sensor on each one.

The result is genuinely useful: real-time and historical consumption, a breakdown of which appliances cost the most, alerts when an appliance behaves abnormally (a fridge cycling too often, a heater left on), and the data to actually reduce a bill. It is honest that NILM is an inference, not a measurement — it works best for larger, distinct loads and struggles to separate several small or similar appliances, and it needs a training/learning phase to recognise a home's specific appliances — so its appliance figures are informative estimates, not billing-grade sub-metering. But as a single-point meter that combines accurate whole-home measurement with appliance-level disaggregation, it delivers most of the value of expensive per-circuit sub-metering from one clamp, turning an opaque bill into an itemised, actionable picture of where the energy goes.

What this project does

• Measures accurate real-time whole-home power, energy and power factor
• Disaggregates the total into appliance-level usage (NILM)
• Detects appliance on/off events by their power signatures
• Attributes consumption and cost to individual appliances
• Learns a home's specific appliances during a training phase
• Alerts on abnormal appliance behaviour (failing/left-on)
• Turns an opaque bill into an itemised, actionable breakdown

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• Single-point measurement, appliance-level insight
• Event-detection + signature-matching NILM
• Real power/energy/PF whole-home base
• Per-appliance cost breakdown
• Learned per-home appliance models
• Abnormal-behaviour alerts
• Honest: NILM is inference, not per-appliance metering

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• Whole-home real-power measurement (CT/meter)
• Event detection in the aggregate power signal
• Appliance signature extraction and matching (NILM)
• Learning/training per-home appliance models
• Consumption attribution and alerting

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹5,050, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 3330 mA. With a 1.5× design margin the supply should deliver at least 5000 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x with the ESP32 board package 3.x (or PlatformIO on VS Code). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Measure whole-home real power (and power factor) with a CT + voltage reference or a metering module on the incoming supply; have a qualified electrician do the mains-side install.
• Sample fast enough to capture appliance switching transients if using transient signatures; steady-state step detection needs less.
• Keep the low-voltage electronics isolated from the mains measurement.
• For heavier NILM/ML, offload to a Pi/server; the ESP32 can do simple event-based disaggregation.
• Log data during a training phase so appliance signatures can be learned.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

The meter's ambition is to give appliance-level insight from a single measurement point, which is valuable because per-appliance sub-metering is expensive and invasive while a single whole-home meter is cheap and non-invasive. The bridge between the two is non-intrusive load monitoring — the idea that the aggregate electrical signal at the meter contains, mixed together, the individual contributions of every running appliance, and that with the right processing you can pull those contributions back apart. It rests on accurate whole-home measurement as its foundation and clever inference as its magic.

The foundation must be solid: accurate real-power measurement of the whole home, including power factor, because everything downstream is inference on top of it. A CT clamp with a voltage reference (or a metering module) on the incoming supply gives real-time total power and energy. This alone is useful — real-time consumption feedback measurably reduces usage — but it is the raw material for the disaggregation.

Disaggregation works because appliances have distinctive signatures in the aggregate signal. When an appliance switches on or off, the total power steps, and the size and shape of that step is characteristic: a resistive heater (geyser, kettle, iron) switches as a clean, rectangular step of a specific magnitude; a motor (fridge compressor, pump) shows a brief inrush spike then settles to a running level; electronic devices have their own patterns; some appliances even cycle in recognisable rhythms. The classic, tractable NILM approach is event-based: detect these on/off events in the power stream, extract each event's signature (step magnitude, transient shape, power factor change), and match it to a library of known appliance signatures, thereby attributing that chunk of consumption to that appliance. More advanced NILM uses machine-learning models, but the event-and-signature approach captures the core idea and runs on modest hardware.

The output is an itemised, actionable picture — which appliances cost the most, when they run, and how their behaviour changes — enabling real savings and catching faults (a fridge cycling too often, a heater left on). But the design is honest about NILM's nature: it is an inference, not a measurement, and it has real limits. It works best for larger, distinct loads whose signatures stand out, and struggles to separate several small or similar appliances whose events overlap or look alike; it needs a learning/training phase to recognise a specific home's appliances, since signatures vary between makes and models; and its attributions are best-estimates, not billing-grade sub-metering. So the meter presents appliance figures as informative estimates, is upfront about uncertainty, and leans on the rock-solid whole-home total for anything that must be exact. Within that frame, it delivers most of the value of expensive per-circuit metering from a single clamp — the genuinely useful trick of turning one aggregate signal into an appliance-by-appliance understanding of where a home's energy, and money, goes.

The maths behind it

Whole-home real power (foundation)

P = V_rms · I_rms · cosφ   (real power, W)
E = ∫ P dt                  (energy, kWh)

Accurate real power + power factor is the base signal NILM
disaggregates. Current alone (apparent power) is not enough.

Event detection

Detect steps in the power stream:

  ΔP = P(t) − P(t−Δ)
  event if |ΔP| > threshold (sustained)  → appliance on/off

Each event's magnitude, sign and transient shape form its
signature.

Signature matching (NILM)

Match an event signature s to appliance models {m}:

  appliance = argmin_m distance(s, signature(m))
  attribute the step power to that appliance until its OFF event

Best for large/distinct loads; small/similar loads overlap →
report as estimates, learn per-home models.

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Install accurate whole-home measurement

   Fit a CT + voltage reference (or metering module) on the incoming supply for real power/PF, installed by a qualified electrician, with the electronics isolated from the mains.

   Sample fast enough to capture the switching transients your NILM method uses.

2. Set up event detection and learning

   Detect on/off events in the power stream and log a training period so appliance signatures can be learned (label known appliances by switching them).

3. Set up disaggregation and reporting

   Match events to appliance models, attribute consumption, and report the breakdown and alerts; offload heavier NILM to a Pi/server if needed.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Detect events and disaggregate

   Detect power steps, extract each event's signature, match to the appliance library, and attribute consumption until the matching off-event.

   pythonnilm-event.py Copy Download

   # Event-based NILM: detect steps, match signatures, attribute energy.
   import numpy as np
   
   class Appliance:
       def __init__(self, name, step_w, pf, tol=0.15):
           self.name, self.step_w, self.pf, self.tol = name, step_w, pf, tol
       def matches(self, dP, pf):
           return abs(dP - self.step_w) < self.tol*self.step_w and abs(pf-self.pf)<0.1
   
   def detect_events(power, pf, thresh=150):
       events = []
       for t in range(1, len(power)):
           dP = power[t] - power[t-1]
           if abs(dP) > thresh:                      # a step = appliance on/off
               events.append((t, dP, pf[t]))
       return events
   
   def disaggregate(events, library):
       active = {}                                    # appliance -> power
       usage  = {a.name: 0.0 for a in library}
       for (t, dP, pf) in events:
           if dP > 0:                                 # turn-on
               for a in library:
                   if a.matches(dP, pf): active[a.name] = dP; break
           else:                                      # turn-off
               for name, p in list(active.items()):
                   if abs(-dP - p) < 0.2*p: del active[name]; break
       return active, usage

   def detect_events(power, pf, thresh=150)Finds steps in the aggregate power — the on/off events of individual appliances that NILM keys on.

   def matches(self, dP, pf)An appliance is recognised when a power step matches its characteristic magnitude and power factor, the essence of signature matching.

   if dP > 0: # turn-onA positive step is an appliance turning on and is matched to the library; the attributed power runs until its off-event.

   if abs(-dP - p) < 0.2*p: del active[name]A negative step near a known active appliance's power is that appliance turning off, closing its usage interval.

2. Attribute, alert and report

   Accumulate per-appliance energy and cost, alert on abnormal behaviour (a fridge cycling too often, a heater left on), and report the breakdown — clearly labelling appliance figures as estimates.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

/* ═══════════════════════════════════════════════════════════════
   Smart Energy Meter — ESP32 (whole-home + event NILM)

   Measures accurate whole-home real power/energy/PF and disaggregates
   into appliance-level usage by detecting on/off power events and
   matching their signatures. Appliance figures are ESTIMATES.
   ══════════════════════════════════════════════════════════════════ */

#include <WiFi.h>
#include <PubSubClient.h>
#include <PZEM004Tv30.h>

#define STEP_THRESH 150.0f    // W step = an appliance event

PZEM004Tv30 pzem(Serial2, 16, 17);
WiFiClient net; PubSubClient mqtt(net);

struct Appliance { const char* name; float stepW; float pf; float energyWh; };
Appliance lib[] = {
  {"Geyser", 2000, 1.00, 0}, {"Fridge", 150, 0.65, 0},
  {"AC", 1200, 0.90, 0}, {"Kettle", 1500, 1.00, 0} };
const int NA = 4;
float prevP = 0; int activeIdx = -1; uint32_t activeSince = 0;

int matchAppliance(float dP, float pf){
  for (int i=0;i<NA;i++)
    if (fabsf(dP - lib[i].stepW) < 0.15f*lib[i].stepW &&
        fabsf(pf - lib[i].pf) < 0.1f) return i;
  return -1;
}

void setup(){
  Serial.begin(115200);
  WiFi.begin(WIFI_SSID,WIFI_PASS); mqtt.setServer(MQTT_HOST,1883);
}

void loop(){
  if(!mqtt.connected()&&WiFi.status()==WL_CONNECTED) mqtt.connect("meter-1");
  mqtt.loop();

  float p  = pzem.power();          // whole-home REAL power (foundation)
  float e  = pzem.energy();         // whole-home energy (exact)
  float pf = pzem.pf();
  if (isnan(p)) { delay(1000); return; }

  float dP = p - prevP; prevP = p;
  uint32_t now = millis();

  if (dP > STEP_THRESH){                              // an appliance turned on
    int idx = matchAppliance(dP, pf);
    if (idx>=0){ activeIdx=idx; activeSince=now; }
    char m[80]; snprintf(m,sizeof m,"{\"on\":\"%s\",\"step\":%.0f}",
      idx>=0?lib[idx].name:"unknown", dP);
    mqtt.publish("meter/event", m);
  } else if (dP < -STEP_THRESH && activeIdx>=0){       // turned off
    float hrs = (now-activeSince)/3600000.0f;
    lib[activeIdx].energyWh += lib[activeIdx].stepW * hrs;   // attribute (est.)
    activeIdx = -1;
  }

  // whole-home total is exact; appliance breakdown is estimated
  char m[240];
  int n = snprintf(m,sizeof m,"{\"total_W\":%.0f,\"energy_kWh\":%.3f,\"appliances\":{", p, e);
  for(int i=0;i<NA;i++)
    n += snprintf(m+n,sizeof m-n,"\"%s\":%.0f%s",
      lib[i].name, lib[i].energyWh, i<NA-1?",":"");
  snprintf(m+n,sizeof m-n,"}}");
  mqtt.publish("meter/1/breakdown", m);

  delay(1000);
}

Configuration & Calibration

Configuration steps

• Configure whole-home real-power measurement and the event-detection threshold.
• Build/learn the appliance library (signatures) during a training phase for the specific home.
• Set tariff for cost attribution and abnormal-behaviour alert rules.
• Choose on-device (event NILM) vs offloaded (ML) disaggregation.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. Whole-home accuracy

   Verify real power/energy against a reference; this foundation must be accurate.

2. Appliance learning

   Run the learning phase switching known appliances so their signatures are captured; validate detections.

3. Thresholds

   Tune the event threshold and match tolerances to detect real appliance events without excess false ones.

Dataset, Model & Training

Dataset

NILM can use event-and-signature matching (lightweight, on-device) or trained machine-learning models. For ML NILM, models are trained on labelled aggregate-power data where individual appliance states are known, learning to disaggregate the total.

A per-home learning phase (switching known appliances while recording) captures that home's specific signatures, which vary by make/model.

Data preprocessing

• Compute real power (and power factor) from voltage/current; resample to the analysis rate.
• Detect events (steps) and extract features per event (step magnitude, transient shape, PF change).
• Label events with the known appliance during the learning phase.

Model architecture

Event NILM: a rule/nearest-signature matcher (tiny, on-device). ML NILM: models such as combinatorial optimisation, factorial HMMs, or neural sequence models (on a Pi/server).

Match compute to method — the ESP32 handles event NILM; heavier ML runs offloaded.

Hyperparameters

Training process

• Record a learning period labelling each appliance's events to build/adapt its signature.
• For ML NILM, train on labelled aggregate data and validate on held-out homes/periods.
• Focus accuracy on large, distinct loads; accept lower accuracy for small/similar ones.

Evaluation, Metrics & Deployment

NILM accuracy is judged per appliance (did we detect it, and estimate its energy) and overall (how much of the total is correctly attributed).

Figures from the reference training run described above — reproduce them before trusting your own changes.

Deployment

• Run event NILM on the ESP32 or offload ML NILM to a Pi/server; keep the exact whole-home total authoritative.
• Present appliance figures as estimates with confidence; refine with the learning phase.
• Log data to improve models over time.

Inference example

# Per-event appliance inference (event NILM).
def infer_event(dP, pf, library):
    best, best_d = None, 1e9
    for a in library:
        d = abs(dP - a.step_w)/a.step_w + abs(pf - a.pf)
        if d < best_d and abs(dP - a.step_w) < 0.15*a.step_w:
            best, best_d = a, d
    return best        # None = unknown/overlapping load

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

The app shows live total consumption, a per-appliance breakdown and cost (as estimates), history, and alerts for abnormal/left-on appliances.

{
  "total_W": 2380,
  "energy_kWh": 512.4,
  "appliances": { "Geyser": 4200, "Fridge": 1100, "AC": 3300, "Kettle": 300 },
  "note": "appliance figures are NILM estimates; total is measured"
}

An accurate whole-home total with an estimated appliance breakdown — enough to see the geyser and AC dominate the bill and target them, while the total stays exact.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Keep the whole-home measurement accurate and continuous — it is the foundation.
• Run event NILM on-device; offload heavier ML to a Pi/server.
• Sample faster where transient signatures improve identification.
• Anchor exactness to the total; present appliance splits as estimates.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• For battery builds use deep sleep between samples: an ESP32 drops from ~160 mA awake to about 10 µA asleep, which is the difference between days and months of runtime.
• Profile before optimising — print micros() deltas around each stage and fix the slowest one first.

Safety Precautions

• Mains measurement is dangerous — use a qualified electrician for the mains-side install and isolate the electronics.
• NILM appliance figures are estimates, not billing-grade sub-metering — present them honestly.
• Respect privacy: appliance-usage data reveals occupancy/behaviour; secure and consent it.
• Keep the whole-home total authoritative for anything that must be exact.
• Mains voltage kills. Anything on the load side of the relay is at 230 V. Do not work on a powered circuit, and never leave exposed mains wiring on a bench where someone could touch it.
• Keep at least 6 mm of creepage between the mains and low-voltage sides of any board you make, and never route mains tracks under the microcontroller.
• Have a qualified electrician do the final installation into a consumer unit or wall fitting. In most jurisdictions this is a legal requirement, not a suggestion.
• Fit an RCD/RCBO upstream and fuse the load appropriately for its rating.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Re-run/extend the learning phase as appliances change.
• Verify whole-home accuracy periodically.
• Tune thresholds/models as usage patterns shift.
• Review alerts and refine appliance models.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Rotate the microSD card annually and keep an image of the working system. Cards used as loggers wear out silently.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add higher-rate transient signatures and ML NILM for better disaggregation.
• Add solar/export awareness for prosumer homes.
• Add appliance-level anomaly detection for predictive maintenance.
• Integrate demand-response and time-of-use optimisation.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add connectivity — an ESP32 and an MQTT publish turn a local gadget into something you can graph, alert on and analyse over months.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Non-intrusive load monitoring (NILM)Reference
2. Hart's NILM (original work)Reference
3. Power factor and real powerReference
4. Real-time energy feedback and savingsReference
5. NILM datasets (REDD/UK-DALE)Reference