This walkthrough uses synthetic data for one cumulative grid-import register. It is a design example, not a report of a field-tested installation.

First, define what the number means

These three measurements need different calculations:

• Power in W: a rate at a particular moment. Estimating energy requires integration over time.
• Interval energy in Wh: energy attributed to a defined interval. Sum non-overlapping, deduplicated intervals.
• Cumulative energy in Wh: a running counter. Compute differences between accepted readings from the same register and counter epoch.

For example, readings of 100,000 Wh and 100,250 Wh represent an increase of 250 Wh, or 0.25 kWh. Adding the two readings would produce 200.25 kWh, which is not the interval's consumption.

Do not combine grid import and export into one increasing counter. Keep register identity, direction, unit, and scaling explicit. Convert to your chosen unit once at the ingestion boundary, preserving the meter's supported precision.

Keep measurement time separate from arrival time

A useful record includes a device identifier, register identifier, source timestamp or sequence number, received-at timestamp, normalized value, quality flag, and counter epoch.

The source time says when the measurement applies. The arrival time says when your server received it. After a network outage, old readings may arrive together; assigning all of them to the arrival minute creates a misleading load spike.

If the meter supplies no trustworthy measurement timestamp, record that limitation. A timestamp assigned by your poller is not proof of the device's measurement time.

For cumulative readings, a repeated value with a newer timestamp can be valid: no measurable energy was added. A repeated event with the same identity must not create another accounting entry.

Make retries safe before calculating totals

Choose an event key using the source's actual guarantees. Device, register, counter epoch, and source sequence can work when that sequence is unique within an epoch. A timestamp is suitable only if its resolution reliably distinguishes samples.

Receiving an identical retry should leave the result unchanged. If the same event key arrives with a different value, retain the conflict for investigation instead of silently counting both.

The following JavaScript example is deliberately narrow. It processes a strictly time-ordered stream for one register, rejects ambiguous readings, and uses integer Wh because the synthetic meter has 1 Wh resolution.

function acceptReading(previous, current) {
  const valid = r => r &&
    Number.isSafeInteger(r.timeMs) && r.timeMs >= 0 &&
    Number.isSafeInteger(r.totalWh) && r.totalWh >= 0 &&
    typeof r.epoch === "string" && r.epoch.length > 0;

  if (!valid(current) || (previous && !valid(previous))) {
    return { status: "invalid" };
  }
  if (!previous) return { status: "baseline", next: current };
  if (current.timeMs < previous.timeMs) return { status: "late" };
  if (current.timeMs === previous.timeMs) {
    const same = current.totalWh === previous.totalWh &&
      current.epoch === previous.epoch;
    return { status: same ? "duplicate" : "conflict" };
  }
  if (current.epoch !== previous.epoch) {
    return { status: "new-baseline", next: current };
  }
  if (current.totalWh < previous.totalWh) {
    return { status: "counter-drop" };
  }
  return {
    status: "accepted",
    deltaWh: current.totalWh - previous.totalWh,
    next: current
  };
}

Update the baseline only when the result contains next. Store a delta only for accepted results. In production, event deduplication, delta storage, and baseline advancement must form one durable transaction or equivalent atomic operation. An in-memory check alone does not protect against concurrent workers or process crashes.

This example does not implement event storage, rollover recovery, clock correction, or late-data reconciliation. Route rejected records to a review or replay path; do not simply discard them. Devices with finer resolution need an appropriate scaled unit or decimal representation.

Treat a counter drop as a question, not an answer

A lower reading can mean a confirmed reset, a replaced meter, a register rollover, an out-of-order response, or a parsing error. These are not interchangeable.

Do not automatically take the absolute value of a negative difference. Do not automatically count the new reading as fresh usage either. Confirm the device's reset or rollover behavior before bridging the boundary.

A confirmed new epoch starts a new baseline in the example above. Energy across that boundary remains unaccounted for unless additional evidence supports recovery. Record that gap rather than presenting the day as complete.

Home Assistant also distinguishes different counter semantics. Its sensor developer documentation explains when total and total_increasing are appropriate. Choose based on the source's behavior, not simply because its unit is kWh.

Calculate daily totals using explicit boundaries

A daily total is not just the last reading minus the first reading found in a folder. You need boundary coverage, a declared site timezone, and consistent treatment of gaps and resets.

For a continuous, trustworthy counter with no reset, missing intermediate samples may still leave a reliable total between two valid endpoints. They do not reveal how consumption was distributed inside that gap.

If a delta spans local midnight, assigning all of it to the later date shifts energy between days. Prefer readings at the boundary, or label any interpolation as an estimate. The same issue matters at tariff changes. Local days can also be 23 or 25 hours where daylight-saving time applies.

Keep import and export totals separate throughout this process. Display completeness alongside the daily figure when missing coverage could change its meaning.

Avoid aggregating counters that reset independently

Two resetting counters can briefly produce a false combined value if one resets before the other. Home Assistant's energy FAQ specifically warns about inflated totals from this pattern and recommends configuring the individual cumulative sensors as separate Energy dashboard sources.

In a custom pipeline, validate each independent counter first, then aggregate compatible energy intervals. Also check the physical measurement boundaries: adding a whole-home meter and an EV submeter would count the EV twice if the whole-home reading already includes it.

Test the failure cases before trusting the chart

Use these cases as a small acceptance checklist:

• A 100,000 Wh baseline followed by 100,250 Wh produces exactly 250 Wh.
• An identical replay produces no new accounting entry.
• A newer timestamp with the same value produces a zero delta.
• The same timestamp with a different value is a conflict.
• An older timestamp goes to late-data handling.
• A lower counter in the same epoch raises a counter-drop flag.
• A confirmed new epoch creates a baseline, not an invented interval total.
• A gap crossing midnight cannot silently become a complete daily allocation.

Keep raw readings available so a correction can be reproduced. A dashboard should show the result of an auditable calculation, not be the only surviving record of it.

For readers building a local collection layer, the EnergyMeterHub energy-device-gateway project page is a related starting point. The checklist and sample above are general ingestion guidance, not a claim that the gateway implements every safeguard described here.

Disclosure: This article is published by EnergyMeterHub, which maintains the linked project page.