Total-Increasing sensor wrongly showing zero instead of unavailable

The problem

The problem

The Discovergy/inexogy API occasionally delivers a meter reading in which the total-increasing registers (energy, energyOut) are exactly 0.0, although the meter has clearly counted before. The integration passes that value straight through to the total_consumption / total_production sensors.

For a sensor with state_class: total_increasing a drop to 0 is, by definition, a meter reset. The recorder therefore does not book the drop (correct), but when the real reading returns it counts the whole register value as new consumption in that one hour of long-term statistics.

What happened here (HA 2026.9.2, meter type EMH, measurement_type: ELECTRICITY):

	last good reading	zero readings	first reading afterwards	real change	booked by the recorder
energy	397.11 kWh (2026-09-10 21:05 UTC)	21:10 UTC – 09:00 UTC next day	413.50 kWh	16.39 kWh	413.50 kWh
energyOut	380.63 kWh	same window	380.80 kWh	0.16 kWh	380.80 kWh

Hourly long-term statistics of the consumption sensor around the event (recorder/statistics_during_period):

10. 20:00 UTC  state=397.1131  change=0.00      <- last good hour
10. 21:00 UTC  state=0.0       change=0.00      <- zero readings, treated as reset
...            state=0.0       change=0.00
11. 09:00 UTC  state=413.4995  change=413.50    <- whole register booked as consumption
11. 10:00 UTC  state=413.5225  change=0.023

sensor.<meter>_last_transmitted kept updating during the window, i.e. the API served fresh readings with zero values, not stale ones. The coordinator did not fail (no UpdateFailed), so the sensors stayed available with state 0.0.

The Energy dashboard consequently showed 641.97 kWh grid import for September on a meter whose absolute reading was 501 kWh, and 189.65 € instead of ~61 € in cost (the derived _cost statistic multiplies the spurious 413.5 kWh by the tariff of that hour). Repairing this requires manually adjusting four statistics (energy in/out, cost, compensation).

Expected behaviour

A total-increasing register that has already counted cannot read 0. Such a reading should not be passed on as a state; the sensor should be marked unavailable until a plausible reading returns, so the recorder ignores the glitch. Registers that have never counted (e.g. energyOut in a household without production) must keep reading 0, and measurement sensors (power, which is legitimately 0 at times) must not be affected.

I have a fix with tests ready and will open a PR referencing this issue.

What version of Home Assistant Core has the issue?

2026.9.2

What was the last working version of Home Assistant Core?

none

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Discovergy

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

No response