A Study of the Capabilities of BMS APIs and Building Application Requirements

Introduction

Buildings are complex systems comprising multiple subsystems that must work together to maintain optimal indoor environmental conditions while ensuring efficient resource utilisation. These subsystems are typically managed by Building Management Systems (BMS), which integrate sensors, actuators, and control software to monitor and control HVAC, lighting, electricity, safety, and security. Beyond enhancing occupant comfort, BMSs also reduce operational costs by optimising energy use.

A typical BMS consists of three layers: (1) the field device level (e.g., dampers, VAV boxes, fans, chillers, sensors, thermostats), (2) the automation level (controllers and routers), and (3) the management level, where servers and software with graphical interfaces allow facility managers to interact with the system [1]. These layers communicate via standard protocols, such as BACnet [2], LONWorks [3], and Modbus [4], which enable integration across multi-vendor devices and systems.

At the management level, however, building systems are represented using internal, vendor-specific data models. While protocols like BACnet specify objects and mandatory properties, there is no universal semantic representation. Vendors, therefore, expose system data through heterogeneous APIs that complicate interoperability [5]. For example, solutions deployed with Siemens’ Desigo BMS API cannot be directly ported to a building running Delta Controls’ EnteliWEB. To address this heterogeneity, researchers, and practitioners often turn to ontologies or metamodels that abstract differences in data representation. Several ontologies exist for built environments, with Project Haystack and Brick widely used for the operational phase.

However, in this blog, our focus is not on the interoperability issues that arise from the heterogeneity in BMS APIs resulting from the differences in semantic data representations of building systems by BMS vendors. Instead, we evaluate the BMS APIs to understand their capabilities based on 12 feature groups. We systematically investigate the capabilities of BMS APIs and their role in enabling advanced built environment applications.

This evaluation to understand the capabilities of BMS RESTful APIs is essential to enabling practitioners and researchers to deploy intelligent solutions for buildings. For example, buildings account for roughly 40% of global energy consumption, and nearly 30% of that is wasted [6]. Deploying energy-efficient solutions utilising control algorithms requires access to building systems and their data.

We provide some insights to practitioners and researchers on what they can achieve with the BMS APIs of Metasys, Ecostruxure, Enteliweb, Desigo, and Enterprise Building Integrator (EBI) by:

• Analysing APIs of the five mentioned BMS and categorising their functionality into 12 feature groups.
• Assessing these APIs against 85 common building applications, providing a framework to measure their suitability for real-world deployment.

The next section presents the various application programming interfaces of these five BMS before evaluating the capabilities of their REST APIs

Building Manage System APIs

In this section, we explore the various APIs that BMSs offer to facilitate integration and data exchange with third-party systems. Our review included online resources and BMS products from five (5) leading vendors: Siemens (Desigo), Schneider Electric (Ecostruxure), Honeywell (EBI), Johnson Controls (Metasys), and Delta Controls (Enteliweb). Our review suggests that these vendors provide three (3) primary APIs for integration and data exchange: Web Services and APIs, middleware solutions, and Internet gateways with MQTT.

Web Services and APIs

While both Web services and Web APIs at the BMS management level enable machine-to-machine communication, they differ in purpose and implementation. Web services typically use protocols such as SOAP, XML-RPC or JSON-RPC to enable software applications to exchange data, and often require a client application or browser interface. In contrast, Web APIs expose application data and functionality over the Internet using protocols like REST, GraphQL, or gRPC and can be accessed directly through code without relying on user interfaces [7, 8].

Schneider Electric offers web services that support both SOAP and REST protocols, along with the EcoStruxure Energy API, which utilises GraphQL. In contrast, Johnson Controls offers RESTful APIs for Metasys. While most BMS vendors make APIs available to access system data, not all offer public documentation. Some APIs are accessible online, while others require connecting through BMS software configured on a control network or subnet. Additionally, not all APIs grant full access to building systems: some only expose information about sensors, actuators, and their locations without supporting control functions. Certain APIs also require users to purchase licenses from the vendor before they can be used.

Middleware

According to Campbell et al. [9], the primary function of middleware is to manage the complexity and heterogeneity of distributed systems, creating a simpler programming environment for developers. In BMS architectures, middleware typically sits between the automation and management layers, providing interfaces to exchange data with building systems. Because vendor APIs and services may not grant full access to all systems and data, third parties often build middleware that connects to core building systems via APIs [10]. This enables the exposure of data through web services or RESTful APIs built on top of the middleware. Integrating middleware can require additional hardware investments and collaboration with vendors, particularly for legacy systems. However, some vendors offer software middleware as Software Development Kits (SDKs) for easier integration.

Internet Gateway

