Dahua Cameras, NVRs, and Video Intercoms (RPC2)

Integration for Dahua IP cameras, NVRs, and video door stations (VTO intercoms) over Dahua's RPC2 API and the eventManager event stream. One camera, NVR, or door station becomes one GEM device.

This is a monitoring / event integration, not a control integration. It opens a long-lived connection to the device and turns what the device reports — motion, a local alarm input, the intercom call button, SIP registration — into live GEM attributes you can build triggers, automation, and access logging on. It does not send control commands to the device (see What this integration covers).

Communication is HTTPS by default; the device's self-signed certificate is accepted automatically. Set the scheme to http to talk to older units on port 80.

What this integration covers

• Live event ingestion — motion start/stop, the local alarm input, the intercom call button, and SIP registration state arrive in real time over the device's event stream and surface as device attributes (see Live events).
• Intercom call workflow — a press of a Dahua door station's call button drives a GEM Call-type access rule: an Access Log entry plus an optional action (chime macro, push notification, door release, …) and a visitor snapshot from a linked camera. See Intercom call button.
• Automation triggers — every event lands on a device attribute, so you can drive Attribute Triggers, scenes, and dashboard widgets off door and motion activity.

What this integration does NOT cover

• No control commands. This driver has no open/close/pulse, no relay control, and no native snapshot or PTZ command. It only listens. Pairing it with the controls below covers the rest:
  • PTZ — use the separate Amcrest PTZ driver (Amcrest is Dahua's North-American consumer brand; the CGI PTZ API is shared). Create a second device on the same camera with that driver for pan/tilt/zoom and presets.
  • Live video / snapshots — point the camera widget at the device's RTSP or HTTP stream URL (set stream_url on the channel zone), or link a snapshot-capable camera for access-log stills (see Intercom call button).
• Call audio / video (SIP). A Dahua door station's two-way voice and video run over its own SIP path (the Dahua app / a SIP server). GEM monitors the registration state but is not the call endpoint.
• General device configuration. Recording schedules, motion-detection regions, network settings, and accounts are configured in the Dahua web UI or DMSS/SmartPSS, not through GEM.

Prerequisites

• A camera, NVR, or VTO door station running firmware that exposes the RPC2 event API (the /cgi-bin/eventManager.cgi endpoint). Practically all modern Dahua firmware qualifies; very old firmware that 404s on that path is out of scope.
• A device account with Operator or higher privileges. Some event topics (alarm/intercom on certain models) require an Admin account.
• HTTPS (or HTTP) reachability from the GEM controller to the device. Sync the clock on both ends — RPC2 digest auth is sensitive to clock skew, so run NTP on the device.

Setup

1. In GEM, go to System → Devices → Add Device (Open Devices) and pick Dahua (RPC2) as the driver.
2. Enter the device's Device IP, Username, and Password (the password is stored encrypted).
3. (Optional) Set the Scheme — leave it at https for modern devices, or choose http for an older unit on port 80. The Port defaults to 443 for https and 80 for http; only set it if the device listens on a non-standard port.
4. Save. The driver connects and opens the event stream automatically — no extra step is needed to start receiving motion, alarm, call, and SIP events. Watch the device's attributes update as activity happens at the camera or door.
5. (Optional, multi-channel NVRs) Create one zone per channel bound to this device and set the zone address to the Dahua channel number (e.g. 1). Add a stream_url to each channel zone for live preview. A single camera needs no zone — its events land on the device.

Subsystem placement (zones only)

The device's events all land on the device, so a bare camera doesn't need a zone. If you do create per-channel zones, the driver hints the Security subsystem and a camera device type, so the New Zone editor pre-selects Security on the exact name match (a stock install also seeds a Cameras subsystem you can choose instead). The subsystem only affects how the channel zone is grouped and presented — there are no control commands either way.

Device attributes

Attribute	Type	Required	Description
ip	string	yes	Device IP address.
username	string	yes	Device account, Operator-level or higher.
password	string	yes	Device account password. Stored encrypted.
port	int	no	Defaults to 443 for https, 80 for http.
scheme	string	no	https (default) or http.

The driver writes the event attributes from Live events below as activity happens.

Zone attributes

Zones are optional and used only to organize the channels of a multi-channel NVR.

Attribute	Type	Description
address	string	Dahua channel number for a multi-channel NVR (e.g. 1). Omit for a single camera.
stream_url	string	Optional RTSP or HTTP stream URL for live preview of this channel.

PTZ targets the channel, not the GEM zone

On an NVR, PTZ (via the Amcrest PTZ driver) and the channel address refer to the Dahua channel number, not the GEM zone id. Set the zone address to match the physical channel.

Live events

The driver holds a persistent subscription to the device's event stream (/cgi-bin/eventManager.cgi?action=attach&codes=[All]) and reflects what the device reports onto these device attributes:

Attribute	Type	Set when	Notes
motion_detected	timestamp	Video motion starts	Epoch-ms value, updated on every motion-start. Build triggers on the value changing, not on a true/false test.
motion_stopped	timestamp	Video motion stops	Epoch-ms value, updated on every motion-end.
alarm	timestamp	The device's local alarm input fires	Epoch-ms value.
call_key	bool	The intercom call button is pressed	Pulses true, then back to false after ~1 second.
call_press	timestamp	The intercom call button is pressed	Epoch-ms value — the most reliable trigger signal, since it changes on every press.
sip_registered	bool	A SIP registration result arrives	true when the door station registers with its SIP server, false on failure.
unhandled_event	string	Any other event code arrives	Holds the raw event text. Useful for discovering event codes this driver doesn't map yet, so you can spot what a specific model emits.

Trigger on the timestamp, not a state

motion_detected, motion_stopped, alarm, and call_press are timestamps (epoch milliseconds), not on/off flags — each new event writes a fresh, larger number. The right Attribute Trigger condition is "value changed", which fires once per event. (call_key is the exception — it's a real true/false you can test directly, but it self-clears after a second.)

call_key, call_press, motion_detected, and sip_registered are cataloged, so they autocomplete in the Attribute editor when you build triggers.

Intercom call button

When someone presses the call button on a Dahua VTO door station, the driver fires GEM's call workflow. To wire it up:

1. Create the door station as a Dahua (RPC2) device as above.
2. In Access Control, add a rule whose access type is Call and whose access device is this device.
3. (Optional) Give the rule an action — a chime macro, a push notification, a door-release command on another device, etc. The action runs every time the button is pressed.

On each press GEM writes an Access Log entry and runs the rule's action. The call rule is exempt from lockdown by default (a visitor pressing the button during lockdown still produces a log + snapshot), and it has no credential lookup — it always logs.

Snapshots need a linked camera

The Dahua RPC2 driver does not capture stills itself. To attach a visitor image to the access-log entry, link a snapshot-capable camera to the access device — set the device's camera_device_id (and camera_address for the channel) to a camera that supports a snapshot command. GEM then grabs the still from that camera when the call rule fires. Without a linked camera the event is still logged, just without an image. See Access Log for the full list of snapshot sources, including on-demand NVR lookup and the optional local facial-recognition match.

Behavior and reconnection

• Event stream resilience. The event subscription is a long-lived chunked HTTP request. If the device closes it after a firmware-controlled idle window (or the network drops), the driver reconnects automatically after a couple of seconds. No action needed.
• Digest auth. The driver authenticates with RPC2 digest auth and tolerates the modern MD5, SHA-256, and SHA-512 variants with qop=auth. The self-signed HTTPS certificate is accepted automatically.

Troubleshooting

Symptom	Check
Every request returns 401	Verify the account has Operator-or-higher rights and isn't locked. RPC2 digest auth is sensitive to clock skew — sync NTP on the device and the GEM controller. A 401 with WWW-Authenticate: Basic means the firmware wants legacy plain auth; check the account's access mode on the device, or try the other scheme.
Events never arrive	Confirm the event endpoint is reachable: curl --digest -u USER:PASS "https://CAM/cgi-bin/eventManager.cgi?action=attach&codes=[All]" should stream text chunks. If it 404s, the firmware predates the RPC2 event API.
Motion / call attributes don't update	Make sure motion detection (or the door-station call event) is actually enabled and configured on the device in its own web UI — GEM only reports what the device emits. Check unhandled_event to see whether the device is sending a code this driver doesn't map.
The call button does nothing in GEM	Confirm an Access Control rule with the Call type is bound to this device. Without a matching rule the press still updates call_key / call_press but produces no access-log entry or action.
Access log shows the call but no image	Link a snapshot-capable camera to the access device (camera_device_id) — the Dahua RPC2 driver can't grab a still on its own. See Access Log.
Need PTZ or a stored snapshot command	This driver doesn't provide them. Add the Amcrest PTZ driver as a second device on the same camera for pan/tilt/zoom, and use the channel stream_url for live video.

Related documentation

• Devices — adding and configuring the camera / NVR / door-station device row.
• Zones and Subsystems — optional per-channel zones for a multi-channel NVR.
• Attributes — where the live event attributes appear and autocomplete.
• Triggers — building automation off motion, alarm, and call events.
• Access Control — the Call-type rule that turns the intercom button into a logged, actionable event.
• Access Log — where call-button presses are recorded, and how visitor snapshots are sourced.
• ONVIF — the protocol-level camera integration, an alternative for devices that speak ONVIF events.