SMART METERING WORKS. SO WHY DOES IT STILL FEEL… ISOLATED?

SMART METERING IS SOLVED. DATA GOVERNANCE IS NOT.

In the previous article, “The Secret Life of Meters - From Basements to Billing”, we looked at how smart metering data travels from physical devices to dashboards and invoices. The conclusion was simple: smart metering works. Devices are deployed, networks are stable, data flows reliably, and utilities depend on it every day.

Yet something interesting happens once this data reaches the IT system - it tends to stop. Not because of technical limitations, but because the system boundaries were designed for billing, not for cities.

Welcome to SMART CITY KISS, my slightly self-ironic attempt to tell the truth about smart cities.

We’ve spent years wandering like digital hobbits through vendor forests, “semantic mountains”, pilot projects that never scaled, and dashboards that preferred to show errors instead of data.

We learned a lot, forgot some of it, stayed stubborn on a few things… and now we’re sharing everything without the usual smart-city bullshit.

KISS means Keep It S… (Smart? Super? Stupid? You choose...) Simple.

Translation for city leaders: If a smart-city project needs a wizard, five consultants, and half of your municipal staff, it’s not smart.

This series is about what actually works: Small. Simple. Practical. Meaningful.

And the third topic? Utility data. Again. Water. Electricity. Gas. Heat. But, this time, from smart metering platforms to smart cities.

WHAT FIWAREBOX IS

(AND WHAT IT IS NOT)

Let’s start with the big clarification:

FIWAREBox is not an off-the-shelf smart city platform.

We don’t parachute into your city, announce that we know everything better, install a magical cloud thing, and promise AI-powered unicorns (Yes, I could add “AI” and "LLM" to every sentence too - but let’s keep the buzzword budget for later).

What FIWAREBox actually is: A simple, powerful enabler.

We don’t replace your existing systems. We don’t take over your operations. We don’t tell you how to run your meters.

Instead, FIWAREBox gives your team the tools to:

• connect messy, scattered utility data,
• standardize it with NGSI-LD + Smart Data Models,
• add semantic meaning,
• keep everything in an open, future-proof format,
• make all data reusable for billing, planning, reporting, analytics, AI…

You keep control.

FIWAREBox simply makes your data usable — by people and machines — and prevents vendor lock-in.

SMART METERING PLATFORMS DO THEIR JOB. CITIES ASK A DIFFERENT QUESTION.

Smart metering platforms are optimized for a very specific purpose: accurate measurement, reporting, and billing. Utilities rely on them, regulators trust them, and operational teams know how to work with them.

Cities, however, are increasingly asking broader questions. 

They want to understand how water consumption behaves during heat waves. They want to correlate energy usage with weather forecasts. They want to connect meters with buildings, districts, public assets, and long-term sustainability goals. They want to combine operational data with open data, planning data, and external sources.

Billing alone is no longer enough. This is where a gap appears - not in metering, but in data integration, standardization, and governance.

WHEN DATA STAYS LOCKED, VALUE STAYS LIMITED

In many cities today, consumption data is technically available, but practically inaccessible. It lives inside specialized systems, often in proprietary formats, exposed through custom APIs, or delivered via scheduled exports.

Each new use case becomes a small project. Each integration becomes a negotiation. Each new dashboard costs time and money.

Over time, cities realize they are not lacking data - they are lacking a shared data layer.

FROM METERING DATA TO CITY DATA

Once consumption data is placed in a common data platform, its value changes dramatically.

Water meter data combined with weather forecasts can reveal leakage risks during droughts. Energy consumption combined with temperature predictions can improve load planning. District-level aggregation allows city planners to understand infrastructure stress. Historical data enables better investment decisions.

None of this replaces the metering system, it simply extends the life and relevance of the data it already produces.

But this extension requires more than another API.

WHERE DCaaS AND DSaaS ENTER THE PICTURE

This is where concepts like DCaaS (Data Catalog as a Service) and DSaaS (Data Space as a Service) become essential.

FIWAREBox DCaaS provides a structured, searchable catalog of available data assets. It answers simple but critical questions: what data exists, who owns it, how often it is updated, and under what conditions it can be used. Instead of data being hidden inside applications, it becomes visible and discoverable.

FIWAREBox DSaaS builds on this by enabling controlled data sharing across organizational boundaries. Utilities, city departments, and external partners can participate in a shared data space while retaining full data sovereignty. Access rules, purposes, and permissions are explicit, traceable, and auditable.

One can start with DCaaS and after upgrade to DSaaS.

This is no longer an IT feature, it is data governance in practice.

CKAN, OPEN DATA, AND THE EXTERNAL WORLD

Cities do not operate in isolation. They consume and publish data.

Platforms like CKAN and FIWAREBox Extended CKAN play a key role in exposing selected datasets as open data. When metering data is already standardized and contextualized, publishing aggregated or anonymized views becomes straightforward. The same applies to consuming external data, such as weather services, demographic statistics, or regional energy indicators.

Instead of building one-off pipelines, cities can treat data as part of a living ecosystem.

WHAT CITIES EXPECT FROM UTILITIES THEY OWN

In many cases, utilities are owned by the city itself. This changes expectations.

City administrations increasingly expect:

• transparency of operational data,
• the ability to reuse data across departments,
• independence from single-purpose platforms,
• and long-term control over strategic data assets.