Some BMS vendors provide gateways with MQTT support to transfer building system data to the cloud. These automation-level gateways are primarily hardware devices, like specialised BACnet routers, acting as hardware middleware within private networks. They support multiple protocols, including BACnet and TCP/IP, enabling seamless communication. Through IoT services from BMS vendors, clients can develop APIs to access building data and information. Gateways allow reading and writing data via Web services and APIs. Vendors use cloud platforms such as Microsoft Azure IoT Hub, Amazon IoT Core, IBM Watson IoT, and Mosquitto, where clients subscribe to building data sent to the cloud infrastructure.

Table 1.0 lists the five BMS vendors and their integration APIs. Johnson Controls' Metasys offers a RESTful API and a .NET SDK. Metasys version 12.0 also supports MQTT for IoT data exchange [11], but we were unable to locate any documentation regarding middleware support for Metasys.

Delta Controls’ Enteliweb provides RESTful APIs and an MQTT broker. It includes PHP libraries (middleware) for creating custom reports within Enteliweb, but does not permit data access or programming outside the platform. Siemens Desigo CC and Desigo Optic offer RESTful APIs and Internet gateways with MQTT for data exchange.

BMS API Feature Groups

Now, we evaluate the web APIs of the five BMS vendors to understand the endpoints they offer for data exchange with their systems. We reviewed the online documentation of five BMS and compiled all API endpoints. Most documentation groups endpoints by managed resources; for example, Desigo’s Building X Openness Structure API includes endpoints for managing locations. Following this, we categorised endpoints into 12 API feature groups: alarms and events, audits, equipment, network devices, objects, space, time-series data, energy, carbon dioxide emissions, assets, energy LEED scoring, and building energy modelling. We excluded user account management APIs and Desigo’s Life Cycle Twin API, which manages Siemens’ Lifecycle Twin but is outside core BMS functions. We also excluded Enteliweb endpoints related to user interface management.

Table 2.0 shows the 12 feature groups of the five building management systems, highlighting the endpoints provided by each of them for accessing data and changing the state of the systems.

From Table 2.0, none of the BMS vendors provides endpoints covering the 12 feature groups. Schneider Electric's EcoStruxure offers extensive APIs for covering 10 out of the 12 feature groups, followed by Siemens Desigo, which covers nine out of the 12 feature groups. Metasys and Enteliweb cover six feature groups, while EBI covers two feature groups.

Building Applications and BMS API Requirements

After evaluating the functional capabilities of BMS APIs and categorising them into 12 feature groups, we analyse how these APIs support a broad spectrum of building applications. Specifically, we assess which feature groups of BMS API functionality are essential for enabling representative application scenarios. This analysis builds upon the work of Bhattacharya et al. [12], who categorised 85 building applications into eight distinct groups. We refine these into seven application groups to better reflect their relevance to modern building operations. Specifically, we remove the Web Display category, as its functionality can be inherently integrated into the other seven groups (e.g., through dashboards for energy monitoring or occupancy visualisation).

Common Built Environment Applications

Occupancy Modelling refers to the prediction and representation of human presence in indoor spaces, which is vital for optimising building energy systems. Approaches vary from correlating arrival and departure times across different days to recognising patterns in user mobility traces to forecast occupancy based on current location or habitual behaviours. These models are essential for enabling responsive HVAC and lighting control systems [13].

Energy apportionment focuses on associating energy consumption data with specific users or usage contexts within a shared environment. By learning the unique appliance usage patterns of individuals, and by monitoring energy consumption through smart meters or distributed smart plugs, these systems identify which user is operating which appliance. This technique enables detailed energy profiling and supports personalised energy feedback and cost attribution [14].

Model Predictive Control (MPC) is an advanced control strategy that uses predictive models of building dynamics—alongside forecasts of external disturbances such as weather or occupancy—to determine an optimal control trajectory. The goal is to balance competing objectives such as maintaining occupant comfort and minimising energy consumption or cost [15, 16].

Participatory Feedback systems incorporate real-time occupant input to enhance comfort and system responsiveness. Unlike traditional HVAC systems that operate on fixed rules or setpoints, participatory systems collect feedback—either explicitly or passively—from users regarding their thermal preferences. By integrating this feedback into control algorithms and connecting with BMS infrastructure, such systems dynamically adjust temperature setpoints to better align with occupant comfort levels [17].

Fault Detection and Diagnosis techniques identify inefficiencies or malfunctions in building systems by analysing energy consumption patterns. These systems often leverage the hierarchy of submeters within buildings to attribute unusual energy use to specific equipment or operational contexts. Modern approaches use statistical models to assess the extent of abnormal behaviour and to distinguish between equipment faults and context-driven variations such as weather or occupancy [18].

