Identity & Signals

The Identity & Signals board (left nav → Hubs → Identity & Signals tab) surfaces two things the monitoring platform watches in the background:

1. Conflicts — when an inbound alarm signal's identity doesn't line up cleanly with what we already know (a new radio on a known account, or a serial and an account code that point at two different sites).
2. Unlinked signals — inbound identifiers (account codes / device IDs) that are reaching a receiver but aren't linked to any site yet — the "link these to a site" worklist. It splits into three views: Losing signals (reaching us but matching no hub, so nothing they send routes), Unlinked (routing fine, just not tied to a site) and Blocked.

Requires the Alarm Receivers module

The tab only appears once Allow 3rd Party Alarm Receivers is turned on for the control room (see Modules & Capabilities) — every conflict and unlinked signal here comes from a 3rd-party alarm-panel receiver (Olarm, Ajax, FSK, RDC, FinMon, SpotBot, Hyyp, Onyyx), not from the Advanced Alarm Handling Brain.

Observe-only for now

This is the first ("shadow") phase. The platform watches and flags, but it does not yet change how live alarms are routed — your existing setup keeps working exactly as before. Binding an identifier here curates the identity index so the platform learns the correct mapping; it has no effect on current routing.

Why it exists

CleverCam identifies a premises by its site, which never changes. The radios, panels and communicators that report to that site do change — a radio gets swapped, a panel is replaced, a new device is installed. Each one transmits its own account code and/or serial / device ID. This board is where those identifiers get tied to the right site, and where mismatches are caught before they can send a response to the wrong address.

A panel can also be known to CleverCam before it has ever transmitted. On an Olarm, HYYP or Onyyx line a panel registered by its TX number (account code) — pre-registered from a site's Add hub, given a typed radio code in Replace communicator, or brought in by an imported register — has no device id yet and is waiting for first signal. It has sent nothing, so it never appears on this board's worklist: it already belongs to its site, and on its first signal the device is adopted onto that record automatically — no duplicate panel, and the site link stays. Until then the Add Hub wizard's TX number step lists it as Registered — waiting for first signal and its row on the site's Hardware tab carries a Waiting for first signal note. See Waiting for first signal.

The summary badges

A row of badges sits above the two tabs, summarising the whole control room:

Badge	What it counts
emergency	Open flags with emergency styling — serial/account contradictions.
open flags	All open conflicts awaiting a decision.
unlinked signals	Unlinked identifier rows — the whole worklist, both Losing signals and Unlinked together.
active bindings	Identifiers currently bound to a site.
radios transmitting	Distinct radios behind those unlinked identifiers.
signals unrouted	Total signals those radios have sent, none of which raised an event.

radios transmitting is always less than or equal to unlinked signals, because one radio can report under more than one identifier — an Olarm panel, for example, reports both a device UUID and an account code, which is two identifier rows for a single radio. Use radios transmitting when you want to know how many physical devices are involved, and unlinked signals when you want to know how many rows are in the worklist below.

Conflicts tab

Each card shows the receiver, the identifiers involved, and the candidate site(s). The action buttons depend on the type:

Flag	What it means	What to do
New serial on known account	A new device is reporting on an account that's already linked to a site (typically a radio or panel swap).	Replace device (the new device takes over from the old on that site) or Confirm & bind (add it alongside). Relink… to choose a different site, or Dismiss.
Serial/account contradiction	The signal's serial points at one site while its account code points at a different site. Shown with emergency styling.	This is a live-risk mismatch — Relink… the identifier to the correct site after verifying, or Dismiss if it's a known false positive.
New account on known device	A device we know is now reporting a new account code.	Confirm & bind, Relink…, or Dismiss.
Ambiguous line binding	A receiver/line identifier appears on more than one receiver. Usually expected (e.g. the IDS Hyyp + Onyyx split).	Dismiss to acknowledge.

Relink… opens a site search so you can pick the correct site. Replace and Confirm use the account's already-known site, so they're one click.

Account code 0000 never raises a conflict

An all-zero account code (0000, 00000) reaches a receiver for two reasons, and neither one is a premises:

• On a radio base (FSK, RDC), it is normally the base itself — its own check-ins, its own mains and battery, its own comms lost/restored. There is no panel behind the signal at all.
• On a panel lane (Olarm, Hyyp), the panel is real but its account code was never programmed, so it transmits the vendor's placeholder alongside its serial. Every unprogrammed panel on the line sends the same placeholder, so the code identifies nothing.

Either way the platform treats an empty or all-zero identifier as no identifier at all: it is never bound to a site, never resolves, never raises a conflict, and never appears in the Unlinked signals worklist. Where the device has its own serial / device ID it is still identified by that, so a genuine new-radio-on-a-known-account conflict is raised exactly as before — just never against a placeholder.

