Dispatch Automation (v1.1)

Dispatches are signals from the Leap platform about a grid event. A dispatch event is a request for an individual meter or group of meters to curtail (or export in some cases) energy during a defined time period. A Leap dispatch notification could contain one or many of these unique dispatch events within it.

Responding to dispatches in a timely and consistent manner is essential to achieving high performance during grid events and maximizing revenue potential.

Dispatch automation with Leap enables you to integrate once and scale to all available markets and programs. While there are differences between each program, Leap simplifies implementation by providing a common dispatch notification structure so that your dispatch processing logic can be leveraged across all markets.

Dispatch Structure

A dispatch has two top-level components:

• Recipient: The Meter or Group responsible for responding to the dispatch event
• Timeslot(s): The dispatch time period as well as additional details about the service required during that time period
  
  

Recipient (Meter or Market Group)

You can choose to receive dispatches at the meter or market group level:

Group Dispatching Considerations:

• You must keep your internal groups in-sync with Leap. As described in the Sync Meter Updates guide, you can use the market_group_id in the meters API endpoints to guide the provisioning process in your system.
• The dispatch event notification will include both the group ID and the list of your meter IDs which are part of that group. The energy curtailment awarded should be distributed across this group of meters.
  
  

Timeslots

A timeslot describes the details of a dispatch. It includes the start and end time, energy quantity, and other metadata. Additional details on these fields can be found later in this guide.

{
      "meter_id": "afce893d-ea68-487f-9f8c-778b1881f60a",
      "timeslots": [
        {
          "start_time": "2022-06-02T00:00:00Z",
          "end_time": "2022-06-02T01:00:00Z",
          "test_event": false,
          "energy_kw": 4,
          "market_type": "day-ahead",
          "cancelled": false,
          "programs": [
             "DRAM"
          ]
        }
      ]
    }

Notification Methods

There are multiple options for receiving these dispatch notifications. The Leap API provides both push and pull models below:

• Webhook Push Notifications - Leap pushes notifications to your webhook endpoint as soon as they are available
• Dispatch Event Polling - You poll the relevant Leap dispatch endpoint on a regular basis checking for new updates

📘

Webhook Push Recommended

The webhook approach is recommended over polling as it is most efficient and more easily enables participation in real-time markets.

The API endpoints available to support these two methods are summarized below:

Webhook Push

• Meter Level
  • Get / Set / Delete your webhook URL
  • Trigger test notification to your webhook URL
• Group Level
  • Get / Set / Delete your group webhook URL
  • Trigger test notification to your group webhook URL

Polling

• Meter Level
  • Search Dispatches - For retrieving dispatch events broken out at an individual meter/site level
• Group Level
  • Search Group Dispatches - For retrieving dispatch events by groups of aggregated meters/sites
    
    

Types of Events

There are many conditions that can lead to a dispatch event. Each event notification you receive could represent one or more of these types. Understanding each type helps you create a workflow that fits your system.

Market/Program Awards vs. Capacity Tests

Market/Program Awards

• Clearing in a wholesale energy marketplace will trigger a market award (dispatch event) for a meter or group.
• Market/grid operators and utilities can also initiate awards (dispatch events) based on program rules or emergency events.

Capacity Tests

• Many programs require meters to demonstrate the full extent of their capabilities. Depending on the program, capacity tests may be called at the discretion of the market operator or scheduled in advance by Leap.
• Capacity tests are important events as performance during these events correlates to capacity revenue payments.

🚧

It is recommended to treat both Capacity Tests and Market/Program Awards in the same way since performance in each directly impacts revenue payments.

A dispatch event can be both a Capacity Test and one or more Market/Program Awards. When this occurs, Leap will send a single dispatch message combining the requested action from each. For example, a Capacity Test event could be called for a specified time period and then a wholesale Market Award could be received for that same time period at a different kW power value. Leap will consider this a single dispatch event for that time period and use the maximum kW value between the test event and market award.

📘

Market/Program Differences

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.

