Hikvision → UniFi Protect Fire Bridge

A small Rust daemon that listens to a Hikvision (thermal) camera's ISAPI alert stream and triggers a UniFi Protect Alarm Manager incoming webhook when a fire-detection event occurs — so a camera fire alarm can ring a Protect siren, send a priority push notification, or drive any other Alarm Manager action.

Safety notice: this is an auxiliary automation component, not certified life-safety equipment. It must never replace compliant smoke alarms, fire panels, evacuation procedures, or emergency-services notification. Test the complete chain regularly.

How it works

Hikvision camera ──ISAPI alert stream──> bridge ──HTTPS webhook──> UniFi Protect
 (HTTP Digest auth)                        │                        Alarm Manager
                                           └── /healthz /readyz /status

• Fail toward duplicate alerts, never missed ones. Alerts trigger on the inactive → active edge, and by default re-alert every 60 s while the fire stays active. Active state expires if the camera goes quiet and is re-armed after every stream reconnect, so a lost inactive notification can never latch the alarm off. An edge suppressed by the cooldown is carried over and fires as soon as the cooldown expires — rate limiting delays an alert, it never discards one.
• Proactive path monitoring. A periodic probe verifies DNS, routing, and TLS toward the Protect host, so a broken webhook path turns /readyz red before a fire, not during one.
• Robust stream handling. Byte-level frame extraction (UTF-8- and chunk-split-safe), structural XML parsing (namespace-agnostic), bounded buffers and queues, exponential reconnect backoff that resets after a healthy session.
• Strict TLS. Certificate validation toward Protect is always on. Plain HTTP is accepted only toward loopback addresses (for testing).
• Hardened container. Non-root, read-only-friendly, built-in Docker HEALTHCHECK, graceful SIGTERM shutdown.

Quick start (Docker)

docker run -d \
  --name hikvision-unifi-fire-bridge \
  --restart unless-stopped \
  --read-only --cap-drop ALL --security-opt no-new-privileges:true \
  -p 8080:8080 \
  -e HIKVISION_HOST=192.168.x.x \
  -e HIKVISION_USER=hik-operator \
  -e HIKVISION_PASS='...' \
  -e PROTECT_BASE_URL=https://your-unvr-hostname \
  -e PROTECT_WEBHOOK_ID='...' \
  -e PROTECT_API_KEY='...' \
  ghcr.io/gasmanc/hikvision-unifi-fire-bridge:0.1.0

Images are published for linux/amd64 and linux/arm64 (Raspberry Pi 4/5 and other SBCs) under the same tag — Docker pulls the right one for your platform automatically.

Pin a version tag or digest; do not auto-deploy latest for a safety-related service.

Configuration

* Not required when PROTECT_WEBHOOK_URL is set.

Health endpoints

A failed alert delivery latches /readyz unready until a later delivery succeeds. That is deliberate: a missed alarm needs a human. Monitor /readyz with something independent of UniFi (e.g. Uptime Kuma) — Protect cannot report the failure of the path used to reach Protect.

Temperature Measurement Alarm (TMA) — recommended primary trigger

Hikvision thermal cameras emit a TMA (Temperature Measurement Alarm) event on the ISAPI stream when a measured temperature crosses a thermometry rule you configure on the camera. Because it triggers on heat crossing a threshold — not on visible flame — TMA generally alarms earlier than the AI fireDetection event, which is why TMA is included in the FIRE_EVENT_TYPES defaults.

To use it:

1. On the camera, enable Temperature Measurement / Thermography.
2. Add a rule (point or region) with an alarm threshold appropriate for fire — a temperature well above anything normal for that scene.
3. Set the rule's linkage to raise a notification so it appears on the alert stream.
4. Confirm the exact eventType your firmware sends (see below) — some firmwares label it TMA, others thermometryAlarm. Add whatever you see to FIRE_EVENT_TYPES.

Caveat: if you also run thermography for non-fire purposes, a TMA raised by an unrelated rule will trigger an alert too. Scope the camera's rules to fire, or narrow FIRE_EVENT_TYPES accordingly.

Finding your camera's event type

Firmwares differ. Capture a test event and check the eventType:

curl --digest --user 'hik-operator:PASSWORD' --no-buffer \
  'http://CAMERA/ISAPI/Event/notification/alertStream'

If yours differs from the defaults, set FIRE_EVENT_TYPES — no rebuild needed.

The bridge also self-reports misconfiguration: every event type it sees that does not match FIRE_EVENT_TYPES appears in the unmatched_event_types list on /status (and is logged once). If your camera's fire type is wrong in the config, it shows up there instead of failing silently.

Verifying the Protect webhook

Protect UI and API paths can move between versions. Test yours directly:

curl --fail-with-body -X POST \
  -H "X-API-Key: $PROTECT_API_KEY" \
  "https://YOUR_UNVR/proxy/protect/integration/v1/alarm-manager/webhook/$PROTECT_WEBHOOK_ID"

If your Protect version exposes a different URL, pass it verbatim via PROTECT_WEBHOOK_URL.

Development

cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo test            # unit + end-to-end tests (fake camera & Protect servers)

Releases are tagged vX.Y.Z; CI builds and publishes the container image to ghcr.io/gasmanc/hikvision-unifi-fire-bridge.

Security

• Use a dedicated, least-privilege camera account and a minimum-scope Protect API key; rotate on any suspected exposure.
• TLS certificate validation is always enforced toward Protect and cannot be disabled.
• Restrict the health port to your monitoring network.
• Report vulnerabilities via GitHub private vulnerability reporting.

License

Copyright © 2026 contributors.

Licensed under the GNU Affero General Public License, version 3 or later (LICENSE, AGPL-3.0-or-later).