Confine device power to operation-mode power bands by Flix6x · Pull Request #2278 · FlexMeasures/flexmeasures

Flix6x · 2026-07-10T15:37:18Z

Description

Adds support for devices whose power is not free to modulate within [0, P_max], but is confined to a set of power bands — e.g. a device that is either off or running at (or above) some minimum power. Fixes #2113.

Following the S2 standard's FRBC OperationMode terminology, the storage flex-model gains an operation-modes field: a list of signed power ranges (positive is consumption, negative is production). The device must operate within one of the declared ranges at every time step:

"operation-modes": [
    {"power-range": ["0 W", "0 W"]},
    {"power-range": ["883.7 W", "883.7 W"]}
]

In the device_scheduler, this adds one binary variable per device per band per time step (exactly one band active; device power bounded by the active band's range), turning the LP into a MILP when the field is used. Without the field, the model is unchanged.

Motivation / validation

When a control layer (e.g. an S2 CEM/RM pair) receives a fractional schedule for an on/off device, it has to round it — typically up — which can overshoot site capacity limits. In a two-house community co-simulation with on/off heaters, a community-level capacity breach could not be resolved because the scheduler kept planning fractional heater power that was implemented as full-on blocks. With this field, the schedule only contains implementable power values; in that same co-simulation the breach was fully resolved (community peak landed exactly on the inflexible-load floor), with no observed solver slowdown (~10s solves, HiGHS, 96 time steps).

Scope

New OperationModeSchema + operation-modes field in the storage flex-model schema (documented via the metadata module, so it shows up in the docs table and OpenAPI specs).
device_power_bands argument on device_scheduler, wired through StorageScheduler._prepare/compute.
Docs: field documented in the storage flex-model table (with S2 reference) + changelog entry.
Tests: flexmeasures/data/models/planning/tests/test_operation_modes.py (on/off band, min-power band, and a no-bands sanity check).

🤖 Generated with Claude Code

New storage flex-model field "operation-modes" (S2 terminology): a list of signed power ranges; the device must operate within one of them at every time step. Adds one binary per device per band per time step to the device scheduler, so devices that cannot modulate below a minimum power (or are strictly on/off) no longer receive fractional schedules that their control layer must round up, overshooting site capacity limits. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Adds the field to the storage flex-model table (via a new OPERATION_MODES MetaData entry, which the schema now also uses for its API docs), including the sign convention, an on/off device example, the MILP note, and a reference to the S2 standard's FRBC OperationMode concept. Also adds a changelog entry. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

read-the-docs-community · 2026-07-10T15:43:02Z

Documentation build overview

📚 flexmeasures | 🛠️ Build #33743526 | 📁 Comparing 0f2dd10 against latest (922ecf6)

🔍 Preview build

54 files changed · + 7 added · ± 47 modified

+ Added

± Modified

Combine the operation-modes power-bands flex-model field with the new group-based intermediate power constraints from PR #2276. Conflicts were co-located additions in the storage flex-model schema, metadata descriptions, docs, and the generated OpenAPI spec; both features kept. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016MLCUiSdXDqDBmg8GbYp1B Signed-off-by: F.N. Claessen <claessen@seita.nl>

Signed-off-by: Felix Claessen <30658763+Flix6x@users.noreply.github.com>

Flix6x · 2026-07-22T09:33:46Z

 * CLI support for adding/editing account attributes [see `PR #2242 <https://www.github.com/FlexMeasures/flexmeasures/pull/2242>`_]
 * Improve chart axis domain for event values not around zero, with a per-sub-chart ``y-axis`` option in ``sensors_to_show`` (default ``zero``, which pads the axis out to include zero) that can be set to ``data`` to fit a sub-chart's y-axis to the values shown, to an explicit ``[min, max]`` domain that the axis will cover at least (expanding to fit data beyond it), or to a strict ``{"min": min, "max": max}`` domain that the axis will never exceed (clamping data beyond it, with a warning when that happens), editable from the graph editor [see `PR #2244 <https://www.github.com/FlexMeasures/flexmeasures/pull/2244>`_]
 * Extended ``GET /api/v3_0/jobs/<uuid>`` with a ``result`` field containing ``unresolved`` and ``resolved`` soft state-of-charge constraint analysis (``soc-minima``/``soc-maxima`` violations or satisfied constraints, keyed by asset ID) for scheduling jobs; both arrays are empty when no SoC constraints were defined [see `PR #2072 <https://www.github.com/FlexMeasures/flexmeasures/pull/2072>`_]
+* New storage flex-model field ``operation-modes`` confines a device's power to one of several power bands, following the S2 standard's operation modes — for example, a device that is either off or running at one fixed power [see `Issue #2113 <https://www.github.com/FlexMeasures/flexmeasures/issues/2113>`_]


Suggested change

* New storage flex-model field ``operation-modes`` confines a device's power to one of several power bands, following the S2 standard's operation modes — for example, a device that is either off or running at one fixed power [see `Issue #2113 <https://www.github.com/FlexMeasures/flexmeasures/issues/2113>`_]

* New storage flex-model field ``operation-modes`` confines a device's power to one of several power bands, following the S2 standard's operation modes — for example, a device that is either off or running at one fixed power [see `PR #2278 <https://www.github.com/FlexMeasures/flexmeasures/pull/2278>`_]

Flix6x · 2026-07-22T09:56:24Z

 )
