Signal Path — from Receiver to Alarm Queue

This module is written for operators and supervisors: what happens to a signal between the customer's panel and your queue, and what you can see and do at each step. Programming the tables that drive it is administrator work — those pages are named here so you know where the behaviour comes from.

How the module progresses

1. Follow one signal all the way through, so the vocabulary is in place.
2. Ingestion — how a signal physically reaches the database.
3. Translation — how a raw message becomes a named zone on a named installation.
4. The three ways a signal can fail to match, and what you see in each case.
5. Generation — why one signal becomes a red alarm and the next only a log line.
6. Queue arrival — which queue, what position, what colour.
7. Supervision — the alarms the system raises about itself.

1. One signal, end to end

Task: for any alarm on your screen, be able to say where it came from and what happened to it on the way.

The seven stages. Every customer signal takes the same route:

Words you will hear:

Your signal source in this module is Simulate Alarm — the SBN GUI's manual signal generator on the Dispatch screen. It hands the signal to the alarm-generation stage directly, so it exercises everything from zone matching onward — the last two rows of the table above — but not the receiver, concentrator and FrontEnd legs. Where those legs matter, compare against a real test signal sent to your installation from a panel or a receiver-side test.

Worked example (Branch TRAIN) — one burglary, named at every stage. On MILLER (TRA-00002), raise a Simulate Alarm on one of the installation's four zones, alarm type burglary. Then name out loud, in order, what the system did:

1. Installation — the signal's account ID resolved to installation TRA-00002; the installation name appears in the alarm.
2. Zone — the zone number resolved to that installation's zone record; the alarm carries the zone description you can read on the installation's Zones tab.
3. Decision — the installation's monitoring status permits monitoring, so an alarm is created rather than logged and dropped.
4. Priority — the zone's priority, adjusted by the zone type for this signal type, produced the number in the queue's priority column.
5. Queue — a routing rule (or the fallback) chose the queue it is sitting in.
6. Colour — the alarm is new and untouched, so it wears the site's "new alarm" colour.
7. Log — the same event is written to the installation's Alarm Log, where it stays after the queue row is gone.

Guided practice: repeat the same walkthrough on RIVERSIDE (TRA-00003) with a different zone and a different alarm type. Before you look at the queue, predict the zone description and the priority; then check.

Independent practice: raise one signal on PLATEAU A (TRA-00006-01) and one on the PLATEAU main installation (TRA-00006). Without help, write one line per stage for each, and note every point where the two differ.

2. From receiver to database

Task: explain where a signal physically arrives, and read the receiver information recorded on an alarm.

How it works.

