[frahlg]

Item E1 of the stable plan (27 Oct 2026). OCPP 1.6 only; 2.0.1 Updated and Ended follow in a separate PR.

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. Rig 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, the charger's lifetime register. Example: a car on transaction 42 finishes at a register of 12,345,678 Wh; Core reported a 12.3 MWh session to the loadpoint, the UI, the cloud link and the ev_session_wh metric.
• A new transaction could get id 1 while another charger still held 1.
• A stop naming any id ended the running transaction. With transaction 1 running at 2 kWh, a stop for id 999 with MeterStop 9,000,000 set transactionID to −1, charging to false and session_wh to 8,999,000.
• strconv.ParseFloat accepts "NaN" and "Inf". Taken up as the start reading, one would spoil every later session value, and pushReading cannot marshal a non-finite value (Codex P2 on this PR).

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.
• A stop for a transaction Core never saw keeps session_wh and records no ev_session_wh metric. It still ends charging and clears measured power as before.
• A stop that names another id than the running transaction is logged and confirmed, and changes nothing. Status notifications still drive charging and connected.
• MeterValues skips a sampled value that is NaN or ±Inf.
• Transaction ids start at the seconds since 1 January 2026, so a restart starts above the last run's ids, and ids stay far inside 32 bits. A taken-up id also moves the next id past it.

What this does not fix

• Energy from before the restart is still lost; the start reading lived only in the old process.
• FTW's saved last order (restoreOffers) is still not restored for OCPP.
• OCPP 2.0.1 has the same gap in OnTransactionEvent. It comes next.

Tests

• transaction_resume_test.go: eight tests. The take-up, unseen-stop, id and lifetime-register tests fail on master. TestOCPP16StopForAnotherTransactionKeepsTheRunningOne and TestOCPP16NonFiniteRegisterIsNotTakenUp fail on this PR's previous head and pass now. The last two are the audit's repro tests (TestReproStopNotMatchedToTransaction, TestReproRestartStop16ReportsLifetimeRegister) under normal names.
• cd go && go test -race ./internal/ocpp/... -count=1: ok.
• go vet ./... and go build ./...: ok.
• Rig s7-25 on the earlier head (20 s Core restart while Charge now runs): without this change ev_session_wh read 0 after the restart; with it the log says OCPP running transaction taken up txid=25371034 meter_wh=3337 and ev_session_wh counts again. Rig R4 in the stable plan covers it on this head.

Risk

Low. Nothing here touches dispatch, fuse math, signs or the command path. The one new state rule keeps a running transaction when a stop names another id. If a charger sends a wrong id for the real stop, Core keeps the transaction id until the next StartTransaction replaces it, and that session records no ev_session_wh metric. charging, connected and measured power still follow the status notifications and meter values, so control sees the car stop.

🤖 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-27T13:26:03.741882Z	92230c0	Draft marked ready

ℹ️ 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 👍 / 👎.