Test signals
The Test signals tab (left nav → Hubs → Test signals) shows how often each third-party alarm radio actually sends its periodic test, and compares that with the fail-to-test window the radio is supervised with today.
Most panels are set to send a periodic test — Contact ID E602 — on a fixed period: every 5 minutes, hourly, or once a day. Missing tests are how a control room notices a dead radio. Until now the platform only kept the time of the last test, so the fail-to-test timeout had to be one blanket value that is too short for a daily-testing panel and too long for a 5-minute one. This tab is built on a record of every test signal as it arrives, so it can show each radio's real period.
The tab appears alongside Identity & Signals once Allow 3rd Party Alarm Receivers is on for the control room (see Modules & Capabilities). It covers third-party communicators only — CCUs and CleverMail cameras do not send Contact ID tests.
The suggested window is what a per-hub fail-to-test setting would be if it were driven by this radio's own history. CleverCam never adopts a suggestion on its own: no background job re-tunes your timeouts. The only way one takes effect is applying it yourself, for radios you select, behind a confirmation. Offline supervision otherwise stays where it always was — on the hub, the receiver or the hub type (see Alarm receivers).
What counts as a test
- Test-family CIDs: E602 periodic test, E603 periodic RF transmission, E608 periodic test with a trouble condition present, plus E601 / E605 / E606 / E607.
- Repeated deliveries within 60 seconds count as one test. Some radios (FSK in particular) transmit the same test three or four times inside a few seconds; those are one test, not four. The Tests column shows the number of tests, with the raw signal count in brackets when they differ.
- Radios on a paused receiver are still counted — pausing holds events back, it does not stop the signals arriving.
The page
Window (top right) — the period the statistics are computed over: last 24 hours, 7, 14 (default), 30 or 90 days. Refresh re-runs the query.
Summary tiles — click a tile to filter the list to those radios:
| Tile | Meaning |
|---|---|
| Radios testing | Radios that sent at least one test in the window (tests · raw signals underneath). |
| Typical period | The median period across all reporting radios. |
| Overdue | Radios silent for longer than their own usual period allows (more than 2× their median gap, or past their p90). The radio may be dead, or its timing has changed. |
| No tests | Radios that sent no test at all in the window (panic radios are excluded — they never test). |
| Irregular | Radios whose 90th-percentile gap is more than 3× their median — a jittery or multi-rate radio. |
| Timeout too short | The fail-to-test window in force today is shorter than the radio's p90 gap — a healthy panel will be flagged offline. |
| Timeout too long | The window is more than 4× the radio's median period — a dead radio is only noticed long after it stopped. |
Below the tiles, one chip per hub type shows radios reporting / radios total · median period · overdue count.
Filters — free-text search (hub label, serial, account code, site, type or receiver name — an Olarm or HYYP panel's serial is its device ID, so search by the account code the installer knows it as), Hub type, Receiver (All receivers, one entry per receiver the radios in the list report through, and No receiver when some radios have none), Show (all, outliers, overdue, irregular, no tests, timeout mismatch, tests with trouble, healthy) and Sort (type & name, receiver & name, shortest period, widest spread, longest silence, newest test, most tests).
Columns
Columns (beside the search box) chooses which columns the table shows and in what order: tick or untick a column, use the arrows to move it left or right, and Reset to default view to go back. The button shows how many columns are hidden. Your choice is saved against your login, not the browser, so it follows you to another computer. Hub is always shown, and the selection checkbox always stays first. Receiver and Same code on are off until you turn them on.
| Column | Meaning |
|---|---|
| Hub | Label and serial. The chevron opens the radio's recent signals. |
| Type | Hub type. |
| Receiver (off by default) | The alarm receiver — the base or feed — this radio reports through, for example FSK Base - Gateway Port 4 or FSK Cloud Base. — when the hub has no receiver. |
| Same code on (off by default) | Other receivers holding a hub of the same type with the same account code, leading zeros ignored — one entry per match, reading receiver · last test … ago (or any: … ago, its last signal of any kind, when it sent no test in the window). Hover an entry for that hub's site and exact times. — when there is none. See One radio, two receivers. |
| Site | The linked site (Unlinked if none). |
| Tests | Tests in the window; raw signal count in brackets when repeats were merged. Hover for the first test's time. |
| Period | Median gap between tests. Hover for min / median / max. |
| p90 | 90th-percentile gap — how late a test can normally be. |
| Last test | Time since the last test. If there were no tests, any: … ago shows the last signal of any kind, so you can tell a silent radio from a radio that talks but never tests. |
| Timeout → suggested | The fail-to-test window in force today (hub → receiver → hub-type default; the engine's 21-minute floor applies) and what this radio's history suggests: p90 × 1.5, never under 2× the median, rounded up to the minute. A suggestion needs at least 5 tests. off means offline supervision is switched off for the hub. |
| Status | Healthy, Overdue, Irregular, No tests, Too few to judge (under 3 tests), Timeout too short / too long, Unsupervised, and E608 ×n when tests arrived with a trouble condition. Hover any pill for the reasoning. |
One radio, two receivers
A control room can have two receivers that hear the same radios — for example a physical FSK base
on a gateway port and an FSK cloud base. Each receiver keeps its own hub for the radio, so the
same radio appears in this list once per receiver, and the two may even write its code
differently: the physical base (FSK Base - Gateway Port 4) stores 01573 where the cloud base
(FSK Cloud Base) stores 1573.
Turn on Receiver to see which base each row came from, and Same code on to see the other
copy: the Port 4 row for 01573 shows FSK Cloud Base · last test …, and the cloud row for
1573 shows FSK Base - Gateway Port 4. Use the Receiver filter to look at one base at a
time, or sort by Receiver, name.
Same code on means the same account code, not the same panel. Two bases can reuse a number
for different panels — two RDC bases, for instance, can each hold a 1234 that belongs to a
different customer. Check the site before treating two rows as one radio.
Applying a suggested window
You can put suggestions into effect in bulk, but only deliberately.
- Tick the checkbox on each radio you want. A checkbox is only available once that radio has at least 5 tests in the window — without that there is no suggestion to apply. Hover a disabled checkbox to see why.
- The header checkbox selects every radio on the current page that has a suggestion. Once something is selected, the bar above the table also offers Select all N matching, which extends the selection to every radio matching your current filters, across pages.
- The bar shows N selected and, when they differ, how many would change — radios already sitting on their suggestion are counted but left alone.
- Apply suggested window to N opens a confirmation listing the first few radios and their current → suggested values. Nothing is written until you confirm.
Each radio receives its own suggested value — this is not one shared number applied to a group. Applying sets a hub-level override with supervision switched on, which takes precedence over an "off" set at receiver level. Values are capped at 48 hours (the maximum a hub timeout can hold), and every change is written to the audit log with the value before, the value after, and the statistics behind it.
To change or clear a window afterwards, edit the hub — see Hub management. Changing your selection or the window clears the selection, so you always apply what you can currently see.
The fail-to-test window decides how long a radio may stay silent before the control room is told the panel is dead. Too short and healthy panels raise false "panel link down" events; too long and a genuinely dead radio goes unnoticed. Apply suggestions when the measured period looks trustworthy — several tests, a steady spread, no Irregular pill.
Recent signals
Click the chevron on any row to open that radio's last 20 raw signals, newest first — every signal the platform resolved to this hub, not just tests, with what happened to each:
| Outcome | Meaning |
|---|---|
| Event | An event was created (the event number is in the last column). |
| Test / heartbeat | A test-family CID: stamped the hub's heartbeat, no event. |
| Ignored (CID off) | The CID is disabled in the CID catalogue. |
| Log only | The source generates this code itself rather than the panel — FinMon's app-login E466 / R466 — so it is recorded here and nowhere else: no heartbeat credit, no event, nothing on the desk. |
| No site | The panel is not linked to a site — zone/partition state was tracked, no event raised. |
| Duplicate | The same signal had already been processed. |
| No event | The event step declined to raise one (receiver paused, restore with nothing to restore, receipt de-duplication). |
| Photo lane | Handled by the managed photo-camera lane. |
| Error | Processing failed; the pipeline retried it. |
Each row shows the received time, the CID (with the wire CID in brackets when it was normalised), its catalogue meaning, partition / zone / user, the source protocol, the Receiver that delivered it, and any processing notes. The platform keeps the last 100 signals per hub; the drawer shows the newest 20. Signals started being recorded on 16 August 2026, so older history is not available.