Notifications
What This Page Covers
This page explains how the Security and Alarm Capability delivers notifications when alarm events occur. It describes the available notification channels, how notification rules are configured per partition, what events trigger notifications, and how the platform tracks delivery status.
Notification Channels
Each partition can route notifications through four independent channels:
| Channel | Delivery Method | Configuration |
|---|---|---|
| Message sent to configured addresses | List of email addresses per partition | |
| SMS | Text message to configured phone numbers | List of phone numbers per partition |
| Voice | Automated voice call | List of phone numbers per partition |
| Push | Mobile push notification to app users | List of users per partition |
All channels are configured independently — a partition can use any combination of channels, with different contacts on each. For example, the building manager may receive email and SMS, while all residents receive push notifications only.
Push Notification Infrastructure
Mobile push delivery uses platform-standard push registration:
- Android — Firebase Cloud Messaging (FCM)
- iOS — Apple Push Notification Service (APNS)
Device tokens are registered and managed through the platform's push notification service. When a push notification is triggered by the alarm system, the platform resolves the target users to their registered device tokens and delivers the message through the appropriate provider.
Notification Rules
Notification configuration on a partition consists of two layers:
Contact Lists
Each channel maintains its own contact list on the partition:
| Field | Type | Description |
|---|---|---|
emailReports | List | Email addresses that receive alarm notifications |
smsReports | List | Phone numbers that receive SMS notifications |
voiceReports | List | Phone numbers that receive voice call notifications |
pushReports | List | Users that receive push notifications |
Report Rules
The reports field on the partition holds a list of notification rules. Each rule specifies which contacts receive notifications for which event types. This allows fine-grained control — for example, routing intrusion alarms to all contacts but sending tamper events only to the system administrator.
Events That Trigger Notifications
Notifications are sent when the alarm system produces a significant security event. The key triggers:
| Event | Description |
|---|---|
| Alarm fired | A zone has tripped and the alarm has transitioned to the alarm state — entry delay expired or an immediate zone (Panic, Safety, Tamper) triggered |
| Silent alarm | The partition has silentAlarm enabled — notifications are sent but no sirens activate |
| Tamper detection | A tamper zone has triggered, indicating physical interference with a sensor |
| Controller offline | The master or slave controller has gone offline for longer than the configured threshold |
| Zone trouble | A zone sensor has gone offline or is reporting a problem |
Silent Alarm Mode
When silentAlarm is enabled on a partition, the alarm fires without activating sirens. Notifications are still sent through all configured channels. This mode is used in scenarios where alerting the intruder is undesirable — the notifications reach the owner or monitoring service silently.
Similarly, zones configured as Silent type send notifications without siren activation regardless of the partition's silent alarm setting.
Controller Offline Alerts
The partition can be configured to alert when a controller goes offline:
| Setting | Description |
|---|---|
alertSlaveOffline | Enable alert when a slave controller goes offline |
timeSlaveOffline | Milliseconds before triggering the offline alert |
alertMasterOffline | Enable alert when the master controller goes offline |
timeMasterOffline | Milliseconds before triggering the master offline alert |
These alerts are delivered through the same notification channels as alarm events. The platform waits for the configured duration before sending the alert — brief network interruptions do not trigger false notifications.
Latchkey Notifications
The PRIV_LATCHKEY permission flag enables a special notification type: latchkey notifications. When a user with this permission arms or disarms a partition, a notification is sent to configured contacts.
This is designed for scenarios like parental monitoring — a parent receives a notification when their child arrives home (disarms the system) or leaves (arms the system).
Notification Delivery Tracking
The platform tracks whether notifications have been sent for each event. The alrm maintains notification status records:
- Each notification dispatch is logged with the event that triggered it.
- The platform can query whether a notification has already been sent for a given event to prevent duplicate delivery.
- Notification status is tracked per partition per event occurrence.
How Notifications Fit the Alarm Flow
The complete flow from detection to notification:
All notification channels fire in parallel. The alarm log records the event with all relevant details — the zone, partition state, arm mode and user context — before notifications are dispatched. If needAck = true on the event, it appears in the alarm log as requiring acknowledgement regardless of notification delivery.
Where to Continue
| Goal | Page |
|---|---|
| Understand how arm modes and triggers work | Alarm Logic |
| Configure partitions and their notification contacts | Partitions and Zones |
| Return to the Security and Alarm overview | Security and Alarm Overview |