Connecting a new IoT system to an existing building management system (BMS) is where many projects slow down. The technology usually works; the delays come from unanswered questions about ownership, data, timing and responsibility.
Settling those questions before work starts saves weeks of back-and-forth between the IoT supplier, the BMS contractor, the facilities team and IT. This guide lists the questions to agree up front.
Why are we integrating?
Be specific about what the BMS should do with the new data:
- Display it for operators alongside existing plant data.
- Use it in control, for example adjusting ventilation by occupancy or air quality.
- Raise alarms through the BMS alarm system.
- Store it for reporting and energy analysis.
Display-only integration is much simpler than control. If the data will drive plant, safety and fallback behaviour need much more attention.
Who owns what?
Agree responsibilities in writing:
- Who owns and maintains the IoT devices and platform?
- Who configures the BMS side, and who pays for that work?
- Who owns the network between them, and who manages security?
- Who is called when data stops arriving?
How will the systems talk?
Choose the interface early. Common options include BACnet, Modbus, MQTT or a REST API, sometimes through a gateway that translates between them. Confirm which protocols and versions the BMS supports, and whether it needs a licence or a software update to accept new points.
Also agree how the connection is secured, and whether it crosses between the building network and the internet.
Which points, with which names?
Produce a points list before integration starts. For each point, record:
- A name that follows the building's existing naming convention.
- Units, range and how often it updates.
- Whether it is read-only or can be written.
- Which alarms it should trigger, and at what thresholds.
A consistent naming scheme makes the data usable for years, long after the project team has left.
How fast, and what if it fails?
Agree the timing the BMS really needs. Many building decisions can work with data that is a few minutes old; control loops may need faster updates. Then define what happens when data stops:
- What value or state the BMS uses when data is missing.
- Whether plant falls back to a schedule or a safe default.
- How the loss of data is alarmed, and to whom.
How will we prove it works?
Write acceptance tests before installation. Test each point end to end, from the device to the BMS screen and any control action, including alarms, data loss and recovery. Sign off the tests jointly, so that every party agrees the integration is complete.