[frahlg]

Problem

Item C9 from the 27 October random rig triage (master 83c2b24). Until FTW's first charging profile lands, an OCPP charger runs at its own default, which is usually its rating. FTW orders a plugged-in car every tick, but the first order still takes one tick plus the charger's response time.

Seed 207534 (house/plant.jsonl, house/ocpp-garage.jsonl, ftw.log), in house elapsed seconds:

Time	What happened
5.0 s	BootNotification from the charger. FTW sends no profile. offer_w 11040.
7.3 s	Car plugged in (Preparing).
8.5 s	FTW's first 0 A order is accepted (refused on connector 0, accepted on connector 1).
10–13 s	The charger has not applied it yet (5 s response). The car draws 11040 W. Phase current reaches 18.87 A on a 16 A fuse.
13.5 s	offer_w drops to 0.

The same pattern gives 18.9 A peaks in 207537. With a 0 A profile sent at boot, the 5 s charger in 207534 would have held 0 A about 3.5 s sooner; with the one-second settle wait added in e6fc34b (below), about 2.5 s sooner. This does not help the 40 s chargers in 207532 and 207537. Those need the rig fix (R4).

Rig s7s on 964643e

siterig/short failed twice on s7s-restart-short-25A ("Charge now never stops"): ~/siterig/results/20261027-232851-964643e9-short and ~/siterig-pr/results/20261028-003905-964643e9-short. Master and other PRs pass s7s. The scenario restarts Core for 20 s during Charge now. From house/ocpp-garage.jsonl, seconds after the first boot:

Time	What happened
119.08	The charger reconnects and sends its own BootNotification at once, before FTW's identity probe.
119.08	FTW sends the 0 A start limit (connector 0 refused, connector 1 accepted).
119.08	The charger reports connector 0 Available and connector 1 Charging.
120.03	Connector 1 goes SuspendedEVSE. The car drops to 0 W.
121.04	FTW's own order lands. The car is back to Charging.

The new process held no status and no transaction, so the boot alone looked like a fresh start. The first version of this PR listed this case under Risk as a one-tick pause in the safe direction; the rig counts it as Charge now stopping, and it is right to.

Change

• After a BootNotification (1.6 and 2.0.1), FTW waits for the charger's connector statuses. Once they have been quiet for one second (defaultBootLimitSettle) and none showed a car or an open transaction, FTW sends a managed charger the 0 A profile it already sends to pause: TxDefaultProfile, profile id 1, stack level 0, connector or EVSE 0, with the existing retry on connector 1. A 1.6 charger reports each connector after an accepted boot (§4.9); 2.0.1 stations send StatusNotification there too. On 1.6, connector 0 Available does not count, since it says only that the controller is up. The new code is in go/internal/ocpp/boot_limit.go: maybeSendBootLimit marks the boot, resolveBootLimit runs on each status, fireBootLimit sends when the wait ends. It reuses setLimit, so it shares the one-profile-at-a-time slot with FTW's orders.
• Why the wait (e6fc34b, from review): the limit goes to connector or EVSE 0, the whole charger. On 92104f5 the first status with no car decided alone, so on a two-socket 1.6 charger or a two-EVSE 2.0.1 station a Core restart with a car charging on socket 2 got 0 A as soon as socket 1 reported Available, and that car paused. That is the s7s fault on another charger shape. Now:
  • any status that shows a car or a transaction cancels the limit as it arrives. FTW keeps one connection state per charger and the last status wins, so a check only when the timer fires would miss a car on socket 2 that reported before socket 1;
  • each status with no car restarts the one-second timer, so a slow burst still counts as one burst;
  • an ev_set_current, ev_pause, ev_start or ev_resume from FTW during the wait cancels it (cancelBootLimit in Server.Command), so the 0 A cannot land after FTW's own order.
• Meter values count too (797f806, from review). On a two-socket 1.6 charger after a Core restart, socket 1 may report Available and socket 2 may then send the meter values of its running transaction before its own status. Without fix(ocpp): take up a running 1.6 transaction after a Core restart #1787, FTW holds no transaction id at that point, so the 0 A went to the whole charger and paused that car. A 1.6 MeterValues that names a transaction, or that measures power above zero, now cancels the pending limit as it arrives (meterCancelsBootLimitLocked in boot_limit.go, two call lines in OnMeterValues). On 2.0.1 a running transaction reports through TransactionEvent, which already marks the car and blocks the send.
• FTW's later orders use the same id, purpose and stack level, so they replace the boot profile (OCPP 1.6 §3.13.2; 2.0.1 K01.FR.05).
• A managed charger is one that a loadpoint names. That is the new ocppManagedIDs in go/cmd/ftw/ev_send.go, passed as ocpp.Config.ManagedIDs and updated on hot reload. A charger listed only under ocpp.chargers is approved and metered, but FTW never orders it, so a 0 A start would hold it at 0 A for good. FTW leaves it alone, and pending chargers too.
• FTW skips the boot profile when:
  • the boot answers FTW's own identity probe. After a Core restart the charger did not restart, and the car may be charging under FTW's last order.
  • the last status FTW holds for the charger shows a car, or a transaction is open. This holds across a reconnect: much firmware sends its own BootNotification on every reconnect, before any status, so after a Wi-Fi drop the new socket alone says nothing about the car. FTW orders that car every tick.
  • Core runs in setup measurement mode. That mode blocks every charger write, standdowns included, so ocppStartLimitIDs passes no managed chargers, at start and on hot reload. It reads the mode Core booted in, because leaving it takes a restart.