If you want a panel to be identified by its account code, program a real one on the panel.

FinMon never raises a "new radio" conflict

Some lines identify a panel by one token only. FinMon is the clearest case: the frame carries a control-room id and a virtual unit id, but the panel itself is named solely by the account code inside the Contact ID string — there is no separate panel serial. The receiver therefore reports the same value as both the account and the serial.

The platform counts that as one identity, not two, so a FinMon panel can never contradict itself and never raises a new-radio-on-a-known-account conflict. Before this rule, every FinMon panel that an operator linked by hand flagged a conflict against itself on every single signal, and dismissing it did not help — the next transmission raised it again.

Lines that really do send two identifiers (Olarm, Hyyp, Onyyx) are unaffected: a genuinely new radio reporting on a taken account code is still raised for you to action.

A base's own signals may still show as a site's events

This only governs the identity index. If an all-zero account previously auto-created a panel record on a base — you'll see it as "Alarm Panel 00000" — and that record was linked to a site, then the base's own comms and power signals still arrive as that site's events. Check your bases for a hub named Alarm Panel 00000 (or similar) and unlink it from any real customer site.

Unlinked signals tab

A searchable list of every inbound identifier seen on a receiver but not yet tied to a site, with how many times it's been seen. Three views, switched with the Losing signals / Unlinked / Blocked buttons above the list.

Losing signals

The view the tab opens on, and the only one where anything is actually being lost. These radios reach a receiver but match no hub at all, so routing rejects every frame — the signals never become events, and the panel still reports them as delivered.

They are listed newest first, each showing when it was first seen. That timing is the most useful free evidence of whose panel it is: a burst of identifiers appearing together is one control room switching something on, while a fleet that has been running for weeks is somebody else's. Do not read ownership off the shape of an account code — a single control room routinely uses more than one numbering convention, and guessing wrong sends one company's burglary to another company's operators.

The actions are the same as below: link it to a site to start monitoring it, or block it if the site is cancelled. The count in the button is your daily work — it is normally a handful of rows, and it is kept separate precisely because it would otherwise be lost among the much longer Unlinked list, where nothing is going missing.

Unlinked

Identifiers that already resolve to a hub and route normally — they simply are not tied to a site yet. This is backlog, not breakage. For each row:

• Link to site… — search for and pick the site this identifier belongs to. This creates the binding.
• Ignore — hide it from the worklist. Its signals keep arriving and keep being processed — this only takes the row off your list. Right for a placeholder token like 0000 that will never be bindable but whose signals still route by device ID.
• Block — stop processing this radio altogether. Right for a cancelled site whose panel is still transmitting.

This is the fastest way to onboard a backlog — for example a fleet of radios that have been transmitting but were never linked to their sites.

Finding one radio in a backlog

The list shows 50 radios at a time, busiest first, with Prev / Next beneath it; turning a page returns you to the top of the list. The filter box above it matches on the identifier, the receiver or the protocol, and it searches every unlinked radio on this control room — not just the page in front of you. That matters on a large backlog: one control room is carrying 4 578 unlinked radios, and the one you are looking for is rarely among the busiest.

Blocking a radio

Blocking is for one situation: a site has been cancelled, but nobody removed its panel from the receiver's monitoring-station connection, so it keeps sending. Until it's blocked, every signal it sends is decrypted, forwarded, rejected by routing because it belongs to no site, retried, and parked in the dead-letter queue — work nobody benefits from, on an account nobody is paying to monitor.

Two things blocking deliberately does not do:

• It does not stop acknowledging the panel. The receiver still answers every frame. Cancelled panels usually share one connection with the control room's live ones, and a panel that stops getting acknowledgements retries hard enough to degrade that connection for everybody on it.
• It does not stop the panel transmitting. Only the installer can do that, by removing the hub from the receiver's monitoring-station connection. Until they do, the panel — and the vendor's own installer app — will still show its signals as delivered.

That second point matters commercially: a cancelled site can look monitored from the panel's side. If the panels aren't removed at the source, say so in writing to whoever cancelled.

Blocked rows stay listed under Blocked, and their seen-count keeps climbing, so you can tell at a glance which cancelled radios genuinely went away and which are still talking. Unblock puts a row back on the worklist and signals resume immediately — on that panel's very next transmission, not on a delay.

warning

A radio already linked to a site cannot be blocked — the button refuses it. Unlink it from the site first, deliberately. This is the one guard between "tidy up the worklist" and "silently stop monitoring a paying customer".

In the control room

Operators don't need to open this board to be warned: a signal-identity alert appears in CleverCommand when an operator-actionable flag is open. Serial/account contradictions show with emergency styling so the operator verifies the correct address before responding. Full management (relinking, the unlinked-signals worklist) stays here in CleverOps.

Permissions

You can manage identity bindings for any control room you administer. The actions are scoped to your control room.