Smart Metering

Connect consumption data to real operational insight.

Digitize electricity, water and gas metering with centralized readings, history, alerts and analytics.

Book a DemoDiscuss this Solution

Electricity, water and gas meters with a data concentrator connected to the Vision Smart Platform core, with a consumption bar chart

One model for every meterElectricity, water and gas are described the same way.
Readings you can compareConsumption arrives as timestamped metrics in shared units.
Configured per deploymentThe architecture is built around the meters and networks you already have.

Challenge

A metering estate is large, mixed and long-lived.

Meters are usually the most numerous assets an operator owns, and the hardest to keep consistent.

Several suppliers, several generations

A metering estate accumulates over decades. Different manufacturers, protocols and payload formats end up side by side, and each one brings its own tool.

A reading is not yet data

A number without a unit, a timestamp and the device it belongs to cannot be compared between periods or between sites.

Anything manual limits frequency

If knowing a value depends on someone visiting the meter, how often you can know is decided by the size of the crew.

Architecture

From the meter to a comparable series.

The building blocks are the same as for any other device class. The exact architecture is configured around the meters, protocols and processes of each deployment.

MeterElectricity, water or gas

Concentrator or controllerLocal collection and decoding

NetworkLoRaWAN, Ethernet, LTE, fibre

Protocol instanceContainerised service per protocol

Vision Smart PlatformRegistry, metrics, rules, screens

What each stage becomes in the platform

Every meter becomes an instanceRegistered against a version and a model, so a fleet of the same product is described once and installed many times.
Consumption becomes a metricMetric templates extract the value from the payload and persist it with its unit and timestamp, ready to be compared.
Decoding has a defined placeWhere a payload needs interpretation, controllers carry their own CODEC definition rather than a change to the platform.
Units stay consistentUnits of measure and data types are configured centrally, which is what makes two suppliers comparable at all.

Operational scenario

A meter that goes quiet.

Not every useful event is a reading. Sometimes the signal is the absence of one.

Illustrative example

1

Readings arrive on a cycle

Each one is stored as a metric with its value, its unit and a timestamp.

2

One device stops

No new metric arrives for that instance, while its neighbours keep reporting normally.

3

A rule notices

A condition on the device state or the age of the last value crosses its threshold.

4

A notification goes out

The rule effect reaches the people responsible, with the device it concerns.

5

The map shows where

The instance is located, so the question becomes which crew, not which meter.

6

The record holds

The metric history and the audit trail keep what happened and what was changed afterwards.

This example is illustrative. The rule, its threshold and its effect are configured per deployment — the platform supplies the mechanism, not the policy.

Operational scenario

Consumption data
Preprocessing
Historical metric
Threshold / anomaly rule
Alert

Outcome

Better consumption visibility and reduced manual intervention.

 

Inside the platform.

Vision Smart Platform metering dashboard: accumulated volume index, input voltage chart and tamper, temperature, fault and battery alerts for a gas meter

What it is built on

The platform capabilities behind this solution.

Use the documented device, data, automation, visualisation and integration capabilities to build a metering solution around your existing infrastructure.

Digital Twins & Device Lifecycle

Meters, concentrators and controllers as models, versions and instances, from enrollment to retirement.

Explore ›

Data, Metrics & Commands

Metric templates that turn payloads into timestamped consumption values, and command templates where the meter supports them.

Explore ›

Rules & Automation

Conditions on consumption, device state and time, with priorities and operational enable or disable.

Explore ›

Connectivity & Integration

Protocols as containerised service instances, plus per-controller CODEC definitions for payload decoding.

Explore ›

Developer & Integration Tools

The integration APIs another system uses to read values or trigger an action on the same objects.

Explore ›

Security & Audit

Roles, permissions and a change history with old and new values on practically every entity.

Explore ›

Fit with what you already have

Existing metersA meter family is a model and a version. A second supplier is another model, not another platform.
Existing networksLoRaWAN, Ethernet, LTE, fibre, MQTT and HTTP can coexist, each handled by its own protocol instance.
Existing systems of recordThe platform is the operational layer. Billing, ERP and reporting systems read from it through the integration APIs.
What stays configurableModels, parameters, metric templates, rules, dashboards and map profiles are configured in the interface, not compiled.

See how Vision can fit your deployment.

Share your current devices, connectivity and operational objectives.

Discuss your project