• If the charger refuses, FTW logs one warning and does not retry until the next boot.
• handlers.go gets four call lines, five struct fields and two lines that clear the mark on connect and disconnect, apart from the lines fix(ocpp): take up a running 1.6 transaction after a Core restart #1787 changes. Start in server.go sets the wait, not NewHandler, whose nextTxID line fix(ocpp): take up a running 1.6 transaction after a Core restart #1787 changes. The branch merges cleanly with fix(ocpp): take up a running 1.6 transaction after a Core restart #1787 (git merge-tree on 797f806). This fix does not need fix(ocpp): take up a running 1.6 transaction after a Core restart #1787: the status after the boot shows the car, and a meter value for a running transaction cancels the limit even when that status comes late.

Tests

Each test below fails on master and passes on this branch. Before the fix, no profile arrives at boot and the simulator keeps its rating:

• go/cmd/sim-ocpp/ocppcp/boot_limit_test.go TestChargerHoldsZeroAmpsFromBootUntilFTWOrder runs FTW's Central System against the charger simulator for easee-charge-up (1.6), charge-amps-aura (1.6, refuses connector 0) and defa-power (2.0.1). In each case:
  • the unsteered limit is the rating;
  • after boot the effective limit is 0 A;
  • after plug-in the car draws 0 W;
  • after FTW's 6900 W order the effective limit is 10 A and the car draws 6900 W.
• go/internal/ocpp/boot_limit_test.go:
  • The 1.6 and 2.0.1 boot profiles are 0 A TxDefaultProfile on connector or EVSE 0, with id 1 and stack 0. FTW's order uses the same id, purpose, stack level and connector, at 16 A.
  • A refused start limit sends exactly two profiles (connector 0, then 1) and then nothing more.
• These guard against regressions and pass with or without the change:
  • A charger listed only under ocpp.chargers and a pending charger get no profile.
  • A boot after the socket reported Charging gets no profile.
  • A boot that answers FTW's identity probe gets no profile.
  • A reconnect boot after the car left gets the start limit again (TestReconnectBootWithNoCarGetsBootLimit).
• TestReconnectBootMidSessionKeepsFTWOrder: the charger reported Charging and took FTW's 16 A, then reconnected and booted before any status. It gets no profile. With the first version of this PR it got 0 A.
• The s7s shape, both fail on 964643e and pass on 92104f5 (checked by reverting only the source files):
  • TestCoreRestartBootMidSessionGetsNoBootLimit (1.6): a new Server, the charger boots on its own, then reports connector 0 Available and connector 1 Charging. On 964643e it got 1 profile at 0 A; now none.
  • TestV201CoreRestartBootWithCarGetsNoBootLimit (2.0.1): the same with Occupied.
• The boot-limit tests now report a connector status after the boot, as real chargers do. TestManagedChargerStartsAtZeroAmpsOnBoot also checks that the boot alone sends nothing. The simulator test sends the simulator's Available after Boot(); Sim.Boot itself is unchanged, so the e2e tests see the same frames as before.
• go/cmd/ftw/ev_send_test.go:
  • TestOCPPManagedIDsAreLoadpointChargersOnly.
  • TestOCPPStartLimitIDsFollowMeasurementModeAtBoot: no charger gets the start limit when Core starts in measurement mode, nor on a reload that has left the mode before the restart.
• Two sockets and the settle wait (e6fc34b). The boot-limit tests in go/internal/ocpp use a 50 ms wait so settle() (300 ms) covers it; the simulator test uses the real one second.
  • TestDualSocketCoreRestartCarOnSocket2GetsNoBootLimit (1.6: boot, then connector 0 Available, 1 Available, 2 Charging) and TestV201TwoEVSECoreRestartCarOnEVSE2GetsNoBootLimit (2.0.1: EVSE 1 Available, then EVSE 2 Occupied) fail on 92104f5 with "got 1 profile(s), last 0 A; want none" and "got 1 profile(s); want none", and pass now.
  • TestDualSocketCarReportedFirstStillCancelsBootLimit (socket 2 Charging before socket 1 Available) passes on 92104f5 too. It pins the cancel on arrival: with that cancel removed, so only the timer checks, it fails with 1 profile.
  • TestOrderDuringSettleWaitCancelsBootLimit: FTW orders 16 A right after the Available. With the cancelBootLimit call removed it fails 3 of 3 runs with "2 profile(s), last 0 A"; with it, FTW's 16 A is the only profile.
