Energy monitoring with Zigbee: from live wattage to useful evidence

A Zigbee smart plug may currently show 42 W, 230 V, 0.18 A, and 1.23 kWh. Those values are useful, but they describe different aspects of the circuit and are not interchangeable.

Power indicates the approximate rate of consumption at a moment. Energy measures how much electricity was consumed over a period. Voltage and current help describe the electrical conditions under which the device is operating. The distinction matters: a device drawing 10 W continuously can consume more energy over a day than a device drawing 1,000 W for a few minutes.

A live wattage value helps answer, “What is happening now?” Historical telemetry helps answer the questions that usually lead to savings or maintenance decisions:

• Which devices consume power while they appear to be idle?
• How much energy did the home office use yesterday?
• Does a dehumidifier run longer than expected after a change in humidity?
• Did an appliance’s operating pattern change compared with last month?
• Which loads could be shifted to a cheaper or lower-carbon period?

The useful output is not a stream of numbers. It is evidence about when, how often, and for how long electricity is being used.

Power and energy answer different questions

Zigbee2MQTT device definitions can expose measurements such as power, voltage, current, and energy, but the available fields and reporting behaviour depend on the device. Zigbee2MQTT documents these capabilities through a device’s exposes definition, and individual plugs specify the units and meaning of their measurements.

The most important distinction is between power and energy:

Measurement	What it describes	Useful question
Power, in W	Instantaneous or recently measured consumption rate	What is the device drawing right now?
Energy, in kWh	Accumulated consumption over time	How much did the device use during this period?
Voltage, in V	Electrical potential measured by the device	Was the measured supply value stable or unusual?
Current, in A	Instantaneous measured current	How much current was flowing when the reading was taken?

A power reading is not a bill. To estimate energy from power, you need the duration for which that power was sustained. A 100 W load running for ten hours uses approximately 1 kWh, while a 100 W load running for ten minutes uses approximately 0.017 kWh.

Cumulative energy fields can be convenient for daily or monthly totals, but they deserve validation. Check whether the device resets its counter, whether the value survives a power cycle, whether it reports a cumulative total or an interval value, and how the measurement compares with a trusted meter. Treat low-cost plug measurements as useful monitoring signals, not automatically as billing-grade instruments.

What history reveals

Phantom and standby loads

A live reading of 7 W may not seem significant. History shows whether the load lasts for minutes or remains present day and night.

A continuously running 7 W load uses about 0.168 kWh per day and approximately 61 kWh over a non-leap year, assuming the measured value is representative. The financial impact depends on the electricity price, taxes, tariffs, and whether the load is actually constant, but the calculation illustrates why duration matters more than a single wattage reading.

Look for devices whose power never reaches the expected idle level. Network equipment, media systems, chargers, printers, and office equipment may have several operating states. The goal is not to eliminate every standby load; it is to identify the ones worth changing.

Appliance cycles

A fridge, freezer, pump, boiler, or dehumidifier often has a recognisable cycle rather than a steady draw. A live reading catches one point in that cycle. A chart can show cycle duration, frequency, idle periods, and changes over time.

An apparent increase in energy use does not prove that an appliance is failing. It can also reflect warmer weather, more frequent use, a changed setting, a blocked filter, or a different household routine. History tells you when the pattern changed; inspection and additional context are needed to determine why.

Actual cost of a device or room

If you know your applicable electricity price, historical energy can be converted into an estimate of cost:

Estimated cost = Energy consumed (kWh) × Price per kWh

Use the tariff that actually applies to the relevant period, including fixed or variable components where appropriate. A single flat rate can be adequate for a rough comparison, but it may misrepresent costs when your contract includes time-varying prices, taxes, network charges, or different day and night rates.

For a home office, for example, measure the computer, monitors, network equipment, and peripherals over representative working days. Compare a workday with a weekend rather than multiplying one unusual day across an entire month.

Time-of-use behaviour

If your tariff varies by time, history can show when flexible loads actually run. That can inform decisions about dishwashers, washing machines, water heating, battery charging, or other devices that can operate within a chosen window.

Measured history does not automatically make a load safe or suitable for scheduling. Check the appliance, installation, control method, and household requirements first. Avoid shifting a critical device merely to optimise a small price difference.

Measure the right thing at the right resolution

Not every energy question needs the same reporting frequency.

High-frequency power data is useful for identifying appliance cycles, startup surges, short operating periods, and standby behaviour. For long-term comparisons, hourly or daily energy totals are often easier to interpret and store.

