Measurements

Measurements is a GraphQL API responsible for fetching, aggregating, and adding context to utility agnostic industry activity on a particular supply point. It is a product within the Global Industry Group's Meter Data Management product suite. You should think of Measurements as the bridge to industry across utilities.

Measurements API links:

• Quick start
• Get technical help
• Global reference for marketSupplyPointIds
• Third party integration

Audience

The intended audience for these docs are backend developers or machine learning engineers looking understand how Measurements works in Kraken terms. See the quick start usage guide .

Flow

Key concepts

• API Viewer - The API caller which can be AccountUsers, Organizations, or Oauth Applications.
• Measurements API - The GraphQL API endpoint API Viewers interact with to get measurements.
• Measurements Domain - The Kraken domain responsible for executing the backend logic.
• Measurements Source - The data source where the readings are stored. Usually Amphio, but can be a Postgres Consumption DB. As of now, there are no cases where a single utility has multiple data sources configure; however, there are instances of a source for Water and another source for Electricity.
• Amphio - Amphio is the preferred data backend for industry readings. Most Krakens use Amphio; however, Measurements is source agnostic.
• Amphio AUS - Australia's Amphio offers expanded capabilities to comply with market specifics unique to the AUS territory. Alignment between these two behavior sets is ongoing.
• Costing Domain - After readings are retrieved from the Measurements Source, they are sent to the Costing domain to be enriched with Cost of Usage information.

Measurements statistics and cost of usage

Note that adding cost of usage to Measurements requires two calculations. In order for billing code to be as accurate as possible, we need to aggregate measurements before we ask for COU data. This has the benefit of the two features being able to fail separately. If you are seeing consumption data without COU, it is likely an issue with Product Rate configuration or a result of missing readings for a particular time range.

Importantly, Measurements invokes the financials domain. This allows billing code to evolve without requiring a corresponding Measurements change. From a CDL perspective, this gives you a lot more flexibility as the two systems can develop independently.

Aggregation levels and readingFreqencyType

Measurements is primarily designed for aggregating Interval readings; however, we are seeing increasing support for Accumulation readings. Aggregation levels refer to the time granularity you'd like to group data into.

The API input for this is called readingFrequencyType. The most commonly used inputs for reading frequency are THIRTY_MIN_INTERVAL and DAY_INTERVAL but most clients support up to MONTHLY_INTERVAL.

Raw intervals

All aggregations are based off of your market's raw interval. This is the smallest time granularity offered in your market. Your industry team will be able to tell you exactly what the raw interval is for your Kraken.

The smallest readingFrequencyType you may request from Measurements is the RAW_INTERVAL. In most cases, the raw interval is 30 minutes. For these clients, asking for RAW_INTERVAL measurements is the same as asking for THIRTY_MIN_INTERVAL readings. If you're not sure, you can query measurements with RAW_INTERVAL and compare the startAt and endAt datetimes.

Timezones

All industry readings are stored in UTC format under the hood, but Measurements will prefer the input timezone and convert readings into industrytime before returning them. For most Krakens, industrytime and localtime will be the same. You can always pass in UTC as the timezone to get UTC readings back; however, this isn't common and you would likely only do this to troubleshoot any oddities observed from a timezone offset error.