A PIR alarm system is an intrusion-detection workflow in which a passive infrared detector reports a decision after sensing a qualifying change in the thermal pattern across its field of view. The detector event is only the first stage. Radio or wiring, hub and zone rules, configured sirens or notification services, and a person or monitoring service determine whether the event becomes an alarm and what happens next. A reliable design verifies every stage separately and records who owns it.
“Passive” means that the detector receives infrared energy rather than emitting infrared energy to find motion; it does not mean “battery operated.” The detailed PIR sensor definition and mechanism belongs in a separate guide. This page starts where the sensor becomes part of an alarm architecture: requirement, placement, communication, logic, output, commissioning and failure isolation.
What happens after a PIR detector senses movement?
The usable system path is:
thermal-pattern change → detector decision → radio/message delivery → hub and zone logic → configured local/app/monitoring output → human or service response
These arrows are dependencies, not guarantees. A detector can make a correct local decision while a radio message is missed. A hub can receive an event while the zone is disarmed. A siren can sound while no remote notification is configured. An app can display an event while nobody is assigned to act. Professional monitoring adds a contracted receiving and escalation process, but it still does not make intervention or emergency-service attendance automatic.
Texas Instruments’ SLLA603 PIR technical overview explains why PIR output depends on heat moving across a field of view: opposing pyroelectric elements create a changing electrical response as a target moves, while distance and speed affect the signal. Panasonic Industrial’s PIR FAQ adds an important field boundary: lens zones, target size, speed, temperature contrast and distance all affect detection, and a target may be missed even inside a nominal distance under some conditions.
| System layer | Input | Output | Required dependency | Typical failure | How to verify | Primary owner |
|---|---|---|---|---|---|---|
| Thermal scene | A person, animal, warm object or environmental change moves relative to the background | Changing infrared pattern at the lens | Clear field of view, suitable target/background contrast and movement through detection zones | Obstruction, direct sunlight, rapid background change, little thermal contrast or stationary target | Observe the real route and repeat a walk test under representative conditions | Designer/installer |
| Detector decision | Lens and sensing element receive the changing pattern | Local detection/event decision | Correct model, mounting, orientation, mode, stabilization and settings | Wrong orientation, sleep/mask behavior, unsuitable sensitivity or environmental disturbance | Use the exact model’s installation-test procedure and indicator/event record | Installer; manufacturer defines product behavior |
| Communication | Detector event enters its wired or wireless interface | Message at the hub/control panel | Enrolment, addressing, power and an acceptable communication path | Wrong device identity, low battery, radio degradation, wiring fault or repeater dependency | Trigger at final position and inspect signal/message evidence | Installer/integrator |
| Hub and zone logic | Valid detector message | Alarm, delay, ignored event, automation or other configured state | Correct room/zone, armed mode, entry/exit rules, time/profile and firmware configuration | Zone disarmed, wrong mode, wrong label, delay misunderstood or rule conflict | Exercise every relevant armed state and compare event log with design | Installer/integrator and system administrator |
| Configured output | Hub decision | Local sounder, app/cloud notification or monitoring message, if designed and supported | Compatible output, network/service availability, permissions, contacts and current subscription/contract where applicable | Siren disabled, app permission blocked, network/cloud unavailable, recipient missing or receiver path not commissioned | Witness each contracted output separately; do not infer one output from another | Installer plus platform/ARC/service owner |
| Human or service response | Received, understandable event | Verification, keyholder action, escalation or documented closure | Trained user, contact sequence, service hours, local eligibility and response procedure | Alert not seen, contact unavailable, unclear procedure or service limitation | Run a tabletop or live agreed test and record receipt, interpretation and next action | End user, keyholder or monitoring provider |
The RBF communication-path guide is the Roombanker-specific owner for deeper wireless message routing. Its product and protocol statements should not be generalized to every PIR alarm system.
Who is responsible for each PIR alarm system component?
A commissioning sheet should name the owner of each layer. “Installed by Company A” is not enough if Company B operates the app, Company C receives monitoring messages and the customer controls user permissions.
| Component or role | System responsibility | Dependency to document | Acceptance evidence | Boundary |
|---|---|---|---|---|
| PIR detector | Convert a qualifying thermal-pattern change into a detector event | Exact model, lens/pattern, mounting method, settings, power and environmental limits | Model document, device identity, installation walk test and tamper test | Does not identify a person, verify intrusion or guarantee response |
| Hub/control panel | Receive the message and apply zone, arm, delay and output logic | Supported detector, firmware, room/zone, arming profile and event rules | Event log plus tests in every relevant mode | Receiving a message does not prove all outputs worked |
| Repeater, if used | Relay supported wireless traffic across a planned path | Compatibility, position, power and path to both device and hub | Device-to-repeater/hub signal evidence and end-to-end event test | Not a substitute for unexplained weak coverage or a missing site survey |
| Local sounder, if configured | Produce a local audible indication after the appropriate hub decision | Supported output, enabled state, volume/duration and power | Witnessed alarm and restoration test | Local sound does not prove remote notification or attendance |
| App, cloud and network, if used | Present events, faults, status and user controls supported by the selected system | Account owner, permissions, phone settings, internet/cellular/cloud path and service region | Test account, recipient, timestamp, permissions and loss/recovery behavior | An app alert is not professional monitoring |
| ARC/monitoring service, if used | Receive supported messages and follow the contracted verification/escalation procedure | Compatible receiver/path, account, service hours, contacts and local rules | Commissioning signals acknowledged by the named service | Does not guarantee police or emergency-service attendance |
| Installer/integrator | Survey, design, mount, configure, test, document and hand over the system | Current manuals, agreed risk scope, access to every test path and named subcontractors | Signed survey, configuration, test results, exceptions and training record | Must not substitute product brochure values for final-site acceptance |
| End user/site owner | Operate modes, maintain contacts and report environmental or layout changes | Training, permissions, contact procedure, maintenance and re-test schedule | Handover sign-off and demonstrated operation | Must not be made responsible for an undocumented design gap |
For hub-specific commercial information, use the Roombanker Smart Hub page. For a broader architecture and project discussion, use the Wireless Security Alarm System Solution or Intrusion Detection Solution. None of those pages replaces the exact model manual or site acceptance test.
Select the system from requirements, not from a detector count
“How many PIR detectors?” is a late question. Start with what must be detected, when, and what should happen next.
Site and risk inputs
- Identify protected entrances, internal routes, valuable areas, stock zones and routes that an intruder could use after entry.
- Decide whether detection is required while the site is unoccupied, partly occupied or continuously occupied.
- Separate door-opening detection from movement detection. A door contact can report an opening; a PIR detector evaluates movement through its field of view.
- Record whether the area is indoor, sheltered or outdoor. Outdoor environments require an outdoor-rated, application-suitable detector; the indoor versus outdoor PIR guide owns that comparison.
- Record pets, cleaning robots, hanging objects, curtains, fans, heaters, glazing, sunlight, HVAC outlets, machinery, vibration, shelving and future layout changes. The pet-friendly PIR guide owns the deeper pet-condition explanation; the final site still requires a model-specific test.
Detector and placement inputs
- Select the exact detection pattern before selecting the position. Lens geometry determines the projected zones; it is not simply a circle with a guaranteed radius. The PIR detector lens guide owns deeper lens design.
- Use the exact model manual for mounting surface, bracket, height, angle, orientation, indoor/outdoor limits and tamper method.
- Prefer a stationary, structurally sound wall or approved bracket location. A PIR detector is not normally mounted to a moving door, and the door frame is not a universal PIR position.
- Aim the approved field of view toward the protected entrance approach or movement area so the likely route crosses useful detection zones. A person walking directly toward a detector may produce a different signal from a route crossing several zones; confirm the real route by walk test.
- Check that the rear mounting/bracket geometry can operate as designed. Do not invent a side bracket or mounting orientation that defeats the rear support or tamper function.
System and response inputs
- Document device power, battery supervision and replacement access.
- Survey the final radio or wired path, including construction materials, hub position and any supported repeater dependency. The wireless alarm site-survey guide owns the wider radio survey.
- Define room/zone label, arm modes, entry/exit delays, 24-hour behavior if applicable, tamper behavior and user permissions.
- Define each configured output separately: local sound, app/cloud, SMS/call or ARC only when the exact hub, region, firmware, account, service and contract support it.
- Name who receives the event, who verifies it, who responds, and what happens when the first path or contact fails.
Use the motion-detector type guide when PIR is being compared with other sensing technologies. Use the PIR sensitivity guide for threshold and tuning questions. This page owns how those choices are accepted as part of an alarm workflow.
How should a PIR detector be placed and validated?
Placement is a hypothesis until it passes a test at the final mounting position. Begin with the current manual for the exact model, then verify the real route, environment, communication path and system logic.
Read model-specific numbers as specifications, not site guarantees
The current Roombanker Wiki RBSS-PS1 specification is dated January 5, 2024. The current system User Manual lists PIR Sensor version 1.0.0. For RBSS-PS1, the manufacturer specification states:
| RBSS-PS1 manufacturer specification | Published value or function | Field-use boundary |
|---|---|---|
| Detection distance | Up to 12 m | “Up to” under product conditions; not guaranteed room coverage |
| Horizontal detection angle | 110° | Nominal pattern; furnishings, target route and mounting still matter |
| Recommended mounting height | 1.8–2.4 m | Model-specific range, not a universal PIR height |
| Pet-immunity specification | Up to 10 kg | Not a weight-bearing property or a guarantee for every animal, route or environment |
| Power | One CR123A battery; up to five years in standby mode | Standby product specification, not a promised field replacement interval |
| Tamper | Rear tamper | Requires the documented rear/bracket mounting relationship and enabled system logic |
| Test support | Signal-strength test and installation test | Test functions support commissioning; they do not replace full event-path acceptance |
The RBSS-PS1 Quick Start Guide shows wall mounting with the supplied bracket options and notes that 3M adhesive mounting does not support tamper detection. It also provides separate signal-strength and installation tests. These are model/document statements accessed on July 16, 2026, not proof that every final site will achieve the nominal distance, angle, pet condition or standby life.
Survey the final position
At each candidate point, record:
- the exact model, document revision and intended mounting method;
- protected route or area and the expected direction/speed of movement;
- likely detection-zone crossing and any near-field or direct-approach limitation;
- walls, shelves, doors, partitions, signs, stock, curtains or other obstructions;
- windows, direct sun, heaters, radiators, ovens, HVAC outlets and rapid temperature changes;
- pets, robots or moving objects that can enter the field of view or climb into it;
- mounting stability, bracket articulation, rear tamper and maintenance access;
- final radio/wired path, hub position and supported repeater path if applicable;
- arm mode, entry/exit logic and every intended output path;
- test routes, edge cases, evidence owner and acceptance criteria.
Panasonic’s FAQ explains why this list matters: PIR sensors respond to changes in infrared intensity, not a human identity; ambient temperature affects sensitivity; sudden sunlight or background-temperature changes can cause detection; direct airflow at the lens can change lens or background temperature; and ordinary glass can block the far-infrared wavelengths used by the sensor. These are technology boundaries, not RBSS-PS1 product claims.
The indoor PIR placement guide offers additional room-level planning context. The installer must still resolve any conflict in favor of the current exact model manual and witnessed site results.
Three placement scenarios with explicit assumptions
These scenarios are planning walkthroughs, not universal layouts or customer cases.
House: entrance hall leading to stairs and living areas
Assumptions: The detector is indoor; the entrance opens into a stable hall; likely post-entry movement crosses the hall toward stairs or rooms; no heater, direct sun or moving curtain occupies the candidate view; the selected model and bracket allow the planned wall position.
Planning choice: Use the door contact, if specified, to report the opening and orient the PIR field toward the entrance approach or interior travel route so the person crosses useful zones. Mount on the approved fixed wall/bracket, not on the moving door or by inventing a bracket that defeats rear tamper.
Trade-off: A view covering the hall and stair approach may improve route confirmation but can also include legitimate occupied movement in partial-arm mode. Zone membership and stay/away behavior must match household use.
Excluded conditions: Conservatories, fireplaces, strong sun patches, large or climbing pets, unstable partitions and outdoor approaches require separate model and site assessment.
Validation: Walk the entrance-to-stairs and entrance-to-room routes at normal and edge positions; repeat relevant pet/occupancy conditions; verify detector indication, radio message, zone logic, configured outputs, entry delay, tamper and loss/recovery behavior.
Apartment: compact entrance beside an open-plan living area
Assumptions: One main internal approach exists; the candidate wall is stable; the field can be limited to the entry route without viewing a sunlit balcony door or major heat source; normal occupants require a clear entry-delay procedure.
Planning choice: Avoid the shortcut “one PIR covers the apartment.” Map the protected route and blind areas first. A detector may cover the entrance movement path while a door contact, another detector or a different control strategy covers risks outside that pattern.
Trade-off: A wide view can reduce hardware count but may also include the kitchen, balcony glazing, pets or normal night movement. A narrower, better-controlled route can be easier to commission even if it requires another device or a different zone plan.
Excluded conditions: Split-level apartments, movable partitions, frequent layout changes and glass-separated spaces need additional survey work; ordinary glass should not be assumed transparent to PIR detection.
Validation: Test the actual entry path, a route close to the detector, pattern edges and the intended occupied/unoccupied modes. Confirm that entry/exit delays, user permissions and every configured output behave as documented.
Small shop: sales floor, shelves and a staff entrance
Assumptions: Detection is primarily required after closing; shelves and displays are mapped; HVAC and sun through storefront glazing are identified; staff and delivery routes are known; the selected detector is intended for the indoor environment.
Planning choice: Point the approved pattern toward after-hours movement paths across the sales floor or staff entrance, while avoiding a position where new stock, signs or shelving can obstruct the view. Do not treat an indoor PIR as an outdoor storefront or perimeter detector.
Trade-off: A detector covering more floor can simplify the zone plan, but long aisles, tall stock and rearrangement can create hidden or unstable areas. Multiple accountable zones can make failure isolation and handover clearer.
Excluded conditions: Exterior loading areas, refrigerated or high-temperature zones, moving promotional displays and unusually dusty/wet areas need application-specific equipment.
Validation: Test after the final shelves and displays are installed. Walk staff, customer and likely intrusion routes; repeat tests near pattern edges; verify radio, hub logic, local output, remote/monitoring path if contracted, power/network-loss behavior and the closing/arming procedure.
Diagnose nuisance alarms and missed detection by layer
Do not solve every symptom by changing sensitivity. The observed problem may sit in placement, environment, detector mode, communication, hub logic, output service or user process.
| Symptom | Possible cause or layer | Check | Corrective action | Owner | Required re-test |
|---|---|---|---|---|---|
| Nuisance event at similar time each day | Direct sunlight or rapid background-temperature change in the field of view | Correlate event time with sun, HVAC or heating cycle; inspect final view | Reposition within manual limits, control the source or select a suitable detector/application | Installer/designer | Repeat during the original time/environment plus normal walk test |
| Event when HVAC starts | Airflow changes lens/background temperature or moves a warm/cool object | Observe outlet direction, curtain/object movement and event timing | Move detector/source, redirect airflow or remove unstable object as allowed | Installer/site owner | HVAC cycle test and detection walk test |
| Event associated with pet or robot | Target enters active zones; pet condition differs from model assumptions | Record size, route, climbing/furniture and exact product conditions | Re-plan pattern/mounting within manual, change model/zone strategy or exclude unsupported condition | Designer/installer | Representative target test plus human route test |
| No detection on a direct approach | Route crosses too few zones, target too near, obstruction or weak thermal contrast | Compare route with lens pattern; test lateral and edge routes | Reorient or relocate within manual limits; remove obstruction; revise design if required | Installer | Full pattern walk test under representative conditions |
| No detection behind glass or partition | Far-infrared path blocked or field of view obstructed | Inspect material and line of sight | Place detector on the protected side or redesign coverage | Designer/installer | Walk test in each resulting protected area |
| Detector indicates locally but hub has no event | Enrolment, identity, battery/power, radio/wiring or repeater path | Confirm device ID, online state, signal test and event log | Re-enrol only if required; restore power/path; relocate or add supported path from survey | Installer | Repeated final-position event and supervision test |
| Hub logs event but no alarm in one mode | Zone is disarmed, wrong room/profile, entry delay or rule conflict | Compare event log with arm/zone configuration | Correct documented zone/mode/delay logic | Installer/system administrator | Test every relevant armed mode and restoration |
| Siren works but app notification is missed | Phone permission, account, network/cloud, recipient or service issue | Check event log, account role, notification settings and network/service state | Correct supported permissions/contacts/path; document limitations | Platform owner/installer/end user | Witness notification and loss/recovery test on each required account |
| ARC does not receive event | Receiver/path incompatibility, account not commissioned, service/path outage | Check hub log, transmitter/receiver path and ARC acknowledgement | Correct the contracted integration and recommission with named ARC | Integrator/monitoring provider | Send and acknowledge every required event type |
| Repeated low-battery or offline fault | Battery, contact, environment, radio path or supervision issue | Inspect battery/source, terminal/contact, signal history and site changes | Replace/repair as documented; correct path/environment | Maintainer/installer | Fault restoration, supervision and event-path test |
The wireless alarm troubleshooting guide owns broader system fault patterns. This matrix keeps the PIR page focused on isolating the first failed layer.
Commission the complete PIR alarm path
Commissioning must happen after the detector is in its final position and the site is in its final practical layout. A bench trigger or app screenshot is not a complete acceptance test.
- Identify and enrol. Record manufacturer, model, device/serial identity, firmware if exposed, regional variant and source document.
- Label the location and zone. Use a name that lets the user and service team identify the physical detector without guessing.
- Apply documented configuration. Record sensitivity, arm profile, entry/exit behavior, 24-hour behavior if supported, tamper, delays and linked outputs.
- Allow stabilization. Follow the model’s power-up and installation-test instructions before judging detection.
- Walk-test the detector. Test normal approach, expected crossing route, pattern edges, near-field route and any stated excluded route.
- Test signal or wiring at the final point. Record the model-supported signal test or electrical/path result; include the repeater path if one is used.
- Verify hub and zone logic. Trigger in every relevant stay/away/disarm or scheduled state and compare the result with the design.
- Verify each configured output separately. Witness local sounder, app/cloud or ARC path only when included, supported and configured.
- Verify entry and exit behavior. Confirm the intended delay starts from the correct event and that users can complete the procedure.
- Verify tamper. Use the exact documented method and confirm both local device behavior and hub/system handling. For RBSS-PS1, the Quick Start Guide warns that adhesive mounting does not support tamper detection.
- Test power and network loss. Observe detector, hub, output and service behavior during controlled applicable loss and after restoration.
- Verify permissions and contacts. Confirm who can arm, disarm, administer, receive and acknowledge events; remove test recipients.
- Capture evidence. Save survey assumptions, device/zone list, final positions, configuration, event timestamps, signal results, output receipts, exceptions and retest items.
- Hand over to the user. Demonstrate operation, limitations, contact procedure, battery/fault indicators and what environmental/layout changes require a call.
- Schedule re-test. Re-test after detector relocation, bracket change, firmware/configuration change, battery/power work, hub/repeater/network change, room refit, new furniture, new pet or service-provider change.
The wireless alarm installation workflow owns the wider project sequence. The current Roombanker Support Center is the document and support entry point; it does not replace the named installer, local acceptance record or monitoring contract.
Failure modes and the response boundary
| Failure mode | What may still work | What is not proven | Acceptance or recovery evidence |
|---|---|---|---|
| No detector decision | Hub, siren, app and service may remain healthy | Protected route is being detected | Corrected final-position walk test across required routes |
| Nuisance detector decision | Communication and outputs may operate correctly | Event represents an intrusion | Environment/route diagnosis and representative re-test |
| Radio or wiring degradation | Detector may indicate locally | Hub received the event consistently | Signal/path record and repeated end-to-end triggers |
| Hub offline or wrong zone mode | Detector and communication may operate | Event was processed under intended logic | Hub restoration plus mode-by-mode event-log test |
| Local sounder disabled or failed | Hub/app/ARC may receive an event | Occupants received local warning | Witnessed local-output test and restoration |
| App/network/cloud failure | Local detection and sound may remain available | Remote user received or saw the event | Account/network/service restoration and receipt test |
| Monitoring path or service failure | Local system and app may remain available | ARC received, verified or escalated the event | Named ARC acknowledgement and contracted-path recommissioning |
| Battery/power fault | Some layers may operate temporarily | Duration, supervision or next event is reliable | Power restoration, fault clearance and full path re-test |
| Obstruction or layout change | Device remains online | Original detection pattern remains valid | Updated survey, placement decision and walk test |
| User/contact-process failure | Technical outputs may arrive | Someone will interpret and act correctly | Contact drill, updated permissions and documented escalation |
Keep six outcomes separate:
- Detection: the detector makes a local decision.
- Alarm processing: the hub accepts the event under the active zone logic.
- Verification: a person or supported service evaluates the event using the available evidence and procedure.
- Notification: a configured local or remote output is delivered.
- Intervention: a named person or service takes an agreed action.
- Emergency response: an authority acts under local eligibility, verification and operational conditions.
A successful detector test proves only the layer tested. No PIR alarm system should be described as preventing theft, identifying an intruder, catching someone, guaranteeing notification or guaranteeing emergency attendance. The acceptance plan must state which later stages are included and who owns them.
PIR alarm system commissioning record
Use one row for every detector and repeat rows when the same detector serves different arm modes or routes.
| Record item | Site result | Evidence owner | Exception or next action |
|---|---|---|---|
| Exact model, document/version and regional variant | |||
| Protected route/area and risk assumption | |||
| Mounting surface, bracket, height and orientation | |||
| Lens/pattern and obstruction review | |||
| Heat, sun, airflow, glazing and moving-object review | |||
| Pet/target conditions and exclusions | |||
| Device ID, zone label and armed-mode logic | |||
| Walk-test routes and edge results | |||
| Signal/wiring/repeater result | |||
| Hub event and entry/exit result | |||
| Local output result | |||
| App/cloud/monitoring result, if included | |||
| Tamper and power/network-loss result | |||
| User permissions, contacts and handover | |||
| Re-test trigger and due date |
Frequently asked questions about PIR alarm systems
Does a PIR detector detect an intruder or only movement?
It detects a qualifying change in the infrared pattern across its field of view and produces a detector decision. It does not identify a person or prove criminal intent. Verification and response depend on the rest of the system and the agreed process.
Should a PIR detector face the door?
It may be oriented toward a protected entrance approach or movement area, but the exact position must follow the model’s lens pattern and mounting instructions. The goal is usually to make the likely route cross useful zones while controlling sunlight, heat, airflow, pets and obstructions. Validate the actual route by walk test; do not use the door frame as a universal PIR mounting point.
What mounting height should every PIR detector use?
There is no universal height. Use the current manual for the exact detector and bracket. For example, the RBSS-PS1 manufacturer specification recommends 1.8–2.4 m for that model; the value is not transferable to every PIR detector or a guarantee of final-site coverage.
Can one PIR detector cover a house or apartment?
Do not decide from floor area alone. Coverage depends on the required route, lens pattern, partitions, furnishings, mounting, environment, pets, arm modes and acceptance criteria. Map risks and blind areas first, then validate every required route.
Does pet immunity mean animals below a stated weight never trigger the alarm?
No. A model-level pet specification is not a weight-bearing property or a universal no-trigger guarantee. Animal size, heat signature, movement, distance, jumping/climbing, furniture, mounting, lens pattern, environment and settings can change the result. Test representative site conditions and record exclusions.
Why does the detector work but the app shows no alert?
The failure may be after the detector: communication, hub zone/mode, account permission, phone setting, network/cloud, contact configuration or service availability. Check the event log and each path in order instead of changing detector sensitivity first.
When must a PIR alarm system be re-tested?
Re-test after detector or bracket movement, battery/power work, firmware or configuration changes, hub/repeater/network changes, room refits, new obstructions, HVAC or glazing changes, new pets, changed contacts or a monitoring/service change. Also follow the maintenance interval required by the contract and local practice.
Build acceptance around the first failed layer
A PIR detector is valuable only when its event travels through a documented and tested system path. Start with the protected route and response requirement, select the exact detector and mounting from its current manual, verify the final field of view and communication path, commission every configured output, and give each failure layer an owner.
Installers and integrators evaluating a Roombanker project can use the PIR Sensor product page for the current commercial model route and the Wiki for exact documents. For system-level design, bring the site-survey inputs, event-path drawing and unresolved acceptance items to the Roombanker Partner Program. Product and solution pages support qualification; the signed survey and commissioning record determine whether the final installation meets its documented requirements.