Dispatch Event Processing

Dispatch events could come from a variety of sources depending on the program. For example, these could be triggered by a program operator due to grid stress or emergency, or simply as a test to validate performance. They could also be created by Leap as a way to validate performance for capacity payments. Or it could be a market award given as the result of clearing in a wholesale energy marketplace.

Regardless of the source, it is important to respond in a timely and consistent manner to ensure good performance and maximize revenue. The sections below provide guidance on how to process these incoming event notifications.

Market & Program-Agnostic Integrations

It is recommended to keep your dispatch integration and event processing generic across markets and programs to enable expansion to new programs and revenue streams without requiring any integration updates or code changes.

For this reason, the dispatch information and logic provided in this guide is intended to be applicable for all markets and programs. Where there are significant and relevant differences in behavior between markets/programs, those are noted accordingly.

Example Market Group Event Notification

{
  "integration_test_notification": false,
  "communication_test": false,
  "group_dispatches": [
    {
      "market_group_id": "11aa7aae-24e5-455f-91e9-e0f5f145f2ae",
      "meter_ids": [
        "abae2779-e392-4f00-b0cf-32e716204f78",
        "bbae2779-e392-4f00-b0cf-32e716204f78"
      ],
      "timeslots": [
        {
          "market_group_event_id": "114751e8-c0df-4d69-8a4f-9e7cebef1f84",
          "start_time": "2023-06-04T23:00:00Z",
          "end_time": "2023-06-05T00:00:00Z",
          "cancelled": false,
          "performance_compensation_cap": "up-to-site-load",
          "priority": 2,
          "is_voluntary": false,
          "dispatch_event_types": [
            "day-ahead"
          ],
          "programs": [
            "CCA"
          ],
          "energy_kw": 8.500,
          "nomination_kw": 11.000
        }
      ]
    }
  ]
}

Event Processing

Key Event Fields

To schedule events, most implementations only require parsing the following fields. With this information, you can schedule the curtailment or export of energy from customer devices at the appropriate time and for the expected length of time.

1. market_group_event_id (or meter_event_id) - To understand if this is for a new or existing event
2. meter_ids (or market_group_id) - To lookup which customer devices need to have their schedule updated
3. start_time & end_time - To understand the start time and duration of the event

Overlapping Events & Event Consolidation

It is possible to receive overlapping dispatches for certain timeslots if events are triggered for different reasons or for multiple stackable programs so ensure that your implementation can process and combine these overlapping time periods appropriately.

Updates to Existing Events

If an event notification comes in with an already received meter_event_id or market_group_event_id, see guidance below to see what, if anything, has changed for the event:

1. Cancelled Event - cancelled would be set to "true"
2. Modified Event - Modifications to events can happen occasionally and your integration needs to be able to handle and process these event updates. Any of the fields that changed from the original event notification should be updated.

Event Power & Energy

The energy_kw field provides the power in kW to be curtailed/exported for the duration of the event (if your technology can directly control this).

Example Code Recipes

The recipes below walk through example dispatch event processing code:

• Process dispatch events from meter-level webhook
• Process dispatch events after polling meter-level API

Dispatch Strategies & Additional Event Fields

Depending on your technology and customer experience requirements, you may choose to implement one or combine multiple of these strategies below.

Strategy A: Maximize revenue by responding to all events

When no event duration constraints exist, you can simply use the above mentioned key event fields to respond to all events to maximize revenue. This is the recommended approach whenever possible.

Strategy B: Prioritize events when max event duration constraints exist

Use the priority field to choose the most lucrative time periods when max event duration constraints exist.

Strategy C: Increase revenue when controlling onsite batteries

When controlling battery discharge rates, use the performance_compensation_cap to determine when discharging beyond the specified energy_kw will be compensated for:

Strategy D: Gain flexibility when prioritizing along with outside factors

When daily response flexibility is needed, energy curtailment can be reduced or events can be ignored when the is_voluntary field is set to true.