[frahlg]

Problem

Item C2 of the 27 October rig triage (section 3, item 2): Core raised battery charge into a phase that was already full.

• Seed 207530, 897 s: L3 read 16.04 A on a 16 A fuse, and the order went from 491 W to 2983 W.
• Seed 207535, 37–41 s: L3 read 14.27 A, the order went from 12 W to 871 W (L3 15.52 A), then from 566 W to 797 W with L3 at 15.52 A. The charge then rose and fell around the limit: 871, 566, 797, 632 W.

On master the battery's charge is checked against the total import ceiling only. #1891, lower in this stack, adds a check on each phase, but it measures the rise from the battery's own reading. That fails when the meter's reading is older than the battery's: the battery already reads its last order while the meter still shows it before the move. The guard then takes the order as shown and stacks the next rise on top. The rig's plant shows that lag (207535, 39 s: battery 871 W, L3 still 14.27 A; 40 s: 15.52 A). A charger's raise that the meter does not show yet counts only while the car has a fuse demand (clampEVBatteryHeadroom).

Site rig on c9b52c3 (28 Oct)

siterig/short failed s1-16, s1-25 and s15-25 on this branch's c9b52c3 ("holds 95 % of the time"; on 25 A also "no fuse_limit with room to spare"), while #1923 at 53b8aa3 passed all nine. The cause is not this branch's battery check. c9b52c3 held #1923 only up to 281f9f6, before #1923's ab02710. In s1-25 the charger took the 16 A offer within a second, and the meter reading that showed it came in 7 ms before the tick that first logged the offer:

EV hard limit: site meter over limit grid_w=10972.8 worst_phase_a=15.9 unshown_rise_w=11040 rise_on_its_way_a="[16 16 16]" offer_w=11040 cap_w=5520

A reading cannot show an offer logged after it, so the C4 tracker held the shown current at 0 A. The landing then counted as a raise still to come: 15.9 + 16 A passed 1.2 × In, and Core cut 11,040 W to 5,520 W with 9 A of room on every phase. The car crept back 1 A at a time and held 9,660 W on fuse_limit. s15-25 cut a one-phase 3,680 W offer to 1,840 W the same way; s1-16 cut to 0 W. The battery covered the house throughout (about −2,090 W), and fitBatteryRisesToFuse never touched the car.

I ran the same three scenarios here with the device simulator. #1923's 281f9f6 alone, without this branch's commits, fails s1-25 and s15-25 the same way, with the same log line. This branch's head c0a5274, which merges #1923's ab02710 ("judge a raise's landing from the meter's rise"), passes all three.

Change

fitBatteryRisesToFuse runs right after applyFuseGuard. It caps charge above the battery's latest order (its reading before Core's first order) to

(fuseLineA − worst phase − own unshown rises) × V × phases

• Own unshown rises are the battery's latest order less the least the meter may show of the battery (unshownBatteryW), plus each charger's raise, counted the way evShownW counts them (batterySettle: the declared response time, else evSettle). The car comes first. The least the meter may show is the lowest of the battery's orders over the last evSettle and of its own readings over that time, the current one included. So an order stays unshown until evSettle after the battery reads it, which covers a battery that ramps slower than evSettle. Core now logs each battery's reading next to its order (batteryReadings).

• A discharge that the target ends uses room first.

• Holding an order is never a rise, and this check never cuts. A phase over the line stays with the relief (applyFuseGuard, forceFuseDischarge and its heat model), which reads the battery's own power.

• No margin and no 1 A floor. The working limit is fuseLineA, In − safety_margin_a, so the order ends at the line. The evSettle wait for our own rise is an anti-hunting timer at the line, not current held back.

• The direction of a meter that gives no phase power while the total exports moves into phaseSample.signedPhasesA. phaseFuseReliefW and the new check both use it. A phase there counts as export only when the other phases' currents, at most V × A of real power each, cannot carry the export alone (tolerance as in phasePowersAddUp). Any other phase may be a load beside exporting phases and counts as import. Before this, every phase flipped to export. Tibber Pulse is such a meter: it emits l*_a and no l*_w.

