The main types of burglar alarm systems are not a single list of mutually exclusive products. A system can be classified at the same time by its response model, wired or wire-free interconnection, upstream transmission path, detection coverage, security grade and environment, and installation or service model. A professionally maintained hybrid system, for example, may combine wired detectors, wire-free devices, local warning, app notification and an alarm receiving centre (ARC) path.
That distinction matters because labels such as “local,” “wireless” and “professional” answer different questions. Local describes where the response happens. Wireless describes how selected components communicate. Professional may describe installation, monitoring, maintenance or all three. None of those labels, by itself, proves cost, reliability, police response or suitability for a particular property.
This guide gives installers, integrators, distributors and buyers a repeatable way to classify a burglar alarm system, compare the trade-offs and define what must be verified before a quotation, installation or handover. For the event sequence from detection to notification, use the separate guide to how a burglar alarm system works. This page owns the classification and selection decision.
What are the main types of burglar alarm systems?
Start with six axes. A real system normally has one choice—or a documented combination—on every axis.
| Classification axis | Typical options | Decision it answers | What the label does not prove |
|---|---|---|---|
| Response model | Audible/local, self-monitored, professionally monitored/ARC | Who receives the event and who decides the next action? | Installation method, automatic authority response or outcome |
| Device interconnection | Wired, wire-free, hybrid | How do detectors, controls and warning devices connect to the control and indicating equipment (CIE) or hub? | Upstream internet/cellular path, cost or reliability |
| Upstream transmission | Ethernet, Wi-Fi, cellular, another supported path or a combination | How do supported events leave the premises for an app, cloud service or ARC? | That every path is supported by every hub, market or service |
| Detection coverage | Perimeter/opening, interior/motion, glass/shock, hold-up and other defined inputs | Which event or protected area must be detected or initiated? | Fire, water or video performance unless separately specified |
| Grade and environment | Project-required security grade; indoor/outdoor or another documented environmental class | What level of performance and environmental evidence must the project meet? | Product or system compliance without exact certificates and scope |
| Installation and service model | Self-install, professional install, maintained service, managed monitoring or combinations | Who surveys, configures, tests, maintains and responds? | That a monitored system was professionally installed, or vice versa |
The BSI overview of BS EN 50131-1:2006+A3:2020 describes system requirements for intrusion and hold-up alarm systems using wired or wire-free interconnections. BSI currently marks that edition as “Under Review.” The classification above uses the standard family as a framework; it does not claim that any named Roombanker product or project complies with it.
Keep intrusion, hold-up, fire, environmental and video scopes separate
A burglar or intrusion alarm system is designed around unauthorised entry or movement. A hold-up alarm is a deliberately initiated request for assistance under a defined response procedure. These functions may share equipment or a platform, but their risks, zone logic, user actions and escalation rules are not interchangeable.
Fire and life-safety detection belongs to its own requirements, approvals, siting rules and response plan. Water-leak and temperature monitoring are environmental functions. CCTV can support observation or visual verification, but a camera is not automatically an intrusion detector and a recorded image is not an automatic feature of every burglar alarm.
| Scope | Typical event | Primary design question | Boundary to preserve |
|---|---|---|---|
| Intrusion | Door/window opening, movement, glass/shock or another approved intrusion input | Which entry route or protected area must generate an intrusion event? | Does not prove hold-up, fire, water or video coverage |
| Hold-up | Deliberate operation of a panic/hold-up device | Who may activate it, how is it confirmed and what is the response procedure? | Must not be treated as an automatic substitute for an emergency call |
| Fire/life safety | Smoke, heat or another life-safety condition | Which standards, approvals, siting and response rules apply? | Do not infer fire-system suitability from an intrusion platform |
| Environmental | Water, temperature, humidity or another condition | What threshold/event and mitigation owner are required? | Separate from intrusion grading and police response |
| CCTV/visual verification | Live or recorded visual evidence | Who may view it, under what privacy rules and how does it support verification? | Camera presence does not prove recording, ARC acceptance or authority response |
If the reader first needs the broader distinction between alarm categories and system components, use the security alarm system terminology guide. This article stays focused on intrusion-alarm classification.
Select the architecture in a fixed sequence
Do not begin with “wired or wireless?” Begin with the risk and the required response.
- Define the property and operating risk. Record use, occupancy, access routes, assets, opening schedule, internal movement, out-of-hours activity and any vulnerable or high-risk areas.
- Check insurer, regulation and local-policy inputs. Identify required grade, environmental class, installer/maintenance scheme, monitoring rules and evidence. Requirements vary by market and project.
- Define the response model. Decide who receives an event, who verifies it, who contacts a keyholder or authority, and what happens if the first person or path is unavailable.
- Choose wired, wire-free or hybrid interconnection. Base this on construction, existing cable, device locations, radio survey, power, access, disruption tolerance and maintenance responsibility.
- Map detection coverage. Assign perimeter, interior, glass/shock, hold-up and warning roles to actual zones. Keep fire, environmental and video scopes separate.
- Define upstream transmission. Confirm the exact hub/CIE, supported Ethernet, Wi-Fi, cellular or other paths, account/service dependencies and market variant.
- Design power and communications resilience. State which layers have backup, how long the project needs them to operate, how loss is reported and how recovery is tested.
- Set commissioning and service ownership. Name the installer, system administrator, monitoring provider, keyholders, maintenance owner and evidence required at handover.
The result is an architecture and acceptance plan, not a generic “best type.” Readers evaluating whether an alarm is worthwhile should use the separate benefits and limitations guide rather than turning a taxonomy page into an outcome promise.
Compare local, self-monitored and ARC response models
These response models can share the same detectors or hub. The difference is who receives the event and how escalation is governed.
| Response model | Primary recipient/owner | Main dependencies | How an event may be verified | Escalation boundary | What to confirm |
|---|---|---|---|---|---|
| Audible/local | People at or near the premises; appointed keyholder | Detector, CIE/hub, local warning device, power and an available responder | Local observation or a separately designed verification method | No automatic external response is implied | Sound/visual requirement, placement, duration, keyholder plan and local rules |
| Self-monitored/app | Named users or keyholders | All local layers plus supported network, cloud/service, account, app, permissions and phone availability | User reviews the event and any separately supported information | User action is required unless another service is contracted | Exact hub/app support, account roles, notification settings, network-loss behaviour and fallback |
| Professionally monitored/ARC | Contracted ARC and defined responders | Supported hub/transmitter path, network/cellular service, receiver, account, event mapping, ARC contract and maintained records | According to the agreed alarm-confirmation and receiving procedure | Authority or guard response depends on market rules, evidence, account status and the response plan | Exact receiver/path compatibility, codes, test procedure, escalation order, false-alarm policy and service ownership |
A local alarm is not automatically DIY, cheap or contract-free. A self-monitored system can be professionally installed and maintained. An ARC-monitored system does not by definition guarantee police attendance or prove professional installation.
The self-monitoring burglar alarm guide owns the detailed app/user decision. The ARC integration route is the starting point for a project-specific receiver and monitoring-path review.
As one market-specific example, the UK NPCC Police Operational Advice and Security Industry Requirements for Response to Security Systems, March 2024 distinguishes compliant Type A paths, URNs and response levels. It also states that even Level 1 response depends on current demand, priorities and resources and cannot be guaranteed. This is a UK policy example, not a global response rule. Because the linked edition lists an April 2025 review date, confirm the current NPCC and relevant police-force requirements before design, quotation or handover.
Compare wired, wire-free and hybrid interconnection
“Wireless” is often used too broadly. A wire-free detector-to-hub link does not tell you whether the hub uses Ethernet, Wi-Fi or cellular upstream. Keep field-device interconnection and external transmission as separate decisions.
| Architecture | Cabling and power | Supervision and site checks | Expansion/change | Maintenance | Where it may fit | Conditions that prevent a universal verdict |
|---|---|---|---|---|---|---|
| Wired | Signal/power cable or defined circuit to the CIE/input; backup depends on system design | Circuit state, cable integrity, tamper, resistance/EOL where applicable and power must be tested | New points may require cable routes, spare inputs and building work | Inspect cable, connections, power supplies and backup according to the service plan | New builds, accessible cable routes, existing wired estates or sites where radio is unsuitable | Labour, disruption, cable quality, building constraints and existing infrastructure vary |
| Wire-free | Battery-powered or separately powered field devices communicate by a supported radio path | Enrollment, final-position signal, supervision, interference, battery state and regional variant must be verified | Can reduce new cabling, but every added point still needs compatibility, placement and signal checks | Battery/service intervals depend on device, duty cycle, radio conditions, temperature and policy | Retrofit, finished interiors or changing layouts where supported radio performance is demonstrated | It is not universally cheaper, easier, portable or as reliable as a different architecture |
| Hybrid | Uses both wired and wire-free devices through supported CIE/hub inputs, modules or paths | Both circuit and radio tests are required; cross-layer event mapping must remain clear | Can preserve existing circuits while adding supported new devices | Requires owners and records for both maintenance models | Phased upgrades or sites with usable legacy wiring and new coverage needs | Integration hardware, input type, event mapping, compatibility and responsibility must be exact |
The question “Are wireless burglar alarms any good?” requires a deeper review of radio, supervision, placement and maintenance. That comparison belongs on the wireless alarm evaluation page. Here, wire-free is one architecture axis, not a universal recommendation.
Map the detection and warning coverage
Select coverage by event and zone. Do not use device names as a substitute for the risk map.
| Coverage role | Typical device/input category | Placement or configuration question | Acceptance evidence |
|---|---|---|---|
| Perimeter/opening | Door/window magnetic contact or another approved opening detector | Which doors, windows, shutters, gates or hatches form the protected boundary? | Repeated open/close test, zone identity, tamper and final-position signal/circuit result |
| Interior/motion | PIR, dual-technology or another approved motion detector | Which approach or activity area must the detection pattern cover while avoiding expected movement? | Walk test in relevant directions, environment and armed states |
| Glass/shock | Glass-break, vibration or shock function supported by the exact model | Which material and attack mode must be detected, and what threshold/test method applies? | Model-specific functional test and false-activation check |
| Hold-up | Panic/hold-up device or approved input | Who can reach and operate it, and how is accidental activation controlled? | User training, activation/restoration test and response-procedure record |
| Warning | Indoor/outdoor sounder, strobe or another approved warning device | Who must hear/see it, where can it be serviced and what local limits apply? | Witnessed sound/visual test, duration and tamper result |
Fire detectors, water-leak sensors and cameras may be integrated into a broader platform, but they retain separate event meanings, acceptance tests and compliance evidence. Do not count them as additional “types of burglar alarm” merely because they share an app or hub.
Trace the device-to-response dependency path
For each required event, draw the exact path:
Detector or hold-up input → field interconnection → CIE/hub and zone logic → local warning → supported upstream network → app/cloud and/or ARC receiver → named responder.
Then test each layer independently.
| Layer | Dependency to record | Failure behaviour to define | Verification question |
|---|---|---|---|
| Detector/input | Power, mounting, sensing condition, circuit/radio link, tamper and configuration | Does it report trouble, fail safe, remain silent or create another defined state? | Can the exact event and restoration be repeated at the final position? |
| CIE/hub | Mains, backup supply, firmware, enrolled devices, zone rules and storage/logging | Which functions remain during mains loss, restart or device loss? | Is every zone identified and does the correct logic operate in each arm mode? |
| Local warning | Compatibility, local power, placement, volume/visual setting and duration | Does warning continue, stop or report a fault if another layer fails? | Was the required on-site response witnessed? |
| Ethernet/Wi-Fi/cellular | Router/AP, ISP, SIM/APN, signal, service plan and supported priority/failover | Is loss detected? Is another path actually supported and tested? | Which interruption was performed, what event was reported and how did recovery occur? |
| App/cloud | Internet, cloud service, account roles, app version, phone permissions and user availability | Can an event be delayed, suppressed or missed when any dependency is unavailable? | Did every required user receive and interpret the test event? |
| ARC/receiver | Supported protocol/path, receiver, account, event code, encryption/configuration, contract and operator procedure | What happens when the path, account or event mapping fails? | Did the ARC acknowledge the correct event, zone and restoration under a witnessed test? |
| Human escalation | Keyholder list, contact order, site access, language and regional authority policy | Who acts if the first contact is unavailable or police/guard response is not provided? | Is the escalation record current and has the responsible person accepted the role? |
A successful siren test does not prove the app path. An app notification does not prove the ARC received the correct code. A backup-battery field in a specification does not prove site runtime under the installed load. Record each result separately.
Apply the framework to apartments, houses, shops and warehouses
Property labels do not create fixed kits. They change the questions that must be answered.
| Scenario | Inputs to capture | Verification questions before the architecture is accepted |
|---|---|---|
| Apartment | Shared entrance, apartment door, accessible windows/balcony, landlord/building restrictions, neighbours, Wi-Fi/router access and user roles | Which boundary is under the occupant’s control? Can devices and warning be installed without breaching building rules? Who responds when the user is away? |
| House | Multiple entrances, ground-floor openings, attached/detached areas, outdoor exposure, family routines, pets, router and power locations | Where should perimeter and interior layers overlap? Which exterior points require environment-suitable devices? How are night and entry routes handled? |
| Shop | Public entrance, staff entrance, shutters, stock/cash areas, opening/closing procedure, panic risk, network/service ownership and keyholders | Which zones remain active during trading? Who receives hold-up versus intrusion events? How are staff changes, false activations and after-hours access managed? |
| Warehouse | Loading doors, large-volume interiors, metal cladding/racking, machinery, office separation, multiple users, long routes and network coverage | Where can radio or cable routes be tested? Which areas need perimeter versus motion coverage? How are loading operations, power/network loss and responder access handled? |
Use the apartment alarm guide for apartment-specific constraints, and the business burglar alarm guide for operational site planning. The Home Security Kit page owns packaged variant and bundle comparison; it does not replace a site survey.
Roombanker example: map the framework to exact evidence
The following example shows how to turn public product documents into verification questions. It is not a fixed system recommendation, compatibility guarantee or statement of current market availability.
| Framework role | Exact reviewed document field | What the field supports | Verification still required |
|---|---|---|---|
| CIE/hub candidate | Home Security Hub R2 specification, last updated 23 December 2023; models RBGW-202-868/B and RBGW-202-915/B | The page lists RBF regional variants, 10/100 Ethernet, 2.4 GHz Wi-Fi, app push and a built-in 2,500 mAh backup battery with an “up to 8 hours” document field | Current model/firmware/app availability; exact supported detectors; installed-load backup test; upstream recovery; any ARC/receiver path: verification required |
| Opening detection candidate | RBSS-MC1 specification, last updated 23 December 2023; RBSS-MC1-868/-915 | Reed-switch opening state, rear tamper, signal-strength test, AA battery and regional RBF variants are listed | Exact hub/firmware pairing, opening geometry, installed signal, maintenance interval and current availability: verification required |
| Interior motion candidate | RBSS-PS1 specification, last updated 5 January 2024; RBSS-PS1-868/-915 | PIR detection, rear tamper, signal-strength test, CR123A battery and regional variants are listed | Final placement/coverage, environment, pet conditions, hub/firmware pairing and current product/compliance evidence: verification required |
| Local warning candidate | RBAD-SI1 specification, last updated 2 January 2024; documented -868 EU/UK and -915 adapter variants | Sound/strobe, volume test, rear tamper, signal-strength test and power fields are listed | Market adapter, local warning requirement, hub/firmware pairing, placement and witnessed acceptance: verification required |
The hub document’s open-area range, backup-time, notification and certification fields must remain tied to that exact source and its conditions. They must not be converted into “covers every house,” “always has backup,” “works with any ARC” or a current compliance claim. Use the Smart Hub product route for current commercial evaluation and the Roombanker Support centre for current public documents.
Commission and hand over the selected system
A classification decision is incomplete until the chosen combination is commissioned.
- Record the approved risk, property scope, market requirements, insurer inputs and response plan.
- Record CIE/hub model, firmware, regional variant, serial number, power source and upstream interfaces.
- Record every detector, input, control and warning device by model, serial, zone, location, power source and interconnection type.
- Use zone names that identify the actual opening, area or hold-up point.
- Test door/window contacts at normal and slow movement; test motion detectors with a documented walk pattern; test other functions only by their exact method.
- Test wired circuits, tamper and resistance/EOL where applicable. Test wire-free signal and supervision at the final installed positions.
- Test local sound/visual warning, duration and restoration against the project requirement.
- Verify entry/exit delay, perimeter, interior, 24-hour/hold-up and other approved zone behaviour in every relevant arm state.
- Create only the required users, roles and permissions; confirm who may arm, disarm, configure and receive events.
- Test the app path for every required event and user if self-monitoring is included.
- Run a witnessed ARC test for every required event, restoration and account/zone mapping if professional monitoring is included.
- Interrupt mains and each required network path using an approved test method. Record fault reporting, supported backup/failover behaviour and recovery.
- Review false-alarm causes, user actions, call-verification steps and maintenance escalation.
- Hand over the zone list, placement drawing, model/firmware record, user/permission list, test results, maintenance plan, keyholders and exceptions.
- Remove temporary installer access and test devices according to the agreed service procedure.
The RB Link route provides current public app workflow information for supported configurations. It is not evidence that every model or account supports the same notification path.
Isolate failure by symptom, action and owner
| Failure mode | Check | Action | Primary owner |
|---|---|---|---|
| Missed detection | Physical placement, sensing condition, zone state, arm mode, power, circuit/radio link and event log | Correct the failed layer, repeat the exact trigger and record restoration | Installer/maintainer with site owner |
| False activation | Opening movement, vibration, pets, heat/airflow, threshold, wiring, device condition, user procedure and zone logic | Remove the verified cause or adjust only supported settings; repeat representative tests | Installer/maintainer; user for operating procedure |
| Device communication loss | Battery/power, enrollment, regional variant, final-position signal, obstruction, interference and supervision support | Restore power/enrollment or redesign placement/path; observe for the defined acceptance period | Installer/maintainer |
| CIE/hub power loss | Mains supply, charger/PSU, battery condition, installed load, fault log and recovery | Repair power, replace approved components and run the documented interruption test | Maintainer/site facilities owner |
| Network/cloud/app loss | Router/AP, ISP, SIM/APN, account, cloud status, app permissions and phone availability | Isolate the failed upstream layer; verify any supported fallback and notify users of limitations | IT/network owner plus service provider |
| User escalation failure | Contact list, permissions, phone state, training, site access and fallback order | Update roles and contacts; run a user/keyholder exercise | System administrator/site owner |
| ARC event missing or wrong | Hub/transmitter support, path, receiver, account, zone/event code, restoration and contract status | Correct the exact configuration and repeat a witnessed end-to-end test | Installer/integrator plus ARC |
| Authority-policy mismatch | Market, police/guard policy, installer/ARC status, verification method, account/URN equivalent and false-alarm history | Obtain current local requirements and revise the response plan; never promise attendance from a product label | Contract owner, ARC and local compliance adviser |
Change one variable at a time. Otherwise, a temporary pass does not identify whether the cause was the detector, field link, hub logic, upstream network, app account, ARC mapping or human response.
Quick answers
What is a local burglar alarm?
A local burglar alarm sends its primary warning at or near the protected premises, usually through a sounder or strobe. It may be professionally installed and maintained. “Local” does not automatically mean DIY, no contract, low cost or no external functions.
What is a self-monitored burglar alarm?
A self-monitored system sends supported events to named users, commonly through an app. Its operation depends on the exact hub, network, cloud/service, account, phone permissions and an available user. It does not by itself provide professional monitoring or authority response.
What is a professionally monitored burglar alarm?
A professionally monitored system sends supported events to an ARC under a contract and defined receiving procedure. The ARC path, event mapping, verification and escalation must be qualified for the exact project. Monitoring does not guarantee police or guard attendance.
Is wired or wireless better for a burglar alarm?
Neither architecture is universally better. Wired, wire-free and hybrid systems have different cable, power, radio, expansion, maintenance and environment conditions. The correct choice follows the site survey, response plan and acceptance evidence.
What should be selected first: detectors or monitoring?
Start with property risk, insurer/regulatory inputs and the required response. Then choose interconnection, detection coverage, upstream transmission, resilience and service ownership. Product quantities come after those decisions.
What proves that the selected system is ready for handover?
The record should show exact models and variants, zone names, final-position detector/circuit/radio tests, local warning, user permissions, app and supported ARC tests, power/network interruption results, false-alarm procedure, maintenance ownership and unresolved exceptions.
Choose a system by evidence, not by one label
The strongest selection question is not “Which alarm type is best?” It is: Which combination of response, interconnection, transmission, detection, grade/environment and service responsibilities can be demonstrated for this property and market?
For a commercial Roombanker system discussion, use the Intrusion Detection Solution and bring the property type, risk zones, response model, network conditions, market, current equipment and acceptance requirements. A qualified inquiry starts with those inputs—not a universal kit, cost or reliability claim.