A question we get consistently when talking with facilities managers and their IT/OT teams is this: does Celaxis need write access to our BMS? The short answer is yes — eventually, if you want it to actually control anything. But that answer deserves more precision than a simple yes or no, because the architecture of BMS write access, what objects it covers, and how it's scoped are exactly the variables that determine whether the risk is acceptable.
This piece is about how to think through that question practically: what read-only mode can and cannot do, what write access actually means in BACnet terms, how to scope it minimally, and what fail-safe behavior should look like. The goal is to give facilities managers and their IT security teams a vocabulary for evaluating any building optimization software's access requirements — including ours.
What Read-Only Mode Actually Gives You
A read-only BMS connection lets external software observe what your building is doing: zone temperatures, current setpoints, occupancy sensor states, AHU operating status, VAV damper positions, and setpoint history. This is genuinely useful data. You can build dashboards, generate energy reports, identify anomalies in HVAC scheduling, and diagnose comfort complaints from the data logs. A significant portion of building energy intelligence products operate exclusively in read mode and call it "analytics."
The limitation is fundamental: a read-only connection cannot make your building behave differently. It can tell you that your building is running at full cooling capacity at 3am with no occupants, but it cannot stop that from happening. It can show you that your peak demand readings cluster on Monday mornings, but it cannot pre-cool the building Sunday night to flatten that peak. Analytics without control is a diagnostic tool, not an optimization system.
We're not saying analytics-only is useless — knowing what your building is doing is a necessary precondition for knowing what to change. But if a vendor describes their product as "optimizing your building" and their integration is read-only, ask them specifically what is changing as a result of their software. If the answer is "we give you recommendations and your facilities team implements them manually," that is an advisory product, not a control product. Both can be valuable, but they are different things with different ROI profiles.
What BMS Write Access Actually Means in BACnet
In BACnet/IP (ASHRAE 135), write access is object-specific and priority-scoped. When we write a cooling setpoint to a zone controller, we're issuing a BACnet WriteProperty service call to an AnalogValue object — typically the zone's active setpoint — at a specific command priority (usually priority 8 or 10 in the priority array, where priority 1 is the highest-authority override).
This means our setpoint write can be overridden by the BMS operator console (which typically writes at priority 8) or a manual override at the zone controller (which may write at priority 6). The BMS's native schedule, if configured at a lower priority number, takes back control when we release our command or when the priority array resolves. This is the standard BACnet priority arbitration mechanism — it's not something we implement as a custom feature, it's how the protocol works.
The practical implication: a well-scoped BACnet write integration does not replace or override your BMS's native control logic. It adds a higher-priority command during the pre-conditioning window, and when that command is released (either on schedule or because we've detected a problem), your BMS resumes its normal operation. The native schedule is still there and still running; we're just temporarily writing over it in the priority array.
Scoping Write Permissions Minimally
The right approach to BMS write access for an optimization system is minimum-necessary scoping. There are four dimensions to scope:
Object type. Write access should cover setpoint objects only — typically AnalogValue or BinaryValue objects representing zone heating and cooling setpoints, or AHU supply air temperature setpoints. No write access to mode objects (enabling/disabling equipment), status objects, or anything involving fire/life safety systems. These are different object types in BACnet and can be excluded from the permissions granted to our device instance.
Object range. Within the building's BACnet device network, access should be scoped to the specific device instances and object identifiers that correspond to HVAC setpoints. A BACnet integration that requires access to every object on the network is asking for more than it needs. We provide a specific list of the device IDs and object IDs we'll read and write — your BMS administrator can verify the list against your as-built documentation.
Setpoint bounds. Write commands should be bounded by minimum and maximum values your facilities team defines. We won't write a cooling setpoint below 68°F or above 78°F, regardless of what our model calculates. These bounds are configured in Celaxis and enforced before any command is issued. If our model suggests a setpoint outside those bounds, we log the suppressed command rather than overriding the constraint.
Priority level. Using BACnet priority 10 or 12 (lower authority) means your operators can always override our commands simply by writing at priority 8 from the BMS console. You don't need to disconnect Celaxis or revoke permissions — a standard operator override takes precedence automatically.
The Connectivity Fail-Safe Question
The legitimate concern with any external system that has write access to a BMS is: what happens if that system loses connectivity, crashes, or behaves unexpectedly? This is a good question and the answer should be explicit before you grant write access.
In BACnet, the fail-safe behavior depends on whether the external device maintains a "present value" write in the priority array or releases it. If Celaxis loses connectivity to your BMS, the last written setpoint value may persist in the priority array until it's explicitly released or the device connection times out. This is why our system issues an explicit "release" command (writing a NULL value to the priority array slot) when a pre-conditioning window ends — so control passes back to the BMS's native schedule regardless of whether we're actively connected.
For buildings on Niagara N4 or Honeywell Forge with REST API connections, the same principle applies: our setpoint writes have explicit start and end times, and the end-of-window release is handled by our system before we consider the action complete. If we can't confirm the release command was accepted, we flag the zone for manual review and send an alert.
The short version: if Celaxis goes offline mid-pre-conditioning, your building will continue conditioning at whatever setpoint was last written, and your BMS schedule will reassert control at the next scheduled transition. This is the same behavior as a manual operator who set a temporary override and then left the building — the BMS schedule eventually takes back control.
How IT and OT Teams Should Review Write Permissions
For a building where IT and OT teams have separate responsibilities — common in larger commercial properties and healthcare campuses — write access to the BMS typically requires sign-off from both. The OT team cares about which objects are accessible and at what priority. The IT team cares about the network path, credential handling, and logging.
A reasonable IT/OT review process for write-enabled BMS integration should ask:
- What credential or device identity does the external system use to authenticate to the BMS? (For BACnet, this is a device instance number and optionally a BBMD configuration. For REST APIs, this is a service account token.)
- Is the credential scoped to setpoint objects only, or does it have broader access?
- Are write commands logged by the BMS, and are those logs accessible for audit?
- What is the network path from the external system to the BMS? Does it require traversing the OT network, or does the BMS expose an API on a DMZ or cloud relay?
- What happens to pending write commands if the external system connection drops?
These are questions we expect and are prepared to answer specifically for each BMS platform we connect to. For the Siemens Desigo CC REST API, the credential model, endpoint scope, and logging behavior are different from the JCI Metasys NAE web service — and the answers to the above questions should reflect the specific platform, not a generic description.
The Practical Threshold
For most commercial office buildings, granting write access to zone setpoint objects at BACnet priority 10, bounded by a ±4°F range from the current schedule setpoint, with explicit per-zone enable/disable controls in the Celaxis dashboard, is a reasonable access model. It gives the optimization system enough authority to perform pre-conditioning and demand avoidance actions while preserving manual override capability at every level of the control hierarchy.
What's not reasonable: write access to AHU enable/disable controls, lighting circuit relays, or any system that controls access or life safety. Those are categorically different in risk profile and are not required for HVAC setpoint optimization. If a building optimization vendor's integration request includes access to these objects, ask why — and if the answer isn't specific, treat that as a signal to probe further before approving.
The framework is straightforward: read-only for observation, scoped write for control, explicit bounds on what can be written, and clear fail-safe behavior for connectivity loss. Any vendor offering write-enabled BMS integration should be able to describe all four in detail.