frequenz.api.dispatch.v1.dispatch_pb2 ¤
Generated protocol buffer code.
Attributes¤
frequenz.api.dispatch.v1.dispatch_pb2.SORT_FIELD_CREATE_TIME
module-attribute
¤
CREATE_TIME: Sort by creation time of the dispatch.
frequenz.api.dispatch.v1.dispatch_pb2.SORT_FIELD_LAST_UPDATE_TIME
module-attribute
¤
UPDATE_TIME: Sort by last update time of the dispatch.
frequenz.api.dispatch.v1.dispatch_pb2.SORT_FIELD_START_TIME
module-attribute
¤
START_TIME: Sort by start time of the dispatch.
frequenz.api.dispatch.v1.dispatch_pb2.SORT_FIELD_UNSPECIFIED
module-attribute
¤
UNSPECIFIED: Default, unspecified sort field.
frequenz.api.dispatch.v1.dispatch_pb2.SORT_ORDER_ASCENDING
module-attribute
¤
ASCENDING: Results are returned in ascending order.
frequenz.api.dispatch.v1.dispatch_pb2.SORT_ORDER_DESCENDING
module-attribute
¤
DESCENDING: Results are returned in descending order.
frequenz.api.dispatch.v1.dispatch_pb2.SORT_ORDER_UNSPECIFIED
module-attribute
¤
UNSPECIFIED: Default, unspecified sort order.
Classes¤
frequenz.api.dispatch.v1.dispatch_pb2.CreateMicrogridDispatchRequest ¤
frequenz.api.dispatch.v1.dispatch_pb2.CreateMicrogridDispatchResponse ¤
frequenz.api.dispatch.v1.dispatch_pb2.DeleteMicrogridDispatchRequest ¤
frequenz.api.dispatch.v1.dispatch_pb2.DeleteMicrogridDispatchResponse ¤
frequenz.api.dispatch.v1.dispatch_pb2.Dispatch ¤
frequenz.api.dispatch.v1.dispatch_pb2.DispatchData ¤
Bases: Message
Represents a dispatches data, including its type, start time, duration, and target microgrid components.
This DispatchData message describes a single dispatch instance. If a dispatch is set to recur,
each occurrence is defined by DispatchData in combination with RecurrenceRule.
Indefinite Durations
This API allows dispatches to have an indefinite duration if the duration field
is not set. Indefinite means:
- There is no predefined end time known at dispatch creation.
- The dispatch could, in theory, run indefinitely if no external conditions stop it.
- External logic or changing conditions may end the dispatch at any time. For example,
once a certain operational goal is met (like reaching a particular state-of-charge),
the dispatch may end, or it may be allowed to continue if conditions warrant it.
- Indefinite durations apply to each occurrence individually—every instance of a recurring
dispatch can also be indefinite.
For instance, a dispatch might aim to keep a battery’s SoC stable. If conditions never change, it could theoretically run forever. Conversely, another indefinite dispatch might end as soon as a particular SoC goal is reached.
Recurring Indefinite Dispatches
How recurring indefinite dispatches are managed is implementation-dependent. A key consideration is how to handle overlapping occurrences. For example, if a new dispatch is scheduled to start while a previous one is still running, the system needs a strategy to manage this.
Commonly used approaches include:
1. Start a new instance: Each dispatch occurrence creates a new, independent
instance that runs in parallel with any existing ones. This can lead to
multiple dispatches "stacking up" if not managed carefully.
2. Overwrite existing instances: A new dispatch can replace an existing one
based on certain criteria, such as having the same type or target
components. This prevents multiple dispatches from running for the same
purpose simultaneously.
The chosen strategy is critical for preventing resource contention and ensuring predictable behavior, especially with indefinite, recurring dispatches.
Timestamps
Timestamps are in UTC. It is the responsibility of the receiver to translate UTC to respective local timezone.
Attributes¤
duration
instance-attribute
¤
Duration in seconds The duration of the dispatch in seconds. If the duration is not set, the dispatch will be considered to have an indefinite duration.
A duration of 0 seconds is also valid, indicating a dispatch that immediately starts and ends, e.g. switching a component on and off.
Indefinite durations do not guarantee an eventual end; they continue until external logic changes it.
is_active
instance-attribute
¤
The "active" status An active dispatch is eligible for processing, either immediately or at a scheduled time in the future, including recurring dispatches. If a dispatch is set to inactive, it won't be processed even if it matches all other conditions, allowing for temporary disabling of dispatches without deletion.
is_dry_run
instance-attribute
¤
The "dry run" status A dry run dispatch is executed for logging and monitoring purposes without affecting the microgrid components. This is useful, for example, in scenarios where a user may want to test dispatch behavior without actually affecting any component states. Notably, a dispatch can be both "dry run" and "active," allowing for the system to generate logs and observe behavior without making actual changes.
payload
property
¤
The dispatch payload.
Note!!! The payload field allows for flexible JSON data to be associated with this dispatch. The payload must adhere to the following constraints: - Maximum JSON nesting depth: 5 levels. - The data should not contain executable code or scripts. - Ensure all data is properly sanitized and encoded. - The total size of the payload should not exceed 50 KB.
The payload is expected to follow a specific format that the downstream applications consuming the dispatch API are responsible for understanding and processing.
Example JSON payload: { "settings": { "power_max": 10, // Maximum power level for the dispatch (in kW) "soc_min": 20, // Minimum state of charge for battery storage (in %) "soc_max": 80 // Maximum state of charge for battery storage (in %) } }
In this example, a microgrid could use this payload to set operational parameters such as the maximum power output of a solar PV array or the charge/discharge limits of a battery storage system. This flexibility allows the microgrid to dynamically adjust its behavior based on the current needs or conditions, such as optimizing battery usage or limiting PV output during low demand periods.
start_time
property
¤
The dispatch start time in UTC. For reoccuring dispatches this is when the first time execution occurs. When creating a dispatch, ensure that the starting timestamp is set to the current time or any future time. Timestamps earlier than the current time are not allowed.
type
instance-attribute
¤
The dispatch type. Contains user-defined information about what "type" of dispatch this is. Downstream applications that consume the dispatch API are responsible for understanding and processing this field.
frequenz.api.dispatch.v1.dispatch_pb2.DispatchFilter ¤
Bases: Message
Parameters for filtering the dispatch list
Attributes¤
dispatch_ids
property
¤
Optional filter by dispatch IDs. If this field is not set, dispatches with any ID will be included. Multiple IDs are combined with an OR relationship.
end_time_interval
property
¤
Optional filter by end time Filter dispatches based on their explicit end time.
filter
property
¤
Filter by recurrence details Examples: - To retrieve only recurring dispatches with a specific frequency: filter { recurrence { filter { freq: FREQUENCY_DAILY } } } - To retrieve recurring dispatches with a specific frequency and interval: filter { recurrence { filter { freq: FREQUENCY_HOURLY, interval: 2 } } } - To retrieve recurring dispatches that end after a specific criteria: filter { recurrence { filter { end_criteria: { count: 10 } } } } - To retrieve recurring dispatches at specific minutes of the hour: filter { recurrence { filter { byminutes: [0, 15, 30, 45] } } } - To retrieve recurring dispatches at specific hours of the day: filter { recurrence { filter { byhours: [8, 12, 16] } } } - To retrieve recurring dispatches on specific days of the week: filter { recurrence { filter { byweekdays: [WEEKDAY_MONDAY, WEEKDAY_WEDNESDAY] } } } - To retrieve recurring dispatches on specific days of the month: filter { recurrence { filter { bymonthdays: [1, 15, 30, -1] } } } - To retrieve recurring dispatches in specific months of the year: filter { recurrence { filter { bymonths: [1, 6, 12] } } }
is_active
instance-attribute
¤
Optional filter by active status. If this field is not set, dispatches of any active status will be included.
is_dry_run
instance-attribute
¤
Optional filter by dry run status. If this field is not set, dispatches of any dry run status will be included.
is_recurring
instance-attribute
¤
Filter by recurring status
True: Only recurring dispatches will be returned.
False: Only non-recurring dispatches will be returned.
Examples:
- To retrieve only recurring dispatches:
filter { recurrence { is_recurring: true } }
- To retrieve only non-recurring dispatches:
filter { recurrence { is_recurring: false } }
- To retrieve all dispatches:
filter { recurrence {} }
For advanced recurrence filtering, use the filter field.
queries
property
¤
Optional free-text search filter.
This filter is applied to the dispatch id and type fields.
The queries filter combines multiple queries with an OR relationship.
ID tokens are preceded by a # so we can tell if an id is intended or a type.
- input of [
#4] will match only the record with id of4 - input of [
bar] will matchbarandfoobar - input of [
#4,#24,bar,foo] will match ids of4and24and typesfoobarfoobarfoolish bartender
start_time_interval
property
¤
Optional filter by start time. If no interval is provided, all dispatches will be returned.
targets
property
¤
Optional filter by component ID or category.
Classes¤
RecurrenceFilter ¤
Bases: Message
Recurrence filters
The fields are left commented out for now as the exact definition and requirements for recurrence filtering are still being finalized. The frequency specifier of this recurring dispatch optional RecurrenceRule.Frequency freq = 1;
frequenz.api.dispatch.v1.dispatch_pb2.DispatchMetadata ¤
Bases: Message
Represents the metadata of a dispatch
Attributes¤
end_time
property
¤
UTC Timestamp when the dispatch will stop working.
Will be calculated internally based on the given: start_time,
duration and RecurrenceRule settings. If the duration is not set (indefinite duration),
there may be no calculable end_time. This means the dispatch does not have a
predetermined stopping point and might run indefinitely. External logic, changes in
conditions, or achieving certain operational goals may lead to its termination. If no
such terminating condition occurs, it may effectively continue "forever."
None if dispatch duration time is unset and this value can't be calculated.
frequenz.api.dispatch.v1.dispatch_pb2.GetMicrogridDispatchRequest ¤
frequenz.api.dispatch.v1.dispatch_pb2.GetMicrogridDispatchResponse ¤
frequenz.api.dispatch.v1.dispatch_pb2.ListMicrogridDispatchesRequest ¤
Bases: Message
Message for listing dispatches for a given microgrid.
Allows retrieval of dispatches for a specified microgrid with optional filtering and sorting. Sorting can be specified by setting 'sort_field' and 'sort_order'. If no sorting is specified, the results will be returned by their create time in a descending order.
Attributes¤
pagination_params
property
¤
Pagination Parameters
page_size: Amount of items to return per page. Should only be provided in the first request.
page_token: Cursor to specify which page to return. Should not be set in the first request.
Should be populated in subsequent requests by the next_page_token found in
the pagination_info in the response.
The tokens stays valid indefinitely.
frequenz.api.dispatch.v1.dispatch_pb2.ListMicrogridDispatchesResponse ¤
frequenz.api.dispatch.v1.dispatch_pb2.RecurrenceRule ¤
Bases: Message
Ruleset governing when and how a dispatch should re-occur.
Timezone Note: Timestamps are in UTC. It is the responsibility of each microgrid to translate UTC to its local timezone.
This definition tries to adhere closely to the iCalendar specification (RFC5545), particularly for recurrence rules. For advanced use-cases or further clarifications, refer to RFC5545.
Examples¤
Every 6 months¤
Weekends only¤
message RecurrenceRule {
Frequency freq = FREQUENCY_WEEKLY;
repeated Weekday byweekdays = [WEEKDAY_SATURDAY, WEEKDAY_SUNDAY];
}
At midnight¤
Every day at midnight.
Nightly¤
Assuming "night" means from 8 PM to 6 AM.
message RecurrenceRule {
Frequency freq = FREQUENCY_DAILY;
repeated uint32 byhours = [20, 21, 22, 23, 0, 1, 2, 3, 4, 5];
}
Attributes¤
byhours
property
¤
On which hour(s) of the day does the event occur
byminutes
property
¤
On which minute(s) of the hour does the event occur
bymonthdays
property
¤
On which day(s) of the month does the event occur. Valid values are 1 to 31 or -31 to -1.
For example, -10 represents the tenth to the last day of the month. The bymonthdays rule part MUST NOT be specified when the FREQ rule part is set to WEEKLY.
bymonths
property
¤
On which month(s) of the year does the event occur
byweekdays
property
¤
On which day(s) of the week does the event occur
end_criteria
property
¤
When this dispatch should end. A dispatch can either recur a fixed number of times, or until a given timestamp. If this field is not set, the dispatch will recur indefinitely.
interval
instance-attribute
¤
How often this dispatch should recur, based on the frequency Example: - Every 2 hours: freq = FREQUENCY_HOURLY interval = 2 Valid values typically range between 1 and 10_000, depending on the implementation.
Classes¤
EndCriteria ¤
Bases: Message
Controls when a recurring dispatch should end
instance-attribute
¤The number of times this dispatch should recur. If this field is set, the dispatch will recur the given number of times. Valid values are 1 to 4096.
property
¤The end time of this dispatch in UTC. If this field is set, the last recurrence event will start before this timestamp. Note that the duration of the event is not considered in this value, so the dispatch may end after the timestamp.
Frequency ¤
Bases: _Frequency
Enum representing the frequency of the recurrence
Weekday ¤
Bases: _Weekday
Enum representing the day of the week
frequenz.api.dispatch.v1.dispatch_pb2.SortField ¤
frequenz.api.dispatch.v1.dispatch_pb2.SortOptions ¤
Bases: Message
Message defining parameters for sorting list requests.
Example Usage: To retrieve dispatches sorted by creation time in descending order: sort_options: { field: CREATE_TIME, order: DESCENDING }
frequenz.api.dispatch.v1.dispatch_pb2.SortOrder ¤
frequenz.api.dispatch.v1.dispatch_pb2.StreamMicrogridDispatchesRequest ¤
Bases: Message
Subscribe to a stream of microgrid dispatch requests. This method provides real-time updates on newly or updated dispatch requests for edge-based realtime decision making.
Source code in frequenz/api/dispatch/v1/dispatch_pb2.py
frequenz.api.dispatch.v1.dispatch_pb2.StreamMicrogridDispatchesResponse ¤
Bases: Message
Response to a subscription request for a stream of microgrid dispatches. Real-time information on dispatches affecting a certain microgrid are pushed through this response.
Source code in frequenz/api/dispatch/v1/dispatch_pb2.py
frequenz.api.dispatch.v1.dispatch_pb2.TargetComponents ¤
Bases: Message
Parameter for controlling which components a dispatch applies to either a set of component IDs, or a set of component categories (with optional type). Examples: - To dispatch to a set of component IDs: components { component_ids { ids: [1, 2, 3] } } - To dispatch to a set of component categories: components { component_categories { categories: [ {category: COMPONENT_CATEGORY_BATTERY, type: BATTERY_TYPE_LI_ION}, {cateogry: COMPONENT_CRYPTO_MINER} ] } }
Attributes¤
component_categories
property
¤
Deprecated: Component categories
Use CategoryTypeSet instead
In future versions, this field will be removed.
component_categories_types
property
¤
Component categories with optional types
Classes¤
CategoryAndType ¤
Bases: Message
A tuple of a required category and an optional type If a type is specified, it must be a valid type for the given category and only components of that type will be targeted.
instance-attribute
¤The type of battery Only applicable if the category is COMPONENT_CATEGORY_BATTERY
instance-attribute
¤The type of EV charger Only applicable if the category is COMPONENT_CATEGORY_EV_CHARGER
instance-attribute
¤The type of solar array Only applicable if the category is COMPONENT_CATEGORY_INVERTER
CategorySet ¤
CategoryTypeSet ¤
frequenz.api.dispatch.v1.dispatch_pb2.UpdateMicrogridDispatchRequest ¤
Bases: Message
Message to update the dispatch with the given ID, with the given attributes
Attributes¤
Classes¤
DispatchUpdate ¤
Bases: Message
Message containing the updated dispatch attributes
property
¤The start time in UTC. When updating a dispatch, ensure that the starting timestamp is set to the current time or any future time. Timestamps earlier than the current time are not allowed.
Bases: Message
Message containing the updated recurrence rule attributes
property
¤On which hour(s) of the day does the event occur
property
¤On which minute(s) of the hour does the event occur
property
¤On which day(s) of the month does the event occur. Valid values are 1 to 31 or -31 to -1.
For example, -10 represents the tenth to the last day of the month. The bymonthdays rule part MUST NOT be specified when the FREQ rule part is set to WEEKLY.
property
¤On which month(s) of the year does the event occur
property
¤On which day(s) of the week does the event occur
instance-attribute
¤How often this dispatch should recur, based on the frequency