FlexMeasures / flexmeasures / 29442981886

82%

push

github

Fix: couple stock constraints for multi-device batteries whose SoC comes from a sensor (#2322)

* Fix: couple stock constraints for multi-device batteries whose SoC comes from a sensor

In multi-device (list) flex-model mode, soc-at-start is not resolved during
deserialization (unlike single-sensor mode's ensure_soc_at_start()). A battery
whose only SoC input is a state-of-charge sensor (no explicit soc-at-start) - the
production shape of a battery under an apartment - therefore had soc_at_start=None,
so the scheduler applied no stock constraints and the device could discharge far
more energy than its store held.

Resolve a stock's soc-at-start from its (deserialized) state-of-charge sensor or
time series in _prepare()'s per-stock loop, on the stock-owning entry only, so
shared-stock device entries are unaffected. Resolution is defensive: if no recent
SoC value exists, the stock simply keeps no stock constraints (as before) instead
of failing the schedule.

Signed-off-by: F.N. Claessen <felix@seita.nl>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LQFkeGxDwErydUV5ZmHmki

* Clean up: changelog reference, percent-based SoC conversion, and logging

- The fixed behavior only regressed during v1 development (PR #1946
  dropped the per-entry ensure_soc_at_start call that PR #2026 had added
  to the multi-device branch; v0.33.1 still resolved soc-at-start there),
  so reference this PR from the multiple-feeders feature entry instead of
  adding a Bugfixes entry.
- Pass the stock entry's soc-max to the percent-conversion helper in the
  hyphenated pre-deserialization shape it expects; previously a
  state-of-charge sensor recording percentages could not be converted
  using the entry's own soc-max (new regression test).
- Warn when a stock's starting state of charge cannot be resolved, since
  the stock is then scheduled without stock constraints.
- Reflow comments and docstrings at natural clause bou... (continued)

11 of 12 new or added lines in 1 file covered. (91.67%)

14682 of 18007 relevant lines covered (81.53%)

0.82 hits per line