Skip to content

provision_duration_pb2

frequenz.api.common.v1alpha8.grid.provision_duration_pb2 ¤

Generated protocol buffer code.

Attributes¤

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.PROVISION_DURATION_120_MIN module-attribute ¤

120_MIN: 2-hour blocks, less commonly used but possible in some markets.

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.PROVISION_DURATION_1440_MIN module-attribute ¤

1440_MIN: Full-day delivery period (e.g., capacity or commitment-based products).

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.PROVISION_DURATION_15_MIN module-attribute ¤

15_MIN: 15-minute delivery window (common in balancing energy markets and secondary regulation).

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.PROVISION_DURATION_240_MIN module-attribute ¤

240_MIN: 4-hour block (e.g., German and EU primary regulation tenders).

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.PROVISION_DURATION_30_MIN module-attribute ¤

30_MIN: 30-minute delivery block (used in some scheduling or redispatch services).

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.PROVISION_DURATION_5_MIN module-attribute ¤

5_MIN: 5-minute delivery window (planned for future reconstruction of ancillary service markets).

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.PROVISION_DURATION_60_MIN module-attribute ¤

60_MIN: Hourly provision period (e.g., for day-ahead markets or system dispatch).

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.PROVISION_DURATION_UNSPECIFIED module-attribute ¤

UNSPECIFIED: Default value — must not be used in production messages.

Classes¤

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.ProvisionDuration ¤

Bases: _ProvisionDuration

Defines standard provision durations for flexibility services.

A provision duration is the duration of a single provision period. In many markets, this corresponds to the delivery block or service interval for which a flexibility service is contracted, committed, or delivered.

Provision durations are modeled as an enum because only a fixed set of provision periods is supported by the relevant services, markets, and operator integrations. This makes invalid durations unrepresentable and keeps validation behavior consistent across APIs.

Duration vs. resolution

This field defines the duration of a single provision period. In market terms, this is often the delivery block or product block for the flexibility service. It does not define the cadence or resolution of telemetry samples, control instructions, or setpoint updates.

frequenz.api.common.v1alpha8.grid.provision_duration_pb2.ProvisionPeriod ¤

Bases: Message

Represents the time period during which the flexibility market contract is delivered.

This defines the contractual length of a provision period. Valid start times are determined by the combination of duration, flexibility service, delivery area, and market-specific rules

Attributes¤
duration instance-attribute ¤

The length of the provision period.

Methods:¤
start_time() ¤

Start UTC timestamp representing the beginning of the provision period.

This timestamp is inclusive. The end of the provision period is derived from start_time and duration.

Start Time Constraints

The start time must align with the provision duration and the market rules for the selected FlexServiceType and delivery area.

Unless stricter market-specific rules apply, the following default alignment is used:

  • 15-minute durations must start at :00, :15, :30, or :45.
  • 30-minute durations must start at :00 or :30.
  • 60-minute durations must start at :00 past the hour.
  • 120-minute durations must start on an even UTC hour (00:00, 02:00, 04:00, ...).
  • 240-minute durations must start on a UTC hour divisible by 4 (00:00, 04:00, 08:00, 12:00, ...).
  • 1440-minute durations must start at the daily boundary defined by the relevant market rules for the selected delivery area. If no market-specific rule applies, this defaults to 00:00 UTC.

Market-specific rules may further restrict valid start times. For example, a 4-hour product may only support predefined auction blocks, and a full-day product may follow the delivery-day definition of the relevant market.