Grandstream GDS37xx Door System

Integration for Grandstream GDS3710 and GDS3705 IP video door systems over the GDS37xx HTTP API. One door station becomes one GEM device. The driver opens the door on demand, grabs camera snapshots, receives door / PIN / RFID / doorbell events, keeps the door station's local user list in sync with GEM's users (PINs and RFID cards), projects GEM access-rule schedules onto the device so it enforces day/hour windows even when GEM is offline, and places or ends SIP calls.

Communication is HTTPS to the station's /goform/* endpoints using a challenge/response login; the unit's self-signed certificate is accepted automatically.

What this integration covers

• Remote door open / close — release the door strike the station controls (open_door), and send the station's re-lock action (close_door). Uses the device's own HTTP API Remote Open Door handshake secured by a Remote PIN.
• Camera snapshots — grab a JPEG still from the station's camera.
• Live door events — the station opening a door, keypad PIN entries, RFID/NFC card reads, doorbell calls, and system warnings (tamper, forced, held-open) surface as device attributes you can build triggers and access logging on.
• User and credential sync — push GEM users (name + PIN + RFID card) into the station's local user list, pull the station's list back into GEM, and add or delete users on demand.
• Offline access schedules — GEM access-rule day/hour windows are mirrored onto device schedule slots and bound to per-rule device groups, so the door station enforces the schedule even when GEM is unreachable.
• SIP call control — place an outbound call from the door station to a number, and hang up.

What this integration does NOT cover

• Two-way call audio / video. The station's SIP voice and video path runs through Grandstream's own apps / SIP server; GEM triggers and monitors calls but is not the call endpoint.
• General device configuration. GEM configures only the specific access settings it needs (the door-open API, Remote PIN, keypad routing, and the schedule/group mirroring). Everything else — camera image settings, SIP accounts, door-strike timing, network — is configured in the station's own web UI.
• Failed-credential capture. The station only logs keypad input that it actually acts on (a matched PIN or dialed number); wrong PINs and bad entries are silently dropped by the device, so GEM cannot see or log them.

Prerequisites

• The door station reachable over the network from the GEM controller, and its admin account password.
• HTTPS enabled on the station (the default). GEM accepts the self-signed certificate.
• For live door events by webhook, GEM's own listen address must be reachable from the door station (they are normally on the same LAN — the driver auto-detects GEM's LAN IP).
• No manual device-side access setup is required. On first connect the driver enables the HTTP-API door-open feature, provisions a Remote PIN, and configures the keypad so per-user PINs open the door (see How door open works).

Setup

1. In GEM, go to System → Devices → Add Device (Open Devices) and pick Grandstream GDS37xx as the driver.
2. Enter the station's GDS IP Address and Admin Password (the password is stored encrypted).
3. (Optional) Adjust Admin Username (default admin), HTTPS Port (default 443), and Protocol (https by default). Leave Remote PIN to Open Door blank to have the driver generate and provision one automatically.
4. Save. The driver logs in, auto-configures the door-open access settings, reads the station's identity, registers for event notifications, syncs users from any access rules that reference this device, and starts polling the event log.
5. Create one zone bound to this device with address = "1" for door 1 (see Mapping the door to a zone). The driver does not create this zone for you.

Subsystem placement

This driver hints intercom / access / gate / lock, but a stock GEM install seeds none of those names — it seeds Doors, Gates, Security, etc. Because the New Zone editor only pre-selects a subsystem on an exact name match, it does not pre-select one for a GDS door. Pick the subsystem yourself: Doors for a door strike, Gates for a gate/barrier, or Security for an alarm/aux point. The door commands go through the station's own door-open API, so the subsystem choice affects how the zone is grouped and presented, not whether the door fires.

How door open works

Opening the door is a two-step challenge/response against the station's /goform/apicmd endpoint, secured by a Remote PIN (the device's Remote PIN to Open Door setting) on top of the admin password. On first connect the driver configures the station so this works out of the box:

• Enables HTTP API Remote Open Door — under the station's System Settings → Access Settings, the Enable HTTP API Remote Open Door option (Challenge+Response). Without it, open_door returns "HTTP API open door function is disable".
• Provisions the Remote PIN — if you left Remote PIN to Open Door blank, the driver generates an 8-digit PIN, stores it encrypted on the device row, and pushes it to the station. If you set one, the driver pushes your value.
• Turns on Private PIN mode — so each user's own PIN opens the door (not just a single shared PIN).
• Disables keypad SIP-number dialing — critical: without this the station routes every keypad entry to the SIP dial-by-number path first and never reaches the PIN check, so all keypad PINs are silently dropped. The driver sets this so per-user PINs open the door.

