Building Automation Integration Services

A building rarely runs one vendor’s equipment. It runs whatever was installed over twenty years: BACnet controllers from one era, Modbus meters from another, a LonWorks legacy wing, and increasingly cloud and IoT systems that expect MQTT. Building automation integration is the work of making all of it one coherent system.

Protocols We Integrate

  • BACnet — IP and MS/TP, with proper object mapping rather than raw point dumps.
  • Modbus — TCP and RTU, with the register scaling and byte-order care that decides whether values are correct or merely plausible.
  • LonWorks — legacy estates that still run critical plant.
  • MQTT — edge, IoT and cloud-bound telemetry.
  • SNMP and oBIX — network equipment and enterprise interoperability.
  • Project Haystack tagging — so the data means something to software, not just to the person who mapped it.

Where Integrations Go Wrong

Almost never at the protocol level. They go wrong in the details: a Modbus register scaled incorrectly so a reading looks reasonable and is wrong, a naming convention nobody documented, points mapped without units, or a structure that made sense to the integrator and to nobody since.

We integrate to a convention, document it, and tag the data so analytics and any future AI layer can actually use it. The argument for that groundwork is set out in BACnet vs Modbus and Project Haystack and semantic tagging.

If the network itself is misbehaving — duplicate device IDs, broadcast storms, timeouts — our sister practice covers BACnet and OT network diagnostics.

Tell us what equipment needs to come together and we will scope the integration properly.

Related services

What a Site Survey Turns Up Before Any Driver Is Configured

Integration starts with an inventory, and the inventory is rarely what the drawings say. Controllers get replaced, panels get repurposed, and a wing the documentation still calls LonWorks may have been converted by a contractor who left no record. The survey establishes what is actually on the wire: device addresses, firmware and protocol revisions, which systems are already polling the equipment, and who holds the credentials.

That last item is the one to settle first. A chiller behind a locked vendor gateway can hold a project still while every technical question is already answered. A fire alarm panel is a different case again, and not a commercial one: interfacing to a fire alarm system is governed by code and listing requirements and by whoever holds the fire alarm license, so it is scoped as its own conversation with the people who own that system. Both are far better found during discovery.

  • A device list, with a check that each device answers on the address the drawings claim
  • Existing polling, since another front end sharing an MS/TP trunk consumes part of the poll budget you were counting on
  • Firmware and protocol revision per device, because object and register support varies between them
  • Physical layer notes for serial trunks: topology, termination, and where the trunk was extended over the years
  • Ownership: who can grant access to each system, and what change process they follow

Native Driver or Protocol Gateway?

Gateways are sometimes the sensible answer. When a device speaks something proprietary with no Niagara driver available, or when only a handful of such devices exist, a gateway presenting them as Modbus or BACnet gets the job done without a development cycle. The trade is metadata. Gateways tend to flatten object names, units, alarm state and priority handling into bare registers, and you inherit a second box to power, patch and diagnose at three in the morning.

A native driver keeps the richer model and removes a hop. It tends to win when the device population is large enough that the mapping effort repeats across sites, when the protocol carries state that the gateway discards, or when the integration has to survive equipment being swapped. Custom driver work is covered on the Niagara Framework Development overview, and the Modbus, MQTT and SNMP pages set out what each of those protocols asks of an integration.

Conventions Get Applied at Mapping Time

Renaming a point is trivial before anything depends on it and turns into coordinated rework once histories, alarms, graphics and reports are bound to it. The naming and tagging convention therefore gets agreed before mapping begins, applied to every device in the job, and written somewhere the next engineer will actually find it. Units belong on each point at creation. A dimensionless number that happens to be degrees Fahrenheit will eventually be read by somebody who assumes Celsius.

How an Integration Gets Verified

Verification compares what the station shows against what the device shows, at the source. For analog values that means reading the meter face or controller display while the station is polling. For controllable points it means writing at the intended priority level and confirming both the device response and the release behavior when the write is removed.

Failure behavior is tested deliberately: disconnect the network, power down a gateway, and watch what the station reports. A point that silently holds its last value is a future incident, because an operator will read a stale number as a live one. No test plan covers every case, and a full season of operation can still surface something. The aim is to remove the predictable failures and leave a written record of what was checked, so anything unpredictable can be diagnosed against a known baseline.

When Integration Is Not the Answer

If the estate is single-vendor, the existing front end works, and nobody is asking for cross-system reporting, adding a Niagara layer may buy you very little. If the requirement is one report for one audit, an export from the incumbent system can be enough.

Integration earns its place when several systems have to be compared side by side, when a vendor front end is being retired and the data has to outlive it, when meters and equipment need to share one model for energy work, or when analytics and tagging are on the roadmap. Project Haystack and semantic tagging describes what that model needs to look like.