The blind spot at every substation

Most district heating providers have a live, continuous stream of operational data sitting at every substation: temperatures, flow, valve position, pump status, and no way to see it. They do have visibility into meter readings, but those arrive on the collector’s schedule, not theirs. Depending on the setup, that can mean a batch of hourly-resolution readings delivered once a day, or a single reading collected once a month.

That’s the whole relationship most providers have with their own infrastructure: a delayed, narrow window onto a system that produces far more information every second of every day.

What’s actually possible?

The meter reading isn’t the only thing worth collecting at a district heating substation. The substation controller, which regulates the exchange of heat between the district network and the building it serves, already has access to a much wider set of live signals: supply and return temperatures, flow rate, valve position, and pump status. A device installed at the substation can read these signals directly, alongside the meter, using whatever protocol each source speaks. In practice, that means handling several protocols side by side on the same installation. It also means that different installations speak different protocols entirely, and the device is built to handle that variation.

To talk to the substation controller itself, that's typically Modbus RTU or Modbus TCP. Older or building-management-oriented controllers often speak BACnet, while newer systems increasingly support OPC UA. To read the heat meter, it’s M-Bus, wireless M-Bus, or plain pulse output. On equipment that predates these digital standards, it’s raw analog signals, such as 4 to 20 mA current loops from temperature or pressure sensors, wired directly into the device. This kind of mixed-protocol integration is exactly the terrain we work in, and we know each protocol's quirks and how different vendors implement them. From there, the device sends its readings to the cloud over a 4G cellular connection, avoiding dependence on the building’s network and working at sites with no other connectivity.

This matters because of what the device is built to do. Outsourced collection schedules vary widely, from a daily batch of hourly-resolution readings down to a single reading collected once a month. Still, in every case that schedule is set by the design of the collection service, not by any technical limit at the substation itself. A device built specifically to sit at the substation and report continuously isn’t bound by that same schedule. It can report much more frequently (for example, one setup we’ve worked with reports 1-minute-resolution readings every minute) and do so consistently, without the delay that comes from a collection process designed around periodic batch delivery rather than continuous visibility.

Two different data products, one device

This device actually produces two different things bundled into one installation.

The first is metering data : the energy and volume readings used for billing. This is the same data a third-party collector delivers today, just captured directly instead of through an intermediary. Collecting it yourself means you can, if you choose, stop paying someone else to do it.

The second is operational data : the temperatures, flow, valve position, and pump status that describe what the substation is actually doing right now. This isn’t what a meter collection service is built to deliver, since it isn’t meter data at all. It’s the kind of information that, until now, has mostly stayed locked inside the substation, invisible to the district heating provider unless someone drives out and looks at it in person.

The first is a cost component in a business case, while the second explains what justifies building that case.

Real potential in operations, a hard number as a bonus

Operational, near-real-time data from every substation opens up work that isn’t possible with a delayed, once-daily meter reading:

• Supply temperature optimization. With live temperature and flow data across the network, a provider can adjust supply temperature more precisely, running the network as cool as the coldest substation’s actual demand allows rather than a conservative estimate, cutting distribution heat losses.
• Faster fault and leak detection. A substation whose return temperature or flow starts drifting from its normal pattern is showing an early sign of a fault: a stuck valve, a failing pump, or a developing leak, long before it becomes a customer complaint or a costly emergency repair.
• A foundation for flexibility services. Participating in demand response, coordinating thermal storage, or offering time-of-use products all depend on knowing what’s happening across the network close to real time. None of that is possible on a data feed that updates once a day.

And then, as a secondary line in the business case: the same device that makes all of this possible can also read the meter, which means the fee currently paid to a third-party collector can be reduced or eliminated. It’s a real number, and it helps the payback period. It just isn’t the main argument for doing this.

What does that potential actually look like once it’s realized? We’ve written about a first concrete step in that direction: turning the incoming data into something you can actually look at, in Visualizing district heating telemetry: a case study with TimescaleDB and Grafana .