DATA AND INTEGRATION

Data is only worth as far as it can flow

If data from the meter never reaches the utility's customer management, billing, SCADA and GIS systems, the investment does not pay back. This page explains what data is produced and how it flows.

DATA

The data families the meter produces

Five data groups answer the questions of different teams. Switch between the tabs to see each group's fields and intended use.

The basis for billing and trend analysis.

Meter indexBilling period close and reconciliationm³
Period consumptionConsumption trend per customerm³
Hourly / daily valuesMinimum night flow and profile analysism³/h
Measurement timestampA shared measurement window for DMA comparisonISO 8601

Field names, units and transmission frequency depend on the project configuration. The exact data dictionary is shared with the technical file, tied to a specific release and configuration.

TRANSMISSION PROFILES

The balance between frequency and battery

More frequent data is not always better; every extra transmission comes out of the battery budget. The right profile follows from which decision the data feeds.

Transmission profiles, intended uses and trade-offs.
Profile For which decision Trade-off
One transmission per day Billing and periodic reconciliation Lowest energy use; event visibility can lag by up to a day.
Daily transmission with hourly logging Minimum night flow and consumption profile analysis Slightly larger payload; markedly deeper analysis. A balanced choice for most utility scenarios.
Frequent transmission Leak investigation and critical customer monitoring Higher battery drain; usually applied to selected points rather than the whole fleet.
Event-triggered transmission Tamper, reverse flow and valve fault alerts Normally adds no load; transmission count can rise at a point with frequent events.

The profile names are for explanation only. Exact transmission intervals, payload sizes and the corresponding battery-life assumptions are given in the technical file together with the project configuration.

INTEGRATION

How the data reaches the utility

The utility can keep using its own platform. The aim is not to add one more screen, but to put the data into the existing workflow.

  1. Scope and field mapping

    Which data field maps to which system is decided together; customer number, meter serial number and location matching are settled.

  2. Transfer method

    Depending on project needs, API-based pull, event-based push or bulk file transfer are evaluated. The method is chosen to fit the utility's security policy.

  3. Identity and authorisation

    Which system may access which data, who holds command authority and how the audit record is kept are all defined.

  4. Validation and handover

    The end-to-end flow is tested with pilot data; missing and duplicate packets, timestamp consistency and index reconciliation are checked.

OWNERSHIP AND PRIVACY

Measurement data belongs to the utility

Detailed consumption data can carry information about household behaviour. Data ownership, retention and access are therefore part of the contract, not a detail to settle later.

Security
  • The utility owns the data; on contract termination it is exported in a machine-readable format.
  • Storage location and retention period are defined in writing.
  • Role-based access; who sees which data and who may issue which command is recorded.
  • Data minimisation: fields that do not feed a decision are not collected.
  • Notification, access and deletion processes under GDPR and KVKK are part of the design.
A smart water meter installed in a meter chamber beneath a city street.

NEXT STEP

Start by measuring in your own network

Let us validate the coverage, data, battery and integration assumptions together in a limited pilot. We write the success criteria before the pilot begins.

Define the pilot scope Get in touch