[frahlg]

Draft for the next beta (owner's scope decision, 21 Oct 2026). Do not merge before that beta is cut.

Problem

Core restarts on every update. An OCPP 1.6 charger keeps its transaction through the restart and goes on naming it in MeterValues. Core started every charger with no transaction (transactionID −1) and handed out ids from 1 again. For a session that spans a restart:

• session_wh stayed at 0 until unplug, because OnMeterValues counts energy only while a transaction is known. The rig shows it: s7-25 with fix(loadpoint): Charge now keeps charging after a restart #1778 ended with ev_session_wh 0 while the car drew 11 kW.
• The stop computed MeterStop − 0, which is the charger's lifetime meter total. The simulator starts its meter at 0, which hides this; a real charger reports its lifetime register.
• A new transaction could get id 1 while another charger still held 1.

Change

All in go/internal/ocpp/handlers.go:

• The first MeterValues that names a transaction while none is known takes it up. Energy counts from that reading. A transaction the charger already stopped is not taken up again, so a late meter value cannot drop session_wh to 0 while the car is plugged in.
• A stop for a transaction Core never saw keeps session_wh as it was and records no ev_session_wh metric.
• Transaction ids start at the seconds since 1 January 2026. A restart starts above the ids the last run used unless that run started more transactions than it ran seconds, and the ids stay far inside 32 bits. A taken-up id also moves the next id past it.

OCPP 2.0.1 is unchanged. It has the same gap in OnTransactionEvent (Updated with no known transaction).

What this does not fix

• Energy from before the restart is still lost. The start reading lived only in the old process, so delivered_wh_session still restarts near 0.
• FTW's saved last order (restoreOffers) is still not restored for OCPP. It needs session_wh that has not gone back. After a restart Core also sends its first command about 1 s after the charger reconnects, before the first MeterValues (8 s later in the rig, often a minute on real chargers). A fix needs the start reading kept in state.db and a first command that waits for a reading or asks for one.

Evidence

• transaction_resume_test.go: three tests fail on master and pass here (taking up the transaction, the stop of an unseen transaction, ids after a restart). One more guards the late meter value, and one checks the id start.
• make verify passes.
• Rebased on master after fix(ocpp): an Available charger is a measured 0 W #1779 and fix(loadpoint): Charge now keeps charging after a restart #1778 merged; package tests and make verify pass again there.
• Rig s7-25 (device-simulator, 20 s Core restart while Charge now runs), both on master 41675e4 + fix(loadpoint): Charge now keeps charging after a restart #1778 head 2413095:
  • without this change: ev_session_wh 4038 before the stop, 0 for the rest of the run;
  • with it: the log says OCPP running transaction taken up txid=25371034 meter_wh=3337; ev_session_wh counts again, 607 Wh after 150 s. The charger's MeterValues name the same id throughout.
  • Both runs fail the scenario for a reason this PR does not touch: after the restart the fuse guard holds the car at 7.8 kW (fuse_limit in every sample) instead of 11 kW. An earlier run on fc621be + fix(loadpoint): Charge now keeps charging after a restart #1778 released after ~30 s; master has fix(control): count EV raises per phase until the charger can apply them #1776 since then.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-21T15:50:10.571516Z	89f2cce	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 89f2cceea6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reject non-finite readings before adopting a transaction

If the first energy register received after restart contains "NaN" or "Inf", strconv.ParseFloat accepts it without an error, and this assignment permanently stores a non-finite session baseline. Every subsequent valid reading then produces non-finite session energy, and pushReading cannot marshal its telemetry payload because JSON rejects these values. Unlike a bad sample during an ordinarily started transaction, later valid samples cannot recover this session. Check that the converted meter reading is finite before adopting the transaction so a later valid reading can establish its baseline.

Useful? React with 👍 / 👎.