New, Modified, & Canceled Events

A unique dispatch event is indicated by the combination of meter_id (or market_group_id) and start_time. There could be many different dispatch events included within a single webhook push notification or Search Dispatches response, each of which could indicate a new, modified, or canceled event.

New Events
Sent via webhook (or queryable by polling) as soon as they are available. Depending on the program and market context, a dispatch could be sent days in advance or seconds before the start time.

Modified Events
Modifications are rare but can happen occasionally. In these cases a new dispatch event notification will be sent with the same meter_id (or market_group_id) and event start_time. Any of the fields that changed from the original event notification should be updated. Some examples of modified dispatch notifications include:

• Increased ‘energy_kw’ value
• Updated ‘end_time’ for event

🚧

In California (CAISO), it is possible to get a day-ahead award for less than the full nomination kW value and then in the hour-ahead (HASP) market get a modified dispatch event notification increasing the kW value of that award. In this case, the updates to the dispatch notification would be the energy_kw value and the market_type. For this reason, it is important not to consider a unique event based off of the market_type. An event could be updated with a different market type as described in this example.

Canceled Events
Cancellations are denoted with the cancelled boolean field when needed. These are very rare and generally only occur if a market/program award or capacity test event was initiated in error.

Dispatch Event Processing

Multiple Events Within a Notification

Within the meter_dispatches (webhook) or results (event polling) arrays in the dispatch notifications will be objects that include the meter/group IDs along with their associated event timeslots array. Always assume each array could have multiple objects within it (e.g. multiple meter ID/timeslots objects within the notification and multiple timeslot objects within each timeslots array).

Important Event Data

Beyond looking for cancelled events, dispatch event logic is typically determined by:

1. Which meter_id or market_group_id is being dispatched
2. What is the event start_time and end_time
3. What is the dispatched energy_kw power value (if your technology has control over this)
   
   

start_time & end_time considerations:

• The ISO 8601 standard in the UTC timezone is used throughout the Leap API to indicate start and end times
• Note: In California (CAISO), day-ahead market events are provided in 1-hour increments so for longer duration events, multiple sequential 1-hour timeslots may need to be aggregated together depending on how you schedule and push out events to your end customer devices
• Note: In Texas (ERCOT) ERS program, the end time for these emergency events is not known at the start of an event so in these cases Leap will use your ERS accepted time periods to determine the next point at which you are no longer obligated to curtail energy. If the event ends ahead of that, an updated dispatch notification will be sent indicating the UTC time that the event ended (this update will show a new end time that could be up to a few minutes in the past given that the event just ended). If the emergency event is still ongoing, a new event will be created prior to each contiguous time period you are obligated to participate in.

energy_kw considerations:

• This is the amount of power you are expected to curtail (or export to grid if program allows) for the duration of the event
• It is recommended to curtail as much as you can (within technology & customer experience constraints) given that many programs pay for over-performance and penalize for under-performance
  
  

Optional Event Data

There are other parameters provided in the dispatch message (e.g. test_event, market_type, programs) that you can use depending on your use case. Most often these fields are either ignored or logged in your internal systems. These timeslot object parameters are described in the applicable API reference docs.

Optional parameter considerations:

test_event

• true Indicates a capacity test event (for applicable programs). This is a high priority event that should be responded to in order to prove capacity to the market. Capacity performance will be used in settlement calculations.
• false Indicates a market/program award event. This is also an important event as market performance will be used in settlement calculations.

market_type

• Indicates type of market (e.g. day-ahead, hour-ahead). The different markets have different advanced notice timelines.

programs

• Indicates one or more programs that this event was called for. Programs could have different advance notice expectations or market rules (e.g. exports are allowed in the CAISO ELRP program).
  
  

New Fields in Dispatch Notifications

New fields may be added to these dispatch JSON objects over time as market/program requirements change. These additional fields are not considered breaking changes and therefore would be released under the existing API version so it is important to ensure your implementation can handle any new key/value pairs gracefully.