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.

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.

Partner Reference ID Meters Processing Dispatch Processing Interval Data Upload
Integration guidance - Define partner_reference or refId as a unique identifier based on utility meter vs. device type_ Look for meter_type field in the Meters API response to determine how to store meter_id Lookup dispatched meter_id in relevant database table(s) to determine which device or group of devices to dispatch For programs that require interval data upload
utility_meter partner_reference or refId set to customer/site ID If utility_meter, store according to guidance below Dispatch all associated devices If applicable, upload interval data for each utility meter using corresponding meter_id
device partner_reference or refId set to device ID
(or if desired a combination of customer/site ID + device ID)
If device, store according to guidance below Dispatch that individual device Upload interval data for each device using corresponding meter_id

Where to Store Leap Meter IDs

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.

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.

Important notes:

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.

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.