It connects to the BMS you already own. Here is exactly how.
No new panel, no new sensors, no inbound ports. SKW EnergyOS reads and writes the same BACnet and Modbus points your operators already use — read-only to begin with, and always at a lower write priority than a human.
BACnet/IP, BACnet MS/TP, Modbus.
| Protocol | Where you'll find it | How we connect |
|---|---|---|
| BACnet/IP | Supervisory controllers and most BMS head-ends installed since ~2005. Runs over the building's Ethernet network (UDP 47808). | Direct. The system joins the BACnet/IP network as one more device, discovers objects, and subscribes to the points it needs. |
| BACnet MS/TP | Field controllers on an RS-485 trunk — the AHU and VAV controllers themselves, usually behind a BACnet router or the supervisory controller. | Via the existing BACnet/IP router or supervisory controller, which already exposes the MS/TP devices. No new hardware on the trunk. |
| Modbus TCP / RTU | VFDs, EC-fan controllers, energy meters, chillers and older plant equipment that pre-dates BACnet. | Register maps per device. Read for telemetry (kW, Hz, rpm); written only where the point is already operator-commandable. |
Which AHU points are involved
Read · telemetry
- Supply, return and mixed-air temperature and humidity
- Duct static pressure and airflow / velocity where measured
- Chilled-water valve position, supply and return water temperature
- Fan status, VFD or EC-fan speed and power
- Damper positions, filter ΔP, occupancy and CO₂ where available
- Alarms and digital I/O — fire interlock, door interlock, trip status
Write · bounded, low priority
- Supply-air temperature setpoint
- Duct static pressure setpoint — the fan follows it; we do not drive the VFD directly
- Chilled-water valve setpoint where the sequence exposes it
- Fresh-air damper minimum position and schedule state
- AHU enable / schedule command, inside the agreed window
Only points the operator can already command from the BMS workstation are written. If a point is not commandable there, it is not commandable by us.
Honeywell, Johnson Controls, Siemens, Schneider
Outbound-only from the site gateway
Live-state validation before every write
12+ months autonomous, zero incidents
Write priority: a human always wins, at the protocol level
BACnet commandable objects carry a 16-slot priority array. Life-safety and manual operator overrides sit at the top; scheduled and automated writes sit lower. SKW EnergyOS writes at a lower priority than the operator workstation, so any operator instruction takes precedence over any system command — not because we promise it, but because the protocol enforces it.
Every proposed write is also checked against the building's live measured state (≤10 s old) and against hard bounds configured with your team before go-live. A command outside the bounds is not written. If the connection drops, the last valid state holds and the BMS continues on its own logic.
Longer read: BACnet integration for autonomous HVAC control — a practical guide →
Onboarding, in order
- 01
Point discovery
Read-only. The system discovers the object list, maps points to equipment, and shows you the map for sign-off. Typically a few hundred points per building.
- 02
Shadow, weeks 1–6
Still read-only. It streams live state, builds its model of the building, and presents findings with cost impact. Nothing is commanded.
- 03
Supervised, weeks 7–12
Commands are proposed to operators before execution. Every action is logged and attributable.
- 04
Autonomous, bounded
Writes within hard bounds, at low priority, validated against live state. Kill switch and manual-mode flag stay with your team.
- Outbound-only connection from the site gateway; no inbound ports are opened on the building network
- Data stored on site; a local copy of the dashboard keeps working if the internet drops
- Role-based access — viewers look, managers operate, admins set schedules and limits
- Every write logged: who or what changed which point, when, and why
- AMC contract untouched — the BMS vendor keeps maintaining the BMS
Integration questions we get asked
Our field controllers are on BACnet MS/TP. Do we need a gateway?
Usually not. MS/TP devices are already exposed through the supervisory controller or a BACnet/IP router that the BMS head-end uses. We connect there. A gateway is only needed on the rare trunk that has no IP-side router at all.
Our BMS is Modbus-only. Does that work?
Yes for telemetry and for points that are already operator-commandable — register maps are configured per device. Most plant in that situation is a mix: Modbus on VFDs and meters, BACnet on the AHU controllers.
Can it control duct static pressure or airflow directly?
It writes the static-pressure setpoint and lets the existing fan loop track it; it does not bypass the BMS to drive the VFD. Where airflow or velocity is measured, that reading feeds the model and the validation step.
What about EC fans?
EC-fan controllers typically expose speed and power over Modbus or BACnet. They are read for telemetry and commanded only through the AHU's existing setpoints, the same as a VFD-driven fan.
Does this apply to data-centre AHUs and CRAHs?
The protocol path is identical. Autonomous thermal control for AI data centres is on our roadmap and is not yet in production — the commercial-building deployments are.
Which BMS brands have you connected to?
Honeywell, Johnson Controls, Siemens and Schneider Electric, over BACnet and Modbus. The reference deployment — 68 AHUs, 550,000 sq ft, 12+ months — runs on the BMS the buildings already had.
What happens to our AMC?
Nothing. The BMS is not replaced or modified; the autonomous layer operates through it. The BMS vendor keeps maintaining the BMS.