Security and Alarm Overview
What This Capability Provides
The Security and Alarm Capability provides a complete model for physical security management within a Zipato deployment. It introduces partitions, zones and alarm state logic built on top of the normalized device model, and handles arming, disarming, detection, alarm triggering and notification delivery as a reusable module.
It is not a standalone product. It runs on top of the Core Platform, using the normalized device model and event stream to deliver security logic that any application or integration can consume.
Core Model
Alarm Device
The capability is structured around a virtual alarm device. This device appears in the platform device tree alongside physical devices. All partitions and zones are held within it.
Alarm (virtual device)
└── Partition (one or more)
└── Zone (bound to a physical sensor)
This structure separates the logical security model from the physical devices that feed it. Any supported sensor — Z-Wave door sensor, Zigbee motion sensor, wired detector — can be bound to a zone regardless of its protocol.
Partitions
A partition is a logical grouping of zones that can be armed and disarmed independently. A deployment may have one partition covering the entire premises or multiple partitions covering different areas — for example, a perimeter partition and an interior partition, or separate partitions for different floors or units.
Each partition has:
- an arm mode — the current arming state;
- a trip state — whether a zone has triggered within this partition;
- entry and exit delay windows;
- a set of bound sirens and squawk devices;
- notification rules for email, SMS, voice and push;
- user permissions controlling who can arm, disarm, bypass or edit.
Two partition types are available: pro and basic, selected at creation time.
Learn more about Partitions and Zones
Zones
A zone is a binding between a physical sensor and a partition. It represents one detection point — a door contact, a motion detector, a glass break sensor.
When the sensor's state changes while the partition is armed, the zone triggers the partition's alarm state machine. Zones can be moved between partitions.
Learn more about Partitions and Zones
Arm Modes
Each partition operates in one of the following arm modes:
| Mode | Description |
|---|---|
DISARMED | No zones are monitored |
HOME | Partial arming — perimeter zones active, interior zones bypassed |
AWAY | Full arming — all zones monitored |
ENVIRONMENT | Perimeter or environmental arming |
MAINTENANCE | Maintenance mode — alarm triggers bypassed |
Arming and disarming require an authenticated security session. A user must provide a valid PIN before the partition's arm mode can change.
Alarm State Machine
When a zone detects activity while its partition is armed, the partition enters a tripped state. Depending on zone configuration and partition settings, an entry delay may begin — giving the occupant time to disarm before the alarm fires.
Key state transitions:
- Armed + zone detection → entry delay starts (if configured) or alarm fires immediately
- Entry delay expires without disarm → alarm fires (sirens activate, notifications sent)
- Valid disarm during entry delay → partition disarmed, no alarm
- Alarm acknowledged → event logged, partition remains in arm mode
Exit delays apply on arming: after the arm command is issued, the partition waits for the occupant to leave before monitoring zones.
Notifications
When an alarm fires or a significant security event occurs, the capability routes notifications through configured channels. Each partition has independent notification configuration.
Supported channels:
- Email — messages sent to configured addresses
- SMS — text messages to configured phone numbers
- Voice — automated voice calls
- Push — mobile push notifications to app users
Notification rules are configured per partition and can target different contacts for different event types.
Learn more about Notifications
Alarm Log
All security events are recorded in the alarm log. Each log entry captures the event type, the partition and zone involved, the arm mode at the time, the user who triggered the action, and the siren state. Events that require attention are marked for acknowledgement.
Log entries can be queried by partition, by zone, or by time range. Acknowledged entries include the acknowledging user, timestamp and an optional note.
SIA Alarm Reporting
For professional monitoring integrations, the capability supports the SIA DC-09 standard protocol. This allows alarm events to be forwarded to a central monitoring station in a standardized format. Each SIA event carries a sequence number, account identifier, event code and extended data.
How It Fits the Platform
The Security and Alarm Capability consumes Core Platform services:
- the normalized device model provides sensor data regardless of protocol;
- the event stream delivers real-time zone state changes to the alarm logic;
- the device control layer sends arm and disarm commands to the edge runtime;
- the data storage layer persists alarm logs and configuration.
Arming and disarming workflows execute on the edge runtime so that security state is maintained even when cloud connectivity is intermittent.
Where to Continue
| Goal | Page |
|---|---|
| Understand partitions, zones and their configuration | Partitions and Zones |
| Learn how arm modes and alarm triggers work | Alarm Logic |
| Configure notification channels and rules | Notifications |
| Understand the normalized device model that feeds zones | Device Normalization |
| See how applications consume this capability | Applications Overview |