charge_energy_added appears cumulative across a plug-in session, causing under/overcounting when one plug-in session is split into multiple charging_processes

[wolf800]

Is there an existing issue for this?

• I have checked the existing issues and discussions, and I can confirm that there are no duplicates.

What happened?

charge_energy_added appears cumulative for the whole plug-in session, not per charging_process, causing under/overcounting across segmented charges

---

Hi, I believe TeslaMate may be misinterpreting the semantics of Tesla's charge_energy_added field.

After investigating both the database records and the source code, it looks like charge_energy_added behaves more like a counter for the whole plug-in session (since the cable was plugged in), not a counter local to a single charging_process.

TeslaMate currently seems to treat it as if it were per-process added energy, which leads to incorrect results in at least these scenarios:

• scheduled charging after the car has already been plugged in for hours
• Sentry / vampire drain between plug-in and actual charging start
• a single plug-in session being split into multiple charging segments / charging_processes

Environment

• TeslaMate version: 4.0.1
• Bare-metal install on Ubuntu
• PostgreSQL backend
• Grafana dashboards restored from TeslaMate
• Vehicle: Tesla Model Y Long Range (China)

What I observed

Case 1: scheduled AC charging after plug-in, with energy loss before charging actually starts

I plugged in the car in the evening at about 40%, then scheduled charging to start at 03:00 local time.
Sentry mode was enabled, so the battery dropped before charging actually began.

Plug-in baseline before scheduled charging

From positions, around plug-in time, the car was still at about:

• 18:47:44 local: 40%, rated range 225.89 km
• 18:52:32 local: 40%, rated range 225.61 km
• 18:57:34 local: 40%, rated range 225.49 km

Actual charging process

This charging process then ran from about 03:00 to 05:26.

From charges:

• session start: 03:00:30
  • battery level: 38%
  • rated range: 214.85 km
  • charge_energy_added = 0.00
• first non-zero charge_energy_added: 03:23:40
  • battery level: 40%
  • rated range: 225.74 km
  • charge_energy_added = 0.02
• session end: 05:26:25
  • battery level: 50%
  • rated range: 280.93 km
  • charge_energy_added = 8.30
  • charge_energy_used = 10.54

Why this looks suspicious

Charging was clearly active from the beginning of the process:

• charger current / voltage / power were already non-zero
• SOC increased from 38% to 40%
• rated range increased from 214.85 km to 225.74 km

But charge_energy_added stayed at 0.00 for the first ~23 minutes and only became non-zero when the car had roughly returned to the same range/SOC level it had when first plugged in.

That strongly suggests that the raw field is not "energy added since this charging_process started", but something closer to:

• "net energy added since the cable was plugged in"

I also back-extrapolated the counted portion of the curve and got an implied hidden initial value of about -1.61 kWh, which fits this interpretation very well.

Case 2: one plug-in session split into two charging processes

This is the more direct evidence.

Under the same plug-in session, TeslaMate recorded two charge entries:

Charging process A

• start: 2026-07-09 03:00:32
• duration: 35m
• SOC: 35% -> 38%
• rated range: 198 km -> 214 km
• energy added: 1.20 kWh
• energy used: 2.53 kWh
• efficiency: 47%

Charging process B

• start: 2026-07-09 03:38:56
• duration: 2.1 h
• SOC: 38% -> 50%
• rated range: 214 km -> 282 km
• energy added: 10.22 kWh
• energy used: 10.79 kWh
• efficiency: 95%

These two charging processes belong to the same plug-in session.

The important part is this:

• process A ended with charge_energy_added = 1.20
• process B appears to start with that 1.20 already included
• TeslaMate then reports process B's added energy as the full 10.22, instead of rebasing it

So TeslaMate totals become:

• process A added: 1.20
• process B added: 10.22
• summed total: 11.42

But if 10.22 is the cumulative net added value for the whole plug-in session, then process B's own contribution should be:

• 10.22 - 1.20 = 9.02

So at least 1.20 kWh is counted twice across the two processes.

Why I believe this is a TeslaMate interpretation / aggregation issue

From the source code:

• lib/tesla_api/vehicle/state.ex maps charge["charge_energy_added"]
• lib/teslamate/vehicles/vehicle.ex stores vehicle.charge_state.charge_energy_added directly into charges
• lib/teslamate/vehicles/vehicle.ex also normalizes nil -> 0 in put_charge_defaults/1
• lib/teslamate/log.ex aggregates charging_processes.charge_energy_added using the values stored in charges

This means:

1. TeslaMate stores the upstream field more or less directly
2. TeslaMate then aggregates it per charging_process
3. If the upstream field is actually cumulative over the whole plug-in session, the per-process aggregation is semantically wrong
4. Converting nil to 0 also hides the distinction between:
   • "no positive value yet / counter not usable yet"
   • real zero