Non-Intrusive Load Monitoring (NLIM) refers to techniques that infer the operation of individual electrical appliances from aggregate power consumption data, without the need for dedicated sensors on each device. Using signal processing and machine learning, NILM algorithms identify appliance-specific energy signatures, enabling detailed profiling of occupant behaviour, preferences, and routines. These profiles can be used for energy management, occupancy inference, or even behavioural insights, albeit with implications for privacy [19, 20].

Demand Response (DR) enables buildings or devices to adjust their energy consumption patterns in response to signals from utilities or grid operators, typically to reduce demand during peak periods or in response to dynamic pricing. This capability can be achieved through direct load control or by incentivising users to shift usage [21].

Data Requirements of Common Applications

To support the functionality of the identified application categories, these systems must access both metadata (describing entities and their context) and record data (capturing real-time or historical values) associated with building components. Critical to this access is the representation of various entity relationships (ERs) that define how physical and functional entities are interconnected within a building.

Below, we enumerate the key types of entity relationships required across these applications, along with illustrative examples for each:

• ER1 — Sensor-to-Spatial Location: Captures where a sensor is physically located (e.g., a temperature sensor in Room 305).
• ER2 — Sensor-to-HVAC Component or Appliance: Associates a sensor with the specific HVAC component it monitors (e.g., a pressure sensor in a VAV box).
• ER3 — Person-to-Spatial Location: Maps occupants to spaces (e.g., a person in Office 410).
• ER4 — Spatial Hierarchy: Defines containment and hierarchy among spatial zones (e.g., Room 305 on the third floor).
• ER5 — HVAC Component-to-Spatial Location: Indicates where HVAC components or appliances are situated (e.g., a boiler in the mechanical room).
• ER6 — HVAC Component-to-HVAC Component: Describes connections between components (e.g., a VAV box connected to a duct).
• ER7 — Meter-to-Sensor: Links sensors to the meters that aggregate or relay their data (e.g., a temperature sensor within a thermostat).
• ER8 — Meter-to-HVAC Component: Relates a meter to the appliance or HVAC component it monitors (e.g., an energy meter of a boiler).
• ER9 — Meter-to-Spatial Location: Locates meters within the building structure (e.g., a power meter in Room 205).
• ER10 — Appliance-to-Person: Connects appliances to specific users (e.g., a desktop computer to a staff member).

Table 3.0 presents the seven common building applications, along with their required entity relationships and the BMS API feature groups necessary to support them. Among these applications, occupancy modelling demands the most comprehensive data, requiring all entity relationships except ER7 and ER9. The BMS API feature groups needed for occupancy modelling include Equipment, Objects, Space, and Time-series.

All five evaluated BMS vendors provide APIs that support access to Objects and Time-series data. However, Honeywell’s EBI and Schneider Electric’s EcoStruxure do not expose endpoints for Space, while EBI also lacks support for Equipment.

In contrast, all five BMS platforms offer the API feature groups necessary for non-intrusive load monitoring applications. For more complex applications such as demand response, fault detection and diagnosis, participatory feedback, and model predictive control, only Metasys and Desigo provide the full set of required APIs.

In summary, while all five BMS APIs provide sufficient functionality to enable baseline applications such as non-intrusive load monitoring and energy apportionment, more advanced applications—such as demand response, model predictive control, and fault detection and diagnosis—require a broader set of entity relationships and feature groups. Only certain platforms, such as Metasys and Desigo, currently expose the full range of capabilities necessary for such applications. This highlights the uneven readiness of vendor APIs to support the diverse needs of modern building operations and underscores the importance of aligning API development with real-world application requirements.

Conclusion

Deploying intelligent building applications for energy efficiency and operational optimisation requires reliable access to Building Management System (BMS) data and control functions. While most modern BMS expose APIs for this purpose, these remain fragmented across vendors, with uneven support for core functionalities and inconsistent adherence to standards.

In this blog post, we systematically analysed the BMS APIs of five major vendors—Siemens, Honeywell, Schneider Electric, Johnson Controls, and Delta Controls—to determine what capabilities they provide for interacting with building systems and data. We introduced a categorisation of BMS APIs into 12 feature groups spanning objects, alarms, events, energy data, carbon metrics, and more. This analysis revealed gaps: no vendor provides complete coverage, and access to certain features often requires additional licensing or configuration, limiting the transparency and accessibility of their platforms.

We then assessed the extent to which these APIs can support the development of real-world built environment applications by mapping the feature groups against 85 representative applications. Our findings show that while all vendors enable basic applications through access to objects and time-series data, more advanced applications—such as demand response, predictive control, and sustainability reporting—require combinations of features that no single vendor fully supports.

References

