Use Cases & Templates

1.1 Environmental Sensor Data Transmission

An Axis environmental sensor periodically reads sensor values and transmits them to external systems. Three templates cover the main approaches.

1.1a — Power BI Real-Time Dashboard

Push sensor data directly to a Power BI streaming dataset via its REST API — the camera feeds the dashboard with no gateway in between.

1. A schedule trigger fires every 60 seconds
2. A Device Event Query action fetches cached sensor data (temperature, humidity, CO₂) and injects them as {{trigger.FIELD}} variables
3. An HTTP Request action POSTs a JSON array to the Power BI streaming dataset endpoint

1.1b — Direct InfluxDB Ingestion (Grafana)

Write time-series data points directly into InfluxDB — the camera is the data pipeline, ready to query in Grafana.

1. A schedule trigger fires every 60 seconds
2. A Device Event Query fetches cached sensor data
3. An InfluxDB Write action writes a data point with temperature, humidity, CO₂ as fields and the camera serial as a tag

1.1c — MQTT to Home Assistant

Publish sensor data over MQTT using Home Assistant topic conventions — sensors appear in HA with retained state updates every 60 seconds.

1. A schedule trigger fires every 60 seconds
2. A Device Event Query fetches cached sensor data
3. An MQTT Publish action sends a retained JSON payload to homeassistant/sensor/<serial>/environment/state

1.2 Multi-Platform Motion Alerts

When motion is detected during office hours, send an alert with a camera snapshot to Slack, Microsoft Teams, and email simultaneously.

1. A Device Event trigger subscribes to Motion Detection (active = true)
2. A Time Window condition restricts to weekdays 08:00–18:00
3. Three actions run in sequence: Slack webhook, Teams webhook, and Email — each with snapshot attachment

1.3 Daily Activity Digest

Buffer all motion events throughout the day and send a single summary email at 18:00 — a daily activity report for facility managers.

1. A Device Event trigger fires on motion detection
2. A Notification Digest action buffers each event as one line with timestamp
3. A second schedule trigger at 18:00 ensures the digest flushes daily

2.1 Sunrise / Sunset IR & Light Management

At sunset, switch to night mode and turn on the IR illuminator. At sunrise, switch back to day mode. Times follow the sun — no fixed schedule.

1. Two rules use astronomical schedule triggers (sunset and sunrise)
2. The sunset rule sets IR Cut Filter to night and Light Control on at 80% intensity
3. The sunrise rule mirrors it: IR to day, light off

2.2 Event-Driven Privacy Zones

Privacy masks follow a GDPR schedule but can be overridden instantly during emergencies via MQTT or webhook.

2.2a/b — Scheduled Privacy (Business Hours)

1. Two rules with daily schedule triggers — 08:00 and 18:00 weekdays
2. A Variable Compare condition skips if emergency override is active
3. Privacy Mask actions enable or disable the named mask

2.2c/d — Emergency Override

1. An MQTT Message trigger on building/emergency/+ with an HTTP Webhook fallback
2. The emergency rule sets system.privacy_mode = override, disables the mask, and shows a warning overlay
3. The clear rule restores system.privacy_mode = normal — scheduled rules resume

2.3 PTZ Auto-Tracking with Guard Tour Resume

A PTZ camera runs a guard tour. On human detection, pause the tour, go to a close-up preset, hold 30 seconds, then resume.

1. An AOA Scenario trigger fires on human detection
2. Guard Tour stop → PTZ Preset go to close-up → Delay 30s → Guard Tour start

2.4 Motion → Audio Clip

Play a pre-uploaded audio clip through the camera speaker when motion is detected — deterrent or staff alert.

1. A Device Event trigger subscribes to Motion Detection
2. An Audio Clip action plays the selected clip

2.5 Scheduled Wiper

Run the camera wiper every morning at 07:00 to clear overnight condensation or debris.

1. A schedule trigger fires daily at 07:00
2. A Wiper action starts the primary wiper

3.1 Perimeter Intrusion Response

Person detected in a restricted zone after hours while armed → full response: recording, siren, I/O alarm, Telegram snapshot, live-stream overlay.

1. An AOA Scenario trigger detects humans in the perimeter
2. Time Window (19:00–06:00) + Variable Compare (system.armed = true) must both pass
3. Five actions: Recording → Siren/Light → IO Output (30s) → Telegram (snapshot) → Overlay Text (60s)

