Direct Answer

When designing an alarm-linkage circuit, should you use local relay output or wait for a cloud remote command? The answer: choose by action real-time requirements — second-level actions (exhaust fan, audible/visual alarm, shedding non-critical loads) use local relay output; things that only need recording and notification use platform push; critical protection actions do not go through the linkage module — they are done by hardwired protection. During selection, first ask: "Must this action still execute when the network is down?"

At a campus electrical room, the first-draft linkage design sent "fan start, audible/visual alarm, and non-fire-load shedding" entirely to cloud remote commands. A network-outage drill exposed the problem: within 30 seconds of network loss, the fan did not start, the alarm did not sound, and non-fire loads were not shed — yet gas-suppression/fire scenarios are exactly when power and network go down. Rectified by real-time requirement: fan, alarm, and load shedding changed to local relay output (acts immediately on site, network-independent); event records, SMS notifications, and trend analysis went to platform push (delay acceptable); critical protections (sprinkler, fire pumps) are completed by hardwired protection circuits (outside the linkage module). In a later gas-leak drill, local relays linked the fan and alarm within 2 seconds while offline. Layer linkage by real-time requirement — second-level actions local, records/notifications on platform, critical protection on hard circuits.

Because:

  • Second-level actions cannot wait for the network: fan, alarm, and shedding must act the instant a fault occurs; local relay output is milliseconds–seconds, cloud remote is seconds–minutes and network-dependent;
  • Circuits that must act offline go local: electrical-room fire/gas-leak scenarios are precisely when the network goes down; first ask "must it act offline?";
  • Critical protection does not go through the linkage module: sprinkler/fire-pump protection is done by hardwired circuits; the linkage module only does auxiliary actions;
  • Platform push suits record-type actions: event records, notifications, post-linkage confirmation — delay is acceptable; the platform is more flexible.

Key insight: linkage is layered by real-time requirement, not "everything on cloud" or "everything local." Second-level actions local, records/notifications on platform, critical protection on hard circuits.

At a campus data-center electrical room, the original plan sent all 12 linkage points through the platform. After review: five second-level actions (fan, alarm, shedding) went local relay; five records/notifications stayed on the platform; two critical protections (fire pumps) went hard circuit. The offline drill passed completely. Configure linkage by first asking "must it act offline" — if yes, go local.

1. Real-Time Comparison of the Three Output Types

First compare the three linkage output types by real-time performance:

Local relay output (e.g., ESF Electrical Fire Controller relay output):

  • Real time: milliseconds–seconds (acts immediately on detection);
  • Network dependence: none (acts offline);
  • Applies: fan, audible/visual alarm, load shedding — second-level actions;
  • Features: executes on site, reliable, requires wiring.

Dry-contact output (passive contact):

  • Real time: seconds (signal closes the contact);
  • Network dependence: none;
  • Applies: into external control circuits, cross-device linkage;
  • Features: passive, isolated, universal (any device can connect).

Cloud remote linkage (platform command):

  • Real time: seconds–minutes (network + platform processing);
  • Network dependence: yes (fails offline);
  • Applies: event records, notifications, post-linkage confirmation, cross-site management;
  • Features: flexible, configurable, but with latency.

Comparison conclusion:

  • Second-level actions → local relay/dry contact;
  • Records and notifications → platform;
  • Must act offline → local (platform is unreliable).

Key insight: real-time requirement decides the output type. Second-level actions execute locally; records/notifications push through the platform — do not let the network become the linkage bottleneck.

2. Circuit Checklist: What Must Act Offline

Which actions "must execute even offline"? List them first:

Must act offline (local output):

  • Exhaust-fan start (triggered by gas/smoke/temperature signals);
  • Audible/visual alarm (site annunciator linkage);
  • Shedding non-critical loads (prevent fault escalation);
  • Fire door/damper actions (fire linkage);
  • Emergency-lighting forced start (evacuation support).

May delay (platform push):

  • SMS/phone notifications (can be re-sent after network returns);
  • Event records and reports (retrievable afterward);
  • Cross-site linkage confirmation (synced after network returns).

Judgment standard:

  • Ask: "Can this action wait 10 seconds? Can it wait 10 minutes offline?"
  • Cannot wait → local; can wait → platform;
  • Involving safety/evacuation/fault escalation → must be local.

The offline drill is the touchstone:

  • Run periodic offline drills to verify local linkage really acts;
  • When the platform alarms disappear offline, the local audible/visual alarm must still sound.

Key insight: "must it act offline" is the first question of linkage configuration. Fan, alarm, shedding must be local — because accident scenarios often have no network.

3. Local Relay vs Dry-Contact Wiring

Within local output, how do you choose relay output vs dry contact? Look at the wiring scenario:

Relay output (active output):

  • Features: internal relay contacts, can drive loads (annunciators, contactor coils);
  • Wiring: controller output terminal → load (contactor/alarm);
  • Applies: driving site devices directly (ESF Electrical Fire Controller relay output);
  • Note: load-capacity matching (contact rating ≥ load current).

