-
Notifications
You must be signed in to change notification settings - Fork 2
Home
Energy Meter Tracker is designed to work with smart meter data from a Consumer Access Device (CAD) or similar hardware that provides reliable, high-frequency cumulative kWh readings. Understanding the requirements and limitations below will help you get the most accurate data and avoid common pitfalls.
The import and export sensors must report an ever-increasing cumulative total in kWh — the lifetime reading from your meter, not a session, daily, or resettable value. EMT calculates energy per block by taking the difference between two consecutive readings. If the sensor resets, reports session energy, or reports power in watts rather than energy in kWh, the results will be wrong.
✅ Good: 28,729.885 kWh (lifetime total, always increasing)
❌ Bad: 3.2 kWh (today's usage, resets at midnight)
❌ Bad: 2,400 W (instantaneous power, not energy)
EMT interpolates a precise boundary value at the start and end of each block using the reads that arrive before and after the boundary. If your sensor only updates every 10–30 minutes, or updates sporadically, the interpolation will be less accurate. For 5-minute blocks in particular, a sensor that updates less frequently than the block size will result in many blocks with only a single read — producing zero kWh for those blocks.
The recommended update frequency is at least once per block period. For 30-minute blocks, once every 5–10 minutes is sufficient. For 5-minute blocks, once per minute or faster is ideal.
If a sensor resets to zero, EMT will see a large negative delta for that block and clamp it to zero — the energy during that block is lost silently. Whether a reset is recoverable depends on when it happens:
Acceptable resets — a reset that occurs at a clean block boundary, or during a quiet period with no active consumption, is recoverable. The affected block loses its data but surrounding blocks are unaffected. Use the Corrections page to zero out or manually fix the affected block.
Problematic resets — a reset mid-session (e.g. mid-EV-charge, mid-battery-charge, or mid-import-block) causes cascading issues: the block containing the reset loses all its energy, and the blocks immediately after the reset will show artificially low values until the cumulative reading catches back up to its pre-reset level. For sub-meters, the house remainder is wrong for the entire affected period. These are harder to correct manually.
Common causes of mid-session resets include: HA restarts that reset virtual/template sensors, EV charger integrations that reset on car disconnect (before the final reading is captured), and cloud integrations that briefly return 0 on reconnect. If your integration is prone to this, consider using a utility_meter helper in HA to provide a stable cumulative total that does not reset on integration restarts.
Some integrations report kWh as integers (e.g. 28729 rather than 28729.885). At 1 kWh resolution, a 5-minute block will typically show 0 kWh with an occasional 1 kWh step. This makes interpolation meaningless and sub-meter attribution unreliable. EMT will still record data but the granularity will be poor. A minimum resolution of 0.001 kWh (3 decimal places) is recommended.
The rate sensor must report the current import rate in £/kWh (or your local currency per kWh) as a live value — not a daily average, not a forecast. On time-of-use tariffs (e.g. Octopus Go, Agile), the rate sensor should update at each tariff period boundary. EMT records the rate at the time of each read and uses it to calculate block cost.
When you configure a sub-meter, the rate sensor is copied from the main meter as a default. It is not a live link — if you later change the main meter rate sensor, you must update each sub-meter manually in Settings. See [Settings → Meter Config] for details.
Sub-meters must measure devices that consume grid electricity — their kWh must always be less than or equal to the main meter import. EMT calculates house consumption as the remainder: main import − sum of sub-meters. If a sub-meter reports more than the main meter (which can happen with inverter-capable devices), the house remainder will be negative and will be clamped to zero.
If a sub-meter is on a device that can export back to the grid or house (V2H EVs, hybrid inverters), the sub-meter's cumulative import reading may not reflect the net energy flow correctly. Mark these meters as inverter-capable in Settings — EMT will show a caveat on the Insights page noting that carbon figures are a maximum and may be lower if solar or battery contributed.
A sub-meter that goes offline, reports sporadically, or resets unexpectedly will cause the house remainder calculation to be wrong for the affected blocks. For example, if an EV charger integration only reports kWh when the car is awake, blocks during charging where no read arrived will show zero EV kWh — the full charging energy will be attributed to the house instead. Use the Corrections page to fix affected blocks after the fact.
EMT does not currently support export sub-metering. Solar generation cannot be tracked directly — only grid export is recorded. Battery discharge to the house cannot be separated from grid import without generation-side metering. These are documented on the Insights page.
EMT records what crosses the grid boundary — import and export. Solar generation that is consumed directly by the house (self-consumption) is invisible to EMT. The house consumption figure on Insights represents grid import minus sub-meter consumption, not total house consumption including solar self-consumption.
Carbon intensity data comes from the National Grid ESO half-hourly regional API, keyed by postcode. The intensity figure represents the average for your grid region — it does not account for local generation (rooftop solar, local wind) or distribution losses. Rural postcodes may map to large regions with highly averaged intensity figures.
Carbon intensity data is only stored from when your postcode was first configured. Blocks that predate carbon configuration will have no intensity data and are excluded from carbon calculations. The Insights page shows a coverage percentage — figures based on less than 80% coverage should be treated as estimates.
EMT uses interpolation to estimate the exact cumulative reading at each block boundary. This is accurate when reads arrive frequently on both sides of the boundary. In practice, reads arrive slightly after the boundary (due to sensor update lag, HA processing time, and network latency), so EMT always has at least one post-boundary read to interpolate against. If a restart or gap occurs exactly at a block boundary, the interpolation for that block may be less precise.
EMT is strict about units — passing the wrong unit will produce silently wrong data rather than an error.
| Sensor | Required unit | Notes |
|---|---|---|
| Main meter import | kWh | Cumulative lifetime total |
| Main meter export | kWh | Cumulative lifetime total |
| Sub-meter import | kWh | Cumulative lifetime total |
| Import rate | £/kWh (or local currency/kWh) | Live current rate, not average |
| Export rate | £/kWh (or local currency/kWh) | Live current rate |
| Standing charge | £/day (or local currency/day) | Daily charge, not per block |
| Power sensor (live display only) | W or kW | Used for Live Power page only, not for block calculation |
The rate and standing charge sensors must use the same currency. EMT auto-detects the currency symbol from the import rate sensor's unit attribute (e.g. GBP/kWh → £).
If your device only provides a power sensor (watts) rather than a cumulative energy sensor (kWh), you can derive a suitable cumulative kWh sensor using the PowerCalc integration or a HA integration helper.
PowerCalc integrates a power sensor over time to produce a cumulative kWh entity. It is well-maintained, handles HA restarts gracefully, and produces a stable ever-increasing total suitable for EMT. Configure it in fixed or linear mode pointing at your power sensor, and use the resulting sensor.*_energy entity as your EMT sub-meter sensor.
HA's built-in integration helper (Settings → Helpers → Add → Integrate sensor) does the same thing using a Riemann sum. It is simpler to set up but slightly less robust around HA restarts — it may briefly return unavailable on startup before the source sensor has reported. Set the method to left or trapezoidal and the unit prefix to k (for kWh from W input).
Caveats for both PowerCalc and the integration helper
- Accuracy depends entirely on how frequently the power sensor updates — a sensor that only updates every few minutes will produce stepped accumulation with significant interpolation error
- Accumulation starts from when the helper was created — there is no historical backfill. If you add a new sub-meter using a power-derived sensor, only data from that point onwards will be available
- Neither PowerCalc nor the integration helper protect against the source power sensor going
unavailable— during unavailable periods accumulation pauses, which is correct behaviour (zero energy assumed during the gap) - Neither protects against the source sensor resetting to zero — if the underlying device integration resets, the derived kWh will drop too. In this case a CT clamp is the more robust solution
Some inverters and batteries report a single net power value where positive means export/discharge and negative means import/charge (or vice versa depending on the device). To use this with EMT you need to split it into two unidirectional sensors and accumulate each into kWh.
Step 1 — Split the net sensor into import and export using a template sensor
Add to your HA configuration.yaml (or a template: block):
template:
- sensor:
# Import side — when inverter is drawing from grid (negative net value)
- name: "PW Inverter In Power"
unique_id: pw_inverter_in_power
state: >
{% set val = states('sensor.pw_inverter_power') | int(default=0) %}
{{ (0 - val) if is_number(val) and (val | int < 0) else 0 }}
unit_of_measurement: "W"
state_class: measurement
device_class: power
icon: mdi:batteryThis produces a sensor that is always ≥ 0 — it returns the absolute import power when the inverter is drawing from the grid, and 0 otherwise.
Step 2 — Accumulate into kWh using PowerCalc
powercalc:
energy_update_interval: 60
sensors:
- entity_id: sensor.pw_inverter_in_power
power_sensor_id: sensor.pw_inverter_in_power
name: PW In Aggregated
fixed:
power: "{{ states('sensor.pw_inverter_in_power') | int(default=0) }}"This produces sensor.pw_in_aggregated_energy — a cumulative kWh sensor suitable for use as an EMT sub-meter.
Step 3 — Use in EMT
In Settings → Meter Config, add a sub-meter and point the import read sensor at sensor.pw_in_aggregated_energy. Repeat Steps 1 and 2 for the export side if you want to track export separately (reversing the sign condition in the template).
Note — the energy_update_interval: 60 setting means PowerCalc accumulates every 60 seconds. For 5-minute EMT blocks this gives reasonable accuracy. For 30-minute blocks it is more than sufficient.
For devices without a smart integration that provides cumulative kWh (or where the integration is unreliable), a CT (current transformer) clamp on the circuit is the most robust sub-metering approach. A CT clamp measures current flow on a cable and, combined with a known voltage, produces a power reading that can be accumulated into kWh.
How it works A CT clamp clips around a single live conductor (e.g. the cable feeding your EV charger, heat pump, or consumer unit busbar). The clamp outputs a small AC signal proportional to current. An energy monitor (see below) reads this signal and produces power and/or energy sensors in HA.
Popular CT clamp hardware for HA users
| Device | Notes |
|---|---|
| Hildebrand Glow CAD | Reads directly from your smart meter via SMETS2 — not a CT clamp but the recommended source for the main meter |
| Shelly EM / Shelly Pro EM | WiFi-connected, 1–4 CT inputs, native HA integration, provides cumulative kWh directly — good choice for sub-meters |
| Emporia Vue | Multi-circuit CT monitoring, HA integration available, provides cumulative kWh |
| EmonTx / OpenEnergyMonitor | Open source, highly configurable, MQTT-based, good for custom setups |
| ESPHome + CT clamp | DIY approach — an ESP32/ESP8266 with a SCT-013 CT clamp running ESPHome firmware. Provides a power sensor that you then accumulate via PowerCalc or the integration helper. Very flexible but requires hardware assembly |
Advantages over integration-based sub-metering
- No dependency on device connectivity — the clamp measures regardless of whether the EV, battery, or heat pump is awake or connected
- No reset issues — CT-based energy monitors accumulate continuously
- Works for any circuit — anything with a dedicated cable can be sub-metered, including circuits with no smart device at all
- More accurate than power-derived sensors from device integrations, which often only update when the device is active Practical considerations
- CT clamps must be installed on a single conductor (live only, not around the whole cable). Installation inside a consumer unit should be done by a qualified electrician
- Accuracy depends on clamp quality and calibration — most consumer-grade CT clamps are accurate to 1–2%
- For 3-phase supplies, you need one CT per phase
- The Shelly EM is the simplest plug-and-play option for most users — it provides a cumulative kWh sensor directly without needing a PowerCalc helper
The Hildebrand Glow Consumer Access Device (CAD) connects directly to your SMETS2 smart meter via the Zigbee HAN (Home Area Network) and publishes real-time meter data over MQTT. It provides cumulative kWh import, cumulative kWh export, and live power readings — exactly what EMT needs.
HA Integration — ha_hildebrand_glow_ihd_mqtt
The recommended HA integration is ha_hildebrand_glow_ihd_mqtt by megakid. It creates sensors directly from the MQTT messages published by the Glow device, including:
-
sensor.smart_meter_electricity_import— cumulative import kWh ✅ use as main meter import -
sensor.smart_meter_electricity_export— cumulative export kWh ✅ use as main meter export -
sensor.smart_meter_electricity_power— live power in W ✅ use as power sensor for Live Power page -
sensor.smart_meter_electricity_import_unit_rate— current import rate in £/kWh ✅ use as import rate sensor -
sensor.smart_meter_electricity_export_unit_rate— current export rate in £/kWh ✅ use as export rate sensor -
sensor.smart_meter_electricity_standing_charge— daily standing charge in £/day ✅ use as standing charge sensor Setup guides -
ha_hildebrand_glow_ihd_mqtt by megakid — installation, MQTT broker setup and sensor configuration Requirements
-
A SMETS2 smart meter (most UK smart meters installed after 2019)
-
An MQTT broker — Mosquitto is the standard choice and is available as an HA add-on
-
The Glow device must be on the same network as your MQTT broker Important note on sensor naming
Sensor entity names from this integration vary depending on your HA instance and MQTT topic configuration. The entity IDs shown above are common defaults but yours may differ. Always verify the entity IDs in HA Developer Tools → States before entering them in EMT.
Agile and dynamic tariff users — do not use the CAD rate sensor
The rate sensor provided by the Glow CAD (smart_meter_electricity_import_unit_rate) reflects what your smart meter reports over HAN. For fixed and time-of-use tariffs (Octopus Go, Economy 7 etc.) this is accurate and updates correctly at tariff period boundaries. However for dynamic tariffs like Octopus Agile, where rates change every 30 minutes and are published in advance via an API, the CAD rate sensor will not reflect the correct current rate — it typically lags behind or reports a standing/default rate.
For Agile and other dynamic tariffs, use the rate sensor provided by your supplier's HA integration instead:
-
Octopus Energy integration — provides
sensor.octopus_energy_electricity_*_current_ratewhich updates correctly with the half-hourly Agile rate. See the Octopus Energy HA integration by BottlecapDave - Other suppliers — check your supplier's official HA integration or the HA community for a suitable rate sensor. If none exists, you can create a template sensor that pulls from your supplier's API
The Octopus Energy HA integration provides reliable cumulative kWh sensors and live rate sensors and is the recommended integration for UK users. Ensure you are using the sensor.octopus_energy_electricity_*_current_accumulative_consumption sensors (cumulative) and not the *_current_day_rates_* sensors (not cumulative).
EV charger integrations vary significantly in what energy sensors they provide. Before configuring a charger as a sub-meter, check what your specific integration offers:
- Cumulative lifetime kWh — ideal, use directly as an EMT sub-meter sensor
- Session energy that resets between charges but not mid-session — this can work provided the session does not span a block boundary at the point of reset. The Zappi integration is a known example where this works reliably in practice
-
Session energy that resets mid-charge or on reconnect — not suitable without accumulation via a
utility_meterhelper or PowerCalc - No energy sensor, power only — use PowerCalc or the integration helper to accumulate, or use a CT clamp on the charger circuit Check your charger integration's documentation and the HA community for confirmation of which sensor type your device provides before assuming it is suitable. What works for one charger model or firmware version may not work for another.
Car integrations that report odometer or energy consumption from the car's perspective are unsuitable as sub-meter sensors. They only update when the car is awake (which may be hours after charging completes), they report from the car's perspective (DC energy stored, not AC drawn from the wall), and they may reset on firmware updates. Use a dedicated charger-side sensor instead.
Battery integrations typically provide both import (charging) and export (discharging) cumulative sensors. Use the grid import to battery sensor, not the total charge/discharge sensor which includes solar. Check your integration documentation for the correct sensor entity.
- In-app help — the Help page (📖 in the sidebar) covers setup, sensor requirements, and backup/restore
- GitHub Issues — github.com/RGx01/energy-meter-tracker-addon/issues for bug reports
- GitHub Wiki — this wiki for detailed documentation and known limitations
- Corrections page — use Data Management → Corrections to fix individual blocks after sensor issues
Getting Started
Supplier Integration
Using EMT
Data Management
Reference