open_door releases the door strike; close_door sends the station's matching close action (for a momentary strike this cancels / re-locks — the actual strike duration is set on the device). The commands also answer to the shorthand aliases open and close.

Mapping the door to a zone

Create one zone bound to the GDS device and set its address to the door:

Address	Targets
1	Door 1 — the standard single-door install.
2	Door 2 (GDS3710 dual-door only). Uses a separate Remote PIN if you set the remote_pin_2 device attribute, otherwise falls back to the main Remote PIN.

The station itself decides which strike/relay the HTTP-API open acts on (per its own door configuration) — the address selects which Remote PIN GEM hashes into the request. For the common single-door station, use 1.

The door strike is momentary, so the driver does not maintain a persistent open/closed state attribute on the zone — door activity surfaces as the device event attributes in Live door events instead. A Normally Closed zone toggle is exposed for NC-wired setups; note that the GDS opens the door through its own door-open API rather than by driving a raw relay contact, so match your NO/NC wiring and strike timing in the station's own settings.

Commands

The station's command set (run from the device row, a macro, a scene, or a trigger):

Command	Args	What it does
open_door (open)	address	Opens / releases the door via the Remote PIN handshake.
close_door (close)	address	Sends the station's close / re-lock action.
snapshot / get_image	—	Returns a base-64 JPEG still from the station's camera.
get_system_info	—	Refreshes the device identity attributes (model, firmware versions, serial, uptime, temperatures, tamper).
get_network_info	—	Refreshes the network attributes (MAC, IP, subnet, gateway, DNS).
get_users	—	Returns the station's local user list.
create_user	first_name, last_name, pin, rfid, room_num	Adds a local user with an optional PIN and RFID card.
delete_user_by_id	device_user_id	Removes a local user by its device-side ID (the RFID card number, or a synthetic ID for PIN-only users).
sync_to_gem	—	Imports the station's local users into GEM users (matches by name, creates new ones, imports PIN + card).
sync_users	—	Pushes every GEM user in an access rule on this device up to the station's local list, with their access schedule.
register_webhook	—	(Re)configures the station to POST event notifications to this GEM instance.
unregister_webhook	—	Turns event notification off on the station.
reboot_device	—	Reboots the door station.
dial	number	Places an outbound SIP call from the station to number.
hangup	—	Ends the current call.
disable_tamper	—	Disables the tamper alarm — use on a bench / dev unit with the enclosure open.
enable_tamper	—	Re-enables the tamper alarm.

Live door events

Door activity reaches GEM two ways, and both feed the device attributes you build triggers and access logging on.

Event-log poll (every ~5 seconds) — the source of truth for PIN / RFID / door-open / doorbell activity. On first connect the driver records a watermark of the newest existing entry so it does not replay months of history; from then on only new entries fire. It sets:

Attribute	Set when
last_door_open_at	The station opens a door (PIN match, RFID swipe, or remote API).
last_keypad / last_keypad_at	Keypad input is resolved and acted on — the value is the matched PIN digits or the dialed number / contact.
last_doorbell_at / last_doorbell_target	The doorbell places an outbound call, with the call target.

Event notification webhook — the station also POSTs system warnings to GEM. The driver auto-registers this on first connect, pointing at GEM's LAN IP with a per-device token, so no manual URL entry is needed (set Webhook Base URL Override only if the station must reach GEM through a proxy or NAT). Warnings set:

Attribute	Set when
last_warning / last_warning_at	The station posts a system warning — tamper, door forced, door held open, or an alarm.

note

The webhook carries system warnings only — door-open / PIN / RFID / doorbell activity comes from the event-log poll, not the webhook. If the webhook never fires, check Maintenance → Event Notification on the station and confirm GEM's address is reachable from the door.

Beyond the attributes, the driver also emits named events (door_open, keypad, doorbell, door_held_open, door_forced, tamper, pin_open, warning) for automation to subscribe to at the granularity you need.

Users, credentials, and schedules

On connect — and again whenever an access rule referencing this device is created, edited, or reloaded — the driver pushes users up to the station's local list so it can authenticate them at the keypad and card reader on its own:

• Each user is keyed on the station by their RFID card number. Users with a PIN but no card get a synthetic device ID so they still sync.
• The first_name and last_name fields synced to the station are cataloged, so they autocomplete in the Attribute editor.
• For each enabled access rule, the driver mirrors the rule's day/hour window onto a device schedule slot and binds a device group to it, then places each user in that group. The station then enforces the schedule offline — access outside the window is denied at the door even if GEM is unreachable. A user who lands on more than one rule is placed in the first rule's window (the driver logs which rules it ignored).
• Only users that carry a PIN or RFID card are pushed; users with neither, or disabled users, are skipped. Set up each user's credentials and access scope in Users and Access Control before syncing.

sync_to_gem runs the other direction: it reads the station's local users, matches them to existing GEM users by name (linking them), and creates GEM users for any it doesn't recognize — importing each one's PIN and, where the device ID is a real card number, RFID card.

Treat the admin session as sensitive

An authenticated API session to the station can read back configuration that includes the admin password in plaintext. Restrict who holds the door station's admin credentials, and keep GEM's copy (stored encrypted on the device row) protected accordingly.

Attribute reference

Device attributes

Name	Type	Required	Description
ip	string	yes	Door station IP address (GDS IP Address).
password	string	yes	Admin account password. Stored encrypted.
username	string	no	Admin account username (default admin).
port	int	no	HTTPS port (default 443).
protocol	string	no	http or https (default https).
remote_pin	string	no	Remote PIN to Open Door — the shared secret hashed into the door-open request. Leave blank to auto-generate; stored encrypted.
remote_pin_2	string	no	Separate Remote PIN for door 2 (dual-door GDS3710). Falls back to remote_pin when unset.
webhook_base_url	string	no	Override the auto-detected URL the station POSTs events to. Set only for proxy / NAT routing.
webhook_token	string	no	Per-device token embedded in the webhook URL. Generated automatically; read-only, stored encrypted.

The driver also writes live device attributes as it runs, none of which you set by hand: the station's identity from its system info (product_model, hardware_version, part_number, serial_number, the firmware versions, system_uptime, system_temp, sensor_temp, tamper), the network attributes (mac, ip_addr, subnet_mask, gateway, dns1, dns2), and the event attributes from Live door events (last_door_open_at, last_keypad, last_keypad_at, last_doorbell_at, last_doorbell_target, last_warning, last_warning_at).

Zone attributes

Name	Type	Description
address	string	Door index — "1" for door 1, "2" for door 2 on a dual-door GDS3710 (required).
normally_closed	bool	Exposed for NC-wired strikes (default false). See Mapping the door to a zone for how door polarity is handled.

Troubleshooting

• Login keeps failing — the admin password is wrong, or the account is locked. The station locks the admin account after 5 failed logins (about 5 minutes by default). The driver honors the lockout and will not retry until it clears, so wait it out and confirm the password.
• open_door returns "HTTP API open door function is disable" — enable System Settings → Access Settings → Enable HTTP API Remote Open Door (Challenge+Response) on the station. The driver sets this on first connect; if it was later turned off on the device, re-save the device row to re-apply.
• open_door returns "Remote PIN is null" / "not configured" — set the Remote PIN to Open Door on the device row (or leave it blank so the driver generates one), and make sure it matches the station's Remote PIN to Open Door setting.
• Keypad PINs don't open the door — the station must have keypad SIP-number dialing disabled so PIN entries fall through to the PIN check; the driver sets this on first connect. If a station config change re-enabled it, PIN attempts get silently dropped — re-save the device row to re-apply the access settings.
• create_user returns 408 — the API session is invalid or the admin login is locked out by the station's anti-brute-force timer (default ~5 minutes). Wait and retry.
• Snapshots fail — confirm the admin credentials are correct; the snapshot uses the admin login. If the station's MJPEG authentication is set to challenge-only, the driver falls back to the challenge/response path automatically.
• The webhook never fires — the station only POSTs system warnings (not door/PIN events). Confirm GEM's address is reachable from the door under Maintenance → Event Notification, or set Webhook Base URL Override if the station reaches GEM through a proxy/NAT.

Related documentation

• Devices — adding and configuring the door station device row.
• Zones — creating the door zone and binding it to the device.
• Subsystems — the Doors / Gates / Security subsystem the zone belongs to.
• Commands — running these commands from the admin UI, macros, scenes, or triggers.
• Users and Access Control — the GEM users and access rules that drive credential and schedule sync.
• Access Log — where door events and doorbell presses are recorded.