> ## Documentation Index
> Fetch the complete documentation index at: https://docs.axle.energy/llms.txt
> Use this file to discover all available pages before exploring further.

# Asset and boundary telemetry

> What data we need to participate, and how to send it

We need two kinds of data to participate in a market:

* **operational metering**: readings from the asset to understand and optimize asset usage. We typically need these with as low latency as possible
* **settlement metering**: readings from the asset or site boundary meter, which we send to the market operator as proof of delivery

Operational metering always comes from the asset we're optimising. Settlement metering can also come from the asset (known as **asset-metering**), but in many markets
we're required to obtain readings from the site boundary meter (**boundary-metering**). Axle can obtain boundary meter data for consenting households if you don't already have access to it.

In cases where we use asset metering, we may have to pass additional qualification checks to confirm that the metering provided by the asset is sufficiently accurate.

| Market          | Asset Metering Allowed? |
| --------------- | ----------------------- |
| DNO Flex        | Yes                     |
| Capacity Market | Yes (1.5% accuracy)     |
| DFS             | Yes                     |
| Wholesale       | Yes (CoP11 required)    |

<Note>[CoP11](../assets/chargers#cop11-qualification) is a UK standard which is required to use an asset's metering in the wholesale market. Axle has extensive
experience qualifying assets for CoP11 - please [get in touch](mailto:hello@axle.energy) to discuss how we can qualify your asset</Note>

# Communicating asset telemetry

The kind of telemetry we gather varies by asset.

<AccordionGroup>
  <Accordion title="Chargers" icon="bolt">
    * Charge Power (kW)
    * Plugged in (boolean)
  </Accordion>

  <Accordion title="Electric Vehicles" icon="car">
    * State of charge (SOC) (%)
    * Plugged in (boolean)
    * Charge Power (kW)
  </Accordion>

  <Accordion title="Batteries" icon="battery-half">
    * State of charge (SOC) (%)
    * Inverter Power (kW)
    * Grid Power (kW)
    * Solar Power (kW)
  </Accordion>

  <Accordion title="HVAC" icon="temperature-half">
    * Power (kW)
    * Temperature (°C)
  </Accordion>

  <Accordion title="CT clamp readings" icon="gauge">
    For sites with a CT clamp installed at the grid boundary, Axle can collect half-hourly CT clamp readings through supported asset integrations.

    CT clamp data measures site-level grid I/O similarly to a boundary meter, and is treated as such when verifying delivery.
  </Accordion>
</AccordionGroup>

## Reading direction and sign convention

When you send readings to the [Asset Readings](../api-reference/data/readings) endpoint, the sign of each value tells us its direction.
For readings that can flow either way, the convention is **positive = import, negative = export**:

* **Import** means power/energy flowing *in* — from the grid into the site, or into the battery (charging).
* **Export** means power/energy flowing *out* — out to the grid, or out of the battery (discharging).

All other reading types are unidirectional and must be non-negative. The table below summarises the `label` values accepted by the endpoint:

| Reading (`label`)                         | Unit | Sign convention                                                                     |
| ----------------------------------------- | ---- | ----------------------------------------------------------------------------------- |
| `boundary_import_kw`                      | kW   | Positive = import from the grid, negative = export to the grid                      |
| `battery_inverter_import_kw`              | kW   | Positive = into the battery (charging), negative = out of the battery (discharging) |
| `solar_power_kw`                          | kW   | Generation only — always `>= 0`                                                     |
| `charger_consumption_energy_kwh`          | kWh  | Consumption only — always `>= 0`                                                    |
| `charger_lifetime_consumption_energy_kwh` | kWh  | Cumulative lifetime consumption — always `>= 0`                                     |
| `boundary_lifetime_import_energy_kwh`     | kWh  | Cumulative lifetime import across the site boundary — always `>= 0`                 |
| `boundary_lifetime_export_energy_kwh`     | kWh  | Cumulative lifetime export across the site boundary — always `>= 0`                 |
| `provisional_consumption_kwh`             | kWh  | Consumption only — always `>= 0`                                                    |
| `battery_state_of_charge_pct`             | %    | Between 0 and 100 (inclusive)                                                       |
| `battery_stored_energy_kwh`               | kWh  | Always `>= 0`                                                                       |

<Tabs>
  <Tab title="Via our API">You can push telemetry to our [Asset Readings](../api-reference/data/readings) endpoint, where you'll find a list of accepted reading types</Tab>
  <Tab title="Via your API">We can poll your API or subscribe to webhooks to obtain telemetry.</Tab>
</Tabs>

# Obtaining boundary meter data

Axle can obtain boundary meter data on your behalf, with user's consent and proof of address. [Contact us](mailto:hello@axle.energy) to
discuss the best way to incorporate this consent collection into your product.