Protocols & Integration Technologies

Real buildings are never one protocol. A single site might run BACnet chillers, Modbus meters, Lon field devices, SNMP power gear, and an MQTT feed to the cloud – all needing to land in one Niagara station. Software Pile does the multi-protocol integration that ties a mixed building into a single, coherent system.

Protocols We Integrate

  • BACnet (IP and MS/TP) and Modbus (TCP and RTU) – the workhorses
  • MQTT for cloud and IoT, SNMP for IT and power infrastructure
  • LonWorks for legacy field networks, oBIX and REST for enterprise systems
  • Proprietary and OEM protocols via custom drivers when nothing off-the-shelf fits

The Integration Is the Hard Part

Getting each protocol to connect is table stakes. Making them agree – consistent units, coherent naming, sensible alarms, and a data model that survives the next building added – is the real work. That is where a specialist earns the fee.

Send us the protocol mix at your site and your Niagara version. We will scope the integration end to end.

Which Protocol Should a Building Integration Use?

In most cases you do not get to choose — the equipment already installed decides for you, and the job is to integrate what is there. Where there is a choice, on new equipment, the practical hierarchy is straightforward:

  • BACnet is the default for building automation. It carries not just values but objects, alarms, schedules and trends, which means less mapping work and richer integration.
  • Modbus is simple, universal and everywhere, especially on meters, drives and plant equipment. It carries only registers, so all meaning — scaling, units, what register 40001 represents — lives in your mapping rather than in the protocol.
  • LonWorks is legacy but widely installed and still running buildings.
  • MQTT suits telemetry to cloud or analytics platforms; it is a transport pattern rather than a building-data model.
  • oBIX and REST are how building data is usually handed to IT and business systems.
  • SNMP covers IT and power infrastructure — UPS, PDUs, network gear — that increasingly needs to appear alongside building plant.

What Makes Protocol Integration Fail?

Rarely the protocol itself. The recurring causes are mundane and predictable:

  • Scaling and units. A Modbus register returning tenths of a degree read as whole degrees produces plausible, wrong data that can survive for months before anyone notices.
  • Polling that overwhelms the field network. Legacy networks in particular degrade under polling rates that seem reasonable on paper.
  • No defined offline behaviour. A device that goes away should read as a fault, not hold its last value forever while operators trust it.
  • Vendor deviations. Equipment that claims standard compliance but implements it partially or oddly — common enough that testing against the actual device, not the datasheet, is the only reliable approach.
  • Undocumented mapping. An integration only the original engineer understands is a liability the moment they move on.

How Do You Scope an Integration Properly?

Per device type: the protocol and physical layer, the exact points needed in each direction, the units and scaling for each, the read and write requirements, the acceptable update rate, and what should happen when the device is unreachable. That list is unglamorous and it is the difference between an integration that works and one that produces numbers nobody trusts.

It also exposes early whether a custom driver is needed or whether a gateway or a standard driver will do — a decision worth making before, not during, delivery.

Related services: BAS integration services · custom Niagara driver development.