Rules and alarms

Rules are built in Configure > Events & automation, on the Policies tab. Alarms are handled in Operate > Alarms.

How a rule works

• WHEN: up to 8 triggers. Any one of them starts the rule.
• ONLY WHEN: optional conditions, and an optional Schedule gate of weekly time windows in a chosen time zone.
• THEN: create an operator alarm, run actions, or both.

Create a rule

1. Select Add policy and choose what starts it: Camera offline, Motion detected, Video loss, Recording stops, Camera tamper, Input active, Storage nearly full, Site Node unavailable, or Other event.
2. Choose the source and the condition, then select Configure response.
3. Enter a Policy name, add conditions or a schedule gate if needed, and set the response under THEN.
4. Set the Cooldown: repeats from the same source are ignored for this long (1 minute by default).
5. Under Test, check what the policy would do. Tests never create alarms or run actions.
6. Select Save and apply. The policy is saved and runs straight away.

To keep changes without applying them, select Save as draft instead. A draft is not active until it is applied: the policy shows Draft not applied with Apply and Discard, and an active policy keeps running its current version meanwhile.

Each policy in the list has an on/off switch. Switching a policy off asks you to confirm and names what stops. Earlier versions are kept in the policy's history, where Restore this version brings one back.

Events you can use

• Camera connectivity (online or offline) and camera video (available or lost)
• Tamper and video loss reported by the camera itself, through its own event channel or by email. Each trigger source says whether detection is on-camera or server-side.
• Recording state, recording health, and recording storage health (healthy, nearly full, degraded, or unavailable)
• Camera alarm inputs (active or cleared) and output state
• Site Node health and database health
• Virtual inputs fed by device emails, and virtual alarm panel zones

Responses and actions

Response	What it does
Create operator alarm	Adds an alarm to the queue with a Severity (Information, Warning, or Critical), an Alarm title, and optional Operator procedure text. With Resolve when the source reports recovery, the alarm closes itself when the condition clears.
Start recording	Records the camera with its event pre-roll and post-roll. The camera needs event recording turned on.
Send email notification	Emails the recipients of a delivery profile, operators and external contacts, in the order listed.
Send signed webhook	Sends an HTTPS POST with a JSON body, signed with HMAC-SHA256.
Turn output on, Turn output off, Pulse output	Switches a camera relay output or a Shelly output.
Recall PTZ preset, Move PTZ to home	Moves an Axis PTZ camera.
Arm intrusion partition, Disarm intrusion partition	Arms or disarms a partition of a virtual alarm panel.

Each action has advanced settings for delay, deadline, retries, ordering, and what happens if it fails. Email notifications go through the outgoing mail server set up for your installation.

Webhooks

Webhook endpoints are added under Advanced delivery & destinations > Webhook destinations. An endpoint must use HTTPS on a public address; private and loopback addresses are refused. Each destination needs a Signing secret of 32 to 256 bytes before it can be enabled. Every request carries these headers:

• X-KalyteraVMS-Signature: v1= followed by the lowercase hex HMAC-SHA256
• X-KalyteraVMS-Timestamp: the send time in Unix seconds
• X-KalyteraVMS-Delivery-Id and X-KalyteraVMS-Webhook-Version

The HMAC is computed with the signing secret over KalyteraVMS.Webhook.v1, the timestamp, and the delivery ID, each followed by a line feed, and then the request body. Recompute it on your side and compare the two before you trust a request.

Device emails as events

Every Site Node includes an SMTP receiver for alert emails from cameras and recorders. Configure it on the Ingress tab under LAN SMTP receiver (port 2525 by default), then add Virtual inputs. Each virtual input has its own recipient address and accepts mail only from its Allowed sender address. Its Input mode is either Any accepted message, which triggers on every email, or Decoded raise and restore, which reads each message with a decoder for Hikvision, Dahua, or generic email formats. Attachments such as snapshots are kept with the event.

Virtual alarm panels

The Virtual alarm panels tab turns virtual inputs into intrusion zones that you can arm, disarm, and bypass. Rules can arm or disarm a panel's partitions.

A virtual alarm panel can report its alarms to an alarm receiving center over SIA DC-09. Each report shows one of eight delivery states: Queued, Sending, Retrying, Protocol accepted, Delivery uncertain, Rejected, Failed, or Dead letter. Protocol accepted means the receiver acknowledged the report, not that anyone at the center has seen it. Rejected means the receiver answered and refused the report; Failed means it was not delivered.

Handle alarms

New alarms appear in Operate > Alarms, and their number shows next to Alarms in the sidebar. Filter the queue by State (New, Acknowledged, or Resolved), Minimum severity, and Assignment.

1. Select an alarm to see its details, the related verification video (Live, or Playback at the time of the event), attached media, and Open in Maps for its position.
2. Select Assign to me to take the alarm, then Acknowledge it.
3. Add an Operator note about what you found and did.
4. Select Resolve. An alarm must be acknowledged before it can be resolved, and Reopen returns a resolved alarm to New.

When a rule resolves its alarms on recovery, they close as soon as the source recovers. Each alarm keeps its activity history.