[frahlg]

On master with #1802 and #1801.

Problem

The field matrix (#1800) has two hold3p rows. A 32 A one-phase charger has the step table [0, 1380, 2300, 3680] on an auto loadpoint. Charge now leaves the car idle while there is room for it.

• The API reported phases: 3 for an auto or unset loadpoint on a three-phase site, so the app sent Charge now as "3p".
• holdPhaseMode treated the client's "3p" as a pin. A three-phase order on that table has no step at 6 A a phase, so it went out as 0 W.

Users hit this class of bug: Charge now does nothing.

Change

• Core (holdPhaseMode): a client's "3p" on a charger that threePhaseCapable rejects is not a pin. The loadpoint's own mode decides, so auto and unset run on one phase. A loadpoint pinned to 3p keeps it, as fix(loadpoint): planned charging runs on three phases, and room never cuts a running order #1799's TestResolvePhaseMode requires. The client states intent; Core decides what the charger can run.
• API (decorateLoadpointsWithManual): a charger that cannot run three phases reports phases: 1 unless it is pinned to 3p, as Core runs it. The app then sends "1p", and the manual amp slider's range is the charger's one-phase range: 6–32 A for the table above.
• loadpoint.ThreePhaseCapable exports the existing check for the API.

Evidence

32 A one-phase table, auto, Charge now "3p"	master	this PR
Order	3,680 W 3p (no step, 0 W at the charger)	3,680 W 1p
/api/loadpoints phases	3	1
Matrix hold3p rows	car idle with room (2 rows)	both pass

• TestChargeNowOnAOnePhaseChargerIgnoresAClients3p: fails on master (3,680 W "3p"), passes here.
• TestChargeNowRunsOnThreePhases: three new cases. A client's 3p on a one-phase charger, unset or auto, gives 1p; a loadpoint pinned to 3p keeps 3p. Two fail on master.
• TestLoadpointsReportTheChargersPhases: six cases. Two fail on master (phases 3, want 1).
• Field matrix on master with fix(loadpoint): a one-phase car on a three-phase charger is seen, planned and ordered as one #1801: both hold3p rows pass, and their lines and label go. No row is new. 338 cases, 29 fail: idle 23 (export 13, readback 10) and own-raise 6 (relief).
• go test passes for api, loadpoint, control, sitesim, telemetry and cmd/ftw; go vet is clean.

Limits

• A loadpoint pinned to 3p on such a charger still goes out as 3p, under Charge now and under a plan. That is a configuration conflict; fix(loadpoint): planned charging runs on three phases, and room never cuts a running order #1799 kept operator pins as they are.
• No web code changes. In a local run (make dev with this loadpoint and sim-ocpp), the Charge now slider for the table above reads 6–32 A on one phase, from max_charge_w 7,360 W. It does not read the step table, so its top half asks for more than the 3,680 W Core sends. On master it read 2–11 A on three phases. The UI still needs a person to check it in a browser.
• In that run, every one-phase order got a fuse cap of 0 W (fuse_limit), including one from a loadpoint pinned to 1p, which takes the same path on master. A three-phase charger in the same run charged at 11,040 W. This is outside this PR and needs its own look in the EV fuse budget.
• Draft fix(charging): carry two-phase cars through plans, current limits and Easee #1792 (two-phase cars) changes holdPhaseMode and the same switch in decorateLoadpointsWithManual. Whichever lands second needs a rebase.

🤖 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-22T10:25:12.059057Z	0156fb7	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.