• The battery's own power comes from Store.OnlineRawW, as phaseSample.moveW reads it, so an offline battery's last value never sets the rise base or the least the meter may show. This keeps the repo-hygiene check "no new direct telemetry reads" green; the first version added three direct RawW reads.

• Merge fallout from fix(control): battery fuse cut lands on the line, not half a margin below #1913: a5's phase anti-windup (phaseReliefForTargets) called signedA, which this branch had folded into signedPhasesA. It now calls signedPhasesA, so it reads phase direction the same way as the relief and this check.

• Rig finding (s1, s15): no code change. fix(control): a landed EV cut covers nothing later; a raise that no longer fits comes off #1923's ab02710, merged in c0a5274, fixes it. A new test pins the rig's shape so it cannot come back unseen.

This is #1789's fitBatteryRisesToFuse without its 1 A minimum margin, cut down to the rise check. #1789 is not merged or needed.

Tests

New in go/internal/control/battery_rise_phase_test.go, all through ComputeDispatch, on a 16 A fuse with no margin:

Test	Without the fix	With the fix
TestBatteryRiseIntoPhaseOverTheLine: 207530, phases 8.5/10.5/16.04 A, reading 491 W, ask 3350 W, order ≤ 491 W	passes (463 W, from #1891)	passes
TestBatteryRiseCountsOwnUnshownRise: 207535, phases 13.77/13.97/14.27 A, ask 871 W goes out whole; then the battery reads 871 W, the meter has not shown it, ask 1500 W, order ≤ 12 + (16 − 14.27) × 690 = 1205.7 W	fails: 1500 W, L3 16.43 A	passes
TestBatteryRiseClosedLoopStopsAtTheLine: closed loop, the ask grows 300 W a tick, the battery moves one tick late, the meter one tick after the battery	fails: L3 reaches 16.44 A, orders 1494, 1187, 894, then 1194 W	passes: L3 never over 16 A, the order never falls, it ends at 1193.7 W (the line)
TestBatteryRiseLeavesRoomForUnshownCarRaise: car first, a 6 → 10 A raise not shown yet, L3 at 11 A, battery ask 2000 W → ≤ 690 W, then 690 W and L3 at 16 A once shown	with the car's demand: passes (clampEVBatteryHeadroom); fails without it: 2000 W	passes both
TestBatteryRiseMagnitudeOnlyMeter: no phase power, 15.5/8.7/8.7 A, total −1300 W, ask 3000 W → ≤ (16 − 15.5) × 690 = 345 W; then 17.5 A on each phase with −12075 W total, every phase must export, and the whole 3000 W goes out	fails: 3000 W, L1 19.85 A if it imports	passes both halves
TestBatteryRiseSlowBatteryLaggingMeter: the battery ramps 50 W a tick, the meter shows it two ticks after the battery reads it, 120 ticks	fails: L3 16.145 A, orders 1194 → 1294 at 30 s, then 1287 … 1000 and back to 1194	passes: L3 never over 16 A, the order holds 1194 W

The last two came from review. Each test was run against the code before its fix and failed as shown.

One golden record moved: early_exit/deadband_per_phase_export_side_quiet (L1 26 A, L2/L3 8 A, no phase power, total −6000 W). L2 and L3 may import there, so the relief's per-phase overage attribution drops from 2300 W to 2070 W: a 10 A charge shift would push them to 18 A, and the relief takes the middle instead. The targets did not change. I edited that one value by hand, since a full re-dump also rewrites unrelated rounding in other families. The plain fix (no flip at all) moved 8 seeded_fuse records and cut charge that soaks up export above the fuse. With the per-phase test, those records do not move.

Second check, on the stack as merged on 28 Oct: the reviewer's tests TestReviewRiseMagnitudeOnlyMeterMixedDirections, TestReviewRiseSlowBatteryLaggingMeter and TestReviewRiseClosedLoopSlowMeterAndStep pass. TestReviewRiseFrozenValuesMeter still climbs to 3581 W, as expected: C5 (#1921) owns frozen meters. With the live battery reading switched off, TestBatteryRiseSlowBatteryLaggingMeter fails again (order falls 1294 → 1287 W), so the OnlineRawW path is the one the tests use. .github/scripts/check-telemetry-reads.sh against this PR's base: before, dispatch.go: 40 -> 43; after, none added.

• go test -race -count=1 ./internal/control/... passes.
• make verify passes ("vet + test + build clean"). The Docker steps skipped because no Docker daemon is running here.

Rig finding: TestEVFuseRaiseShownBeforeItsOfferIsLogged (new, ev_fuse_offer_logged_late_test.go) replays the s1/s15 shape through EVFuseBudget. Each meter reading comes in 7 ms before the tick that reads it, and Core logs the offer one tick after it went out, when the meter already shows the car.

Case	c9b52c3 and 281f9f6	c0a5274 and this head
25 A fuse, 11,040 W, landed at 15.9 A a phase	fails: cut to 6,210 W	passes
16 A fuse, 10,350 W, landed at 15 A a phase	fails: cut to 690 W	passes
one-phase charger on L1, 3,680 W, landed at 16 A on L1	fails: cut to 0 W	passes

Local TestSite (FTW_SITE=s1-16,s1-25,s15-25), same device simulator pin as the runner:

• c0a5274 (this branch's head before the test commit): s1-16, s1-25 and s15-25 pass.
• 281f9f6 (fix(control): a landed EV cut covers nothing later; a raise that no longer fits comes off #1923 before ab02710, without this branch): s1-25 and s15-25 fail as on the runner.

The runner has not run c0a5274 or later yet.

Risk

• The rig finding needed no code change here. The offer log still stamps an offer when the next tick reads it, not when it went out. Since ab02710 a rise reads the meter's own rise and does not depend on that stamp. A cut's cover still reads the shown current, so a cut the meter already shows may count as cover for one more reading. That is fix(control): a landed EV cut covers nothing later; a raise that no longer fits comes off #1923's C4 code, and I left it alone.
• Near the line, a battery charge rises at most once per evSettle (20 s), because Core waits for the meter to show its last rise. Away from the line, nothing changes.
• The check only lowers charge above the latest order. It never adds discharge or cuts a held charge, so it cannot cause a new trip or a new swing.
• Without usable phase currents it does nothing, and the total guard stays the check.
• A battery that never reaches its order (its own limit, say) keeps the gap counted as unshown. The order still allows that power, so this is power that may land, not a margin.
• On a meter with no phase power, a phase that may import now counts as import in the relief too. That leaves the relief in the middle when one phase is far over in export and others may import; before, it assumed they all exported. A frozen meter is not covered here (fix(control): a site meter that repeats one reading counts as stale #1921, C5).

Stack and merge order

Stacked on #1923 (ev-cut-landed-and-unshown), which sits on #1913 → #1891 → #1910 → master. Merge after #1923.

#1923's head 8a10b27d (fourth-review fix of its C4 rule) is merged in here (c0a52740). The merge touched only ev_fuse_budget.go and ev_fuse_cut_netting_test.go, with no conflict. On the top of the stack (#1925 at 5babe51a), go test -race passes for ./internal/control, ./internal/loadpoint and ./cmd/ftw, and so does the non-race control run with the field matrix.

The rig-finding test commit 19d8a298 is merged into #1925 (3623603a), with no conflict. There go test -race passes for ./internal/control, ./internal/loadpoint and ./cmd/ftw. On this head, go test -race for ./internal/control and ./cmd/ftw passes, as do make verify and the repo-hygiene checks (no planning docs; telemetry reads 133, none added, against both master and #1923).

Other open PRs that touch these files: #1914 (margin default 0, a sibling on #1913) changes only the peak-limit error text in dispatch.go, so there is no overlap. #1921 (frozen meter), #1916 and #1878 (SoC floor) touch other parts of dispatch.go. #1789 and #1816 are older drafts of the same idea; this PR does not depend on them.

🤖 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-27T21:43:03.632507Z	43d38ff	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.