Repository navigation
fix(loadpoint): a charger on one phase under a three-phase order is seen, and planned at its rate - #1796
fix(loadpoint): a charger on one phase under a three-phase order is seen, and planned at its rate#1796frahlg wants to merge 1 commit into
Conversation
…een, and planned at its rate Field report, v0.155.0-beta.1, Easee Cloud: a 7.6 kW three-phase plan order drawn as 3.13 kW on one phase all night, about 13 of 24 kWh. With a schedule and an empty phase mode Core sends auto and counts it on three phases above 3,680 W; the Easee driver splits auto at the fuse's current on one phase (8,050 W at 35 A) and locks phaseMode 1. An Easee can also stay on one phase. The loadpoint controller now compares the charger's fresh power with the site meter's phases under a three-phase order. Two minutes with all of the current on one phase and less than a third on the others mark the session: the plan counts the rate delivered there (LimitPower), the controller repeats the order that delivered it while a slot has energy left, and the verdict is Limited, "Charging on one phase", with the phase and its current. The fuse limit is unchanged. The closed-loop sim splits auto as the Easee driver does and gains a charger stuck on one phase. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8ac9db74f2
ℹ️ 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".
| if st, known := c.manager.State(lpCfg.ID); known && wantW > 0 && st.OnePhase > 0 && st.OnePhaseOrderW > 0 { | ||
| wantW = min(st.OnePhaseOrderW, maxW) |
There was a problem hiding this comment.
When a detected 3,130 W session is replanned, LimitPower supplies 3,130 W as the MPC maximum, and coreReservePlan emits that value in LoadpointMaxPowerW. The preceding duty-plan branch therefore lowers maxW to 3,130 W, so this assignment clips the saved 7,590 W order back to 3,130 W. The final SnapChargeW(3130, 4140, 3130, steps) returns zero because the ceiling is below the charger's minimum. Consequently, the reserve/duty-plan path stops charging after detecting precisely the one-phase case this change addresses. Keep the modeled delivered-power ceiling separate from the legal hardware-order ceiling, and cover a directive containing LoadpointMaxPowerW in the regression test.
Useful? React with 👍 / 👎.
| case phase > 0 && below == 2: | ||
| return phase |
There was a problem hiding this comment.
On a solar-equipped site, these absolute net meter currents can identify a correctly operating three-phase charger as single-phase. For example, a 4,140 W EV drawing 6 A per phase, balanced 4,140 W PV generation, and household currents of [18, 0.5, 0.5] A leave exactly [18, 0.5, 0.5] A at the meter; onePhaseDraw(4140, 230, ...) returns L1. After two minutes, LimitPower caps planning at 4,140 W and the controller repeats that order instead of allowing higher charging rates, potentially missing a departure goal despite available charger capacity. Net site-current magnitudes alone do not establish the EV's phase distribution; require corroborating charger evidence or account for background load and generation before latching this restriction.
Useful? React with 👍 / 👎.
|
Back to draft. Fredrik's direction for a one-phase car (22 Oct 2026): keep the charger on three phases, learn the car's phases from the site meter when charging starts, keep them on the car (the |
1 participant
Problem
Field report, 22 Oct 2026, v0.155.0-beta.1, Easee Cloud. The plan said "Charge EV at 7.6 kW" on three phases until 09:00, about 24 kWh. The car drew 3.13 kW all night, about 13.6 A on one phase (three phases at Easee's 6 A minimum would be 4.14 kW), and about 13 kWh arrived. Nothing told the household why, and the plan went on counting 7.6 kW.
How FTW itself can put an Easee on one phase
phase_mode, Core sendsphase_mode: "auto"(resolvePhaseMode,controller.go:2232) and nophase_split_w.defaultPhaseSplitW).easee_cloud.luapick_phasessplits auto at voltage ×max_amps_per_phase, which Core fills with the site fuse: 5,750 W at 25 A, 8,050 W at 35 A. Between the two splits Core counts three phases and the driver writesphaseMode=1with amps = W/230, capped by the fuse and the charger.The closed-loop sim now splits auto as the driver does. At 35 A a 7.59 kW auto order puts 16 A on L1 and a car that takes 3,130 W draws exactly the field numbers. A charger stuck on one phase gives the same signature.
The fuse limit is not wrong here. It reads the site meter: cutting a three-phase order by X A per phase lowers a one-phase draw by X A once the order is below the car's own current. It is the plan and the feedback that count the order's watts.
Change
loadpoint/one_phase.go). When one phase carries all of the charger's current and the other two less than a third of it, for two minutes, the session is on one phase: that phase, the most it delivered there and the order in force then. Two minutes with every phase carrying its third, or unplugging, ends it. Below 2 kW it does not judge: a third would hide in the house load.LimitPowergives the delivered rate as the power for the session, so the plan and the goal's need (DeadlineNeed) stop counting the order's watts.charging_phase,charging_phase_a). It explains a draw below the order only; a draw above the order is still judged against it.Evidence
TestThreePhaseOrderDrawnOnOnePhaseIsLimitedruns the real loadpoint controller, command evidence and the API.TestOnePhaseDraw,TestOnePhaseHoldsForTheSession,TestLimitPowerCountsOnePhaseRate,TestOnePhaseRepeatsTheDeliveringOrder; web words incontrol-feedback.test.mjs.go test ./internal/api/... ./internal/telemetry/... ./internal/control/... ./internal/loadpoint/... ./internal/sitesim/... ./internal/mpc/... ./cmd/ftw/...andnode --test web/control-feedback.test.mjspass.Not in this PR
control-feedback.jsand the iOSControlFeedback.swiftneedone_phase; until then they show the reason code. The on-box page needs a look in a browser.classifyControlFeedback); whichever lands second rebases. fix(charging): carry two-phase cars through plans, current limits and Easee #1792 (two-phase cars) touchesLimitPower's neighbours andcontroller.go.🤖 Generated with Claude Code