Cause and effect is one of the most important parts of a modern fire alarm system.

It is also one of the parts most commonly misunderstood.

On a simple system, the required response may genuinely be little more than:

Fire detected → sound the alarms.

But once a fire alarm starts interacting with smoke control, lifts, access control, fire doors, plant shutdowns, suppression systems, sprinkler monitoring or other building services, cause and effect becomes a fundamental part of the building's overall fire strategy.

Yet it is still surprisingly common to see it treated as something to be worked out while programming the fire alarm panel.

That is where problems start.

1. Starting with the fire alarm panel instead of the fire strategy

One of the biggest mistakes is opening the programming software and asking:

"What should this detector operate?"

That question is already backwards.

The required operation should have been determined before the system is programmed.

Cause and effect should ultimately derive from the building's fire strategy, system specification, design information and the requirements of other interfaced systems.

The fire alarm panel is simply implementing that strategy.

An engineer should not be standing in front of a panel deciding whether an alarm on Level 7 should open a smoke damper, recall a lift or release a door because nobody else has documented it.

Programming software is not a fire strategy.

BS 5839-1:2025 covers the design, installation, commissioning and maintenance of fire detection and alarm systems in non-domestic premises; the wider required response of a building can also depend on the fire strategy and standards applicable to interfaced systems.

2. Building the entire cause and effect around individual devices

Modern addressable panels make it incredibly easy to create logic based on individual device addresses.

That doesn't mean you always should.

Imagine a protected corridor containing twelve detectors.

If all twelve detectors are intended to produce exactly the same response, programming twelve independent cause-and-effect relationships creates unnecessary complexity.

If detector 34 is replaced, moved or renumbered later, that logic may also need changing.

Where the required response is genuinely based on the fire occurring within a particular area, it is often far cleaner to base the logic around the zone or functional area.

For example:

Fire in Zone 08
    ↓
Operate smoke control for Level 8
Recall designated lifts
Release relevant access-controlled doors
Transmit fire condition to monitoring

rather than:

Detector 81 → Level 8 smoke control
Detector 82 → Level 8 smoke control
Detector 83 → Level 8 smoke control
Detector 84 → Level 8 smoke control
Detector 85 → Level 8 smoke control
...

There are obviously exceptions.

Individual devices or input types may require special treatment. Examples might include detectors within lift shafts, plant rooms, suppression interfaces or other areas with a specific engineered response.

The point isn't that device-level logic is wrong.

The mistake is using device-level logic when the actual cause is the location or function represented by a group of devices.

3. Assuming every fire input means the same thing

A fire signal is not necessarily just a fire signal.

Consider the possible inputs to a large system:

• Automatic smoke detection
• Heat detection
• Manual call points
• Sprinkler flow switches
• Aspirating detection
• Suppression system interfaces
• Beam detectors
• Other specialist detection systems

Depending on the building strategy, different inputs may legitimately require different responses.

A sprinkler flow switch, for example, represents a very different physical event from somebody operating a manual call point.

That doesn't automatically mean it should have different cause and effect, but it means the question should at least have been asked.

Simply placing every input into one enormous GENERAL FIRE group can throw away information that the building's fire strategy could actually need.

4. Treating outputs as individual relays instead of functions

The same problem occurs at the output side.

Engineers often think in terms of:

Output 14 Relay 3 Loop module 67

instead of:

Lift recall Smoke extract Door release AHU shutdown Fire brigade signalling

The first describes the hardware.

The second describes what the system is trying to achieve.

Good cause-and-effect documentation should remain understandable even to somebody who has never seen the programming software.

For example:

Cause	Lift recall	Level smoke control	Door release	Monitoring
Fire – Level 7	Yes	Level 7	Yes	Yes
Fire – Level 8	Yes	Level 8	Yes	Yes
Fire – Level 9	Yes	Level 9	Yes	Yes

The panel programmer can then translate those functions into physical output modules, network commands or output groups.

That separation matters enormously when equipment is changed later.

5. Forgetting that other systems have their own requirements

A fire alarm interface isn't just a spare relay contact.

The equipment on the other side of that relay may itself form part of a life-safety system.

Common examples include:

• Smoke control systems
• Automatic opening vents
• Fire and smoke dampers
• Door release systems
• Access control
• Lifts
• Mechanical plant
• Gas shut-off systems
• Suppression systems

The fire alarm designer therefore needs to understand what signal the other system requires and what it is expected to do with it.

Interface arrangements for some fire protection equipment are specifically addressed by standards within the BS 7273 series.

A relay changing state does not prove that the required fire safety function happened.

If a fire alarm output is supposed to recall a lift, the meaningful test is not:

"The relay LED came on."

It is:

"Did the lift perform the required operation?"

The same applies to smoke control.

The fire panel saying SMOKE CONTROL OUTPUT ACTIVE means very little if the actual smoke control system hasn't responded correctly.

6. Ignoring the normal condition and failure condition