Dry-contact output (passive contact):

  • Features: passive open/close contact, no power, needs external supply;
  • Wiring: contact in series with an external control circuit (e.g., fire panel, PLC input);
  • Applies: cross-device linkage, into existing control circuits (ESI Digital Status Monitor/output);
  • Note: contact capacity and circuit voltage matching (24 V vs 220 V).

Selection points:

  • Driving loads directly (fan, alarm) → relay output;
  • Into external circuits (fire panel, PLC) → dry contact;
  • Both can combine: local relay drives the device + dry contact reports externally.

Wiring checklist:

  • Contact rating ≥ load current;
  • AC/DC circuits distinct (do not put 220 V into a 24 V circuit);
  • Output/input isolation (anti-interference).

Key insight: relay output drives loads; dry contact enters circuits. Direct device driving uses relay; cross-device linkage uses dry contact — distinguish active/passive before wiring.

4. What Suits Platform Push

Which actions are suitable for the platform? Record and notification types:

Actions suited to platform push:

  • SMS/phone/app push notifications (alerting O&M);
  • Event records and reports (linkage trace);
  • Trend analysis and health (long-term data);
  • Cross-site management (unified monitoring of multiple rooms);
  • Post-linkage confirmation and reset (remote status confirmation).

Platform push boundary:

  • Only "notification and recording," not "second-level actions";
  • Linkage executes locally; the platform confirms results;
  • When the platform is offline, local execution continues; state syncs when the network returns.

Platform value is "seeing everything":

  • Local execution + platform recording = reliable action + visible management;
  • The platform turns scattered local linkage into one linkage-network diagram.

Key insight: platform push is notification and recording, not execution. Actions stay local, records go to the platform — platform outage does not affect safety actions.

5. Why Critical Protection Does Not Go Through the Linkage Module

Why can sprinkler and fire pumps not be given to the linkage module?

Critical-protection characteristics:

  • Must act with absolute reliability (sprinkler must spray in a fire);
  • Must not depend on any intermediate link (controller, network, platform);
  • Protection logic is simple and clear (low pressure → start pump).

Linkage-module limitations:

  • Depends on front-end detection + module logic + output circuit — many links; any failure causes misoperation/refusal;
  • A module fault or power loss kills critical protection;
  • Linkage is for "auxiliary actions," not "life-saving actions."

Correct division:

  • Critical protection (sprinkler, fire pump, main-breaker protection): hardwired protection circuit (dedicated controller/relay, independent supply);
  • Auxiliary linkage (fan, alarm, shedding): linkage module;
  • Records/notifications (SMS, reports): platform.

Design principles:

  • Redundant life-saving actions: dual circuits for critical protection (hardwired primary);
  • Linkage module adds value: auxiliary actions, faster response;
  • Never make critical protection depend solely on the linkage module.

Key insight: critical protection goes on hard circuits; the linkage module only assists. Sprinkler and fire pumps rely on dedicated protection; linkage is enhancement, not the life-saving foundation.

6. Product Landing: Layered Linkage

FEXLINK's Digital Electrical Intelligent Supervision System brings layered linkage to practice:

  • ESF Electrical Fire Controller (relay output): local relays drive fan, alarm, load shedding — second-level action, reliable offline;
  • ESI Digital Status Monitor: dry contacts into external circuits (fire panel, PLC linkage);
  • ESX Edge Computing Gateway: local linkage logic executes at the edge + event records upload;
  • Platform push: SMS/app notifications, linkage records, trend analysis, cross-site management;
  • Critical protection: independent hardwired circuit (outside the linkage module);
  • The platform shows one linkage-network diagram: local actions, platform records, hard protection at a glance.

Design principle in one sentence: turn "all cloud or all local" into "layer by real-time requirement." Second-level actions on local relays, records/notifications on platform push, critical protection on hard circuits — reliability and flexibility together.

7. Common On-Site Mistakes

  1. All linkage through the platform: fan and alarm also wait for remote commands. Consequence: linkage fails offline — precisely when accidents occur. Correct: second-level actions use local relay output.
  2. Critical protection depending on the linkage module: fire pumps controlled by the platform. Consequence: module/network failure kills protection. Correct: critical protection on hardwired circuits.
  3. Using dry contact as a relay: passive contact drives loads directly. Consequence: insufficient capacity, burnt contacts. Correct: loads use relay output.
  4. Wiring without separating AC/DC: 220 V into a 24 V circuit. Consequence: burnt equipment, misoperation. Correct: separate AC/DC circuits with isolation.
  5. No offline drill: assuming platform linkage suffices. Consequence: failure exposed only when the network drops. Correct: periodic offline drills verifying local linkage.

Scope and Limitations

This article discusses alarm-linkage output selection (local relay output, dry-contact output, and cloud remote linkage) for electrical rooms, server rooms, and storage stations. Real-time layering and the circuit checklist are engineering experience references; actual design follows site equipment, fire codes, and vendor proposals. Critical protection must be completed by independent hardwired circuits and must not depend solely on the linkage module; linkage wiring must meet contact capacity and AC/DC isolation requirements. Data and records are managed uniformly through the platform to form a linkage-network diagram. All cases are anonymized (a certain campus / data center) and do not refer to any specific customer.