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

[Flix6x]

Problem

When scheduling a subtree with multiple storage devices (multi-device / list flex-model mode), a battery whose starting state of charge is provided only by a state-of-charge sensor (or time series) — with no explicit soc-at-start — was scheduled without stock constraints. Its soc_at_start stayed None, so the solver never coupled the device's energy flow to its stored energy, and it could discharge far more energy than its store held.

This is the production shape of a battery under an apartment: the child asset's DB flex-model references the battery's power sensor via a nested output reference and its SoC via a state-of-charge sensor, and provides soc-min/soc-max but not soc-at-start.

Root cause: in single-sensor mode, ensure_soc_at_start() resolves soc-at-start from the state-of-charge field during deserialization, but the multi-device (list) branch of _deserialize_flex_model() never does. The per-stock assignment in _prepare() then reads stock_model.get("soc_at_start") and gets None, so add_storage_constraints is skipped.

Fix

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 and cannot be mistaken for stock owners. In line with single-sensor mode's ensure_soc_at_start() (#2026), a state of charge that is given but cannot be resolved fails the schedule with a ValueError, rather than silently scheduling the device without stock constraints.

Test

Adds test_multi_device_battery_couples_stock_from_soc_sensor: a battery in a multi-device flex-model, whose only SoC input is a state-of-charge sensor holding a small 0.05 kWh reading, with charging forbidden. It must not discharge more than the ~0.05 kWh it holds. Before the fix it discharged the full power capacity every step (10 kWh over the window); after the fix it respects the stored energy. The existing #2321 alignment / inventory / shared-stock tests continue to pass.

Cleanup (follow-up commits)

• This turned out to be a regression from v1 development: Feat/dynamic soc at start #2026 added a per-entry ensure_soc_at_start call to the multi-device deserialization branch, which Add multi‑commodity support to device scheduler #1946 dropped (v0.33.1 still resolved soc-at-start there). The changelog entry is therefore an appended reference on the multiple-feeders feature entry, rather than a Bugfixes entry.
• Percent-based state-of-charge sensors are now converted using the entry's own soc-max (the percent-conversion helper expects the pre-deserialization flex-model shape), with a regression test.
• A given but unresolvable state of charge fails the schedule (see above), with a regression test.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LQFkeGxDwErydUV5ZmHmki

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #33604860 | 📁 Comparing 5d688ab against latest (97a5ef1)

  🔍 Preview build  

4 files changed

± changelog.html
± genindex.html
± _autosummary/flexmeasures.data.models.planning.storage.html
± api/v3_0.html