Four companies control the intelligence layer of most commercial buildings on earth. Honeywell and Tridium own the edge gateway market. Johnson Controls (Metasys), Siemens (Desigo), and Schneider Electric (EcoStruxure) divide the building management system layer above it. If you want to know what your HVAC is doing, the conventional assumption is that you need to go through them.
That assumption is largely wrong. And understanding precisely where it is wrong, and where it remains accurate, is the starting point for building something better.
I have spent significant time recently researching this problem with Claude, asking it to cut through the marketing noise and identify the actual technical reality of data access in commercial buildings. What follows is what that research surfaced: where the real lock-in sits, where it does not, what the regulatory picture looks like for buildings without any control infrastructure at all, and what role AI can credibly play in estimating performance and identifying faults when sensor coverage is limited or nonexistent.
Where the lock-in actually lives
The wire-level protocols underneath nearly every commercial building control system are open ASHRAE and ISO standards. BACnet (defined in ASHRAE 135 and ISO 16484-5) and Modbus (a de facto industry standard from 1979) are what field controllers actually speak. A Tridium JACE 8000 is, at its core, a BACnet and Modbus aggregation device with a licensed software layer (Niagara Framework) wrapped around it. The proprietary moat is in the software and the licensing model, not in the communications protocol.
This matters practically. If you can reach a building’s IP network on the same subnet as its field controllers, you can send a BACnet Who-Is broadcast, receive I-Am responses from every device that hears it, and then read any point those devices expose, without touching a JACE, without a Niagara licence, and without any cooperation from the incumbent vendor. There is mature, actively maintained open-source tooling for exactly this: BAC0, a Python library built on bacpypes3, runs on Python 3.10 and above and implements the full BACnet client stack including device discovery, point reading, trend log access, and write capability. It ships on PyPI and receives weekly downloads in the thousands.
The real lock-in is one layer up, at what the vendors call the “cloud integration” layer. This is where Siemens, JCI, and Schneider have built their actual moat, and it is more sophisticated than the marketing lets on.
I checked the Siemens Building X documentation and the JCI OpenBlue architecture carefully. Both market themselves as open and vendor-agnostic. Both require a vendor-controlled, vendor-licensed on-premises edge appliance before any third-party application can access data through their APIs. Siemens Building X requires a “Connected Device” installed and connected to the internet, with the Tridium EULA explicitly binding the edge connector. JCI OpenBlue requires its own physical edge appliance, the OpenBlue Bridge, embedding a proprietary zero-trust network relay between the building and the cloud. “Openness” in their marketing means open at the API layer, after you have purchased and deployed their gateway.
The practical implication: for an independent application developer, the path that avoids vendor dependency is not to negotiate API access through their cloud platforms. It is to read from the wire directly, before the data ever reaches their layer.
The one genuine future threat to direct wire access
BACnet/SC (Secure Connect, defined in Annex AB of ASHRAE 135-2020) is a real shift. It applies TLS 1.3 encryption and certificate-based device authentication to BACnet traffic, which means that once a network migrates to BACnet/SC, a standard BAC0 discovery scan will not be able to decode the traffic.
s a real shift. It applies TLS 1.3 encryption and certificate-based device authentication to BACnet traffic, which means that once a network migrates to BACnet/SC, a standard BAC0 discovery scan will not be able to decode the traffic.
The current state of BACnet/SC adoption gives you time. Certificate onboarding headaches are the most cited deployment issue. Vendor tooling for diagnostics and management remains immature. The existing installed base of BACnet/IP devices is enormous and will not migrate quickly, partly because BACnet/IP and BACnet/SC cannot communicate directly without a gateway or router between them. In mixed-system facilities, which is nearly all of them, the migration path is gradual and the legacy segment will remain accessible for years.
The architectural implication for a new application is: build your direct BACnet access path now, while the window is clear, and design the data model to accommodate a fallback path (negotiated API access or local sensor augmentation) for the segment that eventually migrates to BACnet/SC.
The no-BMS scenario: a regulatory tailwind you should know about
size=”9″ fill=”white”>By 30 November 2026
This is not a voluntary initiative. It is a regulator-mandated, technically-specified API surface for whole-building interval energy data, and AEMO is the custodian. The contrast with the US Green Button programme is instructive: in the US, no utility voluntarily adopted Connect My Data. Every adoption was forced through state-level regulatory orders. In Australia, the rule is national and mandatory. For a product developer, this is a concrete, dateable API to build against, not a vague future capability.
The second factor is that the physics of building energy use are well-understood, and the research literature on inference from coarse data is more mature than the marketing around “AI-powered” buildings typically acknowledges.
What the physics-informed modeling literature actually says
Gray-box thermal modeling, combining a physics-based resistance-capacitance (RC) network model of a building’s thermal envelope with statistical fitting to observed data, is the established approach for building energy inference without dense sensor coverage. A recent implementation using this approach achieved a CVRMSE of 3.06 percent on indoor temperature prediction versus 10.2 percent for a full EnergyPlus simulation over a six-month period, and notably outperformed the physics-only model without requiring any BMS data.
Claude’s role in this research was not to retrieve the papers or the vendor documentation autonomously. What it did was something harder to replicate with a search engine: it held the BACnet protocol layer, the vendor cloud architecture layer, the AEMC regulatory timeline, the NILM and gray-box modeling literatures, the Project Haystack and Brick Schema ontologies, and the competitive landscape simultaneously, and formed associations between them that a researcher working through each domain sequentially would not naturally surface.
The specific connection between AEMO’s CDR real-time data rule and the gray-box thermal modeling literature, for instance, is not a connection that either discipline draws. This is the specific capability that matters here: not that AI knows the answers, but that it can form associations between disparate datasets, frameworks, and literatures that a domain expert working within a single field would not naturally traverse.
Being honest about what sparse-data inference can and cannot claim
This matters enough to state clearly, because the market is full of overclaiming.
With whole-building interval meter data plus weather data and a calibrated gray-box thermal model, you can credibly estimate aggregate energy waste relative to a physics-based baseline, detect anomalous consumption patterns that indicate a fault or operational problem, and quantify the gap between actual and expected performance at a building level. These are real, commercially valuable capabilities.
What you cannot defensibly claim from the same data is: which specific piece of equipment is faulty, whether the fault is a stuck damper, a refrigerant leak, or a failing compressor, or what the precise energy attribution is between HVAC subsystems. Research on ML-based fault detection consistently shows classification accuracies above 90 percent for specific fault modes, but those results are obtained on labeled datasets from densely-instrumented test rigs or simulation environments. Almost 30 percent of commercial building energy consumption is wasted due to unnoticeable system failures during operation. The aggregate opportunity is real. Pinpointing the cause from a single meter and a weather feed alone is not.
The credible product boundary is: flag the anomaly, quantify the likely magnitude, and recommend the diagnostic step (which may involve deploying a targeted sensor, reading a BACnet point if the building has one, or requesting a technician inspection). The AI does not replace the diagnostic; it surfaces the case and frames it.
The metadata problem and why it matters for analytics
There is one bottleneck that neither open protocols nor smart meter APIs solve on their own, and it is worth naming because it is where most well-funded attempts at building analytics have quietly run aground.
Fewer than 5 percent of commercial buildings have metadata schemas that meet the baseline required for automated analytics. What this means in practice: even if you can read every BACnet point in a building, you will typically receive object names like “AHU-2.SA.TEMP” or, in older systems, “Analog Input 47.” Translating those raw point names into a semantic model (this point is the supply air temperature of Air Handling Unit 2 on Floor 3, linked to the chiller it is served by) is called tagging, and it is a significant, largely manual effort that sits between data access and analytics.
Two open standards address this: Project Haystack (a tagging ontology maintained by an open community) and Brick Schema (an RDF-based semantic model with stronger support for spatial and equipment relationships). Both are gaining traction, and both matter for your data model design. Claude was able to reason across both standards in the same conversation, compare their coverage of HVAC equipment types, and identify the specific gaps that would arise when applying either to older BACnet installations with non-standard naming conventions.
JCI’s OpenBlue platform actually uses an internal tool called ROBOT (Rapid OpenBlue Onboarding Tool) that claims to apply AI to classify raw entity data into a Brick-compliant standard. The fact that JCI built this for internal use confirms that the tagging problem is real and expensive even for the incumbent vendors. It is also a signal that a vendor-neutral version of the same capability, not locked to OpenBlue, is a meaningful differentiator.
What a realistic architecture looks like
For a mixed portfolio, the data collection layer needs three distinct paths.
The first path covers buildings with an existing BACnet/IP infrastructure and network access. A lightweight edge agent based on BAC0 handles discovery and periodic polling. Modbus TCP devices on the same network are read through a gateway (or directly if they are IP-addressable). The agent normalises raw point data against a Project Haystack or Brick Schema tagging model, ideally using AI-assisted tagging for the initial labeling pass and exception-handling for non-standard object names. Data streams to a time-series store (InfluxDB is the natural pairing with the BAC0 ecosystem; it connects natively and supports Grafana for operational dashboards).
The second path covers buildings with no BMS but a smart meter under the NEM. Once AEMO publishes the real-time data procedures in late 2026, the API surface is defined and mandatory. Until then, existing CDR pathways through accredited energy retailers cover historical interval data going back 24 months at the NMI level. The gray-box thermal modeling layer sits here, combining meter data with BOM weather station data (or on-site sensor data if available) to produce a calibrated building energy model and a baseline for anomaly detection.
The third path is sensor augmentation for the no-BMS, no-smart-meter segment. A small set of strategically placed sensors (a current transformer on the HVAC circuit, a return air temperature sensor, an outdoor temperature logger) moves inference from whole-building estimation to equipment-level signal.
The AI layer sits above all three data sources, forming associations between what would otherwise be siloed streams: correlating weather-normalised load anomalies against BACnet setpoint trends, flagging the combination of high supply air temperature and stable chiller runtime as a candidate refrigerant undercharge signature, or identifying that a building consuming 23 percent above its peer group average shares an operational schedule with a high-consumption outlier from the previous summer.
The competitive gap worth occupying
Most platforms that compete in this space, Enersee, nanoGrid, and the analytics layers built into the incumbent BMS vendors’ cloud offerings, assume one of two things: either you are feeding them data from an existing BMS already, or you are installing a fresh IoT sensor deployment. The installed-base reality makes both assumptions expensive for the customer. BMS integration requires a licensed gateway and often a system integrator. Sensor deployments require hardware procurement, installation, and commissioning.
A product that can read directly from the wire where BACnet exists, pull regulated smart meter data where it does not, and use physics-informed AI inference to close the gaps between those two cases occupies a position that currently has no clean incumbent. The regulatory tailwind in Australia is real and time-bounded, given that AEMO’s real-time data procedures must be published by November 2026. The open-source BACnet tooling is production-quality today.
The window where this is genuinely uncrowded will not stay open indefinitely. The incumbent vendors are moving toward cloud-relay architectures precisely because they see the direct-wire risk. BACnet/SC will close the protocol-level access path in new construction over the next decade. The AEMC rule will eventually attract the large energy analytics platforms from the US and Europe who currently do not have Australian NEM integrations.
The best time to build in this space was five years ago. The second best time is while the window is still clearly open.
A note on how this research was done
The analysis in this article was produced in collaboration with Claude. I want to be specific about what that means, because the way AI contributes to research like this is often mischaracterised in both directions.
Claude did not retrieve the papers or the vendor documentation autonomously (I directed each search and it worked with the results). What it did was something harder to replicate with a search engine: it held the BACnet protocol layer, the vendor cloud architecture layer, the AEMC regulatory timeline, the NILM and gray-box modeling literatures, the Project Haystack and Brick Schema ontologies, and the competitive landscape simultaneously, and formed associations between them that a researcher working through each domain sequentially would not naturally surface.
The specific connection between AEMO’s CDR real-time data rule and the gray-box thermal modeling literature, for instance, is not a connection that either discipline draws. The observation that JCI’s ROBOT tool confirms the tagging problem is expensive even for incumbent vendors, and therefore represents a gap for a vendor-neutral product, required reasoning across vendor marketing, competitive positioning, and open-standard ontology design at the same time. The flag that BACnet/SC closes the direct-wire access path in new construction but leaves the installed base accessible for years is a synthesis of the protocol specification, the deployment friction reports from integrators, and the product roadmaps of specific vendors, none of which state the combined implication explicitly.
This is the category of work Claude does well: not answering questions that have a single authoritative source, but drawing defensible inferences from the intersection of multiple datasets and technical domains that are not usually read together. For research at the edge of a technical and commercial problem, that capability is genuinely useful. That is why I keep using it.
Rob Aldrich is a technology and sustainability executive based in Sydney, Australia. He is co-creator of Cisco EnergyWise, former Global Sustainable Buildings Lead at Amazon Web Services, and author of IP-Enabled Energy Management (Wiley/IEEE Press). He was interim Chief AI Officer at SafetyCulture, where he drove 84 percent AI tool adoption across 221 engineers.
robaldrich.com · LinkedIn · @googlenut
Sources
- ASHRAE Standard 135-2020, BACnet: A Data Communication Protocol for Building Automation and Control Networks, ASHRAE
- BAC0: BACnet Scripting Framework for Python, Christian Tremblay (PyPI / GitHub)
- BACnet Secure Connect (BACnet/SC) Overview, BACnet International
- Siemens Building X Data Sheet: Building Automation APIs, Siemens Smart Infrastructure
- OpenBlue Data Platform: Airwall Architecture, Johnson Controls
- AEMC Final Determination: Real-Time Data for Consumers, Australian Energy Market Commission, 18 December 2025
- AEMO Guide to CDR APIs, Australian Energy Market Operator
- Grey-box modeling for thermal dynamics of buildings under the presence of unmeasured internal heat gains, Energy and Buildings, 2024
- Grey-Box Modeling and Application for Building Energy Simulation, US Department of Energy / OSTI
- Hybrid Random Forest and Support Vector Machine Modeling for HVAC Fault Detection and Diagnosis, Sensors, 2021
- Project Haystack Open Standard, Project Haystack Community
- Brick Schema: A Metadata Schema for Buildings, Brick Consortium
- A Systematic Review of Building Energy Management Systems: Sensors, IoT, and AI Integration, Energies, December 2025