How CT Energy Measurement Really Works — From Clamp to Kilowatt-Hours

You clip a current transformer around a wire, wire it into an ESP32, and Home Assistant lights up with watts and kilowatt-hours. Then you check it against the meter on the wall — and the numbers don't agree. One Home Assistant user summed up the whole genre of forum post:

"Since the install yesterday it showed me a usage of 6 kWh. But when I looked at my electricity meter, it only says 4.8 kWh."

That's a ~25% gap on day one. On the OpenEnergyMonitor forum someone had it far worse — "emoncms with SCT-013-000 = 53 kWh and electricity meter = 8 kWh for ~20 hours." These people didn't wire anything wrong. They ran into the physics of what a clamp actually measures, and the several places a reading can drift between the copper and the dashboard. This article walks the whole chain so you know exactly where accuracy comes from — and where it leaks.

A CT clamp measures current, not power

Start with the sensor. A split-core current transformer is a ring of iron that clamps around one conductor. The alternating current in that wire creates an alternating magnetic field; the field induces a proportional current in the CT's winding. A CT with a 2000:1 turns ratio passing 30 A in the primary gives you 15 mA in the secondary. That's the entire trick — and notice what it gives you: current. Amps. Nothing else.

That single fact is behind a huge share of "my readings are wrong" threads. As one r/esphome user asked, exactly right:

"Is the ADC measuring current or power? A CT clamp can't determine power by itself. You also need voltage and phase angle or power factor."

Hold onto that. A clamp alone can never tell you watts. To get power you have to combine its current with the voltage and the timing relationship between them. Skip either and you're not measuring power — you're estimating it, and the estimate has a predictable bias we'll get to.

The burden resistor and the signal

The CT's secondary current has to become a voltage the ESP32's ADC can read. That's the job of the burden resistor: current through a known resistance makes a proportional voltage. Size it wrong and you either clip the waveform on big loads or lose the small ones in noise.

This is also where the classic DIY CT, the SCT-013, splits into two families. The common SCT-013-030 (and its 5/10/20/50 A siblings) has the burden resistor built in and outputs a voltage directly — easy, and what most modules expect. The bare SCT-013-000 outputs current and expects you to add the burden; get that wrong and you're the 53-kWh-vs-8-kWh person. Either way, the burden is a real link in the accuracy chain, not an afterthought.

From a wiggly wave to a single number: RMS

Mains current isn't a steady value — it's a wave, 50 or 60 times a second, and often not a clean sine at all. To turn it into one "current" figure you compute the RMS (root-mean-square): square every sample, average, take the square root. Do it over enough samples and you get a true reading regardless of wave shape.

The shortcut that bites people is assuming the wave is a clean sine and computing RMS from a single measured value. Modern loads — LED drivers, computer power supplies, variable-speed motors — draw current in sharp, distorted pulses. On those, an assumed-sine calculation is simply wrong. True-RMS sampling — enough points across each cycle — is what keeps a distorted-waveform load honest.

Current isn't power — you need voltage and phase

Now the big one. Power is not volts times amps. It's:

P = V × I × cos φ

You need the voltage, the current, and cos φ — the cosine of the phase angle between them. On a purely resistive load (a kettle, an incandescent bulb, a heater) voltage and current rise and fall together, cos φ ≈ 1, and V × I happens to equal the real power. On everything else — motors, compressors, fluorescent ballasts, switch-mode supplies — current lags or leads voltage, cos φ < 1, and V × I overstates the real power by exactly 1/cos φ.

This is the "real power vs apparent power" distinction, and it's the honest answer to a whole category of "my clamp reads too high" reports. As one r/homeassistant reply nailed it:

"The difference is real vs apparent power and will have the clamp meter reading higher than the billed current."

• Real power (W) — what does work and what you're billed for. Needs V, I and phase.
• Apparent power (VA) — just V × I. Always ≥ real power. What you get if you measure current and multiply by an assumed voltage.
• Power factor — real ÷ apparent = cos φ. The gap between the two.

Any monitor that clamps current and multiplies by a voltage — without measuring the phase on that same circuit — is reporting apparent power dressed up as watts. It's fine for "which circuit is drawing and roughly how much," and it's genuinely useless for reconciling with your bill on reactive loads.

Phase error and why calibration exists

Even when a monitor does measure voltage and phase, the CT itself introduces a small phase shift between the real current and the one it reports. At high load it's negligible. At low current it dominates — and it's not a defect. As OpenEnergyMonitor's Robert Wall puts it:

"Errors, and particularly phase errors, increase at very low currents, and it's inherent."

Correcting it means phase compensation — a per-sensor calibration that lines the current back up with the voltage. Do it well and low-power-factor loads read correctly; skip it and, as one emonlib user found, your "power factor calculations [are] fairly inaccurate … the culprit [is] the linear interpolation used to compensate for a phase offset."

Which is why calibration is the difference between a monitor you trust and one you fight. The realistic DIY answer, again from the OpenEnergyMonitor forum, is sobering:

"With careful calibration over a period of time (weeks, probably), you should get the energy (kWh) to match to better than 5% … you will never get an exact match, because the two are reading different quantities."

