Choose Modbus RTU over RS-485 for most UK leak detection installations, because virtually every panel supports it and it carries zone-level alarms, location, and cable diagnostics. Use BACnet MS/TP when the BMS is BACnet-native, so leak data appears as native objects. Treat volt-free relay contacts as a last resort.
A leak detection system that cannot talk to the BMS is a standalone alarm box sitting in a plant room, and standalone alarm boxes get ignored. Every facilities manager has inherited at least one system where the leak sensors are technically working but nobody finds out about an event until water is already pooling across a slab or dripping through a ceiling tile into a comms cabinet. The root cause is almost never the sensor. It is the protocol layer, the decision about how the leak detection panel communicates with the building management system. Get this wrong and you end up with a system that detects water perfectly but tells nobody who matters, logs nothing useful, and provides zero data for trending or compliance reporting.
The frustrating part is that the protocol decision is usually made too late. It gets left to the installing contractor, who picks whatever cable they have on the van or whatever the panel's default output happens to be. By the time the FM team takes over, the integration is either a single volt-free relay wired to one BMS digital input, giving you nothing more than “alarm” or “no alarm”, or a Modbus connection where the register map was never configured and the BMS is polling addresses that return zeroes.
This is fixable. But it requires understanding what each protocol actually offers for leak detection integration and choosing deliberately based on the existing BMS platform, the site's physical infrastructure, and what the FM team actually needs to see on their screens.
Protocol selection for leak detection is the communication method between the leak detection panel (the controller that monitors the sensing cables or point sensors) and the BMS head-end or outstation. The panel detects the water. The protocol determines what information reaches the BMS, how quickly it gets there, and how much detail it carries.
At the most basic level, every leak detection manufacturer — Andel, TTK, CMR, RLE Technologies, TraceTek, Aqualeak — supports at least one form of digital communication and a set of volt-free relay contacts. The difference between a useful integration and a useless one comes down to which method you choose and whether the BMS engineer who commissions it actually maps the data points properly.
There are six protocols you will encounter in UK commercial leak detection installations, and each one has a specific use case where it makes the most sense.
Modbus RTU over RS-485 is the most common protocol in the leak detection world. Virtually every panel on the market supports it. It uses a simple master/slave polling architecture where the BMS outstation (the master) requests data from the leak panel (the slave) at regular intervals. The data is register-based, which means you need the manufacturer's register map to know which address contains the zone alarm status, which contains the cable resistance value, and which tells you the leak location in metres along the sensing cable. Andel's Multipoint range, TTK's FG-SYS, CMR's LD32, and RLE's SeaHawk controllers all speak Modbus RTU natively. For the majority of UK leak detection installations — plant rooms, risers, ceiling voids, under raised floors — Modbus RTU over a twisted-pair RS-485 bus is the pragmatic choice. It works, it is well understood by most BMS engineers, and it carries enough data to give you zone-level detail, alarm severity, and cable diagnostics.
Modbus TCP over Ethernet is functionally the same protocol but transported over IP rather than a dedicated RS-485 bus. This matters when the leak detection panel is physically remote from the BMS outstation — in a different plant room, on a different floor, or even in a different building on the same campus. TTK's FG-NET controller, CMR's LD32 with Ethernet option, and Andel's HLD range all support Modbus TCP. The advantage is that you can route the data over the building's existing IP network rather than running dedicated RS-485 cabling. The disadvantage is that you now depend on the IT network infrastructure, which introduces switch configuration, VLAN management, and potential latency issues that you do not have with a direct RS-485 connection. For larger systems or sites where remote monitoring is a priority, Modbus TCP is the right call, but you need the IT team involved early.
BACnet MS/TP over RS-485 is the native BMS protocol. If the building management system is BACnet-based — Trend IQ4, Distech ECLYPSE, Siemens Desigo, Honeywell — then integrating the leak detection system over BACnet means the leak data appears as native BMS objects rather than Modbus registers that need to be mapped. RLE Technologies specifically designed their BMS-LD3Z leak detection controller for BACnet MS/TP integration, exposing each zone as a BACnet analogue or binary object that the BMS discovers automatically during a device scan. TraceTek panels can be converted to BACnet via protocol gateways. The advantage is seamless integration: the leak alarms, zone statuses, and diagnostic values appear in the BMS exactly like any other HVAC point. The disadvantage is that fewer leak detection manufacturers support BACnet natively, which limits your product options.
BACnet/IP over Ethernet extends BACnet communication over the IP network. This is less common in dedicated leak detection panels but increasingly relevant in enterprise BMS environments where the entire controls backbone runs on BACnet/IP. Some higher-end controllers and gateways support it, and it offers the same seamless BMS integration as BACnet MS/TP but with the reach of IP networking. For sites with a mature BACnet/IP infrastructure — typically large commercial offices, hospitals, or university campuses — this can eliminate the need for separate MS/TP trunks to serve the leak detection system.
Volt-free contacts (relay outputs) are the universal fallback. Every single leak detection panel on the market provides relay outputs — typically one for alarm, one for fault, and sometimes one for cable break. These wire directly to digital inputs on the BMS outstation with no protocol configuration required. The BMS sees a contact closure and generates an alarm. This is the simplest integration method and the one that gets used when nobody has planned the protocol layer properly. The problem is that relay contacts carry almost no information. You get “leak detected” or “no leak detected.” You do not get which zone triggered, where along the cable the water was found, what the cable resistance is, or any trending data. For a small system with one or two zones in a single plant room, volt-free contacts may be adequate. For anything larger, they are a compromise that will cost you in diagnostic capability.
SNMP (Simple Network Management Protocol) is the data centre protocol. If the leak detection system lives in a server room or data hall and needs to integrate with a DCIM (Data Centre Infrastructure Management) platform rather than a traditional BMS, SNMP is the standard approach. RLE Technologies, CMR, and TTK all offer SNMP support on their enterprise-grade controllers. SNMP traps push alarm events to the monitoring platform in near real-time, and SNMP polling retrieves status and diagnostic values. This is the right protocol when the building is a data centre and the monitoring platform is Schneider StruxureWare, Nlyte, or a similar DCIM tool, but it has no role in a conventional BMS integration.
The protocol you choose determines three things that FM teams care about deeply: the quality of alarm data, the ability to trend and report, and the speed of fault diagnosis.
A building management system receiving Modbus or BACnet data from a leak detection panel can display zone-specific alarms (“Zone 3 — Plant Room B — Leak detected at 14.2 metres along cable”), log the event with a timestamp and zone identifier, trend cable resistance values to spot degradation before a false alarm occurs, and distinguish between a genuine leak, a cable fault, and a system error. That information flows into the BMS alarm management workflow, gets emailed to the FM team, and creates a documented audit trail for compliance purposes.
The same system wired on volt-free contacts gives you “DI47 — Leak Panel Alarm — ON.” That is the entire picture. No zone, no location, no diagnostics, no trending. When the panel has forty zones of sensing cable across three floors of a data centre, a single relay contact telling you “something happened somewhere” is operationally worthless. The FM engineer still has to walk to the panel, read the local display, and work out what triggered and where. That defeats the purpose of BMS integration entirely.
The protocol decision also affects your ability to satisfy BREEAM leak detection requirements, where evidence of alarm logging, response sequences, and system monitoring strengthens the submission. A BMS trend log showing timestamped zone alarms and response actions is far more compelling to a BREEAM assessor than a statement that the system has relay outputs.
The most common failure on site is a Modbus integration where the register map has not been configured. The BMS outstation has a Modbus master driver loaded, the RS-485 wiring is connected, and the communication link shows “online”, but the BMS is reading default register addresses that the leak panel does not use for anything meaningful. The alarm page shows a permanent healthy state while the panel itself has three active leak alarms that nobody in the FM control room knows about.
The second most common failure is RS-485 bus wiring errors. Modbus RTU over RS-485 requires a specific wiring topology — a daisy-chain bus with 120-ohm termination resistors at each end, correct polarity on the A and B data lines, and a common reference ground. We regularly find sites where the RS-485 bus has been wired as a star topology (which creates reflections and communication dropouts), the termination resistors are missing (which causes intermittent polling failures), or the polarity is reversed on one device (which means it responds to nobody). BS 7671:2018, the 18th Edition IET Wiring Regulations, covers requirements for data communication cabling separation from power circuits, and IEC 61000-4 sets out EMC requirements that become relevant when RS-485 cables run alongside power feeds in cable trays — a situation that causes noise-induced communication errors that are extremely difficult to diagnose without an oscilloscope.
The third failure mode is protocol mismatch. Someone specifies a BACnet BMS, the leak detection contractor installs a panel that only speaks Modbus, and nobody orders the gateway until six months after handover when the FM team asks why the leak alarms are not appearing on the BMS. Protocol gateways (Modbus to BACnet converters like the Intesis or Contemporary Controls BASgateway) work well when properly configured, but they add cost, add a point of failure, and add commissioning time that should have been avoided by specifying the correct panel in the first place.
A subtler problem is polling rate mismatch. Modbus RTU is a polled protocol — the BMS asks, the panel answers. If the BMS is polling every 60 seconds and a leak triggers and self-clears within that window (which can happen with condensation drips), the event never registers. For leak detection, a polling interval of 5 to 10 seconds is appropriate, but sites are often set to 30 or 60 seconds because the BMS engineer copied the polling rate from a meter integration where speed does not matter.
We'll assess your controls and provide a detailed quotation.
BS EN ISO 16484-5, the international standard for BACnet data communication protocols in building automation and control systems (also published as ASHRAE Standard 135), defines the object types, services, and conformance classes that a BACnet device must support. For leak detection integration, the relevant objects are Binary Input (BI) for zone alarm status, Analogue Input (AI) for cable resistance or leak location values, and Notification Class for alarm routing. Any leak detection controller claiming BACnet compliance should publish a PICS (Protocol Implementation Conformance Statement) document that lists exactly which BACnet objects and services it supports. RLE Technologies publishes a PICS for the BMS-LD3Z; if a manufacturer cannot produce one, their BACnet claim should be treated with scepticism. The standard requires that BACnet devices be interoperable — meaning a Trend IQ4 should be able to discover and read objects from an RLE controller without custom mapping — but in practice, interoperability depends on both devices supporting the same BIBBs (BACnet Interoperability Building Blocks), which is why checking PICS documents matters more than checking marketing brochures.
BS EN ISO 16484-6 covers data communication conformance testing for building automation and control networking. This is the testing methodology standard — it defines how BACnet devices are verified for conformance. The BACnet Testing Laboratories (BTL) certification programme uses this standard as its testing framework, and a BTL-listed device has been independently verified to conform to the protocol. When specifying leak detection controllers for BACnet integration, requiring BTL listing is the single most effective way to avoid interoperability problems at commissioning. A device that passes BS EN ISO 16484-6 conformance testing has had its BACnet implementation independently validated; a device that merely claims BACnet compliance has not.
BS EN 61158, the fieldbus standard that covers Modbus among other industrial protocols, defines the data link layer and application layer requirements for serial communication. While most BMS engineers treat Modbus as a de facto standard rather than referencing BS EN 61158 directly, the standard matters when writing specifications because it gives you a normative reference for communication parameters — baud rate, parity, stop bits, frame format — that should be defined in the commissioning specification rather than left for the installer to guess at.
For the wiring layer, BS 7671:2018 Section 528 covers segregation of data communication cables from power circuits. RS-485 cables for Modbus or BACnet MS/TP should maintain separation distances from power cables as specified in Table 52.2, and where separation cannot be maintained, screened cable with earthed screens is required. We see this violated regularly in plant rooms where RS-485 cables are bundled with 230V feeds in the same tray, causing intermittent communication faults.
Alpha Controls was brought in to integrate a leak detection system into an existing Trend IQ4 BMS at a financial services building in the City of London. The building had a ground-floor data suite with under-floor leak detection (sensing cable in the cable void) and three plant rooms with point sensors on risers and manifolds. The original specification called for BACnet MS/TP integration across the board, which would have been the cleanest approach, but the leak detection contractor had already procured CMR LD32 panels configured for Modbus RTU only.
Rather than delay the project by eight weeks waiting for BACnet-native panels or adding gateway cost and complexity, we commissioned the integration using Modbus RTU. We obtained the full CMR LD32 register map, configured the Trend IQ4's Modbus master driver with the correct register addresses for each zone alarm, cable resistance, and leak location value, and set the polling interval to 5 seconds. Each zone appears on the BMS as individual alarm points with meaningful descriptions — “Data Suite Zone 1 — Under-Floor North — Leak Status” rather than “DI47.” The BMS trends cable resistance values weekly so the FM team can spot sensor degradation before it causes a false alarm, and the alarm routing sends zone-specific emails to the facilities management company and the building owner's representative.
The entire Modbus integration added two days of commissioning time beyond what a relay-only connection would have required. The result is a system that gives the FM team full visibility of every zone, full trending capability for compliance reporting, and full alarm detail for diagnostics. A relay-only connection would have given them one binary signal for the entire building, which on a site with fourteen monitored zones across four rooms would have been nearly useless. If you are dealing with a similar integration challenge on an existing BMS, our guide to BMS retrofit costs in the UK covers the commercial side of upgrade projects.
The right protocol depends on the existing BMS platform, and the decision should be made at specification stage, not left to the installing contractor on site.
If the BMS is BACnet-native (Trend IQ4, Distech ECLYPSE, Siemens Desigo PX, Honeywell Spyder) and you have the option to specify a BACnet-native leak detection controller, do it. RLE Technologies' BMS-LD3Z is purpose-built for this. The leak detection zones appear as native BACnet objects, discovery is automatic, and there is no register mapping or gateway to configure. This is the lowest-risk integration path for BACnet sites.
If the BMS is BACnet-native but the leak detection panel is Modbus-only (which covers the majority of panels from Andel, TTK, CMR, and Aqualeak), you have two options. Option one: use the BMS outstation's Modbus master driver to poll the panel directly, which requires RS-485 wiring to the outstation and correct register map configuration. This works well and most modern BMS outstations handle Modbus master duties without issues. Option two: install a Modbus-to-BACnet gateway (Intesis, Contemporary Controls BASgateway) between the panel and the BMS, which converts the Modbus registers into BACnet objects. This adds hardware cost but can simplify the BMS-side configuration, particularly if the outstation does not have a spare RS-485 port.
If the BMS uses Modbus as its native protocol (older Trend 963, some Schneider systems, many smaller packaged BMS platforms), then Modbus RTU is the natural choice. Both the BMS and the leak panel speak the same language, and integration is a matter of wiring, addressing, and register mapping.
For data centres integrating with DCIM platforms rather than traditional BMS, SNMP is the correct protocol. The leak detection controller sends SNMP traps to the DCIM server on alarm events and responds to SNMP GET requests for status polling. This integrates natively with platforms like Schneider StruxureWare and Nlyte.
For legacy BMS systems with no spare communication ports or no protocol driver capability, volt-free relay contacts remain the only option, but this should be treated as a temporary measure with a plan to upgrade, not as the permanent integration strategy. A single relay contact per panel is acceptable only on very simple installations. For anything else, it represents a significant diagnostic blind spot. Our overview of BMS installation costs covers what to expect when upgrading controllers to support proper protocol integration.
If you are specifying a new leak detection system for a building that has a BMS, the protocol decision needs to be in the specification document. Not in the O&M manual. Not as a commissioning afterthought. The specification should state the protocol (Modbus RTU, Modbus TCP, BACnet MS/TP, BACnet/IP), the data points required (zone alarms, cable resistance, leak location, fault status), the polling interval, and the alarm routing requirements. This ensures the leak detection contractor procures a panel that matches the BMS, and the BMS integrator knows exactly what they need to commission.
If you have an existing leak detection system that is integrated on relay contacts only, upgrading to Modbus or BACnet integration is usually straightforward if the panel already has the communication port fitted — many panels ship with Modbus RS-485 as standard but it is simply not connected. The cost is the RS-485 cabling, the BMS commissioning time to set up the driver and register mapping, and the graphics changes to display the additional data points. On a typical system, that is one to two days of BMS engineering time plus cabling.
If you are about to commission a new leak detection installation and the BMS integration has not been discussed, stop and address it now. The cost of adding proper protocol integration during initial commissioning is a fraction of retrofitting it later when the ceiling tiles are back up, the BMS engineer has demobilised, and the defects period has expired.
For sites where leak detection and BMS integration is already planned, verifying the protocol selection against the existing BMS platform before procurement prevents the most common and most expensive integration failures.
Protocol selection for leak detection integration is not a technical footnote — it determines whether your BMS provides full zone-level leak data with trending and diagnostics, or a single binary alarm that tells you nothing useful. Modbus RTU covers the majority of installations well. BACnet MS/TP is the cleanest option for BACnet-native BMS platforms. Volt-free contacts should be the last resort, not the default.
Alpha Controls works with all protocols and advises based on what the existing BMS platform requires, not what a particular manufacturer prefers. Whether you need a new leak detection system specified and integrated, or an existing system upgraded from relay contacts to full Modbus or BACnet integration, get in touch or request a quote and we will recommend the right approach for your site.
Yes. Some panels support both protocols simultaneously — CMR's LD32, for example, can communicate over Modbus RTU to a BMS outstation while also providing relay outputs to a separate alarm panel. However, running both protocols to the same BMS is unusual. The typical scenario is Modbus to the BMS and SNMP to a DCIM platform, or BACnet to the BMS and relays to a local annunciator.
Not necessarily. Most modern BACnet BMS outstations (Trend IQ4, Distech ECLYPSE, Siemens PXC) include a Modbus master driver that can poll Modbus devices directly via an RS-485 port. A gateway is only needed if the outstation lacks a Modbus driver, has no spare RS-485 port, or if you want the leak data to appear as native BACnet objects on the network for third-party access.
Five to ten seconds. Leak detection is a safety system — you need alarms to propagate to the BMS within seconds, not minutes. A 60-second polling interval, which is common for meter readings, is too slow for leak detection. Some leak events (condensation drips, brief overflow events) can trigger and clear within 30 seconds, and a slow poll rate will miss them entirely.
Not always. BACnet is better when the rest of the BMS is BACnet-native because the integration is seamless and does not require register mapping. But Modbus has broader manufacturer support in the leak detection industry, and a well-configured Modbus integration provides the same data quality as BACnet. The “best” protocol is the one that matches your existing BMS platform and is configured correctly.
Wireless leak sensors (such as those from Andel and some IoT providers) typically communicate to a wireless gateway or hub, which then connects to the BMS over Modbus, BACnet, or relay contacts. The wireless element is between sensor and gateway; the BMS integration still happens over conventional wired protocols. The considerations in this article apply equally — you still need to choose the right protocol between the gateway and the BMS.
Specialist BMS installation, commissioning, and maintenance across London and the South East. SafeContractor Approved, BCIA Member.
Our team of building automation specialists is ready to help you optimise your building's performance and efficiency.
Get in Touch
