What is centralised ON/OFF control for an impulse relay? It is a second control input — either built into the relay (a dedicated command terminal on ranges like Schneider's iTLc) or added through a separate central command module — that lets one switch position or one BMS contact force every impulse relay on a floor, corridor or whole building to a known ON or OFF state, without removing or rewiring the local push-buttons that operate it day to day. The local circuit keeps working exactly as before; the central command simply overrides it when someone pulls the master switch.
This is the feature that turns a pile of independent impulse relays into a lighting system. A single relay switching a single stairwell doesn't need it. A distribution board carrying twenty relays across four floors does — a caretaker, a security guard or a BMS needs to turn everything off at once, and nobody wants to press forty local buttons to do it. Before choosing hardware, it's worth reading the impulse and latching relay engineering guide for the baseline behaviour this article builds on.
Why Local Control Alone Runs Out of Road
Parallel push-button wiring is the whole appeal of an impulse relay: any number of momentary contacts, wired in parallel across the same coil terminals, toggle the same relay with no interlocking logic. That's covered in detail in the piece on parallel push-button wiring for impulse relays. The limitation shows up the moment a building operator wants a single point of control that doesn't depend on the state anyone left the local buttons in.
Picture an office floor with six impulse relays, one per lighting zone. At 7pm the facilities team wants every zone off. Walking the floor and pressing each local button risks toggling a zone that was already off back on — a momentary relay doesn't know "off," it only knows "pulse." Central control solves that: it drives every relay to a defined state, not a toggle.
Key takeaway: Local push-buttons toggle state; a central command forces state. Mixing the two without the right relay variant or module means the central switch can accidentally undo what it was meant to do.
How the Master Command Input Works
On relays built for it, the master command is a separate pair of terminals from the local control input. Pulsing the local terminals toggles the relay as normal. Applying a signal to the command terminals — typically held closed, not pulsed — forces the relay to a specific state (usually OFF, sometimes selectable) regardless of what the local buttons last did, holding it there while the command is present. Release it and local control resumes.
That's the mechanism behind Schneider's iTLc variant of the Acti9 iTL family — the "c" specifically denotes centralised-control capability added to the base iTL impulse relay. It's also why the product listing for the Schneider Electric A9C32816 iTLc 2P 16A extension is worth reading closely: it's designed to sit alongside standard iTL relays on the same board and add the command function without changing how the local buttons are wired.
ABB's E290 range takes a related but not identical approach: central command capability is delivered through dedicated command inputs on the relay itself, or through accessory options within the range, rather than a single labelled variant. The practical difference is smaller than it sounds — in both cases you're adding a second input to a relay that already has a local one, and the datasheet for the specific reference tells you whether that input is pulse or maintained.
Master command input
A control terminal on an impulse relay, separate from the local pulse input, that forces the relay to a specific state (typically OFF) for as long as it is held active, overriding whatever state the local buttons last set.
Central command module
An add-on device, wired in series or parallel with a group of impulse relays' command inputs, that lets one switch, timer, or BMS output drive centralised control across several relays without each relay needing its own dedicated command variant.
Wiring the Master ON and Master OFF Circuit
The physical wiring is straightforward once the relay's command input type is confirmed. Local push-buttons stay wired in parallel across the local (pulse) terminals exactly as in a standalone installation — see the push-button wiring guide for the general rules on that circuit, including why long runs and glow-indicator switches matter. The central command line is a separate pair of conductors run from the master switch, key-switch, or BMS relay contact to the command terminals of every relay in the group — daisy-chained terminal to terminal, not one long loop back to a single relay.
Two details cause most of the site problems. First, coil and command voltage: the command input usually runs at the same control voltage as the local coil, but not always — the background on coil voltage and control circuit design is worth checking before assuming they match, especially on mixed 230 V AC / 24 V DC boards where a contractor has reused whatever control cable was already run. Second, the command signal needs a clean, maintained closure — a momentary pulse into an input that expects "hold" releases the relay back to local control the instant the pulse ends, which reads on site as "the master switch doesn't work."
I_total = n × I_leak
Where: I_total is the cumulative leakage current reaching the coil or command terminal when several local switches with LED/glow indicators are wired in parallel; n is the number of illuminated local control points on that circuit; I_leak is the leakage current of a single illuminated switch, stated on its datasheet and normally a small fraction of a milliamp. If I_total approaches the relay's minimum pickup current, the coil can trigger with nobody at any button — the classic phantom-switching fault, made more likely on a centralised install simply because there are more parallel points feeding the same terminals.
Choosing Between a Command-Capable Relay and a Separate Module
Two design paths reach the same result, and the choice is mostly about how the board is laid out and how much rewiring an existing installation can absorb.
Specifying a command-capable relay for every position — an iTLc instead of a plain iTL, or an E290 reference with a command input — keeps the command wiring local to each relay and avoids an extra device on the board, at a small cost premium per position.
A dedicated central command module wired to a group of ordinary local-only relays — for example a run of standard iTL 2P units — adds one device per group instead of a premium variant per relay. It's usually the cheaper path when retrofitting central control onto an existing board, because the local relays and their wiring don't move.
| Method | Wiring effort | Local control preserved | Best fit |
|---|---|---|---|
| Command-capable relay per position (iTLc, E290 with command input) | Command wiring run to each relay individually | Yes, by design | New installations specified from the start |
| Central command module + plain local relays | One module, one feed to the group's command bus | Yes, unaffected | Retrofitting central control onto an existing board |
| Timer or BMS contact wired directly across local terminals | Low, but shares the pulse path | Risk of toggling zones the wrong way | Not recommended for whole-building override |
Key takeaway: Wiring a timer or BMS output straight into the local (pulse) terminals instead of a proper command input is the shortcut that causes lights to come back on instead of going off — it toggles rather than forces state.
Grouping Relays for Whole-Building Override
On a multi-floor building, central command lines from several boards are usually brought back to a single master point — a key-switch by the main entrance, a contact from the fire alarm panel, or a BMS output. Daisy-chaining command terminals across relays on the same board keeps wiring short; running one command feed the length of the building to every relay individually adds unnecessary cable and voltage-drop risk on long DC runs. Group boards floor by floor or zone by zone instead, and feed each group's command bus from the central point.
Status feedback matters here too: on a board with a dozen relays under central control, knowing which ones actually responded is worth more than the switch itself. The auxiliary contacts covered in auxiliary contacts and status feedback close that loop back to a BMS, confirming the central command latched every relay it was meant to.
Key takeaway: Central control without status feedback is a switch you trust blindly. On more than a handful of relays, add auxiliary contacts so the override can be verified, not just assumed.
Where This Goes Wrong on Site
The most common field fault is the pulse-into-maintained-input mistake already mentioned: a contractor wires the BMS output as a momentary contact because that's how the local buttons work, so the command releases the instant the pulse ends. The relay appears to ignore the master switch, when it's actually obeying it briefly and reverting.
The second is voltage mismatch — a command bus run at 24 V DC into relays whose command input expects 230 V AC, usually because the control cable was reused from an earlier system without checking the new relay's data sheet. Neither fault is a relay defect; both trace back to the command input's specified behaviour, not the relay itself. A less obvious failure mode is scale: a command bus that works fine on a five-relay test board can develop voltage drop or leakage issues once extended to thirty relays across a real installation, particularly on long DC runs. Verify it at the full installed scope, not just on the bench.
Frequently Asked Questions
Can I add centralised control to impulse relays that are already installed?
Yes, usually with a central command module wired to a command bus that reaches each relay's command terminals, provided the relays have that input. If the relays fitted are local-control-only with no command terminals at all, they need replacing with a command-capable variant such as iTLc or an E290 reference that offers a command input.
Does a central command pulse or hold the relay in its override state?
It depends on the relay and module, but most command inputs expect a maintained (held) signal rather than a momentary pulse. Wiring a timer or BMS output as a short pulse into an input that expects a held signal is a common site mistake — the relay reverts to local control as soon as the pulse ends.
What's the difference between iTLc and a standard iTL relay?
The base iTL is a local-control-only impulse relay: parallel push-buttons toggle it, with no separate override input. The iTLc variant adds a dedicated centralised-control command terminal alongside the local input, letting a master switch or BMS contact force the relay's state without disturbing local operation.
Will a central override circuit conflict with local push-buttons?
Not if wired correctly through a proper command input: the command forces state while active and releases control back to local buttons once removed. Conflicts happen when the central signal is wired into the local pulse terminals instead of a separate command input, because that toggles rather than forces the state.
Do I need auxiliary contacts for a centralised control circuit to work?
No, the command function works without them. Auxiliary contacts are optional but strongly recommended once more than a few relays are under central control, because they let a BMS or panel confirm that every relay actually latched to the commanded state rather than just assuming the master switch worked.
Can one central command bus cover relays from different manufacturers?
Only if their command inputs share the same voltage and signal type (pulse vs maintained). Mixing an ABB E290 command input with a Schneider iTLc on the same bus is possible electrically if both specifications match, but it should be verified against each range's datasheet rather than assumed.
Specifying It Correctly the First Time
Centralised control is a small addition to the bill of materials and a much bigger simplification for whoever operates the building afterwards. The decision that matters most is made at specification stage, not on site: pick command-capable relays or a module before the board is built, confirm the command input's voltage and pulse-versus-maintained behaviour against the local control voltage, and add status feedback once the group grows past a handful of relays. Everything else — the daisy-chained command bus, the grouping by floor or zone — follows cleanly. Compare this against a straight contactor-based approach in the contactor engineering guide if a project is still deciding between the two switching technologies at board-design stage.