Energy assets sit in the ground and across a service territory, mostly somewhere nobody is standing. Meters, concentrators, controllers, stations, cabinets and street lighting accumulate over decades, from suppliers who no longer exist, and none of it will be replaced to make the software tidier.
Vision Smart Platform is our IoT platform for estates of that kind. It models equipment, turns payloads into readings that carry a unit and a timestamp, evaluates rules on those readings, issues commands where the equipment supports them, and keeps a change history behind all of it. The same registry covers metering, network points, lighting and the buildings an operator runs.
One device family, described once
A meter type or a luminaire type is a model and a version. The units in the field are instances that inherit everything defined above them, so a fleet is configured once rather than device by device. Equipment from different generations is described rather than replaced, each generation as its own model.
Protocols are configurable, containerised service instances, and LoRaWAN, cellular, fibre and Ethernet can run at the same time. Payload decoding sits in a per-controller CODEC definition, so a new supplier is added by configuration rather than a platform release.
Metering across electricity, water and gas
Electricity, water and gas meters are held in one model. Consumption is extracted from the payload and persisted as a metric with its unit and timestamp, which is what makes a value comparable and defensible when it is challenged. Collection runs through concentrators or controllers that decode locally, then over whichever network reaches the site.
Integration APIs let billing, ERP and reporting systems read the same values instead of keeping a divergent copy.
When a device goes quiet
A meter that stops reporting produces nothing, so nobody finds out until someone asks. Rules can be written on device state and on the age of the last value, which turns silence into a condition the system can act on. Rules carry priorities and can be enabled or disabled operationally, and practically every entity keeps a change history with old and new values, which matters when a figure is questioned.
Commands and what confirms them
Command templates define the parameters supplied at execution and the response metrics that confirm the command ran. In lighting that means dimming one luminaire or a whole group from the same screen, driven by schedules, calendars, sensor input or reported state. At stations and network points, a supervisory layer sits over existing control with validated commands.
Public lighting in Chitila
VISION implemented smart lighting for Chitila in Ilfov County, covering more than 1,600 street lighting units with centralised control and real-time monitoring. The town had high energy costs, manual maintenance, poor visibility in key areas and slow fault detection.
The reported results were a 60% reduction in energy consumption through adaptive dimming and scheduling, and maintenance time cut by 50% through real-time fault alerts and remote diagnostics. The rollout depended on coordinating civil works with the IoT deployment, pre-commissioned devices, edge-based auto-configuration and validating LoRaWAN and NB-IoT coverage first.
Built around your processes
Vision App Maker is our low-code platform, used across more than a hundred industry implementations. Applications are built in a visual designer: data structures, forms, business rules and workflows configured around how the organisation runs — its asset classes, its field crews, its reporting obligations, its approvals.
When the process changes — a new regulatory return, a different maintenance regime, a reorganised territory — the change is made in configuration.