1. Hamza. 2018. Understanding the Basic Concept of BMS System. https://tinyurl.com/5n7ukbfc Accessed Jun. 13, 2024.
2. BACnet. n.d.. About BACnet - BACnet Committe. https://bacnet.org/about/. Accessed Jul. 10, 2025.
3. WAGO Global. n.d.. LonWorks. https://www.wago.com/global/lonworks. Accessed Jul. 10, 2025.
4. Schneider Electric, USA. 2013. What is Modbus and how does it work? | Schneider Electric, USA. https://www.se.com/us/en/faqs/FA168406/.
   Accessed Jul. 10, 2025.
5. Bharathan Balaji, Arka Bhattacharya, Gabriel Fierro, Jingkun Gao, Joshua Gluck, Dezhi Hong, Aslak Johansen, Jason Koh, Joern Ploennigs, and
   Yuvraj Agarwal. 2016. Brick: Towards a unified metadata schema for buildings. In Proceedings of the 3rd ACM International Conference on Systems
   for Energy-Efficient Built Environments. Association for Computing Machinery, New York, NY, USA, 41–50.
6. US Department of Energy. 2015. An Assessment of Energy Technologies and Research Opportunities. https://www.energy.gov/sites/prod/files/
   2017/03/f34/qtr-2015-chapter5.pdf Accessed Sep. 13, 2023.
7. Thomas Bush. 2023. What is the difference between web service and API. https://tinyurl.com/bdf932vs. Accessed Jul. 10, 2025.
8. Priyanka. 2025. Web Services vs APIs - What are they and how are they different? https://testsigma.com/blog/web-service-vs-api/. Accessed Jul.
   10, 2025.
9. Andrew T Campbell, Geoff Coulson, and Michael E Kounavis. 1999. Managing complexity: middleware explained. IT Professional 1, 5 (1999), 22–28.
   doi:10.1109/6294.793667
10. Facility Executive. 2014. Optimising Data from Building Management Systems. https://facilityexecutive.com/building-automation-analytics/
    Accessed Jul. 10, 2025.
11. Johnson Controls. 2022. Introducing Metasys Release 12.0 by Johnson Controls. https://tinyurl.com/2tb687bm Accessed Jul. 10, 2025.
12. Arka Bhattacharya, Joern Ploennigs, and David Culler. 2015. Short Paper: Analysing metadata schemas for buildings: The good, the bad, and the ugly. In Proceedings of the 2nd ACM International Conference on Embedded Systems for Energy-Efficient Built Environments. ACM, New York, USA, 33–34.
13. Wilhelm Kleiminger, Silvia Santini, and Friedemann Mattern. 2014. Smart heating control with occupancy prediction: how much can one save? In Proceedings of the 2014 acm international joint conference on pervasive and ubiquitous computing: Adjunct publication. ACM, Seattle, WA, USA, 947–954.
14. Daniel Garnier-Moiroux, Fernando Silveira, and Anmol Sheth. 2013. Towards user identification in the home from appliance usage patterns. In Proceedings of the 2013 ACM conference on pervasive and ubiquitous computing adjunct publication. ACM, New York, USA, 861–868.
15. David Sturzenegger, Dimitrios Gyalistras, Manfred Morari, and Roy S Smith. 2012. Semi-automated modular modelling of buildings for model predictive control. In Proceedings of the Fourth ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Buildings. ACM, New York, USA, 99–106.
16. Rawlings JB Mayne DQ. 2009. Model predictive control: theory and design.
17. Lam Abraham Hang-yat and Dan Wang. 2013. Carrying my environment with me: A participatory-sensing approach to enhance thermal comfort. In Proceedings of the 5th ACM Workshop on Embedded Systems for Energy-efficient Buildings. ACM, New York, USA, 1–8.
18. Joern Ploennigs, Bei Chen, Anika Schumann, and Niall Brady. 2013. Exploiting generalised additive models for diagnosing abnormal energy use in buildings. In Proceedings of the 5th ACM workshop on embedded systems for energy-efficient buildings. ACM, New York, USA, 1–8.
19. Stephen McLaughlin, Patrick McDaniel, and William Aiello. 2011. Protecting consumer privacy from electric load monitoring. In Proceedings of the 18th ACM conference on Computer and communications security. ACM, New York, USA, 87–98.
20. Ting Liu, Yuqi Liu, Siyun Chen, Yulin Che, Zhanbo Xu, and Yufei Duan. 2014. A user demand and preference profiling method for residential energy management. In Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing: Adjunct Publication. ACM, New York, USA, 911–918.
21. Y Agarwal, B Balaji, S Dutta, R Gupta, and T Weng. 2011. Managing plug-loads for demand response within buildings. In Proc. of 3rd ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Buildings (BuildSys). ACM, New York, USA, 13–18.