• Meter values during the wait (797f806). The tests use a 200 ms wait and check 400 ms later.
  • TestMeterValuesShowingACarDuringWaitCancelBootLimit: boot, connector 0 and 1 Available, then MeterValues on connector 2 in three cases: transaction and 7 kW (the reviewer's shape), transaction at 0 W, and 7 kW with no transaction. All three fail on a814fb4 with "got 1 profile(s), last 0 A; want none" and pass now, 3 of 3 under -race.
  • TestIdleMeterValuesDuringWaitKeepBootLimit: MeterValues at 0 W with no transaction still gets the 0 A limit. It passes before and after, and guards against cancelling too often.
  • The reviewer's three edge tests (TestReviewNoCarStatusRestartsTheWait, TestReviewV201TransactionUpdateDuringWaitBlocksBootLimit, TestReviewMeterValuesWithTransactionDuringWait) pass 3 of 3 under -race on 797f806. I ran them from a temporary copy and did not commit them, since the new tests cover the same shapes.
• On 797f806: gofmt and go vet ./internal/ocpp are clean. go test -race passes on ./internal/ocpp/..., ./cmd/sim-ocpp/... and ./cmd/ftw. make verify passes (Docker steps skipped, no daemon). My first make verify run failed in one test I did not capture; make test and make verify then passed in full. The known TestLaterRunsAfterTheSlotIsFree flake fails on master too. The repo-hygiene scripts pass against 7840c33 (check-no-planning-docs.sh; check-telemetry-reads.sh, 134 reads, none added; test_telemetry_reads; test_verify). On a local merge of 797f806 with fix(ocpp): take up a running 1.6 transaction after a Core restart #1787 (92230c0, clean), go test -race ./internal/ocpp/... passes.
• On a814fb4 (e6fc34b merged with master 7840c33, plus a814fb4, which only moves where the wait is set; make verify, the internal/ocpp and sim-ocpp race tests, the e2e subset and the hygiene scripts ran again there): go test -race on ./internal/ocpp/..., ./cmd/sim-ocpp/..., ./cmd/ftw and ./internal/loadpoint passes, the boot-limit tests pass 3 of 3 under -race, FTW_E2E=1 go test ./test/e2e -run 'Evify|OCPP|Ocpp' passes, make verify passes (Docker step skipped, no daemon), and the repo-hygiene scripts pass against 7840c33 (check-no-planning-docs.sh; check-telemetry-reads.sh, 134 reads, none added; test_telemetry_reads, test_verify). I did not run TestSite or siterig, and I touched no real devices. No siterig result exists yet for 92104f5 or later; s7s-25 should pass, since the charger reports connector 1 Charging inside the wait.

Risk

• Order race. An FTW order during the wait cancels the limit. What remains is the moment between the timer firing and the boot profile taking the profile slot, a few microseconds: an order that wins the slot in that gap is overridden by 0 A until the next tick re-sends it. The error is in the safe direction.
• One second later. The limit now goes out about one second after the last status, not at the first. A car plugged in during the wait reports Preparing, which cancels the limit, and FTW's own order covers it, as on master. A charger whose statuses arrive more than a second apart is treated as two bursts; a car on a socket that reports after the limit went out is paused until FTW's next order.
• Reconnect or reboot with a car plugged in. If FTW last saw a car, or a transaction is open, it sends no start limit. A charger that really power-cycled with a car keeps its own default until FTW's next order, as before this PR. A car that left while the charger was offline also leaves no start limit at that boot.
• Core restart with self-booting firmware. Fixed in 92104f5 (see the s7s table). The charger reports Charging after its boot, so FTW sends nothing.
• Meter values cancel on raw content. A 1.6 meter value cancels the limit when it names a transaction or shows power above zero, even if the power sample is too old for FTW to record. A queued sample from before the boot can then leave the charger without a start limit, which is how master behaves. The cancel never sends anything, so it cannot pause a car.
• No status after the boot. A charger that never sends a connector status after its boot gets no start limit, as on master. The mark clears on the next connect.
• Two connectors. Charger state is per charger, not per connector. The start limit now handles that (above): a car on any socket in the burst cancels it, in either order. The same per-charger state still treats one Available as 0 W for both connectors, as on master; that is outside this item.
• No car plugged in. This does not cover a charger that keeps FTW's last non-zero order after an unplug and then sees a new plug-in. That case is outside this item.
• Hardware. I have no hardware evidence. Validate on a beta site with an OCPP charger: boot it, plug in a car, and check that it holds 0 A until FTW orders.

Merge order

Independent of #1787. Either can merge first; they merge cleanly together, and the internal/ocpp race tests pass on the merge. Since 797f806, this PR no longer needs #1787 for the case where a running transaction shows only through meter values.

🤖 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-27T17:03:29.871477Z	3e46299	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.