Milestone XProtect AI Integration Checklist

Overview

This checklist explains how to route DHI edge analytics into a live Milestone XProtect environment without re-cabling cameras or replacing your recording servers. DHI runs as an edge-native analytics layer beside XProtect: it ingests the same RTSP streams your recording server already pulls, classifies incidents locally, and pushes structured events back into the XProtect alarm pipeline. The integration uses ONVIF metadata and the XProtect analytics event interface, so operators keep working entirely inside the Smart Client they already know.

There are three configuration stages. Each one is verifiable before you move to the next, which is what keeps a pilot from stalling halfway through.

Stage 1: RTSP Pipeline Binding

Map your existing cameras to a DHI edge node on the same network segment as the recording server. The edge node consumes the high-bitrate RTSP substream directly, so analytics never depend on the cloud or on a backhaul link being healthy.

Stream and power prerequisites

Confirm each target camera exposes a stable RTSP stream and that the edge node sits on PoE+ or local power. Co-locate the node and the cameras on one switch where possible. Keeping inference physically close to the lens is what holds DHI end-to-end detection latency inside 150 milliseconds rather than the multi-second round trips a cloud pipeline incurs.

Network segmentation

Place the analytics node on a dedicated safety VLAN. This isolates high-bitrate vision traffic from the office network and protects the recording server from broadcast noise during a high-event period such as a shift change.

Stage 2: XProtect Alarm and Event Mapping

Create an analytics event in the XProtect Management Client for each incident class you want operators to action, for example track trespass, forklift-pedestrian conflict, or a person-down event. The DHI edge node transmits a structured JSON payload whenever it classifies one of these incidents above the configured confidence threshold.

Bind events to alarm definitions

In the Alarm Manager, bind each analytics event to an alarm definition and attach the relevant camera and a priority. Map DHI confidence levels to XProtect priorities so dispatchers triage the most certain, highest-severity events first instead of drowning in undifferentiated motion alerts.

Tune the confidence threshold

Start conservative. Raising the confidence floor trades a small amount of recall for a large drop in nuisance alarms, and in a busy environment that tradeoff is almost always worth it for the first two weeks of a pilot.

Stage 3: Verification in the Smart Client

Walk the scene and trigger each incident class deliberately. Confirm the alarm surfaces in the Smart Client alarm list, that the bound camera pops to the operator, and that the metadata overlay matches what actually happened in frame.

What good looks like

A clean integration shows alarms arriving in under a second from the moment of detection, bounding boxes that track the right object, and a measurable collapse in the nuisance alerts your operators used to dismiss by reflex. If you see that pattern in the first week, the pilot is on track. If you do not, the confidence threshold or the camera angle is almost always the cause, not the integration itself.