+OPERATION_MODES = MetaData(
+    description="""Confine the device's power to one of several power ranges at every time step.
+Each operation mode declares a signed power range (positive is consumption, negative is production).


I'd like to switch to key names that are explicit about their sign convention: "consumption-range" and "production-range". They can be used in combination. We can document that the S2 power-range maps to the FM consumption-range, because S2 holds to one sign convention for power, while FM keeps it open to the user.

Replace the single signed `power-range` on an operation mode with explicit `consumption-range` (positive = consumption) and/or `production-range` (positive = production). A mode may use either or both; combining both (each starting at 0) forms one band through zero. Document that the S2 power-range maps to the FM consumption-range (S2 fixes one sign convention; FM leaves it to the user). Also update the changelog reference to PR #2278. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016MLCUiSdXDqDBmg8GbYp1B Signed-off-by: F.N. Claessen <claessen@seita.nl>

Flix6x · 2026-07-22T10:05:51Z

Addressed:

Sign-explicit ranges: replaced the single signed power-range with consumption-range (positive = consumption) and/or production-range (positive = production). A mode may use either or both; combining both (each starting at 0) forms one band through zero [-production_max, +consumption_max]. Documented that the S2 signed power-range maps to the FM consumption-range. Added schema tests for the mapping + validation; OpenAPI regenerated.
Changelog: applied your suggested wording (now references PR Confine device power to operation-mode power bands #2278).

The unit-commitment work stays out of this PR (separate branches). I will reconcile the branches stacked on this one — #2327 (running-cost) and the operation-modes UC route — to the new key names.

Add integration-level tests that exercise StorageScheduler.compute() end-to-end with "operation-modes" set in the flex-model, so that a regression severing the plumbing that reads operation-modes and passes device_power_bands into device_scheduler() would be caught. Previously only LP-level tests (calling device_scheduler() directly) covered this feature, which is why a recent merge could sever the wiring without any test failing. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: F.N. Claessen <claessen@seita.nl>

Flix6x and others added 2 commits July 10, 2026 17:36

Flix6x mentioned this pull request Jul 18, 2026

feat: running cost (S2-aligned rate) per operation mode #2327

Open

Flix6x self-assigned this Jul 22, 2026

Flix6x added the Scheduling label Jul 22, 2026

Merge branch 'main' into feat/2113-operation-mode-power-bands

98ae6c5

Signed-off-by: Felix Claessen <30658763+Flix6x@users.noreply.github.com>

Flix6x commented Jul 22, 2026

View reviewed changes

Flix6x mentioned this pull request Jul 22, 2026

feat: multi-commodity operation modes (per-commodity ranges + no-load flow) #2335

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Confine device power to operation-mode power bands#2278

Confine device power to operation-mode power bands#2278
Flix6x wants to merge 6 commits into
mainfrom
feat/2113-operation-mode-power-bands

Flix6x commented Jul 10, 2026

Uh oh!

read-the-docs-community Bot commented Jul 10, 2026 •

edited

Loading

Uh oh!

Flix6x Jul 22, 2026

Uh oh!

Flix6x Jul 22, 2026

Uh oh!

Flix6x commented Jul 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

	* New storage flex-model field ``operation-modes`` confines a device's power to one of several power bands, following the S2 standard's operation modes — for example, a device that is either off or running at one fixed power [see `Issue #2113 <https://www.github.com/FlexMeasures/flexmeasures/issues/2113>`_]
	* New storage flex-model field ``operation-modes`` confines a device's power to one of several power bands, following the S2 standard's operation modes — for example, a device that is either off or running at one fixed power [see `PR #2278 <https://www.github.com/FlexMeasures/flexmeasures/pull/2278>`_]

Uh oh!

Conversation

Flix6x commented Jul 10, 2026

Description

Motivation / validation

Scope

Uh oh!

read-the-docs-community Bot commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Documentation build overview

Uh oh!

Flix6x Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

Flix6x Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

Flix6x commented Jul 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

read-the-docs-community Bot commented Jul 10, 2026 •

edited

Loading