Engineers naturally concentrate on what happens during a fire.

Cause and effect also needs consideration of what happens when something fails.

What happens if:

• an interface cable is severed?
• an output module loses power?
• a network connection between panels fails?
• a smoke control panel is unavailable?
• the fire alarm CPU carrying the relevant logic fails?
• an external system doesn't acknowledge the command?

The correct answer depends on the system and the interface involved, but these failure modes need consideration during design.

This is particularly important on distributed or networked systems where the device detecting the fire and the panel controlling the required output may be in completely different parts of the building.

7. Forgetting about network boundaries

Networked fire alarm systems create another common trap.

The cause might occur on Panel 1 while the required output physically exists on Panel 4.

Everything works perfectly during local testing:

Panel 4 detector
    ↓
Panel 4 output

But nobody properly verifies:

Panel 1 detector
    ↓
Fire alarm network
    ↓
Panel 4 logic
    ↓
Panel 4 output

This matters particularly on large residential developments, campuses and multi-building systems.

A cause-and-effect matrix should describe the required operation of the system as a whole, not merely what happens locally on each control panel.

Network configuration is part of the signal path.

8. Creating clever logic nobody can maintain

Modern fire alarm panels can perform some extremely complicated logic.

Multiple input groups.

Coincidence detection.

Timers.

Disablements.

Conditional outputs.

Day/night modes.

Dependencies.

Network logic.

The temptation is to be clever.

Don't be clever unless the fire strategy actually requires it.

A system that needs three pages of Boolean logic to explain why an AOV should open is going to be an absolute nightmare for somebody to fault-find five years later.

Cause and effect should generally be as simple as the required fire strategy allows.

Complexity creates more opportunities for:

• programming mistakes;
• undocumented dependencies;
• commissioning errors;
• maintenance errors; and
• unintended behaviour following future modifications.

If the logic cannot be explained clearly, that is often a warning sign.

9. Copying cause and effect from the previous system

This one deserves special mention.

During a panel replacement or system upgrade, engineers will often inherit an existing configuration.

The old panel operated Output X when Zone Y went into fire, so the new panel gets programmed to do exactly the same thing.

Job done.

Except nobody has established why.

The old programming might already have been wrong.

The building may have changed.

Smoke control may have been modified.

Lift controls may have been replaced.

A door that once released may no longer exist.

A compartment may have been altered.

An undocumented temporary programming change made eight years ago may have quietly become the "design".

Existing programming is useful evidence.

It is not automatically design information.

10. Commissioning the components instead of the cause and effect

This is perhaps the most important one.

You can test every detector.

You can test every interface.

You can test every relay.

And still have a system whose cause and effect is wrong.

Why?

Because component testing proves that the pieces work.

Cause-and-effect testing proves that they work together in the required sequence.

If a Level 12 detector operates, does the correct smoke control response occur?

Does the lift respond?

Do the required doors release?

Does monitoring receive the correct signal?

Do unrelated floors remain in their intended state?

If the activation comes from a different panel on the network, does everything still happen?

This is why a cause-and-effect matrix is so valuable during commissioning.

It gives the engineer something objective to test against.

Without it, commissioning can quickly become:

"It looks about right."

For a life-safety system, about right isn't a particularly useful test result.

11. Never updating the cause-and-effect matrix

Finally, cause and effect shouldn't disappear into a commissioning folder and never be seen again.

Buildings change.

Tenants change.

Plant changes.

Doors change.

Smoke control systems are refurbished.

Fire alarm systems are expanded.

Outputs get moved.

Devices get replaced.

If the cause-and-effect documentation is not maintained alongside those changes, eventually the programming and the documentation stop describing the same building.

At that point future engineers are effectively reverse-engineering the fire strategy from somebody else's panel configuration.

That is not where you want to be.

A better approach

For anything beyond a very simple system, the workflow should look more like this:

1. Establish the required fire strategy and system specification.
2. Identify the meaningful causes - zones, areas, input types and any genuinely special individual devices.
3. Identify outputs by function, not merely by module address.
4. Create the cause-and-effect matrix before programming.
5. Coordinate the matrix with other life-safety systems and relevant specialists.
6. Translate the approved matrix into panel programming.
7. Commission the completed system against the matrix.
8. Verify interfaced equipment actually performs its required function.
9. Retain and update the matrix as controlled system documentation.

The fire alarm panel should be the implementation of the cause and effect.

It should not be where the cause and effect is invented.

Cause and effect should tell the story of the building

A good cause-and-effect matrix should allow another competent engineer to look at it and understand what the building is expected to do when a fire occurs.

They shouldn't need the original programmer standing beside them.

They shouldn't need to reverse-engineer hundreds of output groups.

And they certainly shouldn't have to guess why an output operates.

Ultimately, cause and effect isn't about making relays click.

It's about coordinating the building's response to fire.

Treating it as merely a programming exercise is how technically functional systems end up behaving completely differently from the way the fire strategy intended.