Cumulative energy readings can be plotted directly, but you should account for resets, counter rollovers, missing messages, and device replacements. If the counter resets after a restart, a naïve difference calculation can produce a large negative value or an incorrect daily total.

A robust history workflow records enough context to detect these problems:

• Device topic or stable identifier.
• Measurement name and unit.
• Timestamp and timezone handling.
• Whether the value is instantaneous or cumulative.
• Device replacement or reset events.
• Gaps in reporting and bridge outages.

For a smart plug, a useful recent-history view might include power and cumulative energy. For a whole-home meter, daily energy totals may be more important than every instantaneous fluctuation. For a solar or battery system, import, export, charge, and discharge should not be collapsed into one undifferentiated number.

Avoid treating one measurement as proof

Energy monitoring can reveal anomalies, but it cannot explain them on its own.

A fridge drawing more energy might be working harder because the room is warmer. A heater running in summer might reflect an incorrect schedule, a sensor problem, or a legitimate hot-water cycle. A plug showing zero power might have stopped reporting rather than genuinely stopped consuming energy.

Before acting on an apparent anomaly, compare:

• The same device’s history over a longer period.
• Similar days or operating conditions.
• Power and cumulative energy together.
• Device state, such as on or off.
• Temperature, humidity, or occupancy where relevant.
• The reporting timeline and any bridge or network interruptions.

Also consider measurement limits. Smart plugs differ in accuracy, minimum measurable load, sampling, calibration, and support for reactive or complex loads. A small displayed value may be rounded, and two devices measuring the same circuit may not agree exactly.

History makes an investigation more precise; it does not turn an inexpensive sensor into a laboratory instrument.

The DIY telemetry route

A self-hosted implementation usually starts with the Zigbee2MQTT MQTT messages. You subscribe to the relevant device topics, extract fields such as power and energy, store timestamped points in a database, and build dashboards for recent and long-term analysis.

A serious setup may also need:

1. Normalisation of device-specific field names and units.
2. Handling for cumulative counters, resets, and replacements.
3. Aggregation for hourly and daily totals.
4. Retention policies for high-frequency measurements.
5. Backups and recovery tests.
6. Alerts for missing data or unusual consumption.
7. Access controls for dashboards and remote access.

This is a sensible route when you already operate a reliable telemetry platform or want to combine energy data with server, network, solar, and building information. The trade-off is ongoing maintenance. A dashboard is only useful if ingestion, storage, timestamps, and queries continue to work after upgrades and outages.

Where ZigStream fits

That can be useful for investigating questions such as:

• How did a plug’s power draw change over the last week?
• Which devices reported the largest energy values during a selected period?
• Did an appliance’s operating pattern change after a repair or configuration change?
• Was a suspected standby load continuous or intermittent?

The answer depends on the fields your device publishes, the reporting interval, and the history available for your account.

A practical energy-monitoring workflow

Start with one device whose consumption is easy to interpret: a dehumidifier, office setup, fridge, freezer, or network cabinet. Define the question before collecting data.

For example, to investigate an office setup:

1. Record power and cumulative energy during several workdays and weekends.
2. Mark when the setup is expected to be idle.
3. Compare the overnight minimum with the active working pattern.
4. Calculate energy over the same time windows rather than comparing isolated wattage values.
5. Change one behaviour, such as switching off a monitor or using a power strip, and measure the result.

For an appliance, compare similar operating conditions. For a tariff decision, compare energy by time window and apply the correct price structure. For an anomaly, first establish a baseline before creating an alert.

The best automation may be a simple one: notify when a normally idle load remains above a chosen level for a defined period. Use a delay and an appropriate threshold to avoid alerts caused by startup behaviour or normal short cycles.

The bottom line

Live wattage is a useful snapshot, but energy history explains duration and accumulated consumption. It can expose persistent standby loads, show appliance cycles, support tariff decisions, and provide a baseline for investigating unusual behaviour.

A DIY MQTT, database, and dashboard stack gives you maximum control and integrates well with an existing home-lab monitoring system. If you want focused historical queries for Zigbee2MQTT energy telemetry without building that pipeline yourself, ZigStream provides a narrower managed workflow while your local bridge and automations remain local.

Choose one device and one measurable question first. Keep enough detail to answer it, compare representative time periods, and validate unexpected results against the device’s reporting behaviour and measurement limits. That is how a stream of wattage readings becomes useful evidence for reducing consumption.