1. A receiver decodes one panel protocol on one physical line. Lines are grouped on ports; ports belong to a concentrator.
2. The Concentrator speaks every supported receiver protocol and normalises all of them into a single internal format. It has no database connection at all — its job is to collect and forward. Concentrators run in primary/backup pairs, and a signal that arrives on both is de-duplicated later so the operator sees it once.
3. If the database is unreachable, the concentrator does not lose the signal: it holds it in a crash-safe file queue and replays it when the link returns.
4. FrontEnd is the piece that actually writes the signal into the database, into an immediate queue. Only after FrontEnd confirms the write does the concentrator acknowledge the signal back down the line. That acknowledgement chain is why a healthy path never silently loses a signal.
5. Immediate queues are numbered 1–64, plus an internal queue 0 the system uses for signals it generates itself (section 7). One alarm-generation service instance serves each queue, and reads it strictly oldest-first. Which concentrator feeds which immediate queue is administrator configuration on the Concentrator/Immediate Queue page (#1824).
6. Newer sites also receive over IP Receiver and Alarm Receiver services instead of, or alongside, the classic concentrator. They decode different transports but deliver through the same FrontEnd hand-off, so everything from the immediate queue onward is identical.
7. Each concentrator/port/line combination can be given a plain-language description on the Concentrator/Port/Line page (#1680). That description is what shows in the Alarm Log's Misc 3 column — it is how you tell "came in on the Montreal IP line" from "came in on the backup dialup line."

Why the pair matters to you. During a changeover the same signal can genuinely arrive twice. De-duplication is automatic and happens before the alarm exists, so a doubled alarm in your queue is not normally a redundancy artefact — look at section 5's duplicate rule and at the panel instead. The Atlas Concentrator page carries the data-flow drawings for the normal, redundant, failed-concentrator and failed-FrontEnd cases.

Worked example (Branch TRAIN): raise a Simulate Alarm on your own installation, open its Alarm Log and read the Misc 3 column: it is empty — the simulated signal never travelled a receiver line. Say which of the four hand-offs (receiver → concentrator → FrontEnd → immediate queue) it skipped, and where it joined the path.

Guided practice: for that same simulated alarm, walk the four hand-offs a real panel signal would have made before it appeared, and name for each what would be recorded — the line description on #1680, the immediate queue on #1824 — that your simulated alarm has blank.

Independent practice: given an alarm whose Misc 3 says a specific line, state who you would contact if that line's signals stopped arriving — and which section of this module tells you the system would have raised its own alarm about it.

3. Matching the signal to a zone

Task: explain how a raw receiver message becomes "Zone 3 — Front Door, Burglary" on a named installation, and what to check when the description looks wrong.

How it works — three lookups in order.

1. Installation. The account ID carried in the signal is looked up against the accounts table. A hit gives the installation; a miss goes to section 4.
2. Translation. The raw message is matched against the Alarm Translation Tables (#1876), which turn a receiver's protocol text into SBN's own fields: event, zone, user, area and code. The matching has two important properties:

- The wildcards live in the table, not in the signal. A translation row's message pattern may contain % (any run of characters) and _ (one character); the incoming message is compared against that pattern. This is what lets one row cover a whole family of messages. - Exact beats wildcard. SBN makes one pass looking for rows whose format matches exactly, and only if that finds nothing does it make a second pass allowing the format itself to be a pattern. Within a pass, the first matching row in table order wins — so a broad % row placed early can shadow a narrow one. Language-specific text overrides are looked up with the identical test, so a translation can never widen a match.

1. Zone. The translated zone identifier is matched against the installation's own zones. On sites where the option is enabled, area and code participate in that match too. The zone record supplies the description, the zone type and the base priority the rest of the pipeline works from.

Three related mechanisms, at awareness level:

1. Signal Injection Translation (#1685) does the same job for signals that never came from a receiver — camera events, pendants, API-delivered payloads. Its precedence is stated plainly on that page: direct match → first defined row, top down → treat as ALARM by default.
2. Zone masks — each zone carries an eight-position mask (alarm, restore, battery, cancel, supervisor, bypassed, trouble, logging) declaring which signal types that zone accepts, allows or requires. The Zones page's "Defining a Mask" section has the worked patterns. Masks are why a zone can accept a burglary but ignore a trouble on the same zone number.
3. Where a zone can be defined. Zones are not held only on the individual installation: a site can define them at template, global and local level, and the account ID a definition applies to can be written as an exact value or as a pattern. Which level wins in which situation follows a fixed precedence order set out on the Zone Matching reference page.

A quick way to tell translation problems from zone problems: if the alarm shows the wrong event (a fire reported as a burglary), suspect translation. If it shows the right event on the wrong or missing zone, suspect the installation's zone records. The first lives in a table owned by an administrator — record what arrived and what you expected, and hand it to whoever owns #1876 on your site. The second is data entry you may well own yourself.

Worked example (Branch TRAIN): raise a Simulate Alarm on MILLER (TRA-00002) naming a zone number that exists on the installation. Open the resulting alarm and trace the description back to the Zones tab entry it came from. Then repeat with a zone number the installation does not have, and keep the result for section 4.

Guided practice: on RIVERSIDE (TRA-00003), read the mask on each of the four zones and predict, for each, whether a restore signal would be accepted. Verify one of your predictions with a simulated restore.

Independent practice: take three alarms from your own installation's Alarm Log and, for each, name (a) which zone matched, (b) where the description came from, and (c) which of the three lookups above would have to be wrong for the description to be wrong.

4. When nothing matches

Task: recognise, from what you see on screen, which kind of match failed — and know which ones still reach an operator.

There are three distinct outcomes.

Three details worth remembering.

1. The error-account re-processing is capped at two attempts. If the error account itself cannot be resolved, the signal is abandoned and recorded as "No error account. ALARM LOST". It is rare and it is a configuration fault — report it, don't retry.
2. Error accounts are not the same thing as account 0000. An error account catches a customer signal whose account ID nobody recognises. Account 0000 carries the alarms the system raises about itself (section 7). Both are "alarms without a real customer behind them", and they are easy to confuse on a busy screen — the account ID tells you which you are looking at.
3. Unmatched zones are collected on the Unknown Zones report. A steady trickle there usually means data entry has not caught up with what the panel is actually sending.

Worked example (Branch TRAIN): NORTHERN LIGHTS JEWELLERS (TRA-00001) has no zones at all. Raise a Simulate Alarm on it naming any zone. The alarm arrives — tagged ???, priority from the site default, no description. That is outcome two, live.

Guided practice: add one zone to TRA-00001 with a proper description, re-simulate on that zone number, and put the two alarms side by side in the Alarm Log. Then check the Unknown Zones report and find the first attempt.

Independent practice: set one of your own installations to a monitoring status that carries the cancel flag, simulate a signal, and confirm that nothing arrives anywhere. Restore the status afterwards, and be able to state which of the three outcomes each of your three experiments produced.

5. From match to alarm — how SBN decides

Task: explain why one signal became a red alarm in your queue while a similar one only appears in the Alarm Log — or nowhere.

A matched signal is not automatically an alarm. Several checks stand between the match and the queue row.

Priority — and the direction that trips everyone. The number is built up in stages: the zone's own priority, plus an offset from the Zone Types page (#1733) for this particular signal type, then cumulative adjustments from the dealer, the panel type, the subscriber type and any VIP setting, finally clamped into the range 1–99.

Priority 1 is the most urgent. 99 is the least. A "high priority alarm" carries a low number.

Restore required. A zone can be flagged so its alarm cannot be closed until the matching restore has arrived. When the restore turns up later, the flag is satisfied in place on the existing alarm.

Auto-removal — "the cancel clears the burglary." A later signal can remove an earlier alarm automatically, but only under all of these conditions:

1. inside the window — each zone type defines how long after the original alarm the removal is still allowed; after that, nothing happens;
2. the pairing must be permitted — which cancel may clear which alarm type is defined by rule, not by assumption;
3. not blocked — an earlier event on the incident, or the zone type itself, can forbid automatic cancellation;
4. and never after an operator has acted. If anyone has taken or worked the alarm, it stays. The system logs that a removal would have applied and leaves the alarm standing for you to finish.

Test mode diversion, by scope. Putting something in test mode diverts matching signals to the Test/Runaway queue. The scope can be a single zone, the whole installation, a monitoring group, an alarm type, or a defined test group. Signals in scope appear in the test queue and never in dispatch — which is exactly what you want during an installer's walk test, and exactly what confuses you if you forget the installation is still in test.

Worked example (Branch TRAIN): on MILLER (TRA-00002), raise the same simulated burglary twice in quick succession — confirm you get one queue row, not two. Then raise a cancel for the same zone: where the site's pairing rule permits the cancel to clear that alarm type, the burglary disappears. Finally repeat the pair, but take the burglary before sending the cancel — this time it stays, and the log records the cancel. If the first cancel did not remove anything, that is the pairing rule, not a fault; check the zone type.

Guided practice: put one of your own installations on a log-only monitoring status, simulate a signal, and find it in the Alarm Log with no queue row. Restore the status afterwards.

Independent practice: put RIVERSIDE (TRA-00003) into test mode for the whole installation, simulate two signals, locate both in the Test Queue, take the installation out of test, and simulate a third to prove dispatch routing is back.

6. Arriving in the queue

Task: explain why an alarm landed in the queue it did, in the position it did, wearing the colour it does.

Which queue — four passes, then the fallback. SBN tests the alarm against the routing table on the Queue Routing page (#1738) in four progressively looser passes and stops at the first hit:

1. branch, zone type, dealer, time window and subscriber type all match;
2. the same, ignoring subscriber type;
3. any zone type, but subscriber type must match;
4. any zone type, any subscriber type.

If none of the four matches, the alarm goes to Queue 1. An alarm in Queue 1 therefore means one of two things: a rule deliberately sent it there, or no rule matched it at all. There are sixteen dispatch queues.

The keep-together rule. If the same installation and monitoring group already has an alarm sitting in a different queue, the new alarm is redirected to join it, overriding the routing result. Related alarms on one premises stay in front of one operator instead of being split across the floor.

Position in the queue. The list is ordered: untouched alarms first, then by priority (1 first), then oldest first. Alarms parked on a timer or already in dispatch sort behind untouched ones, and auto-handled alarms are pushed to the back. So an alarm "moving down the list" usually means someone touched it, not that it became less urgent.

Colour. Five per-alarm flags — taken, acted on, timer 1 running, timer 2 running, dispatched — combine into the state that drives the row colour. The mapping from state to colour is configured per site on the Alarm Queue Colors page (#1649), and a second palette can apply above a configured priority threshold. Learn your own site's table from the Alarm Queue page rather than carrying colours over from another installation.

Skills. Zone types carry a skill marker, and queue retrieval can filter on it, so an operator only gets alarms they are qualified to handle. A "missing" alarm that a colleague can see and you cannot is very often a skill filter, not a routing fault.

Four related behaviours, at awareness level:

Working the alarm once it is in front of you — getting, acknowledging, timers, VIP adjustment, emergency mode — belongs to the Alarm Queue module; this module stops at arrival.

Worked example (Branch TRAIN): simulate a burglary on MILLER (TRA-00002). Note the queue number, the priority and the colour. Take the alarm — the colour changes. Start a timer — it changes again, and the row moves down the list. Name the flag responsible for each change.

Guided practice: raise two alarms on the same installation in the same monitoring group and confirm both are in one queue. Then raise one on PLATEAU A (TRA-00006-01) and one on the PLATEAU main installation (TRA-00006) and see whether they stay together — and explain the difference in terms of the keep-together rule.

Independent practice: find an alarm in Queue 1 and give the two possible explanations for it being there. Then, for three alarms in your queue, predict the order they should appear in and check against the actual list.

7. Watching the watchers — receiver supervision

Task: recognise the alarms SBN raises about itself, and know that they are handled differently from customer alarms.

A silent line. Every receiver port runs a watchdog timer. If nothing arrives before it expires, the concentrator raises a line-timeout alarm; when traffic returns, it raises the matching restore. The same mechanism reports undecodable traffic, corrupt data, a lost carrier and individual phone-line timeouts. A port that is deliberately out of service can have these suppressed.

Where those alarms land. They are stamped with a generated account made of the prefix ZREC, the two-character concentrator ID and the two-digit port number — so ZREC0402 is concentrator 04, port 02. From that point they are translated, prioritised and routed exactly like a customer signal, which is why they show up in an ordinary queue looking ordinary. Reading the account name tells you immediately that the problem is on the receiving side, not at a premises.

Service-level supervision. The Alarm Supervisor raises its own signals — operator line up and down, undecodable signal, service down and restored — onto account 0000. Account 0000 is therefore the place to look when you suspect a component, rather than a line, has stopped.

Overdue periodic tests. Each monitored installation can be expected to report in on an interval. Every qualifying signal that arrives pushes the next-expected time forward, with a five-minute grace period on intervals of an hour or longer so a marginally late panel does not generate noise. A background sweeper looks for installations whose next-expected time has passed and injects a missing-test signal into the internal queue — which then travels the normal path and becomes an alarm like any other. Sites can enable a second-stage signal for installations that stay overdue, cap how many times one installation escalates, and exclude particular zones from the check.

What operators do with these. Treat them as alarms — they queue, they are acknowledged, they resolve. But the action is escalation to technical staff, not a call to a premises. A ZREC… line timeout means signals may be missing for every installation on that line; a missing-test alarm means one specific panel has gone quiet and someone must find out why.

Worked example (Branch TRAIN): decode ZREC0705 — concentrator 07, port 05 — and state, in one sentence, what a customer on that line would be experiencing and who you would call.

Guided practice: search the Alarm Log for activity on account 0000 and identify which supervisory condition produced each entry.

Independent practice: given a missing-test alarm on one of your TRAIN installations, say which of the three supervision mechanisms in this section raised it, what pushed the next-expected time forward until now, and what would happen if the panel stayed silent for another interval.