Two honest truths live in that sentence. First, a generic CT can be calibrated — but it's weeks of nudging. Second, no CT clamp will ever exactly match a revenue meter, because it's measuring something slightly different under different assumptions. A monitor that's individually factory-calibrated and phase-compensated starts where that person ended up, without the weeks — but it still lives inside that "different quantities" truth. Anyone promising a perfect match is selling you something.

From watts to kilowatt-hours: where energy leaks

Power is instantaneous; energy is power added up over time. Get a watt figure every second, multiply by the seconds, keep a running total — kilowatt-hours. Simple in principle, and the source of the most dramatic "my dashboard is insane" screenshots.

The trouble is who does the adding up. Many setups report only power to Home Assistant and let HA integrate it into energy with a Riemann sum — estimating the area between samples. On a spiky load that guess goes wrong fast. A Home Assistant user watched their fridge:

"My fridge uses ~5 kWh/day, which can't be true … the Tuya app reports ~0.5 kWh/day … the fridge consumes energy in spikes and then drops to 0 … is the drop to 0 maybe an issue for the Riemann-sum calculation?"

Ten times too high, purely from integrating a spiky signal in software. It's common enough that a core Home Assistant issue argues the "default of trapezoidal [Riemann method] is simply wrong for practically any use case."

The other failure mode is the counter that resets. When a device reboots and its energy total jumps back to zero — or reconnects as a "new" entity — Home Assistant sees the drop and records a huge negative or a wild spike:

"Random spikes in my energy panel … negative spikes should be impossible … values like −200 kWh … completely screw up the graphs."

"If I install an ESPHome update the total value will be reset … even though the ESP32 has the possibility to store the data persistently, this is not used."

Both classes of artifact disappear when the energy is accumulated on the device itself — a monotonic, non-volatile watt-hour counter that survives reboots and firmware updates, handed to Home Assistant as an already-integrated total. There's no software guess between samples, and no reset-to-zero for HA to misinterpret. (That's exactly how the rbAmp modules keep their Wh — counted on-device and checkpointed to flash — which is why they don't leave cliffs in your Energy Dashboard history.)

So why doesn't your reading match the meter?

Put it together, and the "6 kWh vs 4.8 kWh" mystery isn't one bug — it's a chain, and any link can drift it:

None of these make DIY monitoring pointless — they make it understandable. Measure real power with a calibrated, phase-compensated sensor, accumulate the energy where it can't be corrupted, and you land within a few percent of the meter and stay there. Which is the honest ceiling: a few percent, not zero. As one forum regular said of a 740 W-vs-780 W difference against the utility display — "No, it is to be expected."

Questions & answers

Can a CT clamp measure power without knowing the power factor? No. A CT measures current only. Power is V × I × cos φ, so without the voltage and the phase relationship you can only estimate apparent power (V × I), which overstates real power on any load that isn't purely resistive. Measuring voltage and phase on the same circuit is what turns current into real watts.

Why doesn't my energy monitor match my utility meter? Usually a stack of small things: the clamp is reporting apparent power instead of real power, the CT isn't phase-compensated (worst at low load), the waveform isn't being true-RMS sampled, or Home Assistant is integrating spiky power into energy and overshooting. Fix those and you get within a few percent — but never an exact match, because a CT clamp and a revenue meter measure slightly different quantities.

How accurate is an SCT-013 clamp? Its datasheet claims about ±3% over 10–120% of rated current, and accuracy falls off below ~10% of rating — that's a vendor figure, and it assumes correct burden and calibration. It's a fine sensor for awareness and trends; matching a meter closely takes patient calibration, and it can't resolve the tiny standby currents a purpose-built low-range CT can.

Why does my Home Assistant energy dashboard show negative values or huge spikes? Almost always because a power/energy sensor reset to zero (reboot, firmware update, reconnect) and HA recorded the drop as a negative, or because HA's Riemann-sum integration overshot on a spiky load. Accumulating watt-hours on the device — a reboot-proof, monotonic counter — removes both causes.

Do my kilowatt-hours reset when the ESP reboots? They do if the total is only held in RAM or re-integrated by HA. They don't if the device stores the counter in non-volatile memory and hands HA an already-accumulated total that continues across reboots.

What does "±0.5%" or "class 1" accuracy actually mean? It's the meter's error at a defined test point (nominal current, unity power factor) — not a promise across all loads. Real-world error is usually worse at low current and low power factor, which is why phase compensation and per-unit calibration matter more than the headline class number.

Can I bill a tenant using an energy monitor? No — and neither can any DIY monitor. Legal billing needs a certified revenue-grade / MID-approved meter, and typically a registered energy provider. A calibrated DIY monitor gives you repeatable numbers for personal accounting and fair cost-sharing — trustworthy, but not legally billable.

Where to go next

• Build one and see it in Home Assistant: rbAmp in the Home Assistant Energy Dashboard in 15 minutes.
• Meter the whole panel per circuit: the whole panel on one ESP32.
• Deeper dives coming in this series: what factory calibration really buys you (S4), where the Energy Dashboard loses watt-hours (S5), and honest three-phase measurement (S3/B4).

For the register-level detail of how the modules measure and store all this, see the API reference and CT / sensor selection.