Partitions and Zones

What This Page Covers

This page explains how the Security and Alarm Capability organizes physical detection devices into a logical security model. It describes partitions — the independently armable units of a security system — and zones — the bindings between a normalized sensor attribute and a partition.

The Logical Model

The Security and Alarm Capability does not interact with sensors directly. Instead, it introduces a two-level logical model on top of the normalized device layer:

Alarm (virtual device)
  └── Partition (logical security area)
        └── Zone (bound to a ClusterEndpoint + Attribute on a normalized sensor)
              └── AlarmZone (the zone's alarm state)

Physical devices — door contacts, motion detectors, glass break sensors — exist in the device tree as normalized devices with ClusterEndpoints and Attributes. A zone does not bind to the raw physical device. It binds to a specific Attribute on a specific ClusterEndpoint — the alarm state attribute that the normalization layer exposes, regardless of the underlying protocol. The partition holds the arm state and the alarm logic. Zones hold the normalized binding and zone-specific configuration.

This separation means that the same sensor can be rebound to a different partition, that partition configuration can change without touching sensor wiring, and that any sensor supported by the platform can serve as a zone input regardless of its protocol.

Partitions

What a Partition Is

A partition is an independently armable area within an alarm system. A deployment can have one partition covering the entire premises, or multiple partitions covering separate areas — for example:

a perimeter partition (exterior doors and windows) and an interior partition (motion detectors);
separate partitions for different floors, units or buildings within the same system;
a partition for common areas and separate partitions for individual tenants.

Each partition is armed and disarmed independently. Arming one partition does not affect others.

Partition Types

Two partition types exist, selected at creation time and not changeable afterwards:

Type	Description
`basic`	Simplified configuration for standard deployments
`pro`	Full configuration with advanced scheduling, per-user permissions and extended notification rules

Partition State

At runtime, each partition carries the following state:

Field	Description
`armMode`	Current arm mode: `DISARMED`, `HOME`, `AWAY`, `ENVIRONMENT` or `MAINTENANCE`
`tripped`	Whether a zone has triggered within this partition
`tripType`	Type of trigger: `ALARM`, `TAMPER` or similar
`trippedBy`	The zone that caused the trip
`tripSensorState`	Sensor state at the time of the trip
`entryStarted`	Whether an entry delay countdown is active
`entryFrom` / `entryUntil`	Entry delay window
`exitStarted`	Whether an exit delay countdown is active
`exitFrom` / `exitUntil`	Exit delay window
`entryZone`	The zone that started the currently active entry delay

Partition Configuration

Partition configuration falls into two groups: stored configuration (contacts, permissions, outputs, scheduling) and timing and feature settings (delays, operating modes).

Notification contacts

Channel	Configuration
Email	List of email addresses
SMS	List of phone numbers
Voice	List of phone numbers for automated calls
Push	List of users for mobile push delivery

Notification rules (reports) specify which contacts receive which event types.

Output devices

sirens — list of siren device UUIDs activated when the alarm fires
squawks — list of squawk device UUIDs for audible confirmation of arm/disarm

User permissions

Each user's access to a partition is controlled by a permission bitfield:

Permission	Description
`PRIV_VIEW`	Can see partition state
`PRIV_ARM`	Can arm the partition
`PRIV_DISARM`	Can disarm the partition
`PRIV_BYPASS`	Can bypass individual zones
`PRIV_EDIT`	Can modify partition configuration
`PRIV_LATCHKEY`	Latchkey notification — receives alert when the user arms or disarms

Permissions are combined as a bitfield per user and stored in the partition configuration.

Keypad and key fob slots

Physical keypads and key fobs are represented as slots. Each slot links a physical authenticator device, a slot number on that device and the platform user associated with it. Slots are read-only from the partition configuration — they are managed through the authenticator device.

Scheduling

Partitions can hold scheduled arm and disarm rules, allowing automatic state transitions at configured times.

Timing settings

Field	Description
`entryDelay`	Seconds allowed to disarm after an entry zone trips before the alarm fires
`exitDelay`	Seconds after arming during which exit movement does not trigger the alarm
`homeEntryDelay`	Entry delay when partition is in `HOME` mode
`homeExitDelay`	Exit delay when partition is in `HOME` mode
`sirenDelay`	Seconds after alarm trip before the siren activates
`sirenTime`	Seconds the siren stays active

Operating mode flags

Field	Description
`alwaysArmed`	Partition cannot be disarmed
`silentAlarm`	Alarm fires silently — notifications sent but no siren
`quickArm`	Allow arm/disarm via key fob without PIN entry
`healthCareMode`	Monitors for inactivity rather than intrusion; alerts if no motion is detected within `mobilityTime` seconds
`crossZoning`	Require two zones to trip within `crossZoningTime` seconds before confirming an alarm

Offline alerts

The partition can be configured to send notifications when the edge runtime goes offline, with configurable delay thresholds for both master and secondary runtime instances.

Zones

What a Zone Is

A zone represents one detection point in the security system — a door contact on a specific door, a motion detector in a specific room, a glass break sensor on a specific window. It is a virtual element within the alarm device hierarchy that binds a specific Attribute on a specific ClusterEndpoint from the normalized device tree to a partition.

Each zone owns an AlarmZone child that holds the zone's current alarm state, derived from the bound sensor attribute. When that state changes while the partition is armed, the zone triggers the partition's alarm logic.

The binding is always to the normalized model, never to the raw protocol layer. A Z-Wave door sensor and a Zigbee door sensor are bound through their respective ClusterEndpoints — the zone logic does not distinguish between them.

Creating a Zone

A zone is created by specifying a ClusterEndpoint and an Attribute from the normalized device tree. This means:

any sensor type supported by the platform can serve as a zone input;
the zone does not depend on the sensor's protocol;
if the physical sensor is replaced with a device on a different protocol, rebinding to the new ClusterEndpoint is sufficient — the zone configuration and history remain intact.

Zone Types

Each zone has a type that determines when and how it triggers:

Type	Description
`Interior`	Active only in `AWAY` mode — bypassed when partition is in `HOME` mode
`Perimeter`	Active in both `AWAY` and `HOME` modes
`Panic`	Triggers an immediate alarm regardless of arm mode
`Silent`	Sends notifications only — no siren
`Safety`	Fire, gas, smoke or health monitoring — always active regardless of arm mode
`Tamper`	Triggers on sensor tamper detection

Zone Configuration

Field	Description
`number`	Zone number (auto-assigned, writable) used for 3rd party systems
`zoneType`	Zone type (see table above)
`bypassable`	Whether the zone can be bypassed before arming
`chime`	Zone triggers a chime sound when tripped while the partition is disarmed
`zoneEntry`	Marks this zone as an entry zone — tripping it starts the entry delay countdown rather than firing immediately
`zoneExit`	Marks this zone as an exit zone — movement through it during the exit delay does not trigger the alarm
`zoneFollower`	Follower zone — triggers the alarm if tripped during an active entry or exit delay
`entryDelay`	Per-zone entry delay override (seconds)
`exitDelay`	Per-zone exit delay override (seconds)
`homeEntryDelay`	Entry delay override when partition is in `HOME` mode
`homeExitDelay`	Exit delay override when partition is in `HOME` mode
`sirenDelay`	Per-zone siren delay override (seconds)
`removeZoneBypass`	Automatically remove bypass after the partition is armed
`crossZoneGroup`	Cross-zone group assignment — used with the `crossZoning` partition setting

Zone State

Each zone has an AlarmZone child — a virtual element within the alarm device hierarchy that holds the zone's current alarm state. This is derived from the bound ClusterEndpoint and Attribute on the physical sensor, but it is owned by the zone, not by the sensor. The alarm logic reads it to evaluate whether a trip has occurred.

Zone state fields:

Field	Description
`ready`	Zone is ready — sensor is in its normal (non-tripped) state
`armed`	Zone is currently armed
`tripped`	Zone has been triggered
`bypassed`	Zone is bypassed
`sensorState`	Current binary state of the bound sensor
`sensorOffline`	The bound sensor device is offline

Multiple Partitions: Practical Implications

When a system has multiple partitions:

Arming one partition does not arm others. Each partition's arm mode is independent.
A siren can be bound to multiple partitions. If any of them fires, the siren activates.
Notification contacts are configured per partition. Different partitions can notify different people.
User permissions are per partition. A user may have arm/disarm rights on one partition and view-only rights on another.

Where to Continue

Goal	Page
Understand arm modes, delays and alarm triggers	Alarm Logic
Configure notification channels and contacts	Notifications
Learn how the normalized device model works	Device Normalization
Return to the Security and Alarm overview	Security and Alarm Overview

What This Page Covers​

The Logical Model​

Partitions​

What a Partition Is​

Partition Types​

Partition State​

Partition Configuration​

Zones​

What a Zone Is​

Creating a Zone​

Zone Types​

Zone Configuration​

Zone State​

Multiple Partitions: Practical Implications​

Where to Continue​