Skip to content

Commitments can be scoped to specific sensors, binding their aggregate flow#2295

Open
Flix6x wants to merge 1 commit into
mainfrom
feat/sensor-scoped-commitments
Open

Commitments can be scoped to specific sensors, binding their aggregate flow#2295
Flix6x wants to merge 1 commit into
mainfrom
feat/sensor-scoped-commitments

Conversation

@Flix6x

@Flix6x Flix6x commented Jul 11, 2026

Copy link
Copy Markdown
Member

Description

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 (using the existing device_group machinery of FlowCommitment).

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

…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
@read-the-docs-community

Copy link
Copy Markdown

Documentation build overview

📚 flexmeasures | 🛠️ Build #33545366 | 📁 Comparing 69f7f56 against latest (60cfda8)

  🔍 Preview build  

1 file changed
± api/v3_0.html

@Flix6x Flix6x left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only wish to clear up some documentation. And one clarification request.

The test is correct, but would be slightly stronger if the statement about 0 consumption being preferred without the extra commitment would be proven.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explain the term "band" in the docstring.

@Flix6x

Flix6x commented Jul 12, 2026

Copy link
Copy Markdown
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant