Alarm Receivers

The Alarm Receivers tab is where a control room connects third-party alarm panels to CleverCam so their signals land in CleverCommand alongside camera events. Each receiver is one inbound channel for a communicator brand — Olarm, Ajax, Hyyp, Onyyx, FSK, RDC, FinMon, SpotBot — and the tab lists every receiver for the selected VCR with its live signal stats.

Where to find it

Open Settings from the CleverOps sidebar, then click Alarm Receivers under Alarm in the Settings navigation. The list is scoped to the VCR you are working in.

The same receiver table is also on the Hubs page as its Receivers tab — one and the same list (same receivers, same Add receiver button, same edit dialog), placed next to the hubs that report through the receivers. Edit a receiver in either place and the other shows the change; see Hub Management → Receivers tab.

The tab has four sub-tabs:

• Receivers — the logical receivers: the accounts and feeds your signals arrive on. This is where you add, edit, pause and delete receivers, and everything below up to Hardware describes it.
• Hardware — the physical devices behind those receivers: the site routers (Teltonika) and the serial receiver gateways CleverCam has installed for your control room, with their live status. Read-only — see Hardware.
• Base health — experimental. Whether each base station is still hearing the panels registered against it. See Base health.
• Alerts — where this control room is told when a receiver, gateway or router goes quiet, and what is currently down. See Alerts.

The receiver table

Each row is one receiver, grouped by communicator type and then by label, so two receivers of the same type (two RDC bases, two Olarm feeds) sit together. The columns are:

Column	What it shows
Label	The name you gave the receiver (with the communicator logo, when set).
Communicator	The communicator type — Olarm, Ajax, Hyyp, Onyyx, FSK, and so on.
Panels	How many alarm panels / hubs are linked to a site through this receiver. The number is a link — click it to open the Hubs list filtered to those hubs.
Radios	How many distinct radios this receiver has heard in total, with any unrouted ones called out underneath. Reads none unrouted when every radio is bound to a site. See Radios and unrouted radios below.
Webhooks	How many inbound messages (signals and keep-alive pings) this receiver has taken — over all time, or over the window chosen with the Signals over chips above the table. See Counting signals over a window below. Under All time, an Olarm receiver's cell splits per ingest feed — see Olarm's two feeds below.
Last Webhook	When the most recent signal arrived, or Never if none yet. Also split per feed on Olarm receivers.
Supervision	The receiver's own fail to test: green OK while the receiver has delivered anything inside its window, red Fail to test once it has gone quiet for longer, with the age of the last message on the pill. Underneath, the window itself — set it per receiver, in place. See Receiver supervision (fail to test) below.
Status	Active, Paused or Inactive — see Pausing a receiver below.
Setup	For master-account receivers (Hyyp + Onyyx) a clickable setup-status chip showing the IDS portal admin-role + endpoint check; other types show —.
Actions	On an active receiver, a Pause / Resume button. The row's More menu holds Manage panels (Olarm only), Export unrouted radios, Activate / Deactivate and History — plus Receiver settings for a Hyyp or Onyyx receiver, whose row opens the IDS portal. Delete is not on the row; see Deleting a receiver.

If the VCR has no receivers yet, an empty state reads "Add a receiver to integrate 3rd party alarm panels (Olarm, Ajax, FSK, etc.)."

Pausing a receiver

A receiver has three states, and the difference between the middle one and the last one matters:

Status	What it means
Active	Signals arrive and raise events as normal.
Paused	Signals still arrive and are still recorded — panel and radio counts, Webhooks and Last Webhook all keep moving — but they raise no events, so nothing reaches the control room.
Inactive	The receiver is not accepting signals at all. Anything sent to it is refused and lost.

Pause is the one to reach for when you want to hold a receiver's alarms off the control room for a while — commissioning a new base, migrating a book of accounts across, or testing a communicator before going live. Because the signals still land, you keep a full record of what each radio sent and which account codes it used, so you can check the radios are bound to the right sites before you resume.

Deactivating is not a quieter version of pausing. An inactive receiver refuses its signals outright, so nothing is recorded and nothing can be recovered afterwards — you lose the very history that tells you the setup is correct. Deactivate a receiver only when you want it genuinely switched off.

To pause, click Pause in the Actions column; the Status badge turns amber and reads Paused, and the button changes to Resume — click it to resume. The button only appears on an active receiver — pausing an inactive one would change nothing, since its signals never get through in the first place.

note

Pausing stops events from the panels on that receiver. It does not stop Alarm panel link down supervision events, which are raised by CleverCam when a panel stops reporting rather than by the panel itself.

Receiver supervision (fail to test)

Every receiver can carry its own fail-to-test window — how long the receiver as a whole may stay silent before the control room should treat it as down. This is supervision of the receiver: the vendor's endpoint, the cloud base, the physical base station and the gateway behind it. It is not the per-panel offline supervision described under Hub offline supervision, which asks whether each individual radio is still reporting.

The Supervision column shows the verdict on the first line and the window on the second:

Pill	What it means
OK · 2m ago (green)	Something arrived inside the window. The age is that of the last message.
Fail to test · 3h ago (red)	Nothing has arrived for longer than the window — the receiver has gone quiet. Check the vendor's endpoint, the base station or the gateway behind it.
Never heard	A window is set but nothing has ever arrived. It turns red once the receiver has existed longer than its own window; a receiver created minutes ago simply has not had the chance yet.
Not supervised	No window is set. Pick one underneath to supervise the receiver.
Inactive	The receiver is inactive, so it refuses its signals at the door and there is nothing to supervise.

