Distech ECLYPSE and Trend IQ controllers can talk over BACnet, but rarely do straight out of the box. Both support BACnet/IP and BACnet MS/TP, yet on site they fail to exchange data because of mismatched network numbers, MS/TP baud rates, Device Instance clashes, unexposed objects, and missing BBMDs. Fix the network design and the conformance, not the protocol.
Here is the scene we walk into more often than we would like. A consultant has specified an open, multi-vendor BMS. The mechanical contractor has fitted Distech ECLYPSE controllers on the new AHUs and FCUs, and the existing Trend estate — IQ4 and a few older IQ3 boxes — is staying put on the floors that were not touched. The data sheets all say BACnet. The handover meeting is next week. And right now nothing is talking to anything. The Trend supervisor cannot see the Distech points, the Distech head-end cannot read the Trend zones, and the integrator is blaming the controls company who is blaming the network. Both products genuinely support BACnet. So why is the graphic still full of question marks?
They speak the same protocol, but "supports BACnet" is not one capability — it is a stack of them, and the two manufacturers expose different parts of that stack by default. BACnet is defined by BS EN ISO 16484-5 (also published as ASHRAE Standard 135), which sets out the object model, the services, and the network layers. Two devices can both be fully compliant and still refuse to exchange a single value, because compliance does not mean they have been configured onto the same network in the same way.
Distech ECLYPSE is a BACnet/IP-native platform. It is built around IP from the ground up, programmed in Distech's ECLYPSE / EC-gfxProgram and Niagara-adjacent tooling, and it expects to live on an Ethernet network exposing BACnet objects over BACnet/IP. Trend, by contrast, comes from a long heritage of its own internal network — the Trend current-loop and Ethernet "local supervisor" world — and bolts BACnet on as an interface. The IQ4 range exposes BACnet/IP and BACnet MS/TP, but historically the BACnet interface on a Trend system has been a layer over the native Trend protocol rather than the controller's mother tongue. That difference in heritage is exactly where the friction comes from: one device treats BACnet as home, the other treats it as a translation.
Discovery is where most multi-vendor jobs stall, and it is almost always a network-layer problem, not a protocol one. BACnet finds devices using a Who-Is / I-Am broadcast exchange. On a single flat IP subnet that works fine. The moment the Distech controllers and the Trend controllers sit on different subnets or different VLANs — which on a real building network they usually do — those broadcasts stop at the router and discovery dies.
The fix is a BBMD — a BACnet Broadcast Management Device — configured on each subnet, with a correctly populated Broadcast Distribution Table so broadcasts are forwarded between subnets. Get one BBMD entry wrong, or run two BBMDs on the same subnet, and you get duplicate I-Ams, missing devices, or a network that half-works then drops out under load. The other classic showstopper is the BACnet network number. Every BACnet network segment needs a unique network number, and if the Distech side and the Trend side were each commissioned in isolation, both teams may have used the same number — or left it at a default. Two segments sharing a network number is illegal in BACnet and the routers will not stitch them together. We also routinely find Device Instance clashes: the Device Object Instance number must be unique across the entire internetwork (0 to 4194302). If a Trend controller and a Distech controller both ended up as Device 1001, one of them simply disappears from the other's device list.
Plenty of these jobs are not pure IP. Where Trend or Distech field controllers sit on a BACnet MS/TP trunk over RS-485, the failure modes shift from IP to serial — and they are unforgiving. MS/TP is Master-Slave/Token-Passing, and for the token to pass cleanly every device on the trunk must agree on the baud rate (commonly 9600, 19200, 38400 or 76800), and each must have a unique MAC address on that segment. One controller set to the wrong baud rate, or two sharing a MAC, and the token gets lost, devices go offline intermittently, and you chase a fault that moves around the bus.
Then there is the physical layer, which is where good intentions go to die. RS-485 wants a proper daisy-chain — in, out, in, out — not a star and not spurs. It needs the correct end-of-line termination (typically 120 ohm) at both ends of the trunk and nowhere else, screened cable with the screen earthed at one point only, and consistent polarity. We have lost count of the trunks we have found wired as a star off a junction box, with termination resistors fitted at every controller "to be safe," reflections bouncing up and down the line, and a comms fault that everyone blamed on the BACnet "not being compatible." It was never the protocol. It was the cable.
We'll assess your controls and provide a detailed quotation.
This is the document that separates engineers from box-fitters. Every BACnet device has a PICS — a Protocol Implementation Conformance Statement — and a BIBB list (BACnet Interoperability Building Blocks) that spell out exactly which services the device performs and whether it acts as a client (initiates requests) or a server (responds to them) for each one. "Supports BACnet" on a brochure tells you nothing. The PICS tells you whether the device can do DS-RP-A (read another device's property), DS-WP-A (write to it), AE-N (issue alarms), SCHED-E (act as a schedule client), and so on.
Here is the trap on a Distech-and-Trend job. If the Trend interface is configured to serve objects but not to read from the Distech side, and the Distech head-end is expecting to be read rather than to read, you get a standoff: both are waiting to be asked. The data is technically exposed on both sides and still nothing flows, because nobody is configured as the client for that exchange. You also have to check that the points you actually need are exposed as BACnet objects at all — on Trend in particular, an internal value, a calculated point, or a parameter inside a module is not automatically a published BACnet object. If it has not been mapped and given an Object Identifier, it does not exist as far as the Distech supervisor is concerned. Read both PICS statements before you cable anything. It is fifteen minutes that saves a fortnight.
The pattern is depressingly consistent. The two systems are commissioned by two different parties who never sat in the same room. The Distech installer commissions IP, sets a network number, picks Device Instances, and exposes their objects. The Trend installer does the same in isolation. Neither agrees an addressing scheme, a network-number plan, or who is BBMD on which subnet. They meet for the first time at integration, discover the clashes, and the programme has no time left to resolve them properly — so somebody bodges in a third-party gateway to force the two halves together.
That gateway is the symptom of a design that should never have needed one. It adds a point of failure, it adds a licence cost, it adds a box nobody documents, and it usually maps a fraction of the points "to get the handover signed." Eighteen months later the FM team cannot trend a space temperature that lives on the wrong side of the gateway, the alarms do not propagate, and the "open" system the client paid for is quietly proprietary again. The deeper cost is commercial: when the integration is undocumented, the building owner is locked to whoever did the bodge. BSRIA BG 11/2010 (Soft Landings) exists precisely to stop this — it pushes for the integration strategy and the responsibilities to be nailed down early and for proper aftercare, rather than discovered in the last week before handover.
Good looks boring, and boring is the goal. Before a single controller is addressed, there is one agreed BACnet network design covering both vendors: a network-number plan with no duplicates, a Device Instance allocation table so nothing clashes across the whole internetwork, a BBMD plan naming which device manages broadcasts on each subnet, and — for MS/TP trunks — a baud rate and MAC address schedule. Both manufacturers' controllers are BTL-listed (verified by BACnet Testing Laboratories against BS EN ISO 16484-5), so their conformance is independently checked rather than taken on trust.
The integration is done natively over BACnet/IP wherever possible — Distech reading the Trend objects it needs and Trend reading the Distech objects it needs, client and server roles agreed point by point against the PICS statements — with no third-party gateway unless there is a genuine reason one cannot be avoided. The required points are explicitly exposed as named BACnet objects on both sides, with sensible Object Names and engineering units, so the supervisor and any future contractor can discover and read them without a translation document. And the whole lot is documented: the network-number plan, the Device Instance table, the BBMD configuration, the MS/TP schedule, and a points list mapping every cross-vendor value. CIBSE Guide H recommends BACnet at all network levels for exactly this reason — so the building is not quietly locked in behind a partial implementation. When we integrate a Distech ECLYPSE front end with a retained Trend IQ estate, this is the package the client gets and keeps.
Sort it at design stage. The cheapest time to agree a network-number plan and a Device Instance scheme is before anyone has powered up a controller; the most expensive time is the week before handover with two installers pointing at each other. If you are writing the specification, state BACnet/IP at all network levels, require BTL-listed controllers from both vendors, require the BACnet network design as a deliverable, and name a single party responsible for the cross-vendor integration. That one paragraph prevents the gateway bodge before it can happen.
If you have already got a building where the Distech and Trend halves will not talk, it is not too late — but stop adding gateways and start with a survey. The fault is almost always discoverable: a duplicate network number, a Device Instance clash, a missing BBMD entry, a points list that was never exposed, or an RS-485 trunk wired as a star. Find the actual cause and the integration usually comes back without new hardware.
BACnet is not the problem, and these two systems are not incompatible. They fail to interoperate when the network is designed by two people who never spoke — clashing network numbers and Device Instances, missing BBMDs, mismatched MS/TP settings, a star-wired RS-485 trunk, and points that were never exposed as BACnet objects. Get the network design right, read both PICS statements, agree client and server roles point by point, and the Distech ECLYPSE and the Trend IQ controllers will share data natively, with no gateway and no lock-in.
Alpha Controls integrates multi-vendor BMS estates — Distech ECLYPSE, Trend IQ3 and IQ4, and others — over native BACnet, and untangles the half-talking, gateway-bodged systems that other contractors leave behind. Get in touch or request a quote and we will survey the network and tell you exactly why it is not talking.
Yes, when the network is designed for it. Both support BACnet/IP, but the Trend points must be exposed as named BACnet objects, the two sides must share a coherent network-number and Device Instance scheme, and the client and server roles must be agreed against each device's PICS statement. With that in place, the ECLYPSE can read the Trend objects natively.
Discovery uses Who-Is and I-Am broadcasts, which do not cross routers between subnets or VLANs. If the two vendors sit on different subnets without a correctly configured BBMD on each, discovery fails. Duplicate BACnet network numbers or clashing Device Instance numbers will also stop devices appearing in each other's lists.
Usually not. A third-party gateway is normally a symptom of a network that was commissioned in isolation by two parties. With a single agreed BACnet design and the right objects exposed on each side, the two systems integrate natively over BACnet/IP without extra hardware, which avoids the licence cost and the lock-in that gateways create.
A PICS (Protocol Implementation Conformance Statement) lists exactly which BACnet services a device performs and whether it acts as a client or server for each one. It matters because two devices can both "support BACnet" yet fail to exchange data if neither is configured as the client for the read or write you need. Checking both PICS statements first prevents that standoff.
MS/TP problems are usually physical or addressing related. Every device on the trunk must share the same baud rate and have a unique MAC address, or the token gets lost. The RS-485 cabling must be a proper daisy-chain with 120 ohm termination only at the two ends, screened cable earthed at one point, and correct polarity. Star wiring and termination at every device are common causes of intermittent dropouts.
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
