Repository navigation
fix(web): follow the car's planned charge on an EV step - #1542
Conversation
Expected charge used the home battery's SoC on the same slot, so a car at 76% read as 24% after the next step and 10% at the end of the plan. Signed-off-by: Cursor Agent <cursoragent@cursor.com> Co-authored-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. |
![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: 4950ad2900
ℹ️ 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".
| const where = car ? " in the car" : (evStep ? " in the home battery" : ""); | ||
| const nextFrac = car ? car.nextSoc : (next ? next.soc : null); |
There was a problem hiding this comment.
When a batteryless site schedules two cars in the same step, carChargeForecast deliberately returns null because it cannot choose one car, but every Go Action still serializes soc: 0; consequently batteryIsPresent returns true and this branch renders “0% in the home battery” even though no home battery exists. Handle the ambiguous multi-car case without falling back to next.soc, or determine battery presence independently of the always-present aggregate soc field.
Useful? React with 👍 / 👎.
2 participants
Problem and result
The car card showed 76% and a plan from 76% to 80%. Opening the full plan still said Expected charge 24% after next step and 10% at the end of the plan.
Those percents are the home battery on the same slot (
soc, with start SoC 17% in the header). The next step is Charge EV at 11.0 kW, so Expected charge now uses that car's planned SoC (loadpoint_soc/loadpoint_soc_by_id): about 79% in the car after next step and 80% in the car at the end of the plan for the reported 2.8 kWh then 1.1 kWh into an 86.5 kWh pack.The overview card uses the same sentence, so it no longer shows the home battery as the car's charge either. A home-battery step is unchanged. Start SoC in the plan header stays the home battery.
If the next step charges more than one car, one percent is not invented. If an EV step has no car SoC, the home-battery figure is labeled as the home battery.
Scope and safety
Web briefing only (
web/plan-brief.js). No planner, dispatch, or driver change. Open PR #1177 touchesweb/plan.jsfor hidden-tab polling; this change does not.Verification
npm test— 707 passed.The briefing was rendered with the app CSS at phone width and desktop width, using a plan shaped like the screenshots (home battery 24% then 10%, car 79.2% then 80.4%).
Phone width: expected charge follows the car
Desktop: expected charge column
Not checked on a live site. A person still needs to look at the rendered plan on a real box.
Checklist
To show artifacts inline, enable in settings.