When you inherit a Distech BMS, expect a flood of standing alarms, time schedules nobody has touched in years, login credentials that left with the last contractor, and graphics that no longer match the plant. Your first job is not fixing controls. It is getting documentation, alarm priorities, schedules, and trend data back under control before anything else.
You sit down with the system for the first time and find 300 alarms, half the schedules haven't been touched since 2021, and the only person who knew the password left the maintenance contractor eighteen months ago. That is the normal starting point for an inherited Distech estate, and it is not a sign the system is broken. It is a sign the system has been running open-loop, with nobody reading what it has been trying to tell them. The good news is that a Distech ECLYPSE platform is genuinely capable once you can see into it. The bad news is that everything you need to see is buried, and the people who buried it are gone.
What is a Distech BMS and how is it actually built?
Distech Controls makes building automation hardware and software, and on most UK commercial sites you will have inherited their ECLYPSE range. The ECLYPSE connected controllers (the ECB series for plant and the ECY series as supervisory or connected room controllers) are BACnet-native devices that talk over BACnet/IP and BACnet MS/TP. Below them you often find ECB-PTU room controllers and Allure series wall sensors. Above them sits a supervisor, frequently Distech's own ENVYSION or EC-Net (a Niagara Framework variant), or a third-party head-end pulling everything together over BACnet/IP.
This matters because the way the system is layered decides what you can and can't get at. If your graphics live in EC-Net or ENVYSION and you've only inherited a username for the front end, you may have no engineering access to the controllers themselves. The BACnet objects are all still there, broadcasting away on the network, but the logic, the schedules and the alarm setup are locked behind tool-level credentials you don't have. Knowing whether you hold operator access or engineering access is the single most useful thing to establish on day one.
Why do inherited Distech systems have hundreds of standing alarms?
Alarm floods are almost never a sudden fault. They build up over years because nobody owns the alarm list. A sensor fails, it goes into alarm, nobody acknowledges it, and it sits there. A valve gets overridden to hand for a one-off and never gets put back, so its feedback alarm chatters forever. A boiler gets decommissioned but its points stay configured, so it alarms permanently as offline. Multiply that across a few hundred points and a few years and you get a screen that is useless because everything is red.
The problem with a flooded alarm list is not the noise itself, it is that a real, dangerous alarm, a frost coil at risk, a critical pump tripped, a fire damper showing closed, hides in the middle of three hundred nuisance ones and nobody sees it. BS EN ISO 16484-1, the standard for building automation and control system design, is clear that alarms should be prioritised and managed so operators can act on the ones that matter, not drowned in undifferentiated noise. An inherited Distech system almost always fails that test on day one. The fix is not technical wizardry. It is going through the list point by point, deciding what is genuinely critical, what is informational, and what is dead, and rebuilding alarm priorities and routing around that.
What documentation should come with a Distech BMS handover?
In theory, a proper handover gives you points lists, controller schedules, network architecture drawings, a copy of the controller programs or backups, valid login credentials at engineering level, and an as-installed description of the control strategy. BSRIA's Soft Landings framework (BG 54/2018) exists precisely because this handover is so routinely botched, it pushes for the people who will operate the building to be involved before completion and for documentation and training to be treated as deliverables, not afterthoughts.
In practice, with an inherited system, you usually get a folder of out-of-date drawings and a verbal assurance that "it's all in the system." What you actually need to recover is a current points list straight off the live BACnet network, a backup of every controller's configuration, and the engineering credentials to make changes. Until you have controller backups, you are one power surge or one corrupted device away from losing logic that nobody documented and nobody can recreate from memory.
We'll assess your controls and provide a detailed quotation.
Time schedules are where inherited systems quietly waste money. On a Distech system schedules can live in the controllers themselves, in the supervisor, or in a mix of both, and that split is where it goes wrong. Someone edits a schedule at the head-end, but a local controller schedule still runs the plant on its own clock, so the AHU starts at 5am for a building nobody occupies before 8. Optimum start gets disabled during a fault and never re-enabled, so the plant runs flat out from cold instead of learning the building's warm-up time. Approved Document L of the Building Regulations expects buildings to have effective time and temperature control and features like optimum start and weather compensation, and a system running on stale schedules is quietly in breach of the spirit of that, as well as burning energy every single day.
Trend logs are the other casualty. A Distech controller will happily log data, but trends have to be configured and they consume memory. On an inherited system you often find trends were set up for commissioning, then never reviewed, so you either have no historical data at all or you have logs that filled up and stopped years ago. Without trend data you are flying blind: you cannot prove a space is overheating, you cannot show a pump is short-cycling, and you cannot build a case for any improvement work. Getting meaningful trends running again is one of the highest-value early moves on any inherited estate.
The temptation is to start fixing things on day one. Resist it. The plant has been running in some fashion, and a clumsy change to a schedule or a setpoint you don't fully understand can knock out heating to a floor or trip a chiller. The disciplined approach is to survey before you touch. Establish what access you really have, pull a live points list off the BACnet network, back up every controller, and only then start triaging.
Triage in a sensible order. First, deal with anything safety-related: frost protection, fire and smoke interfaces, critical plant. Then attack the alarm flood, because until that list is meaningful you cannot trust anything it tells you. Then schedules and optimum start, because that is where the energy savings and comfort complaints both live. Trends come alongside, because they give you the evidence for everything that follows. What good looks like at the end of this is a system where a red alarm actually means something, where the plant runs to the building's real occupancy, and where you have backups and documentation that would let someone else pick it up tomorrow if they had to.
Some of this you can do in-house if you have the access and the time. Plenty of it you can't. If you've inherited only operator-level credentials, you physically cannot edit controller logic, reconfigure alarms at source, or re-point a corrupted device without engineering tools and licences, and that is the point to bring in a controls contractor with genuine Distech experience. The same applies when the supervisor is an EC-Net or Niagara head-end nobody on site understands, or when you suspect the as-installed strategy no longer matches the plant after years of patches and part-replacements.
A good specialist does not just "clear the alarms." They recover the documentation, back up the system properly, rebuild the alarm strategy around real priorities, sanity-check the schedules and optimum start against actual occupancy, and hand you something you can run. That is the difference between paying for a visit and buying back control of your building.
Inheriting a Distech BMS is not a disaster, it is a recovery job, and recovery jobs go well when you do them in the right order. Get your access and documentation sorted, back everything up, make the alarm list mean something again, then fix the schedules and trends that are quietly costing you money and comfort every day. Do that and a system that looked like a wall of red on day one becomes a genuine asset you can actually operate.
If you've taken on a Distech estate and the alarm list, the schedules or the missing credentials are getting away from you, get in touch with Alpha Controls and we'll help you get it back under control, or request a quote for a full handover health-check.
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
