Connecting a Roombanker alarm system to an Alarm Receiving Centre (ARC) involves work at the site and at the monitoring centre. The installer sets up the Hub and tests the devices. The ARC checks that it receives the reports and can identify the right site and event.
This guide covers what to prepare, how to test together and what to check when a report is missing or incorrect.
The path is simple:
Device → Hub → network → ARC receiver → operator
For example, a shop’s rear-door alarm reaches the Hub, which sends a report to the ARC. The operator identifies the shop and follows the customer’s monitoring instructions. Planning connects the equipment to that service.
For an introduction to the service itself, see What Is an Alarm Receiving Centre?.
Before installation: get the details from the ARC
Ask the ARC for the connection details and agree what will be tested. This lets the installer finish the site work and the ARC prepare its records before the joint test.
| Prepare | What you need |
|---|---|
| ARC contact | Who will help with setup and testing, and when they are available. |
| Reporting method | The protocol and receiver the project will use. |
| Connection details | Main Address, Port Number and Account Number for the RB Link ARC setup. |
| Site and device references | How the ARC will identify the account and any supported zone or point information. |
| Events | Which supported events the customer wants reported and which will be tested. |
| Network | The Hub’s network connection and any backup connection included in the project. |
| Customer contacts | Who the ARC should call and what to do if that person is unavailable. |
Roombanker supports SIA DC-09 and ADM-CID/Contact ID reporting. Confirm the receiving setup with the ARC. The SIA DC-09 guide and Contact ID guide explain the protocols in more detail.
Make locations easy to recognise
Use clear device descriptions in the project records, such as Ground floor — rear door — door contact or Stockroom — north aisle — PIR.
Match the account and point references received by the ARC to those locations. Names may need to be entered separately at the ARC; do not assume an RB Link device name transfers automatically.
For several shops, use the same naming pattern at each site. A technician returning later should be able to find the device without asking the original installer what “Point 6” means.
Set up the site and Hub
Before testing ARC reporting, check that the installed devices work correctly with the Hub.
| Item | Site check |
|---|---|
| Door contact | Check alignment and opening/closing operation. Place the main body on the fixed frame and the magnet on the moving door. |
| PIR | Follow the model’s installation instructions and test detection along the intended walking route. |
| Wireless connection | Check each device where it will stay. If the connection is weak, investigate its location and nearby obstructions before ARC testing. |
| Alarm settings | Check the settings needed to produce the planned test event, including the relevant armed area. |
| Hub | Check power and an available network connection. |
Pairing can happen before final mounting. The important step here is testing the device in its installed position.
In RB Link, enter the ARC’s Main Address, Port Number and Account Number. Account Number is the username in this configuration.
Record whether the project connects the Hub directly to the receiver or uses RBLinkConvert. The two arrangements differ in how the ARC can see a broken connection, so they need different connection-loss checks.
Test with the ARC
Arrange the test with the ARC before triggering alarms. Agree how test events will be handled so they are not treated as real incidents.
Start with one alarm. Trigger the intended device, note the time and check the local event. Ask the ARC contact which account and event appeared. Then repeat for the other points in the test plan.
RB Link shows local events, not the Hub-to-ARC reporting status. Ask the ARC to confirm receipt.
| Test | Installer action | ARC check |
|---|---|---|
| Intrusion alarm | Trigger the door contact or PIR under the planned alarm conditions. | Correct account and alarm event received. |
| Point identification | Test the agreed points one at a time. | Each supported point or zone reference matches the correct location. |
| Repeat after a correction | Repeat the test that failed after fixing the problem. | The expected report now arrives and is identified correctly. |
Add the other events included in the project
Confirm support for each additional report before adding it to the test plan. The following are possible project requirements, not a list of features available in every setup. Use the device instructions and the agreed test method.
| If supported and required | Installer action | ARC check |
|---|---|---|
| Alarm recovery | Restore the device or reset the alarm as instructed. | Expected recovery report received. |
| Tamper | Carry out the approved device tamper test. | Correct tamper report and device reference received. |
| Arming/disarming | Arm and disarm using the agreed control. | Expected operation and supported identifying details received. |
| Low battery | Use the approved low-battery test method. | Correct device and low-battery report received. |
| Emergency button | Carry out the agreed emergency-event test. | Correct emergency event received, separately from intrusion alarms. |
A successful intrusion test does not test these other events. Include only the reports the installation supports and the customer needs.
Check the backup connection, if fitted
Agree this test with the ARC and restore the normal connection afterwards.
| Test | Installer action | Check with the ARC |
|---|---|---|
| Backup reporting | With the backup available, interrupt the main connection using the agreed method and trigger a test alarm. | Did the alarm arrive? |
| Connection-loss indication | Carry out the connection-loss check agreed for the direct or RBLinkConvert setup. | What indication appeared, if the setup provides one? |
| Restored connection | Restore the main connection and repeat the reporting test. | Are reports received again as expected? |
Receiving alarms over a backup connection and detecting a lost connection are different checks. Do not assume that disconnecting the main network always produces an ARC fault event.
Common problems and what to check
Use what you already know. If the local event is confirmed, move on to the reporting checks. If the ARC received the report but the point is wrong, check the point reference rather than starting again with device pairing.
| Problem | Check first | Next step |
|---|---|---|
| No local alarm event | Device operation, pairing, installed signal quality and relevant alarm settings. | Get the correct local event before testing ARC reporting. |
| Local event appears, but ARC receives nothing | Hub network, reporting method, Main Address, Port Number and Account Number. | Compare with the ARC’s details and ask it to check the receiver at the recorded test time. |
| Wrong account or point | Account number and supported zone/point references. | Correct the mismatch and trigger that point again. |
| Alarm arrives, but another event does not | Whether that event is supported, enabled where required and generated locally. | Ask the ARC to check for that event and repeat its test. |
| Reports stop when the main network is disconnected | Backup availability and setup. | Check the backup connection, then repeat the agreed test. |
| Operator cannot locate the device | Point reference, site plan and location description. | Update the records so the reference identifies a clear location. |
| ARC receives the alarm but cannot contact the customer | Primary and backup contacts. | Update the contact list and call order with the customer and ARC. |
Matching the saved address and account details does not prove the network or reporting software is working. If no report arrives after those checks, compare the available Hub and receiver information with technical support and the ARC. Keep the test time and device reference so everyone investigates the same event.
A short fault-finding order
When the ARC has not received a report, start at the first unconfirmed step:
- Local event: did the intended device produce the correct event at the Hub?
- Network: does the Hub have power and an available connection?
- Reporting settings: do the protocol and connection details match the ARC’s instructions?
- Receiver: did anything arrive at the ARC at the test time?
- Account and point: was the received report identified correctly?
This order avoids unnecessary work. An event already visible at the Hub does not require another pairing test. A report received under the wrong point needs a point check, not a new radio survey.
Keep the handover short and useful
Record what was tested and what the ARC confirmed. Leave any unfinished item clearly assigned to someone.
| Keep | Details |
|---|---|
| Site | Customer, address and ARC account reference. |
| Devices | Device list, locations and corresponding point references. |
| Connection | Reporting method, direct or RBLinkConvert setup, main and backup network if used. |
| Test results | Events tested, date/time, result and ARC contact who confirmed receipt. |
| Follow-up | Any failed or unfinished test, who will resolve it and when. |
| Service contacts | Who the ARC should contact under the customer’s monitoring agreement. |
Store sensitive settings securely with the project records.
The job is ready to hand over when the agreed tests are complete, the ARC can identify the reports correctly and the customer’s contact arrangements are in place. That gives the customer a working monitoring connection and the next technician a clear record to work from.
For help with a Roombanker ARC integration, provide the target ARC, the events you need to report and the proposed network connection.