Feature request: consistent total charged kWh

[nename0]

Usecase

I have a time-series database in my home automation system. To ingest data about the wallbox charging I query information every minute from evcc. One metric it want to put into my database is total charged energy (since dawn of time).
This value should increase monotonically for every charging session but also increase live during charging.
However this metric gives me a bit of trouble since #10341.

I only have one loadpoint and one vehicle, so I just use one metric in the time-series database and no separation between vehicles or solar/grid.

Describe the solution you'd like
Something like the savingsTotalCharged before #10341. The value increased live during charging, but did not reset when the vehicle is unplugged.

Describe alternatives you've considered
#10341 replaced savingsTotalCharged with statistics.total.chargedKWh.
However there a some very important subtle differences for my application: 1. The value only gets updated every hour (source) 2. It's impossible to tell if the current (paused) charging session is already included in the value.

With the current API here are the options I have considered and why they don't really work (sessions will be referring to the /api/session endpoint; all other values are from /api/state):

• loadpoints[0].sessionEnergy + statistics.total.chargedKWh:
  This is the one I used for the last 2 months (since Replace savings with session based stats (BC) #10341). It suffers from the problem that if a charging session gets paused (e.g. because of a cloud) the charging session will be added to the database of charging sessions. Then later the statistics will be updated once per hour and you will see the sessionEnergy twice.
• statistics.total.chargedKWh:
  works, but only updates once very hour (too slow for me) and only if the charging session was paused in the meantime.
• SUM(sessions[*].chargedEnergy) (similar to what the statistics do: source)
  works, but only after the charging session was paused.
• loadpoints[0].sessionEnergy + SUM(sessions[*].chargedEnergy)
  If a charging session gets paused (e.g. because of a cloud) the charging session will be added to the database of charging sessions and you will see the sessionEnergy twice.
• loadpoints[0].sessionEnergy + SUM(sessions[0:n-1].chargedEnergy) (skip the latest charging session in the sum)
  If the charging session has just started (and never paused) it will not be part of the database of charging sessions and thus you'd remove the previous session resulting in a wrong accumulated total charged energy value. I have not found a way to detect if the current charging session (loadpoints[0].sessionEnergy) already has a entry in the /api/sessions

Also it would be cool, if I needn't query the whole /api/sessions endpoint, because that might get big after month/years. And you might be adding pagination to that endpoint making it more pain to get the total charged kWh.

[naltatis]

Does your charger have an integrated meter that evcc can read? You can try this by running

$ evcc charger

number_one
----------
Power:          0W
Energy:         7155.0kWh
Current L1..L3: 0.009A 0.01A 0.01A
Charge status:  B
Enabled:        false
Charged:        0.0kWh
Identifier:     <none>

The Energy value is what you're looking for. Currently we don't expose charger data via http api. For vehicles and meters we already do (see status endpoint in experimental Config UI). With #12958 this data will also be added for chargers. Is this sufficient for your use-case?

[nename0]

Does your charger have an integrated meter that evcc can read?

Sadly not. I'm using the ABL eMH1:

Power:          0W
Current L1..L3: 0A 0A 0A
Charge status:  B
Enabled:        false

This is the whole reason why I rely on evcc to integrate the continuous power measurements to get a energy metric.
Obviously, this is not the most accurate, but it fits my purpose of displaying statistics.

[naltatis]

We will (re)introduce time-based metrics sometime. But the solution we had before #10341 was too simple/naive and created quite a lot of confusion and inconsistency. That's why we currently use charging session as our only data source.

I've created a new issue for the time-based feature #13050, and I'll be closing this one.