Impact

This appears to affect at least:

• Charge Details -> Added
• charge efficiency
• total energy added
• summed statistics across multiple processes
• and possibly higher-level derived dashboards if they use these charge totals

I also observed obviously implausible downstream values such as battery capacity estimates temporarily exceeding the configured "new" capacity, which suggests that these bad charge totals can propagate into higher-level estimation.

Expected behavior

For each charging_process, added energy should reflect only the energy attributable to that process.

If charge_energy_added is actually cumulative for the whole plug-in session, TeslaMate should probably not use it directly as a per-process counter.

Possible directions:

• preserve raw nil instead of coercing it to 0
• rebase charge_energy_added against the start of the plug-in session, or at least against the start of the process
• detect carry-over when one plug-in session is split into multiple charging processes
• avoid using affected sessions for higher-level estimations if the raw field cannot be safely rebased

Summary

The observed behavior is consistent with this interpretation:

• Tesla's charge_energy_added is cumulative for the whole plug-in session
• TeslaMate currently treats it as if it were local to each charging_process
• this causes undercounting when charging starts below the original plug-in baseline
• and overcounting / double-counting when one plug-in session is split into multiple charging processes

Expected Behavior

No response

Can the issue reliably be reproduced?

Yes

Steps To Reproduce the issue

No response

Relevant log output

Charging process A
start: 2026-07-09 03:00:32
duration: 35m
SOC: 35% -> 38%
rated range: 198 km -> 214 km
energy added: 1.20 kWh
energy used: 2.53 kWh
efficiency: 47%
Charging process B
start: 2026-07-09 03:38:56
duration: 2.1 h
SOC: 38% -> 50%
rated range: 214 km -> 282 km
energy added: 10.22 kWh
energy used: 10.79 kWh
efficiency: 95%
These two charging processes belong to the same plug-in session.

The important part is this:

process A ended with charge_energy_added = 1.20
process B appears to start with that 1.20 already included
TeslaMate then reports process B's added energy as the full 10.22, instead of rebasing it
So TeslaMate totals become:

process A added: 1.20
process B added: 10.22
summed total: 11.42
But if 10.22 is the cumulative net added value for the whole plug-in session, then process B's own contribution should be:

10.22 - 1.20 = 9.02
So at least 1.20 kWh is counted twice across the two processes.

Screenshots

No response

Additional data

No response

Type of installation

Manual (no support)

Version

v4.0.1

PostgreSQL version

No response

Are you running latest major supported PostgreSQL version?

• I run the latest major supported PostgreSQL version

Are you using a reverse Proxy for TeslaMate?

No

Details about your reverse Proxy if applicable

No response

[JakobLichterfeld]

Thanks for your report and detailed writeup.

May I ask if your call was awake? Did you miss a small scheduled charge while car tried to fall asleept?

[wolf800]

Thanks for your report and detailed writeup.

May I ask if your call was awake? Did you miss a small scheduled charge while car tried to fall asleept?

Thanks — if you meant car rather than call, then my understanding is:

I cannot prove from raw Tesla API payloads whether the car briefly tried to sleep right before the scheduled start, because I did not capture the raw upstream responses at that moment.

However, based on the charges rows stored by TeslaMate, the car does appear to have been actively charging from the start of the first recorded process, not just missing a tiny scheduled charge while falling asleep.

For example, at the beginning of the first process I already see non-zero charging values:

• start: 2026-07-09 03:00:32
• charger_voltage ≈ 217 V
• charger_actual_current ≈ 20 A
• charger_power ≈ 4 kW
• SOC increased from 35% to 38%
• rated range increased from 198 km to 214 km

So energy was clearly already flowing during that first segment.

The more suspicious part is that the second charging process in the same plug-in session appears to inherit the previous charge_energy_added value (1.20 kWh) instead of starting from zero. That is why I suspect the field is cumulative across the whole plug-in session, rather than local to each charging_process.

So my current answer would be:

• I cannot fully rule out some sleep/wake behavior around the scheduled start without raw API payloads
• but the recorded charging data strongly suggests the first process was a real charging segment
• and the carry-over into the second process still looks like a plug-session-scoped counter rather than a per-process counter

[JakobLichterfeld]

Ty.

I cannot fully rule out some sleep/wake behavior around the scheduled start without raw API payloads

Just look in the logs of TeslaMate.

From a user perspective a short stop during a charge should not log a second one but extend the previous, like data connection loss.
I personally didn't observed the behavior you described when the car was genuinely asleep in between or I ensured it was not falling asleep while charge started.