"Anything" means anything. The clock is reset by every inbound message — a real signal, a keep-alive ping (Olarm and the FSK cloud base ping every minute or so) or a serial base station's own supervision beat. It is deliberately not restricted to supervision codes: a base whose panels' signals are still flowing is alive, whatever its own supervision engine is doing. Hover the pill for the exact reading.

Setting the window

Use the picker under the pill. It offers the common cadences — 2, 5, 10, 15 and 30 minutes, 1, 2, 4, 12 and 24 hours — plus Custom…, which takes any number of minutes (from 1 minute up to 7 days; press Enter to save, Esc to cancel). Off removes the window and stops supervising that receiver. The change saves immediately, applies to that receiver only, and is recorded on the receiver's History with the old and new window and who changed it.

Pick the window from how often the receiver actually speaks:

• A busy webhook receiver (Hyyp, Olarm, FinMon) with many panels delivers something every minute or two — 5–10 minutes catches an outage quickly without false alarms.
• The FSK cloud base pings every minute — 5 minutes. A new FSK cloud base starts on 5 minutes automatically.
• A physical RDC / D20 base station on a serial gateway checks in roughly hourly, and on a quiet estate the panels themselves may not fill the gap — 1 hour. Setting it tighter than the base's own cycle makes a healthy base read as failed at every quiet stretch.

For a serial-gateway channel the same window is what the Hardware and Base health tabs measure the base's own supervision heartbeat against, so changing it here changes those readings too.

What supervision does and does not do

The pill is a live indicator on this list, refreshed every 30 seconds while the tab is open. A receiver failing to test does not yet raise an event, a notification or an escalation on its own — an operator has to look. Panels reporting through the receiver keep their own offline supervision regardless.

Paused receivers are still supervised (their signals still arrive; only events are held). Inactive receivers are not.

Counting signals over a window

The Webhooks column is a lifetime counter by default. To see how busy a receiver has been lately, use the Signals over chips above the table: All time, 30 days, 7 days or 24 hours. The choice applies to every row, is remembered in your browser, and the column heading names the window while one is on.

With a window chosen, each cell shows the number of inbound messages the receiver took in that window in bold, with the lifetime figure underneath so nothing you used to read there is lost. All time puts the column back exactly as it was, including the per-feed split on Olarm receivers (the feeds are only counted over all time).

Where the windowed numbers come from

CleverOps samples every receiver's counter every ten minutes and works the window out as the difference. Sampling began on 5 September 2026, so until a full window of samples exists the figure is counted from the oldest sample instead and the cell says since 5 Sept in amber. The 30-day window fills on 5 October; 7 days and 24 hours are already complete. A receiver added since the last sample shows — for a few minutes until it has one.

The windowed count is the same thing the lifetime counter counts — every inbound message, keep-alive pings included — so a receiver that only pings still shows a number here. The Radios column is the one that says whether real signals are getting through.

Radios and unrouted radios

Most receivers create a panel record automatically for every radio they hear, so a radio shows up in CleverOps as soon as it transmits — before anyone links it to a site. Those unlinked radios keep transmitting, but because they are not bound to a site their signals raise no events.

The Radios column shows both halves of that picture per receiver:

• The top figure is the total distinct radios the receiver has ever heard.
• Underneath, in amber, how many of those are currently unrouted and the total signals they have sent — or none unrouted when every radio is bound.

Hovering the cell explains the state and points to where to fix it.

Unrouted is a live count, not a running total

A radio counts as unrouted only while it resolves to no site. The moment its panel is linked, it drops out of the unrouted figure and stays in the total — so the number always reflects what still needs attention, not everything that ever needed it.

This column is also the quickest way to tell whether a receiver is actually receiving anything. Webhooks counts every inbound message including keep-alive pings, so a receiver that a panel platform has pointed at you but attached no panels to still shows a recent Last Webhook — while Radios and Panels both sit at zero. A receiver with zeros across Panels, Radios and Webhooks is not being sent anything at all.

To bind these radios to sites, go to Hubs → Identity & Signals — see Identity & Signals.

Exporting a receiver's unrouted radios

To take the list away — to hand to the installer, the alarm company or whoever owns the panels — open the row's More menu and choose Export unrouted radios. It downloads a CSV for that receiver only, named after the receiver and stamped with the date (for example unrouted-radios-fsk-cloud-base-2026-09-14.csv), and a toast says how many radios it wrote.

The file has one line per radio, loudest first (most signals, then most recently heard), with these columns:

Column	What it holds
Receiver	The receiver's label — the same on every line, so files from several bases can be pasted together.
Serial	The radio's serial as CleverOps knows it (the account code on FSK, RDC and FOX bases; the device ID on Olarm; the IMEI on Hyyp).
Radio name	The name on the panel record, if anyone gave it one. Reads No radio matched for a transmitting identity that matched no panel record at all — the same signals the Identity & Signals tab counts as losing signals.
Account code	The account code(s) the radio transmits.
Other identifiers	Any further identity the radio carries that the serial does not already say — a Hyyp panel IMEI, for example.
Signals	How many signals the radio has sent while unrouted. Summed the same way as the amber figure in the Radios column, so the column total matches the screen.
First seen / Last seen	When the receiver first and most recently heard the radio, in your local time.
Last CID	The Contact ID code of the most recent signal — a panel sending nothing but E602 periodic tests is a very different chase from one sending E130 burglaries.
Source	The protocol the signals arrived on.
Notes	Any note an operator left on the radio's pending identity in Identity & Signals.

