BACnet
BACnet integration in Niagara is usually straightforward – until it is not. Software Pile handles both ends: standard BACnet/IP and MS/TP integration through Niagara’s native driver, and the awkward cases where devices expose non-conformant objects, proprietary properties, or firmware quirks that break discovery.
Standard BACnet Work
Device discovery and point mapping, alarm and history configuration, COV subscriptions tuned so the network is not flooded, priority-array behavior that matches how the building is actually operated, and BACnet export of Niagara points so third-party front ends can consume them.
When the Native Driver Is Not Enough
Some equipment speaks BACnet in name only. For proprietary properties, vendor-specific services, or segmentation problems, we extend integration at the Baja level: custom proxy points, tuned polling, and translation layers that make nonstandard devices behave like citizens of the station. Where a device needs a full custom driver, that is core work for us.
Scoping a BACnet Project
Useful things to have ready: device counts and models, network topology (IP vs MS/TP segments), your Niagara version, and whether the target is a Supervisor or JACE. A PICS statement for problem devices helps; a protocol capture helps more. Send what you have and we will tell you what the integration actually involves.
What Is BACnet?
BACnet is the open communications standard for building automation, and the default protocol for new building systems. It is a full data model rather than a simple register map: BACnet devices expose objects with properties, and the standard covers alarming, scheduling, trending and device discovery as well as reading and writing values.
That richness is why BACnet integration is generally less work than Modbus for equivalent equipment. The meaning travels with the data instead of living in a separate mapping spreadsheet.
What Is the Difference Between BACnet/IP and BACnet MS/TP?
They are the same protocol over different physical layers, and the distinction has real operational consequences:
- BACnet/IP runs over standard Ethernet and IP networking. Fast, and it uses infrastructure the building already has — which also means it is subject to IT network policy, VLANs and firewalls.
- BACnet MS/TP runs over RS-485 serial twisted pair. Much slower and limited in devices per segment, but inexpensive to run to field equipment and still extremely common on terminal units.
Most real estates are both: MS/TP out to the field devices, IP for the backbone, with routers between. Performance complaints in BACnet systems very often trace to MS/TP segments being polled as though they were IP.
What Are BACnet Objects and Properties?
A BACnet device presents objects — analog inputs, analog outputs, binary values, schedules, trend logs, and others. Each object has properties: its present value, units, description, status flags, alarm limits and more. Reading a temperature means reading the present-value property of an analog-input object.
Status flags are the part most often ignored and most worth using. They tell you whether a value is in fault, out of service or overridden. An integration that reads present value without checking status will faithfully report the last good reading from a failed sensor.
Why Do BACnet Integrations Go Wrong?
- Over-polling MS/TP. The most common cause of a “slow BMS”. Poll rates must match the segment, not the ambition.
- Duplicate device instance numbers. Must be unique across the network; duplicates cause intermittent faults that are miserable to diagnose.
- Partial vendor implementations. Equipment that claims BACnet compliance but omits or misimplements parts of it. Test against the device, not the datasheet.
- Ignoring priority arrays. BACnet has a defined command-priority mechanism. Writing at the wrong priority, or never releasing a command, leaves equipment stuck in override — often for months.
- Discovery on a live network without agreement. Broadcast-heavy discovery can disturb a production control network.
BACnet Security
BACnet was designed for isolated control networks, and much of the installed base has little or no authentication. When those networks become reachable from the business network — which is usually how integration projects end — that assumption no longer holds.
Treat network position as the primary control: segment the control network, restrict what crosses the boundary, control and review remote access, and monitor. This is a large part of what an integration project should address rather than leave to someone else.
Related services: BAS and BACnet integration services · custom driver development.