3.2 Smart Access Control

I/O input from a card reader. Business hours: release door, record, count. After hours: alert only.

1. An I/O Input trigger on port 1 (rising edge) from the card reader
2. Business hours rule: Time Window 08:00–18:00 → IO Output (door strike 5s) + Recording + Increment Counter
3. After-hours rule: Time Window 18:00–08:00 → Recording + Telegram alert with snapshot

3.3 Occupancy Monitoring with Escalation

AOA counts people. Warning overlay at 20, Slack alert + I/O indicator at 30.

1. Schedule triggers every 30 seconds poll AOA counts via AOA Get Counts
2. Warning rule: occupancy ≥ 20 → Overlay Text
3. Critical rule: occupancy ≥ 30 → Slack webhook + IO Output

4.1 Live Queue Ticket Display

Ticketing system publishes MQTT updates → display shows current ticket number and queue length instantly.

1. An MQTT Message trigger on queue/reception/update
2. A Speaker Display action renders ticket number and wait count on a dark-blue background

4.2 Air Quality Monitor (MQTT)

Three rules work together: live dashboard on green, critical alert override in red, all-clear to resume.

4.2a — Live Data Dashboard

MQTT trigger on sensors/airquality/data → display CO₂, PM2.5, temp, humidity on green background. Suppressed when alert is active.

4.2b — Critical Alert Override

MQTT payload critical → set system.airquality_alert = active → red scrolling alert that persists until cleared.

4.2c — All Clear

MQTT payload clear → reset variable → brief green confirmation → live dashboard resumes.

4.3 Direct Axis Sensor → Speaker Display

The display polls an Axis air quality sensor directly every 60 seconds — no MQTT broker, no gateway, no middleware.

1. A schedule trigger fires every 60 seconds
2. A Device Event Query targets the remote sensor and queries Environment / AirQuality
3. A Speaker Display action renders {{trigger.CO2|0}}, {{trigger.Temperature|1}}, {{trigger.Humidity|0}}

4.4 Webhook-Driven Speaker Display

A BMS or automation platform POSTs air quality data over HTTP — no MQTT broker required. Each POST instantly updates the screen.

1. An HTTP Webhook trigger receives POSTs with a JSON payload
2. A Speaker Display action renders the values, held for 5 minutes or until the next POST

5.1 Arm / Disarm via MQTT

A single MQTT publish arms or disarms all rules that gate on system.armed.

1. Two rules listen on cameras/{{camera.serial}}/arm — payload arm or disarm
2. Each sets system.armed and logs to syslog

5.2 Daily Counter Reset

Reset daily counters (door_access, motion_count) to zero at midnight.

5.3 MQTT Heartbeat

Publish a status payload every 60 seconds so monitoring systems can detect device silence.

5.4 Maintenance Mode via MQTT

MQTT enable/disable maintenance mode — suppresses alert rules and shows an overlay on the live stream.

5.5 Remote Rule Control via MQTT

Dynamically enable or disable any rule by ID from a central automation system.

6.1 I/O Input → Remote I/O State → Speaker Display

Door sensor opens on camera A. Only alarm if camera B's sensor is also active — then show alert on a remote speaker display.

6.2 AOA → Remote Occupancy Condition → Alert

Camera A detects a person, but only alerts if camera B also counts occupancy > 0 — confirming it's not a false positive.

6.3 Remote Sensor Data Relay

Poll environmental data from a remote Axis sensor every 60 seconds and publish over MQTT with decimal formatting.

7.1 Counter-Driven Escalation

Count every motion event during the day. When the count hits 50, escalate once — Slack alert, variable update, and optional rule chain.

7.1a — Increment the Counter

Every motion event increments motion_count by 1. Pair with 5.2 (midnight counter reset) to keep it daily.

7.1b — Escalate at Threshold

When motion_count >= 50, the counter_threshold trigger fires. A counter condition double-checks, then escalates via Slack and optionally chains to another rule.

7.2 Compound Trigger — Tailgate Detection

A door sensor and motion detection each fire independently on legitimate events. A tailgate occurs when both happen within 8 seconds of each other.

1. trigger_logic: "AND" + trigger_window: 8 — both I/O input and motion must fire within 8 seconds
2. Time Window restricts to after-hours (18:00–08:00)
3. Recording (30s) → Telegram snapshot alert → IO Output (alarm relay 5s)

7.3 Night-Only Recording

