Utility Meters vs. Devices

Leap provides access to programs that dispatch and measure performance at either the utility meter (e.g. residential home or commercial site) or the individual device (e.g. battery, EV charger, or thermostat). The “Leap meter” refers to the asset where dispatching and performance measurement occurs and where revenue is generated from. The Leap meter_id is the unique ID that is used to identify this asset.

Since a utility meter can have multiple controllable devices behind it (e.g. 2 thermostats and an EV charger), there are some differences in processing Leap meters that are utility meters compared to Leap meters that are individual devices. The meter_type parameter within the Meters API response enables partners to tell which type (utility_meter vs. device) each Leap meter is.

📘

Utility Meter vs. Device Programs

To understand which programs operate at the utility meter vs. device, check out the Performance M&V column in the Onboard Overview program tables.

Processing Utility Meters vs. Devices

The table and database options below outline approaches for handling the differences between utility meter and device type Leap meters.

Where to Store Leap Meter IDs (see Meters Processing above)

Depending on the meter type, you will need to adjust how you Sync Meter Inventory and store the associated Leap meter ID in your internal database. How you store this is ultimately up to you and dependent on your database architecture, but provided below are some possible options with meter_type differences outlined:

Option A: Store all meters in a dedicated meters table
This approach stores all meters together with an additional field to indicate the meter type and would link back to customer/site and device tables accordingly. This would simplify the Meters API and Dispatch API integrations since all Leap meter IDs would be written to and looked up in the same table.

• If utility_meter, store as such so it can be associated with all controllable devices behind that meter
• If device, store as such so it can be associated to that individual device

Option B: Store all meters in existing device table
This approach is a variation of the above option but stores meters directly in your existing device table.

• If utility_meter, store in device table for all controllable devices behind that meter
• If device, store in device table for that individual device

Important notes:

• A customer could have a device in both a utility meter program and a device level program and therefore up to 2 Leap meter IDs must be able to be stored for each device. If you are unable to store 2 meter IDs in a single field, you would need to have 2 separate fields and your Dispatch API integration would have to look for meter IDs in both fields. For example:
  • If utility_meter, store in a “leap_utility_meter_id” field
  • If device, store in a “leap_device_meter_id” field
• If participating in a utility_meter level program, each new controllable device added over time would need to have the utility_meter meter_id assigned

Option C: Store in customer & device table depending on meter type
This approach allows for storing the Leap meter ID in the location that the meter ID is uniquely identifying based on the meter type and where event performance is being calculated. This requires that Meters API and Dispatch API integrations write to and lookup Leap meter IDs in both tables.

• If utility_meter, store in customer/site table
• If device, store in device table

📘

Note on Sub-Meters

It is possible to create partner-created meters with a meter_type of submeter instead of utility_meter or device. This would be used in the rare case that you have access to submeter data (instead of utility_meter or device level data) at a customer site. If this occurs, this submeter value would show up as a meter_type in the Meters API response as well. In that case, you would need to process these similar to a utility_meter where any controllable devices behind that submeter would be tied to the relevant Leap meter_id.