Meters
The utility meter as a Texture entity — and how its AMI telemetry is ingested
Meters represent the utility's advanced metering infrastructure (AMI) in Texture. Each meter is modeled as a Device, carries interval telemetry — consumption, voltage, power quality, and demand (where applicable) — and is attached to a Site and the grid hierarchy where topology allows.
This page covers the meter as an entity, its lifecycle, how AMI telemetry is ingested, what metrics are collected, and how meter history is backfilled. Placement on the grid is covered in Grid Topology & GIS.
Why meter data?#
Meter telemetry is the foundation for distribution-level visibility. It lets you:
- Monitor usage and voltage at the meter and roll it up to sites, transformers, and feeders.
- Track power quality — voltage against ANSI limits, harmonic distortion, and unbalance.
- Reconstruct history through historical backfill, not just data since the meter connected.
The meter entity#
A meter is a Device in Texture, identified by its meter number. The meter number is the join key: it ties the integrated device (from the AMI source) to the meter's metadata in the utility's GIS — including its status and whether it is a consumer or a generator meter.
- Consumer vs. generator meters — the grid data distinguishes consumer meters (load) from generator meters (e.g., the production/generation meter at a solar site). Texture tags each device with the correct meter type.
- Status — a meter carries a status (e.g., connected, retired/disconnected) sourced from the AMI/MDM system.
- DER sites — a site may legitimately carry more than one meter (for example, a generation meter and a net/production meter at a solar site). These are not duplicates.
AMI data ingestion#
Meter telemetry typically arrives from one or both of the following, each with its own cadence and latency:
| Source pattern | Transport | Cadence / latency | Carries |
|---|---|---|---|
| MDM / AMI head-end | Scheduled API poll | Daily · 15-min or hourly intervals · ~1-day delayed | Primary telemetry for the full meter fleet; new and retired meters |
| Real-time interval feed | SFTP / file drop | Every few minutes · near real-time | A sampled subset; instantaneous power & voltage at high cadence |
:::note Data freshness Plan around the source: an MDM poll is usually ~1 day delayed (a 24-hour chart can look empty — use a 7-day window), while a real-time feed lags only a few minutes and is suited to live operational views. :::
The telemetry model#
Meter telemetry is stored as a time-series: Source (one per meter) → Series (one per metric × channel) → Points. Each series is an interval channel at one of four resolutions — 5-minute, 15-minute, 1-hour, or 1-day.
What Texture collects#
AMI metrics fall into four broad categories. Coverage generally narrows as the data gets richer — the highest-resolution metrics come only from the most capable meters.
| Category | Metric | Unit | Typical channels |
|---|---|---|---|
| Energy | Consumption (kWh usage) | kWh | 15m, 1h |
| Energy | Reactive / apparent energy | kVARh, kVAh | 15m, 1h |
| Power quality | Voltage / current THD | % | 15m, 1h, 5m |
| Power quality | Voltage / current unbalance | % | 15m, 1h |
| Power quality | Frequency, power factor | Hz, ratio | 15m, 1h |
| Daily demand | Real / reactive demand | kW, kVAR | 1 day |
| High-res (capable meters) | Voltage (avg / min / max), incl. polyphase | V | 5m |
| High-res (capable meters) | Per-leg current; asset temperature | A, °C | 5m, 1h |
:::important Provisioned ≠ populated A metric series can be provisioned (the channel exists for a meter) without being populated (the source actually delivers readings). Power-quality series in particular are often provisioned fleet-wide but only carry data for the high-resolution meter cohort. When validating coverage, confirm that points exist — not just that the series does. :::
Surfaced vs. collected#
Texture collects more than it renders by default. Consumption and voltage are typically surfaced first (the site usage section, consumption chart, device-detail voltage chart, and meter telemetry explorer). Reactive/apparent energy, daily demand, power quality, current, and asset temperature are collected, but not surfaced in the platform.
Voltage & ANSI limits#
Voltage charts draw reference lines at the ANSI service limits. For a 240V service these are 252V (high) and 228V (low) — industry-standard limits shown for operator context, not derived from meter metadata. Where the source supports it, voltage is collected at 5-minute resolution.
Historical backfill#
Historical backfill fills in interval history that predates the connection — recovered by re-fetching from the AMI source — so a newly onboarded fleet can show months of consumption and voltage history rather than an empty chart. Each meter has its own earliest available date; there is no single fleet-wide floor.
:::important Refresh continuous aggregates after a backfill Telemetry rollups are hierarchical, materialized continuous aggregates. Any backfill into older buckets must refresh them in order — 15-minute → 1-hour → 1-day — or the data stays invisible to consumption and telemetry queries despite being present in the underlying store. :::
Placement on the grid#
Recording telemetry is independent of placing a meter on the map. A meter is attached to a Site and the grid hierarchy only when its meter number matches a Service Point in the GIS topology. A meter onboarded after the latest topology snapshot records telemetry but "floats" — no Site, no map placement — until the topology is refreshed. See Grid Topology & GIS for the full placement model.