HVAC Telemetry Across a Multi-Site Facilities Estate
A multi-site facilities operator brought HVAC energy, fault and runtime data from BACnet/IP, Modbus RTU and closed OEM controllers into one normalized pipeline they own, without replacing a single existing building system.
Project context
A facilities operator runs a national estate of mixed-use buildings: offices, light-industrial sites, and a handful of cold-storage facilities. No two sites share an HVAC vintage. Some run a recent BACnet/IP plant, some run Modbus RTU loops, and several depend on closed OEM controllers that expose nothing but an undocumented service port.
The brief was narrow and demanding: three numbers, every site, one normalized view. Realtime energy consumption per plant. A fault and alarm history with timestamps that line up across vendors. Runtime hours per major asset, so maintenance follows wear rather than the calendar. The operator had been quoted a per-site SaaS subscription with a five-year minimum commitment, and rejected it on principle. The data is operational truth, and operational truth belongs in the operator's own infrastructure, not on someone else's rental.
Why the obvious path was wrong
The reflex on a programme like this is to put a new BMS in front of the old one. We argued against it, on three counts.
It rebuilds a wheel that already turns. Most sites already had a working BMS at the plant level, sequencing chillers and air handlers competently. Replacing that layer buys a year of disruption and a multi-year procurement cycle, in exchange for capabilities the site already has.
It does not solve the cross-site problem. A second BMS is just a second silo. The question was never "what is this plant doing right now": it was "what is happening across the whole estate tonight at 02:00," and no single-site BMS answers that.
It trades one lock for another. The operator already lived with vendor lock-in at the plant level. Paying to acquire a second, this time over the data layer, made no sense.
So we built the opposite of a new BMS: a thin telemetry layer that reads from the systems already in place and ships normalized records into the operator's data plane. It adds a path for the data to travel. It changes nothing about how the buildings are controlled.
Architecture: one gateway per site, one schema everywhere
Each site gets an Owasys open-Linux gateway, installed alongside the existing controllers rather than between them and the plant. The gateway speaks BACnet/IP to the modern plants, Modbus RTU over a serial loop to the older ones, and a custom adapter to the closed OEM controllers. That adapter was negotiated with the OEM under the operator's own contract, not ours, which mattered: it kept the access rights with the party that owns the buildings.
An acquisition daemon polls each upstream system on its own cadence, faster on energy meters, slower on slowly-changing setpoints, and normalizes every reading against a shared HVAC asset model: air handler, chiller, pump, cooling tower, zone. It writes one record per asset per minute into a local time-series buffer, so a dropped network link costs nothing but a short replay. From that buffer an MQTT publisher ships to a broker the operator hosts. A stream worker then fans the data two ways: into Timescale for live dashboards, and into long-term object storage for compliance and audit.
The asset model is a flat schema we ship and the operator owns. Every point on every site maps to it. Nothing in the path is a per-vendor adapter dashboard, because the moment one site's data only makes sense in one vendor's screen, the cross-estate view is dead.
Rollout in three waves
Wave 1, reference site (weeks 1 to 4). One office building with the most complete BACnet plant. We used it to lock the asset model, validate the energy KPIs against meter readings the operator already trusted, and confirm that the existing BMS would not contend with the new gateway on the bus.
Wave 2, the hard sites (weeks 5 to 12). Three sites running closed OEM controllers. The bottleneck here was never the code. It was the legal work to open the OEM service port under the operator's contract, which we sequenced first, then built the adapter inside the operator's account once access was granted. Slow on the calendar, quick once unblocked.
Wave 3, the rest of the estate (weeks 13 to 26). By now the install was a routine: a pre-flashed gateway, a site survey checklist, a two-hour wiring window, and a calibration pass against the values the existing BMS was already reporting. Field crews ran the installs. We watched each one come online from the operator's console.
What changed for operations
The dashboards were the small part. The change that mattered was that the operations team could ask a question about the whole estate and trust the answer.
- Estate-wide HVAC energy KPI, hourly: live across all sites within minutes of plant data, against a previous reporting lag of one to three days.
- Time to identify which site triggered an after-hours alarm: seconds, from a single ranked list, instead of phoning each site's facility manager in turn.
- Dashboards the operator still depends on a vendor to publish: zero.
- Maintenance now scheduled against runtime hours per major asset, not a fixed calendar interval.
Engagement shape and handover
The programme ran as Consulting, Implementation, Operation, with a hard handover date written into the SOW. At handover the operator received the gateway image and the instructions to rebuild it from source, the acquisition daemon source, the HVAC asset model, the dashboards together with their underlying queries, and a runbook for bringing a new site online without us.
Twelve months later, the operator has added four sites on their own. That is the claim we care about most, because it is falsifiable: the team can extend the system without re-opening our contract, and they have.
Build your industrial telemetry solution.
Discuss embedded gateway delivery, telemetry pipelines, and customer-owned IP with our team.

