Commitments can be scoped to specific sensors, binding their aggregate flow#2295
Open
Flix6x wants to merge 1 commit into
Open
Commitments can be scoped to specific sensors, binding their aggregate flow#2295Flix6x wants to merge 1 commit into
Flix6x wants to merge 1 commit into
Conversation
…gregate flow A flex-context commitment gains an optional 'sensors' field: instead of binding each device of the matching commodity separately, the commitment binds the aggregate flow of the devices whose power sensors are listed, as one grouped commitment (device_group machinery). Useful to commit a band on a subset of devices, e.g. an aFRR upward-regulation band on a site's e-heaters (aggregate consumption >= band, deviation penalized). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016MLCUiSdXDqDBmg8GbYp1B
Documentation build overview
|
Flix6x
commented
Jul 12, 2026
| commitment_commodity = commitment_spec.get("commodity", "electricity") | ||
|
|
||
| # A commitment scoped to specific sensors binds the *aggregate* flow | ||
| # of those devices as one commitment, rather than each device separately. |
Member
Author
There was a problem hiding this comment.
Is the regular commitment not aggregating over all devices (of one grid-connected commodity), rather than applied to each device individually?
| """ | ||
| heater_type = get_or_create_model(GenericAssetType, name="e-heater") | ||
| site = GenericAsset( | ||
| name="Band site (scoped commitment test)", generic_asset_type=heater_type |
Member
Author
There was a problem hiding this comment.
Explain the term "band" in the docstring.
Member
Author
|
I think this would also close #2179, as this essentially adds support for an activation price per device, if you model the commitment with a zero baseline, a positive upwards deviation price and a negative downward deviation price. But if that is the case, then I suggest an additional test (making sure that the problem remains convex) and extending the documentation accordingly. |
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.
Description
A flex-context commitment gains an optional
sensorsfield: instead of binding each device of the matching commodity separately, the commitment binds the aggregate flow of the devices whose power sensors are listed, as one grouped commitment (using the existingdevice_groupmachinery ofFlowCommitment).Example — reserve an upward-regulation band on a site's e-heaters (their combined consumption must stay at/above the band, with downward deviation penalized):
{ "commitments": [ { "name": "reserved band", "sensors": [123, 124], "baseline": "10 MW", "down-price": "-10000 EUR/MWh" } ] }If none of the listed sensors appear in the flex-model, a warning is logged and the commitment binds nothing (rather than failing the whole schedule).
Look & Feel
New unit test
test_sensor_scoped_commitment_binds_aggregate_of_selected_devices: two 8 MW heaters that would otherwise stay off (they only cost money) are held at a combined 10 MW — a level neither device could carry alone — while the rest of the planning problem is unaffected.How to test
pytest flexmeasures/data/models/planning/tests/test_commitments.py -k scoped🤖 Generated with Claude Code
https://claude.ai/code/session_016MLCUiSdXDqDBmg8GbYp1B