The export reads live, not the figure on screen: a radio bound to a site a moment ago is already out of the file, even if the row still shows it until the next 30-second refresh. The menu item is greyed out when the receiver has nothing unrouted at all, and if a live read finds nothing, no file is offered and a toast says so.

How a signal finds its receiver

Every inbound signal carries a routing token — for most communicators a base or gateway id issued by the vendor, and for Ajax and Hikvision AX PRO / IP Receiver Pro the panel's own account code, because those protocols put nothing else on the wire. CleverCam matches that token against each receiver's registered tokens to decide which receiver, and therefore which company, the signal belongs to.

Account codes are short and chosen by whoever set the panel up, so two companies can easily pick the same one. CleverCam narrows the match by protocol before it decides: an Ajax signal will only ever land on an Ajax receiver, a Hikvision signal only on a Hikvision receiver, and so on. An Ajax panel numbered 0001 and a Hikvision panel numbered 0001 at two different companies are told apart correctly and never cross.

Hyyp and Onyyx share on purpose

A single IDS VBS base serves both products, so a Hyyp receiver and an Onyyx receiver in the same company legitimately carry the same base id. Signals from that base are allowed to land on either — this pairing is expected, not a fault.

Which of the two a panel belongs to is decided by its device id: an OnyyxHub's id is 16 characters (656B054F23E0FEA4), a Hyyp communicator's is a 15-digit IMEI. A panel that reports through the shared base is created on the matching receiver — an Onyyx hub under the Onyyx receiver, a Hyyp panel under the Hyyp receiver — and a panel registered by TX number moves to the matching receiver when its first signal reveals its device. If your company only has a Hyyp receiver, Onyyx hubs land on it until you add an Onyyx receiver on the same base. Adding one moves the monitor-only Onyyx hubs onto it straight away: their site, zones, partitions and billing stay as they were. Managed panels are never moved.

If a signal's token is only registered to receivers of a different protocol, the signal is rejected rather than routed. It is held for retry and then parked, where it is visible and recoverable — far better than silently attaching another company's burglary to one of your sites. Support can see the reason on the parked signal, which names the token and the receiver that already holds it.

When a token is refused at setup

Two receivers at different companies cannot both register the same token when the same kind of signal could reach either one — there would be no way to tell those signals apart, and on Ajax the panel's encryption key is tied to the receiver, so the frames would not even decrypt reliably.

Linking a panel or saving a receiver in that state fails with a message naming the token, the receiver that already holds it and the company it belongs to. The fix is to give the panel an account code that is unique for that protocol across CleverCam, then link it again. Nothing is saved half-way: the panel is not left linked-but-unrouted.

Olarm's two feeds

Olarm can point two independent feeds at the same receiver: the Proxy feed (the signals-proxy URL configured on an Olarm alarm-company account) and the Consumer feed (the webhook configured on customer Olarm accounts via the Olarm API). A receiver can be on one, both, or neither, and each feed is configured separately on Olarm's side.

Once traffic arrives with feed information, the Webhooks and Last Webhook cells split into one line per feed — Proxy first, then Consumer — each with its own signal count and last-arrival time:

• A feed shows its signal count when it is delivering real signals.
• A feed shows pings only (highlighted) when Olarm is reaching the endpoint with keep-alive pings but no panels are sending signals on that feed — the endpoint is live, but nothing is attached to it on Olarm's side.
• Hovering a line shows the feed's full totals: signals and pings.

The split is informational only — the receiver remains a single row, and edit, activate/deactivate, delete and Manage panels all still act on the receiver as a whole. Receivers with no per-feed traffic yet (and all non-Olarm types) show the single aggregate figures as before.

Duplicate handling

One signal can reach a hub more than once. A radio base hears the same transmission directly and again through its repeater while the radio retransmits, so an FSK base can deliver one arm/disarm or one burglary as two to five frames a few seconds apart. A HYYP panel's event is relayed by both IDS base stations a second or two apart. And when a control room runs a backup path for a receiver, the second path delivers its own copy of everything. Without a rule, each copy raises its own event: an extra open/close line in the site's history, or an extra entry under an alarm already on the board.

Each receiver carries a Duplicate handling setting in its edit form, chosen with three chips:

Rule	What it does	Use it for
Off	Every copy raises its own event, unless it carries exactly the same delivery key. This is what every receiver starts on.	Panels that stamp every event with their own time, such as Olarm — their repeats are genuine events, and folding them would swallow real arm/disarm changes.
Same event time	A copy that carries the identical panel event time as a signal already accepted from the same hub raises no second event, whichever base delivered it. Signals without a panel time are not folded.	HYYP and Onyyx lines, where twin VBS bases relay the same event; FSK cloud clients fed by more than one base.
Window	A copy of the same signal (same CID, partition, zone or user) from the same hub arriving within the window of the first copy raises no second event. The window is counted from the first copy, not extended by each repeat.	Radio lines that carry no event identity: FSK, RDC, FOX, FinMon. 45 seconds covers an FSK base's full burst.

The first copy is the one that raises the event. Every later copy is still received and recorded — on the hub's raw signal log it shows as Duplicate, pointing at the event the first copy raised — so nothing is lost from the record, only the second event. A paused receiver never claims a signal, so pausing one path can never silence the other.

Measure before you switch it on. On an existing receiver, choosing a rule shows a line under the chips: Last 24 h on this receiver: N copies received, M would have merged (alarms, open/close). If some merged open/close copies had an opposite arm or disarm in between, the line says so. On a radio base that retransmits, those are late copies and the rule is doing its job; on a panel that stamps its own events, they are real state changes, and that is the sign to leave the rule Off. The form's hint under the legend says which rule fits the line's protocol.