Record motion only during darkness. No fixed time window — adapts to actual sunrise/sunset at the camera's location across the year.

1. Device Event trigger on motion detection
2. Day/Night condition passes only when the sun is below the horizon
3. Recording (30s) + overlay text showing detection time

7.4 Snapshot Evidence with FTP Fallback

POST a snapshot to the primary evidence server. If the upload fails, the on_failure chain automatically reroutes to FTP backup storage.

1. AOA human detection, armed + after-hours
2. HTTP Request with attach_snapshot: true POSTs the base64 image to the evidence server
3. If HTTP fails (any error) → on_failure runs: FTP Upload to backup + Send Syslog warning

7.5 ACAP Service Watchdog

A critical ACAP must stay running. Poll its state every 10 minutes; if it's inactive, restart it, restore a device parameter, and publish an alert.

1. Cron trigger */10 * * * * fires every 10 minutes
2. Device Event State condition checks the ACAP's running event — passes only when the ACAP is NOT active
3. ACAP Control start → Set Device Parameter restore → syslog warning → MQTT alert

7.6 Paging Console Scheduled Announcement

Broadcast a pre-configured announcement on an Axis C6110 paging console at the top of every business hour.

1. Cron trigger 0 8-17 * * 1-5 — top of every hour, 08:00–17:00, Mon–Fri
2. Paging Console Execute triggers the pre-configured paging action by UUID

7.7 VMS Event Bridge

Trigger from the UI or any external system to emit a VAPIX event that your VMS (ACS, Milestone) is subscribed to — bridging Event Engine automation into VMS workflows.

1. Manual trigger (UI "Fire Now" or POST /fire) or HTTP Webhook from any system
2. Fire VAPIX Event emits RuleFired — the VMS subscribes to this and triggers its own workflow
3. MQTT Publish + Syslog provide parallel paths

7.8 Security Event Audit Logger

Whenever a critical security rule fires, log it — with condition_logic: OR, only when the system is armed OR any motion activity has been seen today.

1. Rule Fired trigger watches a security rule by UUID
2. condition_logic: "OR" — logs if system.armed = true or motion_count > 0
3. Syslog (warning) + MQTT audit topic with variable interpolation

7.9 Network-Gated Motion Alert

Confirm the notification endpoint is reachable before acting. Silently skip when connectivity is lost — prevents dead-queue flooding in isolated or occasionally-connected deployments.

1. Motion detection trigger fires
2. HTTP Check condition GETs the health endpoint — passes only if HTTP 200 + body ok within 5 seconds
3. Time Window + endpoint check both pass → Slack alert with snapshot fires

7.10 Raw Binary Snapshot Upload

POST a raw JPEG snapshot directly to an evidence archive. Unlike http_request with attach_snapshot (which encodes to base64 inside JSON), snapshot_upload sends an RFC-compliant binary image/jpeg body — smaller wire size, no decode step on the server.

1. Motion trigger fires; armed + after-hours conditions must both pass
2. Snapshot Upload GETs a warm JPEG from channel 1 and POSTs it as raw binary with authorization header
3. max_executions: 500, max_exec_period: "" — hard lifetime cap to prevent storage flooding

7.11 Paging Console Context Button

Dynamically swap a paging console panel button between an Emergency All-Call action and normal operations — driven by MQTT alarm state. The button a security officer presses always reflects the current posture of the site.

7.11a — Arm: Assign Emergency Action to Slot 1

On site/alarm/state payload armed: GET the page layout, patch slot 1 to the emergency action UUID, PUT it back.

7.11b — Disarm: Restore Normal Action to Slot 1

On site/alarm/state payload disarmed: patch slot 1 back to the standard operations action UUID.

7.12 Dual-Zone Breach — AND_ACTIVE

A door sensor and motion detection must be simultaneously active to trigger a breach alert. A door that briefly opens with no concurrent motion (delivery, false latch) is ignored. Motion with the door closed (cleaning staff, animals) is ignored. Only genuine co-occurrence raises the alarm.

1. trigger_logic: "AND_ACTIVE" — rule only fires while both triggers are simultaneously in their active state
2. After-hours Time Window condition passes
3. Recording (45s) starts; MQTT breach alert publishes (QoS 1)
4. If MQTT broker is unreachable, on_failure logs a syslog error — so the alert is never silently lost
5. Telegram snapshot notification sent in parallel

Every template is designed to be imported and then customised in the web UI: