The question we get asked most frequently during pilot scoping isn't about forecast accuracy or demand charge economics — it's about integration. Specifically: how does the forecast actually get into the BMS? At what point does the HVAC system receive the pre-conditioning schedule, and how is it expressed in a format the BMS understands?
The answer depends heavily on which building automation protocol your BMS uses, what supervisory layer architecture is in place, and whether the system is configured to accept external setpoint writes at all. This post covers the practical integration landscape across BACnet/IP, Modbus TCP, and API-based supervisory systems — what works, what creates problems, and what to check before assuming an integration is feasible.
The BACnet Object Model and Why It Matters for External Writes
BACnet (Building Automation and Control Networks) is the dominant open protocol in commercial BMS deployments. It defines a data model based on objects — each piece of information in the system (a temperature reading, a setpoint, a control output) is represented as a BACnet object with defined properties. The most relevant object types for forecast integration are Analog Value (AV), Binary Value (BV), and Schedule objects.
When an external system wants to write a forecast-derived setpoint into a BACnet BMS, it typically does so by writing to the Present Value property of an Analog Value object that the BMS has been configured to expose. The BACnet priority array governs which source wins when multiple systems write to the same object — manual operator overrides typically hold priority 8, automated supervisory commands priority 14–16, and default values (what the BMS uses when no external write is active) hold priority 16.
For a forecast integration to work reliably, the facilities team or controls contractor needs to configure the relevant setpoint objects with a priority level that the forecast system can write to — and that won't be overridden by existing automated sequences. Getting this priority assignment wrong is the most common cause of "integration is connected but setpoints aren't changing" problems during commissioning.
The other BACnet consideration is COV (Change of Value) subscriptions versus polling. An external system that wants to read BMS data — room temperatures, staging states, chiller plant status — can either poll the BMS at fixed intervals or subscribe to COV notifications that the BMS pushes when a value changes. For a forecast integration that reads building state to update the forecast model, COV subscriptions are preferable — they reduce network traffic and ensure the external system has current data rather than data that's potentially 60 seconds stale. Most modern BACnet/IP installations support COV subscriptions; older systems may support only polling.
Modbus TCP: Simpler Protocol, More Manual Mapping
Modbus is the other major protocol you'll encounter in commercial HVAC, particularly in chiller plants, rooftop units, and packaged HVAC equipment from manufacturers who predate BACnet adoption. Modbus TCP (Modbus over Ethernet) is common in chillers, VFDs, and energy meters; Modbus RTU (Modbus over RS-485 serial) appears in older field devices.
Modbus is a register-based protocol rather than an object-based one. Each data point is mapped to a numbered register in the device's register map, and reading or writing a value requires knowing the correct register address. Unlike BACnet, which has standardized object types and a device discovery mechanism, Modbus has no standard data model — every manufacturer implements their own register map, and the register map for a specific device model is typically found in the manufacturer's integration guide.
For forecast integration purposes, this means that connecting to a Modbus-based chiller plant requires obtaining and working through the chiller controller's register map, identifying which registers correspond to setpoint inputs (chilled water supply temperature setpoint, staging commands, demand limit inputs), and configuring the integration to write to those specific registers. This is more manual than BACnet integration but well within the capability of a competent controls contractor — it's standard integration work for any system that needs to command Modbus devices from a supervisory layer.
One practical consideration with Modbus: many chiller manufacturers implement demand limiting as a specific Modbus register input — a 0–100% demand limit that throttles the chiller's maximum output. Writing a demand limit via Modbus is a clean, supported way to implement the "reduce chiller output during peak-tariff windows" part of a demand management strategy, without modifying setpoints in ways that might conflict with chiller safety logic.
The Supervisory Layer: Where Integration Actually Lives
In most commercial BMS architectures, the integration point for external systems isn't at the field controller level — it's at the supervisory layer. The supervisory layer (sometimes called the building network controller or web server layer) is the software system that aggregates data from field controllers, presents the operator interface, and implements global control sequences that span multiple subsystems.
Modern supervisory platforms typically offer REST APIs or MQTT connections for external data exchange, in addition to native BACnet and Modbus communication to field devices. An external forecast system can write to the supervisory API, which then translates the forecast-derived parameters into BACnet or Modbus writes to the appropriate field controllers. This architecture keeps the forecast integration in the IT-friendly world (HTTPS, JSON, standard authentication) while the supervisory layer handles the OT-side protocol translation.
The practical steps for this architecture are:
- Confirm that the supervisory layer exposes an API that supports external writes (not just reads). Many commercial BMS supervisory platforms have read-only APIs — adequate for monitoring but not for setpoint control.
- Confirm that the API supports the specific write operations needed: scheduled setpoint changes, time-of-day programs, or staging schedule modifications.
- Establish the authentication model — API key, OAuth, or client certificate — and ensure the forecast integration service can authenticate without operator interaction.
- Test write operations in a staging environment or during off-hours before live deployment, confirming that supervisory writes reach the field controller and produce the expected HVAC response.
Network Segmentation and OT Security
Building automation networks are operational technology (OT) networks and should be treated with appropriate security discipline. Most commercial buildings separate the BMS network from the corporate IT network, but the degree of segmentation varies widely — from full air-gap with a one-way data diode to a flat network where BMS controllers are on the same VLAN as office workstations.
For a forecast integration that writes setpoints to the BMS, the integration service needs network connectivity to the supervisory layer. This typically means placing the integration service in a DMZ or a dedicated building tech network segment that has constrained access to the BMS supervisory layer — specifically, access to the API port (usually HTTPS on port 443 or a custom port), but not direct access to field controller BACnet/IP devices.
The OT security principle relevant here is least-privilege network access: the forecast integration needs to reach the API, not the field network. Any integration architecture that requires opening firewall rules to BACnet/IP (UDP port 47808) from an external system should be redesigned to route through the supervisory API instead. Direct BACnet writes from an external internet-connected service to BMS field controllers is a security architecture that most building owners and cybersecurity-aware facilities managers will correctly reject.
We're not saying BACnet direct access is technically difficult — it isn't. We're saying routing external writes through the supervisory API layer is the right architectural choice for security and operational reasons, and integration designs that skip the API layer to save commissioning time create long-term risk.
What to Gather Before a Pilot Scoping Call
To accurately scope a forecast integration during a pilot planning conversation, the following information from the facilities team reduces integration surprises significantly:
- BMS manufacturer and software version (supervisory layer)
- Whether the supervisory layer has a documented external API — and whether that API supports writes
- Primary field communication protocol (BACnet/IP, Modbus TCP, or proprietary)
- Network segmentation: is the BMS on an isolated network, and what are the firewall rules between the BMS network and the building IT network?
- What control sequences are currently running for setback and pre-conditioning — specifically, are there existing scheduled programs that would conflict with external setpoint writes?
With this information, integration feasibility and estimated commissioning effort can be assessed in advance. The typical commercial BMS integration for a Heatvelo pilot takes 1–2 days of controls contractor time for API configuration and write testing — less for sites with modern supervisory platforms and documented APIs, more for legacy systems that require custom protocol gateway work. Knowing the architecture ahead of time is what makes that estimate reliable rather than speculative.