fix(mpc): aim an EV deadline past the horizon at its last slot - #1498
Merged
Merged
Conversation
When a departure passed while the car was still plugged in, the next
one lay past the published prices. Core sent that slot index to
Energyplan unbounded, and the worker rejected the request ("invalid EV
identity, energy, target or steps"), so the box fell back to Core DP
until prices arrived or the car was unplugged. The home box did so on
2 Oct, 07:06–07:13.
Core DP already clamps such a deadline to the horizon's last slot, and
the fleet contract check already reads it that way. Move the rule into
LoadpointSpec.deadlineSlot and use it for the DP, the Energyplan
request and the plan check, so both planners aim at the same slot.
Fixes #1497
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.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. |
Two findings from a local Codex review: - With two cars, a departure past the horizon clamped to the last slot competed equally with a car leaving in that slot. With real charger steps, the worker gave one hour of surplus to tomorrow's three-phase car and left today's single-phase car 3 kWh short. A departure past the horizon now gets no deadline when another car leaves inside it. - The plan check reported a shortfall at the horizon's end for a later departure. The reserve plan's alert would then say the car is short at departure, although the plan does not yet cover the departure night. Only a departure inside the horizon is checked, as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.com>
A third local Codex review: a plugged-in car stays active after it reaches its target, so a satisfied departure inside the horizon still removed tomorrow's deadline, and the surplus went to the grid instead of tomorrow's car. Only a car whose target is above its current SoC now takes priority. The SoC bounds sent to the optimizer move into LoadpointSpec.requestSoC so the rule and the request read the same values. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a departure passes while the car is still plugged in, the next departure lies past the published prices. Core sent that slot index to Energyplan without bounding it to the horizon, and the worker rejected the whole request:
The home box planned with Core DP from 07:06 until the car was unplugged at 07:13 on 2 Oct. With prices for the next day published at about 13:00, a car left plugged in all morning would keep Energyplan out for hours.
Change
Core DP already clamped a deadline past the horizon to its last slot ("so the DP still sees it"), and the fleet contract check already read the deadline that way. Only the request to Energyplan sent it unbounded.
LoadpointSpec.deadlineSlot(n)holds the rule: -1 without a target or deadline, otherwise the deadline, but at most the horizon's last slot. Core DP and the Energyplan request both use it; the DP's behaviour is unchanged.ValidatePlanstill reports a shortfall only for a departure inside the horizon. A later departure is planned when its prices arrive, so the reserve plan's "short at departure" alert does not appear for it.main.gocomment now says both planners clamp.Energyplan treats a deadline as a requirement reduced to what is reachable. With grid charging deferred (the departure is past the published prices), a single car now gets the reachable surplus, as with Core DP.
Tests
TestNativeEVDeadlinePastHorizonPlansruns the bundled Rust worker: before the change it failed with the box's exact error; now it plans, charges from both surplus slots and reports no shortfall.TestNativeEVDeadlineInsideHorizonGoesFirst: 64 quarter-hours, one hour of 5 kW surplus, a single-phase car needing 3 kWh by the last slot and a three-phase car needing 18 kWh tomorrow (6–16 A steps). Without the priority rule today's car is 3 kWh short; with it, it gets its 3 kWh.TestEVDeadlinePastHorizonRequestUsesLastSlot,TestEVDeadlineInsideHorizonGoesFirstandTestEVDeadlineSlotcheck the request and the rule without the worker.make verifyclean.Review
A local Codex review found the two-car priority problem and the misleading reserve alert; both are fixed here.
Fixes #1497.
🤖 Generated with Claude Code