Repository navigation
fix(control): stop charging at the configured soc_max in every mode - #1867
Merged
Merged
Conversation
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. |
This was referenced Oct 27, 2026
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
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.
With
batteries.<driver>.soc_max: 0.9and a fresh 90% reading, EMS could still send a 10 kW charge order. The configured limit reached the planner, but Core's charge stop only checked for 100%. A battery could therefore refuse charge while FTW kept requesting it.EMS now stops charging at each battery's
soc_max, falling back to the planner's limit and then 100% when neither is set. The same stop covers all control modes, manual holds, self-tuning, quiet ticks and dispatch holdoff. It runs after the final fuse adjustment. A battery at its charge ceiling can still discharge or help relieve an import overage.The existing one percentage point restart gap follows the chosen ceiling: a 90% stop resumes at 89%. Config reload updates the limit on the next control tick, and command feedback reports that same restart level.
Tests
TestConfiguredSoCMaxStopsDispatchfailed in bothchargeandplanner_arbitrage: each sent 10,000 W at the configured 90% ceiling, with no solar and 1,000 W of grid import.GOCACHE=/private/tmp/ftw-goran-go-cache GOFLAGS=-p=2 make verify: passed (Go tests, native solver checks, protocol checks, vet and build). The Docker-context check skipped because no Docker daemon is running.Base and scope
Stacked on #1789 (
fix/fuse-one-function, c60da23), which already changes these control paths and carries the per-battery SoC floor. The diff against that branch contains only this charge-ceiling fix and its tests. Retarget tomasterafter #1789 lands.The separate report of an Idle plan beside a charge order still needs logs from the event. This PR does not claim to explain it. No hardware test or deployment has been performed.