The rule is per receiver and only that receiver's signals are affected. Nothing changes on a receiver left on Off.

Opening a receiver

Clicking a row opens the receiver, but where it opens depends on the communicator type:

• Master-account receivers (Hyyp + Onyyx) that have a Portal Company ID open the IDS portal mini-app (the route /settings/ids-portal/:id) instead of the edit modal. This is where you manage the IDS-portal side of the integration — partitions, panels and the portal connection — because Hyyp and Onyyx portal access runs through CleverCam's shared master account rather than per-receiver credentials.
• All other types (Olarm, Ajax, FSK, …) open the receiver edit modal, with a stats view, a read-only configuration view (the setup values to paste into the panel platform), and an edit form.

The configuration view is read-only but it is not redacted — it carries the receiver's credential in the clear, with a copy button, alongside the URLs and settings it belongs to. Whoever can open a receiver's configuration is already the person entitled to its credentials, and the Alarm Receivers page is itself permission-gated, so there is nothing to gain by making them click into the edit form to read a value they only mean to copy — and something to lose, because it puts a Save button under their cursor.

Add receiver

Click Add receiver to open the form. Creation is a two-step flow:

1. Label + Communicator Type — name the receiver and pick the communicator brand (only hub types flagged as alarm communicators appear). Click Next.

2. Type-specific configuration — the second step shows only what that brand needs:

   • Olarm — pick the Default input (Signal Proxy for an alarm-company feed, or End-user API for end-customer accounts). Both webhook URLs (the /p/ signal-proxy URL and the /c/ consumer URL) are generated and stay live on the same receiver regardless of the default; copy whichever the panel platform needs.

   • Ajax — an encryption key is generated automatically; the read-only configuration view lists the full Ajax PRO Desktop CMS connection settings (SIA DC-09 over TCP, addresses, port, encryption key).

   • Hyyp — enter the Receiver Serial (the VBS serial that inbound signals are matched on) and your IDS Portal Company ID, then click Verify. The receiver can't be created until verification against the IDS portal succeeds.

   • Onyyx — enter the Receiver Serial and your IDS Portal Company ID, then click Verify. The serial is the same VBS serial as your Hyyp receiver — one IDS base serves both products — and the field is prefilled from your Hyyp receiver when you have one. The OnyyxHub itself is then linked from a site via the Add Hub wizard. A receiver saved without the serial matches no signals: the hub's events land on the Hyyp receiver instead and show up there as an unlinked Hyyp panel.

   • FSK — record the Client ID and Base ID that FSK issued you. There is no connection to set up: FSK already sends to CleverCam, and these ids tell us the signals are yours. See FSK cloud base below.

   • FinMon — enter the Control ID FinMon issued for your control room. See FinMon below.

   Every type except Videofied also carries a TX number (account code) rule fieldset on this step. Leave it blank to inherit the communicator type's default — see TX number (account code) rule.

   For the remaining webhook types (RDC, SpotBot, AVLytics) an API key is generated automatically — no manual entry needed. It is generated once; afterwards it can only be changed through the guarded rotate flow, see Rotating a credential.

Click Create Receiver to finish. Webhook API keys and Olarm URLs are unique per receiver, so the form generates them for you rather than asking you to type one.

Ajax — the receiver alone does not accept any panel

