Example: a behind-the-meter building with solar and storage

This example builds on the API onboarding flow. Follow that guide first to authenticate, create your meters, and create the asset — this page only covers the methodology-specific parts layered on top. The snippets below reuse the same authenticated client and your account_id.

What this methodology is for

The building_btm_sensored methodology measures building-level impact from multiple behind-the-meter interventions at once. A single building often hosts several distributed energy resources — rooftop solar, a battery, maybe more — sitting behind one utility meter. This methodology reads the directly sensored interval meters for each resource and disaggregates the building into counterfactual scenarios, so you can answer “what would this building have drawn from the grid with no solar and no battery?” from measured data rather than a modeled baseline.

The meters and the sign convention

The methodology relies on an energy balance across up to four electricity meters, in WattCarbon’s sign convention (grid import and building consumption are positive; onsite generation is negative):

Role	Symbol	Sign	Meaning
Point of common coupling	U	import positive	The net meter at the grid interconnection (meterCategory: point_of_common_coupling). Required.
Solar	S	generation negative	Onsite PV generation. At least one of solar or storage is required.
Storage	B	charging positive, discharging negative	Battery charge/discharge. At least one of solar or storage is required.
Building load	L	consumption positive	The building’s own load, if separately metered. Optional.

These satisfy U = L + S + B: what the grid sees is the building’s load plus whatever solar and storage add or remove. The building-load meter is optional — when present it’s used to reconcile the other three and catch a flipped sign or unmetered load.

There must be a point_of_common_coupling meter and at least one DER meter (solar or storage). Without the net anchor, or with nothing to disaggregate, measurement fails with a missing-data log entry rather than producing a result. A utility (revenue) meter does not substitute for the point-of-common-coupling anchor: the methodology recognizes the category and keeps it for a future utility-vs-PCC cross-check, but it does not fill role U.

Set up the meters and asset

Create the meters and the asset using the onboarding guide; this example only adds the methodology on top.

1. Create one electricity meter per role — follow Step 1 — Create a meter for a point-of-common-coupling (net) meter, a solar meter, a storage meter, and optionally a building-load (other_loads) meter. Keep each meter’s id.
2. Upload each meter’s interval data — follow Step 2 — Upload meter timeseries. Mind the sign convention above: solar generation is negative, battery charging positive and discharging negative, the point-of-common-coupling meter import-positive.
3. Create the building asset — follow Step 3 — Create an asset, attaching all of the meters you created via meterIds. The asset’s location drives the weather data used for M&V.

The snippet below assumes you have captured the meter IDs and the asset as asset_id. Add this methodology instead of the generic Step 4.

Add the methodology

The methodology takes the meters as a flat meterIds list. Each meter’s role is derived from its meterCategory (point_of_common_coupling, solar, battery, other_loads, and optionally utility); meters with any other category are ignored. projectInstall is a nested date period; its reporting window (the day after completionDate) bounds the measured impact, so meter history from before the system was installed is excluded.

client.post(
    f"/accounts/{account_id}/assets/{asset_id}/methodologies",
    json={
        "kind": "building_btm_sensored",
        "meterIds": [
            pcc_meter_id,
            solar_meter_id,
            storage_meter_id,
            building_load_meter_id,  # optional
        ],
        "projectInstall": {
            "startDate": "2024-03-01",
            "completionDate": "2024-03-01",
        },
    },
).raise_for_status()

Because this example attaches both a solar and a storage meter, it produces four disaggregated scenarios over the reporting period (the single-DER worlds are emitted only when both DERs are present):

• Observed — the metered net load U, the building as it actually ran.
• Solar only — U − B, the net load with the battery removed but solar retained.
• Storage only — U − S, the net load with solar removed but the battery retained.
• No intervention — U − S − B, the building’s native load with neither solar nor storage.

The gap between observed and no intervention is the combined impact of everything behind the meter; the gap between solar only and no intervention isolates the solar, and the gap between storage only and no intervention isolates the storage.

What you get

The asset’s primary methodology is now building_btm_sensored, producing the whole-building disaggregation and its observed / solar-only / storage-only / no-intervention scenarios. WattCarbon runs M&V on it and computes hourly savings. Results land on the asset detail page in the web app, and EACs are minted from the primary methodology on the usual cadence.