fix: StorageScheduler falls back to 0 correctly if no starting SoC can be found - #2431
Merged
Conversation
…n be found Signed-off-by: Nicolas Höning <nicolas@seita.nl>
Documentation build overview
3 files changed± changelog.html± _autosummary/flexmeasures.data.models.planning.storage.html± api/v3_0.html |
Flix6x
requested changes
Aug 20, 2026
Member
Author
|
I ran QA/Release workflow on this branch successfully: https://github.com/FlexMeasures/flexmeasures/actions/runs/32376386062 |
Flix6x
approved these changes
Aug 20, 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
3 participants
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.
Desription
Closes #2430: Errors when no starting SoC is given to StorageScheduler
documentation/changelog.rstNote: If a
state-of-chargesensor is given, but it has no recent data, we still fail with the clear “No recent state-of-charge value” error.Analysis
Single-sensor scheduling calls ensure_soc_at_start(), which resolves a configured SoC source, tries the legacy asset value, and then defaults to 0 when soc-min or soc-max makes the entry a storage model. Asset/multi-device scheduling skips that routine entirely. The right correction is therefore to restore the same resolution/default policy per stock group, not to special-case soft minima.
PR #1946 deleted that call while retaining it for the sensor/dict branch. This affects your one-sensor case because an asset schedule with an explicit sensor entry remains a list; “multi-device mode” is really “asset/list mode,” not “more than one sensor.”
PR #2322 on July 15 partially repaired the regression by resolving soc-at-start from a configured state-of-charge source in the per-stock loop. It did not restore the zero fallback (or initially the legacy attribute fallback), which is why your no-source case still reaches _prepare() with None. In release terms, v0.33.1 still had the old behavior; the removal first appears in v0.33.2.dev0 and the v1.0 release line.
Look & Feel
Schedules with no SoC at start information should succeed.
How to test
Two tests were added to this PR without such information, but they still schedule.