Creating the Ajax receiver generates the encryption key, but it registers no accounts. Every Ajax hub must also be added as a panel (Add Hub → Ajax, entering the hub's account code from Ajax PRO Desktop in the Account code (manual) field — the receiver token is registered for you) before its signals can be used. Until a panel exists, the receiver has nothing to match the signal to: it is acknowledged back to the panel — so Ajax PRO Desktop shows it as delivered — and then discarded. If you are pointing an Ajax Translator carrying a whole account base at CleverCam, add every hub first, then switch the Translator over.

The account code is whatever you set in the hub's monitoring-station settings. It is usually the Ajax hub ID (for example 00211F8C), but if you are migrating from another monitoring platform you can keep your existing account numbers instead — plain digits such as 9973 work exactly the same. Whichever you use, the code in CleverOps must match the code the hub sends, character for character, and it must not already be in use by another panel anywhere in CleverCam — including on a different control room's receiver, and including non-Ajax panels. Short numeric codes collide far more easily than Ajax hub IDs do, and a collision can send the alarm to the wrong control room.

Adding panels in bulk

Adding a panel registers its account code with the receiver automatically — whether you add it through Add Hub, or it arrives as part of a bulk import or migration. This is handled for Ajax and Hikvision AX PRO / IP Receiver Pro, the two protocols where the panel's account code is also what identifies the receiver.

A receiver that shows panels but has never received a signal is worth checking: for Ajax, a panel whose account code is not registered still decrypts and acknowledges normally, so the panel side looks completely healthy while nothing reaches the control room.

Verify before saving (Hyyp + Onyyx)

For Hyyp and Onyyx, the master account must already be a member of (or hold a pending invite to) your IDS portal company. Add CleverCam's master account in your IDS portal under Company → Members, then enter the numeric Company ID and click Verify. If an invite is pending, Create Receiver accepts it for you. A portal company can only be linked to one CleverOps control room at a time.

FSK cloud base

FSK offers two ways to deliver signals, and CleverCam supports both.

	Cloud base	Physical base
What it is	An FSK-hosted base station	An FSK base station in your control room
How to add it	Add receiver → FSK (this tab)	As a channel on a receiver gateway (Super Admin → Receivers → Add Gateway)
What you configure	Client ID + Base ID	The gateway's serial port

FSK has one connection with CleverCam, not one per control room. FSK points its cloud base at us and we start receiving — there is no endpoint for you to set up, no URL to hand over, and no password for you to manage. CleverCam holds that arrangement with FSK on behalf of every control room. What you record here is which of FSK's bases are yours.

All you do is record the ids FSK issued you, so we know which control room a base's signals belong to. Every account on a base arrives over that one connection, so there is nothing to configure per site either.

To set it up:

1. Ask FSK for your Client ID (issued per client, e.g. FSK DEV) and your Base ID (issued per base instance, e.g. DEVCB1 — the C marks a cloud base).
2. In Add receiver → FSK, enter both and save. That's it — FSK's next signal for your base routes to this control room.

Check the Base ID spelling with FSK

FSK sometimes writes a Base ID with a % where the C belongs — CSW%B3 for CSWCB3. Every real Base ID follows <PREFIX>CB<number>, so if yours has a % in it, ask FSK to confirm the exact spelling before you save. Enter what they confirm; CleverCam recognises the base either way, but the recorded ID should match theirs.

Once FSK starts sending, each account code appears as a monitor-only panel under this receiver. Link each panel to its site the same way as any other communicator.

An unlinked panel raises no events

A panel that is not linked to a site still has its partition and zone state tracked, but its signals do not become events — nobody is alerted. Link every panel that FSK is sending you.

One cloud base per FSK client — never two clients on one base

FSK issues the Client ID and Base ID per client company, not per control room. Most control rooms are one FSK client and so have one cloud base. A bureau that monitors several FSK clients is issued a separate pair for each, and each one gets its own receiver — add them one at a time.

Never record a second client's Base ID on an existing receiver. An account code is only unique within its receiver, and FSK reuses the same 5-digit codes across different clients. Two clients sharing one receiver would make two different customers resolve to the same panel, so one customer's alarm would arrive attributed to the other's site.

The Client ID and Base ID are unique across all of CleverCam, so no other control room can register yours. Because FSK signs in with a single CleverCam-wide credential, the Base ID is what tells CleverCam which control room a signal belongs to. Enter exactly the ids FSK issued you, and nothing else — a Base ID decides where a live alarm feed lands. If CleverOps tells you an ID is already registered elsewhere, confirm it with FSK; if it is genuinely yours, contact support, which releases it deliberately rather than on request.

Moving from the physical base to the cloud base

The two bases are separate receivers, so panels do not move across by themselves. After the cloud base starts delivering, each account reappears as a new unlinked panel and must be re-linked to its site. Nothing is lost — but plan the cutover rather than switching mid-shift.

FinMon

FinMon does not send webhooks. Its alarm server opens a TCP connection to CleverCam and pushes signals down it, so there is no URL and no API key anywhere in the integration. What identifies your control room is the Control ID that FinMon stamps on every message it sends, including its keep-alives.

FinMon issues the Control ID, and only after it has created a virtual control room for you. That is a request you make to FinMon — it cannot be done from CleverOps, and CleverCam cannot choose the number. Until FinMon has created it and started sending, the receiver sits at 0 webhooks / Last webhook: Never, which is accurate rather than a fault.

To set it up:

1. Ask FinMon to create a virtual DirectJSON control room for you, pointed at CleverCam's receiver address.
2. Ask them for the Control ID they assigned it (a short number, e.g. 861).
3. In Add receiver → FinMon, enter it and save.

Once FinMon starts sending, each reporting panel appears as a monitor-only panel under this receiver, identified by its own four-digit panel id. Link each one to its site.

The Control ID is the only thing that routes

A FinMon receiver saved without its Control ID matches nothing. Signals still arrive and are still acknowledged back to FinMon — so FinMon shows your control room as connected and healthy — and are then discarded. CleverOps now refuses to create the receiver without one, but if you see a FinMon receiver stuck at 0 signals while FinMon insists it is sending, check the Control ID first.

One control room, many panels

Every panel FinMon monitors for you arrives over the same connection under the same Control ID — there is nothing to configure per site or per panel. A second FinMon receiver is only needed for a genuinely separate control room, with its own Control ID from FinMon.

Editing a receiver

For non-master-account types, the edit modal lets you rename the receiver, rotate credentials, and copy the setup values. The communicator type and the IDS Portal Company ID cannot be changed after creation — to re-link against a different portal company, create a new receiver and migrate the hubs across.

Rotating a credential

A receiver's credential is only ever generated for you — on create, once. After that it is live out in the field, and replacing it can only break connections, never restore them, so both credential types sit behind a deliberate flow rather than a button you can catch with a stray click:

• Ajax encryption key — Regenerate Key, confirmed by typing regenerate. Connected hubs stay broken until each is re-entered in Ajax PRO Desktop.
• Webhook API key (RDC, SpotBot, AVLytics and the other webhook types) — Rotate API Key. There is no plain Generate button on a receiver that already has a key. The red button opens a panel naming how many linked panels it will cut off, and the confirm stays disabled until you type the receiver's name exactly. The new key is local until you press Save Changes, and an Undo — keep the current key button restores the old one right up to that point.

For SpotBot and AVLytics the key is the webhook URL, and each device stores that URL in its own firmware — a new key means visiting every device before its signals resume. Rotate only if the URL has leaked; it will never fix a receiver that has gone quiet.

The edit form also carries Hub offline supervision — the default for every hub reporting through this receiver (a hub's own setting overrides it):

• Inherit — each hub follows its hub-type default. This is what every receiver starts on.
• Unsupervised — never flag these hubs offline — the hubs are never marked Offline and raise no offline events. Use it when the vendor supervises its own radios (a radio network like RDC monitors radio health itself, so CleverCam flagging every radio that never heartbeats would only generate noise).
• Offline after N — supervised, flagged offline after that quiet period.

See Offline supervision for how the hub → receiver → hub type inheritance resolves and exactly what Unsupervised switches off. The receiver's own fail-to-test window is not on this form — it is set in place on the list, see Receiver supervision (fail to test).

Editing an FSK cloud base lets you correct the Client ID or Base ID if FSK reissues them. Only change them to match what FSK actually issued: the Base ID is what routes your feed, so a wrong one means FSK's signals no longer resolve to this control room. They are rejected downstream and held for redrive rather than lost, but nobody is alerted in the meantime.

TX number (account code) rule

A TX number (account code) is the premises' identity on the wire — the number the panel transmits with every signal — and it is unique per receiver line, not per control room: two of your bases can each hear a 1766, and it is the line that says which premises is meant. A code typed wrongly at setup silently orphans the panel (its signals arrive and match nothing), so each receiver can carry a rule for what a valid code on that line looks like.

The TX number (account code) rule fieldset sits on both the create step and the edit form (it is not shown for Videofied). Four fields, all optional:

Field	What it does
Minimum length	The shortest code the line accepts.
Maximum length	The longest.
Digits only	Inherit, Yes or No — whether the code must be all digits.
Zero-pad to	A width the line pads short all-digit codes out to before saving — 1766 becomes 01766 on a 5-digit line.

A blank field inherits the communicator type's default: FSK 5 digits, RDC 4, FOX 4, Ajax 4–6, Hikvision 3–8 characters. Olarm, HYYP, FinMon and AVLytics have no default, so on those lines nothing is checked until you set a rule. An Effective rule: … line under the fieldset summarises what the line ends up enforcing once inheritance is applied.

The rule is enforced on operator entry only: Add hub, Replace communicator and the hub editor's Correct TX number all refuse a code that breaks it — the reason is shown in red under the field (for example "TX number 1766 is 4 characters; this receiver expects at least 5 (a short code silently orphans the panel)") and the button stays disabled. It is never applied to incoming signals — a radio is recorded exactly as it transmits, whatever the rule says.

Zero-pad turns a short all-digit code into the line's width before it is saved, and the operator is shown the padded code before confirming — the field reads "Will be saved as 01766 — this line pads codes with leading zeros." Leave it off unless the base really pads: the record has to match what the radio transmits.

Route a new device on a known TX number

On Olarm, HYYP and Onyyx lines the same fieldset carries a switch, Route a new device on a known TX number, and it is on by default. It decides what happens when a communicator is swapped in the field and the new unit is programmed with the TX number of a panel already on a site:

• On — the new unit's signals reach that panel's site straight away, and the new device is flagged under Hubs → Identity & Signals ("new serial on known account") for an operator to confirm the swap or, if it is really a different premises on a clashing code, to split it.
• Off — the new unit is parked as an unlinked radio and flagged, and the site hears nothing from it until someone runs Replace communicator.

Either way the flag is raised at once; the switch only chooses whether the site stays live while it is dealt with. It has no effect on FSK, RDC, FOX, FinMon, Ajax or Hikvision lines, whose radios are identified by the TX number itself. A twin that was already parked before the switch was on still needs Replace communicator once — the switch prevents the next one.

Deleting a receiver

Open the receiver (click its row — or More → Receiver settings for a Hyyp or Onyyx receiver), click Edit, and use Delete receiver in the Danger zone at the bottom. It asks you to confirm, and tells you how many alarm panels are linked and will be unlinked. Deleting unlinks every panel from the receiver first, then removes the receiver itself.

Unlinked panels stop raising events

The panels are not deleted — they stay on their sites with their partition and zone state intact. But an unlinked panel's signals do not become events, so nobody is alerted until you link each one to another receiver. If you are replacing a receiver rather than retiring it, create the new one and re-link the panels before deleting the old.

Hardware

The Hardware sub-tab lists the physical equipment CleverCam has provisioned for your control room. It is a live status view: you cannot add, edit or remove devices here — hardware is commissioned by CleverCam, so contact support to add or replace a device. Click Refresh to re-read the latest report; the "ago" times keep counting on their own between refreshes.

If nothing has been provisioned yet the tab shows "No hardware on this control room."

Routers

One row per site router (for example a Teltonika RUT906 or RUT200) — the box that gives your control room its internet link with LTE failover. Routers report every 5 minutes.

Column	What it shows
Router	The router's name, its location and its serial number.
Model / FW	The router model and the firmware it is running.
Status	online (reported in the last 15 minutes), late (15–45 minutes), offline (older) or unknown (never reported). Status is derived from the age of the last report, not from a stored flag.
Internet	Which link was carrying traffic at the last report (for example wired), with the primary and backup links underneath. If the backup link is the active one, the badge turns amber and reads failover active.
Mobile	The mobile operator and connection type on the LTE side, which SIM slot is carrying it, and its IP when connected.
SIMs	One line per SIM slot: the slot number, the carrier the card registers on (Vodacom, MTN…), a status badge and the last digits of the card's ICCID (hover for the full ICCID, IMSI and APN). See Two SIMs.
Signal	LTE signal quality — strong, ok, weak or poor — with the raw RSRP / SINR / RSRQ figures underneath. weak still passes traffic; poor is unusable.
Gateways behind it	The serial receiver gateways that sit on this router's network, each with its channel count.
Uptime	How long the router had been up since its last reboot, as at the last report.
Last failover	When the router last switched to its backup link.
Last seen	When the router last reported.

Two SIMs

A dual-SIM router (the RUT906) carries a second card as a backup to the first — typically a Vodacom card in slot 1 and an MTN card in slot 2, so that one network being down does not take the LTE backup with it. The SIMs column lists both slots.

The router has one modem behind a switch, so it can only read the card it is currently on. That is why the two lines are not the same kind of reading:

Badge	What it means
active	The slot the modem is on now, with a working data session. active · no data means the modem is on this card but has no session yet.
standby	The other slot. Underneath it says how the card was last proven — data verified 3d ago means the router's weekly self-test switched onto this card, made a real request over it and switched back; data FAILED means that request did not get through; seen … means the card was last read at that time but not tested; card remembered by the router, not yet self-tested means the router knows a card is there but has never proven it.
empty	No card in that slot, as at the time shown.

The self-test runs once a week (early Sunday morning) and only while the wired link is carrying the control room's traffic — it takes the LTE backup down for about two minutes each way, so it never runs while the router is on mobile. A standby card's line is therefore always a little dated; that is expected. What matters is that it was verified recently and that the router is back on its primary card, which the Mobile column confirms (SIM 1).

If a router shows no slot lines and just one ICCID, it is on the older telemetry script and reports its single active card only.

Readings from a router that has stopped reporting

Only Status and Last seen describe the present. Internet, Mobile, Signal and Uptime are all readings the router itself sent, so they keep their last value for as long as the router stays quiet — a router that was unplugged a fortnight ago still holds the last "wired, ok signal" it managed to report.

So a router that is not online dates its own row. Under the Status badge it reads "readings below are from 14d ago", and the Internet and Signal badges drop their green and turn grey, with the uptime greyed alongside them. Grey means last known, not current — the reading is still useful for working out what the router saw before it went quiet, but it is not telling you anything about right now.

A late router (15–45 minutes) keeps its normal colours and just gets the dated caption: the readings are old enough to say so, recent enough to act on.

Serial receiver gateways

One row per physical serial gateway (for example a USR-N520 / N540) — the box that bridges your physical base stations (FSK, RDC, C20, FOX) onto CleverCam. Each serial port on a gateway is one base-station channel, and each channel appears as a receiver on the Receivers sub-tab.

Column	What it shows
Gateway	The gateway's name and MAC address.
Model / FW	The gateway model and firmware.
Receiver	The logical receiver (redundancy group) the gateway belongs to, and its mode — single, active / standby or active / active. Reads not grouped if it has not been assigned yet.
Role	The gateway's role in that group — primary, standby or active.
Link (MQTT)	Whether the gateway itself is connected to CleverCam — see Two separate liveness signals below.
Router	The router the gateway sits behind (with that router's active link), or none.
Channels (serial)	Each configured channel: its port number and base-station name, its supervision health (healthy, late, offline or unknown, from how recently the base last heartbeated) and when that last heartbeat was. If no channels are configured yet, the port count is shown instead.
Last seen	When the gateway last checked in.

Two separate liveness signals

A serial gateway can fail in two independent ways, and the tab reports them in two separate columns rather than one combined light — because which one is red tells you where to send someone.

• Link (MQTT) is the gateway's own connection to CleverCam. It reads Online while the box holds its connection, Offline the moment the connection drops (with the reason underneath, e.g. a keep-alive timeout), and Unknown if the box has not connected or disconnected since this monitoring was switched on — connection status is only reported when it changes, so a box that has simply been up the whole time shows Unknown until its next reconnect.
• Channels (serial) is the alarm base station talking to the gateway down the serial cable.

Read them together:

Link	Channels	What it means
Online	healthy	Everything is working.
Online	late / offline	The gateway is fine and reachable — the serial cable or the base station is the problem.
Offline	anything	The gateway itself is unreachable — power, network, or the router behind it. Its channels will go stale shortly.

caution

A base station's own supervision is not frequent. On an RDC/D20 base it arrives roughly hourly, so a channel legitimately shows a last heartbeat that is tens of minutes old. Frequent traffic on a channel is individual panels reporting, not the base checking in — a channel can look busy while the base's supervision is overdue, and vice versa. The Link (MQTT) column is the one that answers "is the box alive right now".

On an RDC network that hourly heartbeat is often a repeater self-testing rather than the base itself. It still proves the whole path works, but it means one repeater going quiet can make the channel read as failed. Use the Base health tab to tell those apart.

Base health (experimental)

The Base health sub-tab answers a question the other two cannot: is the base still hearing its panels? A base whose radio side is degrading keeps its own supervision arriving on schedule while quietly hearing fewer and fewer panels — so neither the Link nor the Channels column would change.

For each base station it shows how many panels are registered against it, how many were actually heard in the last 24 hours, 6 hours and 1 hour, and the resulting coverage percentage.

Column	What it shows
Base station	The base and its port on the gateway.
Panels registered	How many panels are on this base in CleverOps.
Heard (24h)	How many of them sent anything in the last 24 hours.
Coverage	Heard ÷ registered. Green from 80%, amber from 40%, red below.
Recent (6h / 1h)	The same count over shorter windows — a quick read on whether it is still moving.
Signals 24h	Total signals on the channel, not unique panels.
Via repeater	Share of signals relayed rather than heard direct. Shown as not decoded on networks where the wire format does not carry it.
Supervision	The channel heartbeat, same as the Hardware tab.

caution

This tab is experimental and advisory — read it as a hint, not an alarm.

• A low figure can mean a quiet estate, not a deaf base. Panels that only transmit when armed or disarmed simply are not heard on a quiet day, so a control room whose panels do not self-test will always read low. Two bases can legitimately sit at 98% and at 9%.
• There is no baseline yet. Signal history is a rolling window, so coverage compares against the registered panel list, not against what this base normally achieves.
• The meaningful signal is coverage falling on a base that used to be high, and the useful cross-check is coverage against supervision: supervision stale while coverage holds up points at a repeater; supervision fine while coverage collapses points at the base.

note

Only routers and gateways installed by CleverCam appear here. Cloud-hosted communicators (Olarm, Ajax, Hyyp, an FSK cloud base and so on) have no hardware on your premises and are only listed on the Receivers sub-tab.

Alerts

The three sub-tabs above show you what is happening when you go and look. This one is about being told without looking.

Every minute, CleverCam checks each of your receivers, serial gateways and site routers. When one goes quiet for longer than it should, a message is pushed to your control room's group chat — Telegram today, WhatsApp and voice to follow. When it comes back, you are told that too.

Why this exists

Silence is the failure mode, and silence does not announce itself. A control room with four receivers does not notice when one of them dies, because the other three keep the desk busy. Turning this on in September 2026 immediately surfaced a base-station feed that had been dead for 31 days and a control-room router that had stopped reporting 15 days earlier — in both cases with nobody aware.

What gets watched

Fault	What it means
Router offline	A site router has stopped reporting. Either the router is down or its reporting script has stopped. Anything behind it cannot reach us; cloud receivers are unaffected.
Router on backup link	The primary internet link dropped and the router is running on its LTE backup. Signals keep flowing, but there is no second path left.
Gateway link down	A serial receiver gateway has dropped its session to AWS IoT. Base stations on that box cannot deliver until it reconnects.
Base station silent	A base station on a serial gateway has stopped delivering — no signals and no supervision heartbeat.
Receiver silent	A cloud receiver (Olarm, Ajax, Hyyp, FSK cloud base…) has gone quiet for longer than it ever normally does.

How quiet is too quiet

There is no single number, because there cannot be one. A receiver carrying a thousand panels is late after twenty minutes; one carrying a single panel that reports twice a day is not late after twenty hours. So each receiver is measured against its own traffic: CleverCam learns the gaps between that receiver's signals over the last fourteen days and raises a fault only when the current silence is well past anything that receiver has normally shown.

Two consequences worth knowing:

• A receiver that has never delivered a signal is never reported as down. It has not proven it works, so calling it broken would be a guess. It shows as unknown instead.
• A brand-new receiver stays quiet for a few days while there is enough history to measure it against. Setting a supervision window on the receiver (see Receiver supervision) tightens it immediately.

A serial base station is different: it sends a real supervision heartbeat on a known cadence, so it is judged against that, and against its own signals — a base that is delivering alarms is alive whatever its heartbeat says.

One fault, one message

When a router goes down it takes its gateway and every base station behind it with it. That is one incident, not six messages. CleverCam announces the router and folds the knock-on faults underneath it; they appear in the Open faults table marked Folded into a bigger fault, and they clear on their own when the router comes back.

A fault that is still open is chased every six hours, four times. After that it stops nagging and appears instead in a daily 07:00 summary of everything still down — so a long outage stays visible without filling the group chat.

The very first check after this was switched on adopted everything that was already broken without announcing it, because announcing a month of backlog as if it had just happened would have taught the room to ignore the channel on day one. Those faults appear in the daily summary and on this tab, and — importantly — their recovery is announced normally. A device that has been down for weeks coming back is exactly the kind of news the room wants.

The tab itself

Where these alerts go lists each destination for this control room.

Column	What it does
Channel	The transport — Telegram today.
Address	The Telegram chat ID of the group that receives the alerts. Editable in place.
Send at least	Everything, Warnings and faults (the default), or Faults only. A router on its backup link is a warning; a router that is off the air is a fault.
Active	Switch a destination off without deleting it.

Open faults is what is down right now, straight from the last check — the fault, the device, how long it has been quiet, how long it was allowed to be quiet, whether the group chat has been told, and when the watch first saw it.

There is nothing to acknowledge, and that is deliberate. A fault leaves this list when the device comes back and not before; dismissing one would only teach the room to dismiss the thing rather than fix it, and it would reappear on the next check anyway.

Recently cleared shows the last ten faults that recovered on their own, with how long each was down.

Test routing

While this is being proved out, every control room's alerts are routed to CleverCam's own Pretoria HQ group. The message always names the control room it is about, so nothing is ambiguous. Giving a control room its own group is a matter of replacing the chat ID on its row — no other change is needed.

Brand-specific setup guides

This tab is the entry point; each brand has its own step-by-step setup guide:

• Olarm hub setup — the two inbound feeds (signal proxy vs end-user API) and where each webhook URL goes.
• Hyyp hub setup — the HYYP Virtual TCP base station and the IDS portal connection.
• Onyyx hub setup — linking an OnyyxHub through the master account.
• Videofied (Frontel) setup — video-verified panels that report via the customer's own Frontel server. Needs a static IP and a serial + account code per panel.

Related

• Alarm Types & Groups — how the raw CID codes a receiver delivers map to alarm-handling event types.
• Action Plans — the action plans that decide how each delivered alarm is handled.