When consumption data flows through a shared platform, cities gain visibility without interfering in daily operations. Utilities continue to operate their systems, but data becomes a public asset under clear governance, not a black box.

BILLING IS IMPORTANT. DEPENDENCY IS NOT.

Billing remains critical, but cities are becoming cautious about being locked into expensive, inflexible billing solutions that are tightly coupled to proprietary data models.

Once data is standardized and accessible through a shared platform, billing becomes a replaceable service rather than a dependency. 

Cities can:

• keep existing billing providers,
• introduce competition,
• or develop alternative solutions over time.

This does not break existing systems. It restores choice.

FIWAREBOX AS THE MISSING LAYER

FIWAREBox addresses this gap by providing a neutral, standards-based data layer built on FIWARE and NGSI-LD, aligned with European data space principles and Gaia-X. It does not replace metering systems, billing engines, or utility platforms.

It connects them.

FIWAREBox enables DCaaS and DSaaS in real operational environments. It integrates internal systems, external data sources, and open data catalogs. It provides context, semantics, and interoperability without forcing cities or utilities into a single vendor ecosystem.

This is not about building another Smart City platform but about making existing systems work together.

A PRACTICAL SCENARIO – HOW SMART METERING CONNECTS TO FIWAREBOX

Consider a typical city setup where a smart metering platform already collects data from water meters. The platform operates its own communication network, device management, validation logic, dashboards, and possibly billing. Nothing in this setup needs to change. Do not reinvent a wheel.

FIWAREBox is added as an integration and standardization layer, not as a replacement.

In the simplest scenario, the smart metering platform already exposes consumption data through an existing API. FIWAREBox connects to this API as a consumer and periodically or continuously ingests the data. This approach works well for batch data, validated readings, and historical consumption values that are already processed by the metering system. In most cases, it is good enough, at least for water metering you do not need 10 data points per second per meter. Yes, we are aware of LoRaWAN limitations.

Where near real-time or event-based data is required, integration can be implemented using MQTT. In this case, either side can host the broker. Some metering platforms already operate their own MQTT broker and publish events there. In other cases, FIWAREBox provides the broker and the metering system publishes selected events to it. The architectural choice depends on operational preferences, security policies, and existing infrastructure, not on technical limitations.

Once data enters FIWAREBox, it is transformed (mapped) into NGSI-LD entities and stored in a NGSI-LD Context Broker. Also, all metadata is stored to DCaaS. At this stage, raw measurements are enriched with context, such as the related building, district, utility, time window, units, and organizational scope. This contextualization step is what turns raw meter readings into reusable, interoperable city data.

The smart metering platform remains the source of truth. FIWAREBox does not validate, correct, or replace the original data. It mirrors and contextualizes it for broader use. Data ownership remains clearly defined: the utility or the city owns the consumption data, the metering provider owns and operates its platform, and FIWAREBox acts as a neutral processing and sharing layer under agreed governance rules.

At the same time, other data providers can connect to FIWAREBox independently. A weather service can publish forecasts and historical data. Traffic information can flow into FIWAREBox. A building management system can contribute operational parameters. An energy provider can expose grid-related information. Open datasets can be ingested from CKAN catalogs. All these sources coexist in the same data space, using shared semantic models, without being forced into a single vendor ecosystem.

For consuming applications, this results in one consistent access layer. Analytics tools, optimization engines, digital twins, reporting platforms, or third-party services no longer need separate integrations with each individual system. Yes, AI, AI agents, LLMs too. Everyone mention these now, so do we. They query the Context Broker, subscribe to updates, or access curated datasets via DCaaS and DSaaS mechanisms.

This approach fundamentally differs from point-to-point integrations. Instead of each provider building and maintaining custom APIs for every consumer, FIWAREBox provides a shared, standards-based layer where multiple data producers and consumers interact under transparent and enforceable rules. The ultimate backbone.

In practice, a city can start with a limited scope, such as water meters combined with weather data, and expand over time. Electricity, heat, mobility, environmental, or asset data can be added later, even when delivered by different vendors. No existing solution is replaced, and no single provider becomes “the platform”.

The result is a federated architecture where systems remain independent, data ownership is preserved, and interoperability is achieved through standards rather than custom integrations. This is the point where smart metering evolves from a billing-focused system into a foundational component of a city-wide data fabric.

FROM ISOLATED SYSTEMS TO A CITY DATA FABRIC

Smart metering solved measurement and the next challenge is coordination. Cities that invest in shared data platforms gain flexibility, resilience, and long-term control. Utilities gain clarity about expectations and a stable integration layer. Technology providers gain a clear boundary between their core products and the wider ecosystem.

This is how smart metering naturally evolves into smart cities - without disruption, without replacement, and without reinventing what already works.

WHAT SHOULD WE CONNECT OR WRITE ABOUT NEXT?

We are preparing the next use case. It could be EV charging infrastructure, parking data fusion, water and energy cross-border flows, logistics corridors, or even a full regional mobility dashboard. 

Tell us which direction you want us to explore next.

DISAGREE, COMMENT, OR WISH TO KNOW MORE?​

Curious how metering data, city systems, and external sources could coexist on one shared platform?

Want to explore data spaces without turning your architecture upside down?

Let’s continue the conversation.