A commercial building generates a remarkable amount of data and shares almost none of it. The sensors exist, the controllers are polling them every few seconds, and the information reaches a head-end workstation in a plant room where it is retained for as long as the local disk allows. Getting it somewhere useful is less a data problem than a negotiation with three decades of installed practice.
These are the notes we give clients before a portfolio integration, and most of them are things we learned by getting them wrong on site.
What is actually installed, versus what the drawings say
Start with a survey, and budget real time for it. On a recent 14-building portfolio, roughly one in nine points on the commissioning documentation did not exist: sensors specified and never installed, points decommissioned during a refit, controllers replaced with a different model whose object list differs.
What you need per building, before estimating anything:
- Controller makes, models and firmware, per panel.
- Protocol and transport: BACnet/IP, BACnet MS/TP over RS-485, Modbus RTU or TCP, a proprietary bus, or a vendor cloud with an API you must pay for.
- An actual point count, from a discovery scan rather than the design document.
- Network topology, including whether plant rooms have IT connectivity at all. Frequently they do not.
- Who holds the head-end credentials, and whether the maintenance contract permits third-party access. This is a commercial blocker more often than a technical one.
The protocol realities that shape the design
BACnet/IP is the comfortable case. You can discover devices and objects, subscribe to change-of-value notifications for the points that support it, and poll the rest.
BACnet MS/TP is where schedules slip. It is a serial network, typically 38.4 or 76.8 kbps, shared by every controller on the segment. Poll it aggressively and you degrade the control system you are trying to observe — which is a serious matter, not a performance note. A BACnet router to the IP side, conservative poll rates, and change-of-value subscriptions wherever supported are the standard answers. Expect one to five minute intervals on MS/TP points and design your analytics for that, rather than promising a per-second dashboard you cannot deliver.
Modbus has no self-description. Registers are integers in a document, often a PDF from the meter manufacturer, occasionally wrong. Scaling factors, endianness and register offsets by one are the three classic errors; verify every meter against a physical reading before you trust it.
Proprietary head-ends may offer nothing above the workstation. Options degrade from a paid integration licence, through a scheduled CSV or database export, to reading the head-end's own historian. Take the export if the licence is priced as a recurring per-point fee — that pricing model will eat the project's business case.
The three-layer architecture
Layer one: the edge gateway
One appliance per building, on the OT side, doing four jobs: protocol translation, local buffering, normalisation and secure upstream transport. Buffering is not optional — site connectivity fails, and a gap in an energy series is the thing that invalidates a monthly report.
Design points that matter: read-only by default, with any write path requiring explicit approval and a separate credential; outbound-only connections, usually MQTT over TLS with client certificates; local storage sized for a realistic outage, a week rather than an hour; and remote configuration, because sending someone to a plant room to change a poll rate is how the operating cost gets away from you.
Layer two: the time-series and asset model
Two things live here, and conflating them is the most common architectural mistake in this domain.
The time series is high-volume, append-mostly, and queried by range and aggregate. A purpose-built store — TimescaleDB, InfluxDB or equivalent — with retention policies: full resolution for a few months, rolled-up aggregates for years.
The asset model is small, relational, and where the value is. It records that this point is the supply air temperature sensor belonging to that air handling unit, which serves those zones on that floor of this building, and is metered by that meter. Use an established vocabulary — Brick Schema or Project Haystack — rather than inventing tags. Without this layer you have a chart. With it, you can ask which air handling units are heating and cooling simultaneously across the entire portfolio, which is the question that pays for the project.
Tagging is slow, manual and impossible to shortcut. Budget for it explicitly rather than hiding it inside "integration".
Layer three: analytics and the work list
Fault detection and diagnostics rules run against the asset model. The starter set is well established and consistently productive: simultaneous heating and cooling, valves or dampers stuck, economiser not economising when conditions allow, equipment running outside occupancy schedules, short cycling, setpoints drifting from design, meters reading zero or implausible values.
The output should not be a dashboard. It should be a ranked list of findings, each naming a specific asset, with an estimated annual cost and a suggested action, pushed into the ticketing system the facilities team already uses. A finding in a tool nobody opens is not a finding.
Segmentation, and the writeback conversation
Building control networks are operational technology. Treat them accordingly: separate VLAN, firewall between OT and IT with an explicit allow-list, no inbound connections to the gateway, certificate-based authentication, and an inventory of every device you have touched.
Sooner or later someone will ask for optimisation that writes setpoints back. That is a different project with a different risk profile, and it needs: a written scope of exactly which points may be written and within what limits; limits enforced at the controller, not only in your software; a manual override that always wins; an audit log of every write with its origin; and a documented failure behaviour — if the optimiser stops, the building must fall back to a safe schedule on its own.
Measuring savings so that finance believes them
Raw year-on-year comparison is not evidence; it is weather. Build a weather-normalised baseline — an IPMVP Option C whole-building regression is usually enough — fitted on twelve months before any intervention, then report against the adjusted baseline. It takes a day of analysis and it is the difference between a claim that survives a finance review and one that does not.
The short version
Survey before you estimate. Put a buffering, read-only gateway in each building. Keep the time series and the asset model separate, and invest in the tagging that connects them. Deliver findings into the facilities team's existing workflow, not a new dashboard. And normalise for weather before you claim a saving.
Written by the Bytescope Tech engineering team from live engagement work. If you want to argue with any of it, or you have a case where the opposite held, tell us — those are our favourite emails.