Access Control

The Access Control page manages physical access control rules that link user credentials (PINs, RFID cards) to automated actions, as well as credential-free exit triggers (REX). When a valid credential is presented to an access device, or a REX input is triggered, GEM executes configured commands or macros.

Open Access Control

Licensing

Access Control & Visitor Management — access rules, access groups, holiday calendars, visitors, and the access log/report — is part of the Access Control module. Creating these items requires the module in your license; the nav items are locked otherwise. Trials and development builds unlock it, and existing rules keep working if a license later changes. See License.

Overview

Access Control enables:

• Physical Security Integration: Link door locks, gates, and keypads to GEM
• Credential Management: Associate user PINs and RFID cards with actions, with valid-from / valid-until / revoked lifecycle
• Request to Exit (REX): Trigger actions from exit buttons or sensors without credentials
• Call Buttons / Doorbells: Log + snapshot + optional action when a visitor presses an intercom call button — no credential required
• Automated Responses: Unlock doors, run macros, trigger scenes — or log only
• Time-Based Access: Restrict access by day, hour, exception dates, and shared holiday calendars
• User-Specific Actions: Different users can trigger different actions
• Access Groups & Roles: Authorize groups of users or anyone holding a specific role
• Cooldown: Prevent repeated triggers within a configurable time window
• Lockdown Mode: System-wide kill-switch that restricts access to opt-in rules (REX and call-button rules always fire — fire egress, and seeing who is at the door)
• Duress PIN: A second PIN per user that grants access and fires a silent panic action
• Centralized Device Sync: Credentials are pushed to readers that cache them locally, and disabled, expired, or revoked users are switched off there automatically — no editing the intercom's own directory

Viewing Access Control Rules

The main grid displays all configured access control rules with the following columns:

• ID - Unique rule identifier
• Name - Internal rule name
• Description - Rule description
• Users - Authorized users (comma-separated usernames)
• Access Device - Device that receives credentials
• Type - Credential type (PIN, RFID, REX, or Call)
• Action - What happens on successful authentication (or "Log Only")
• Enabled - Whether the rule is active
• Days - Active days summary (e.g., "Every day", "Weekdays", or individual days)
• Hours - Active hours summary (e.g., "24h", "8:00–17:00")
• Last Triggered - Timestamp of the most recent trigger

The Access Device and Action cells are drill-through links — click a device, zone, or macro name (including the door's snapshot camera) to open that record in a reference modal over this page, so checking what a rule points at doesn't cost you the grid's scroll, filters or a half-built rule. When the modal can't host the record it falls back to the matching admin page, filtered to that row.

The Access Device cell also names the door's snapshot camera (· camera: …) when one is linked, so a reader that will produce snapshot-less access-log rows is visible without opening every rule. Nothing after the device name means no camera is linked and GEM will ask the reader for its own picture — fine for an intercom, useless on a reader with no imager. Because the camera is stored on the device, every rule on the same door reports the same one.

Grid Actions

• Add - Create a new access control rule
• Edit - Modify an existing rule
• Duplicate - Copy an existing rule (click the copy icon in the row)
• Delete - Remove a rule
• Reload - Refresh the grid data

Creating an Access Control Rule

To create a new rule:

1. Click Add in the grid toolbar
2. Configure the rule (see sections below)
3. Click Save Access Rule

Rule Configuration

Basic Information

Rule Name

• Internal identifier (lowercase_with_underscores)
• Examples: front_door_access, garage_entry, admin_gate
• Auto-formatted on change

Description

• Human-readable description
• Examples: "Front door access for family", "Garage opener for residents"
• Helps document rule purpose

Status

• Toggle to enable/disable the rule
• Disabled rules:
  • Do not process credentials
  • Remain configured for later re-enablement
  • Shown with "Disabled" indicator

Access Configuration

Access Device

• Select the intercom, keypad, reader, or cloud access controller that reports the credential — not the lock it opens. The lock is chosen further down, in the action.
• The device must already exist and be enabled in System > Devices. A rule pointing at a missing or disabled device is saved but never arms; enable the device, then reload it (or re-save the rule) and the rule attaches immediately.
• A disabled rule (Status off) is likewise not armed at all.

Access Type

• PIN Code: Numeric PIN entered on a keypad
• RFID Card: Card/fob presented to a reader
• Request to Exit (REX): Triggered by an exit button, motion sensor, or other input on the access device — no credential or user required
• Call Button / Doorbell: Triggered when a visitor presses the call button on an intercom or doorbell — no credential or user required. The event is logged with reason call_button and a snapshot is captured. Use the optional action to ring a chime macro, send a push notification, or open a video preview.

The access type has to be one the device actually reports. A 2N intercom reports all four; Brivo reports PIN, card, and request-to-exit; a Dahua or AXIS door station reports the call button only. Picking a type the device never sends produces a rule that saves cleanly and then never fires — see Which devices can be the access device.

Action Type

• Device Command: Execute a specific command
• Run Macro: Execute a macro (for complex sequences)
• None (Log Only): No action is performed — the event is logged only. Useful for monitoring access without triggering a device or macro.

Cooldown (seconds)

• Minimum time between repeated triggers for this rule
• For PIN/RFID rules, cooldown is tracked per-user — two different people can badge in back to back
• For REX and Call Button rules, cooldown applies to the whole rule
• Set to 0 to disable (default)
• Duress codes always bypass cooldown so a panicking user mashing the keypad still triggers the alarm

note

The two behave differently in the log. A PIN or card refused by cooldown is logged as denied with reason cooldown. A REX or call-button press inside its cooldown is dropped silently — no log row, no action. That is deliberate (a bouncing exit button would otherwise flood the log), but it means the access log is not the place to prove a call button was pressed during its cooldown window.

Snapshot Camera Zone

• Which camera photographs this door on every access event. Use the search button to pick a camera zone by name.
• The hint under the field always states what will actually happen — the linked zone and its camera selector, the explicit camera_device_id still in effect, or that the reader will be asked for its own picture.
• This is a property of the access device, not of the rule. It is stored on the device as the camera_zone_id attribute, so every rule pointing at the same door shows and shares one camera. The same field is editable under System > Devices > (device) > Attributes.
• Clearing it falls back to camera_device_id / camera_address if those are set, and otherwise to the access device's own camera. See Readers with no camera for the full chain.
• Written when the rule is saved, and only if you changed it — editing a rule's schedule never touches the device.

tip

For denied-access notifications, attach an Attribute Trigger to the access device's last_access_result attribute (set to denied on every failed attempt). This composes with the rest of the trigger system — schedule, debounce, notification profile selection — instead of being a per-rule one-off.

Authorized Users

Select Users

• Multi-select list of users who can authenticate
• Selected users' credentials will be accepted
• User must have a PIN or RFID card configured on the Users page
• Saving the rule re-pushes credentials to devices that keep their own copy (2N intercoms, Brivo), so a user added here can badge in without any further step. Editing a user's PIN or card on the Users page pushes the same way.

warning

A PIN or RFID rule will not save with an empty Select Users list — the editor answers "Please select at least one user". That applies even when you intend to authorize entirely by access group or role, so pick at least one individual user (typically the person who owns the door) and let the group or role cover everyone else.

note

REX and Call Button rules do not require user selection. They are credential-free events (a push-to-exit button or an intercom call button) — no user matching is performed, and the configured action (if any) executes immediately when the device signals the event. Choosing either type hides the Access Groups and Roles sections, because neither is consulted.

Access Groups

For PIN/RFID rules, you can authorize users via Access Groups in addition to individual user selection. Members of any selected group are authorized alongside individually selected users.

• Select one or more access groups from the multi-selector
• Group membership is evaluated at access time (adding a user to a group immediately grants access), and a group that has been disabled authorizes nobody
• Access groups are not offered on REX or Call Button rules

Roles

Authorization can also be granted by Role. Anyone holding a selected role is authorized — useful for "anyone with the maintenance role can enter the boiler room" rules without maintaining a parallel user list.

• Roles, groups, and individual user lists are evaluated as a union (any path grants access)
• Removing a role from a user immediately removes their access

How It Works:

1. User enters PIN or presents RFID at access device (or REX input is triggered)
2. Device sends credential (or REX signal) to GEM
3. For PIN/RFID: GEM checks if credential matches any authorized user
4. For REX: GEM executes the action immediately (no user matching)
5. If match found and schedule allows, action is executed

Action Configuration

Device Command

Choosing Device Command opens the same command builder used by macro command steps, in three parts:

1. Target Selection — pick the Subsystem (Doors, Gates, Lighting …), then tick the Zone the command acts on. This is the lock, strike, or gate operator, not the reader.
2. Command Configuration — pick the Device that owns that zone, then the Command (unlock, open, pulse …). Test fires the command straight at the hardware so you can confirm the door actually moves before anyone stands at it.
3. Parameters — any arguments the selected command takes (a pulse delay, a relay address). Tick the checkbox beside a parameter or it is not sent — an unticked value is treated as "leave it to the driver", which is why a pulse duration typed but not ticked appears to do nothing.

A Device must be selected: a command action with only a zone chosen refuses to save with "Please configure the command".

Example — a strike wired to a relay:

Subsystem: Doors
Zone:      front_door
Device:    front_door_relay
Command:   pulse
Parameters: address = 1:4   [x]
            delay   = 5000  [x]

Choosing the zone here also matters for held-open detection, which watches the zone this command targets — see Held-Open Threshold (s) under Lockdown & Duress below.

Run Macro

When action type is "Run Macro":

Select Macro:

• Choose macro from dropdown
• Macro can include multiple steps:
  • Unlock door
  • Turn on lights
  • Disarm security
  • Send notification
  • Any automation sequence

Example Macro: "Arrive Home"

Step 1: Unlock front door
Step 2: Turn on entry lights
Step 3: Disarm security system
Step 4: Set HVAC to home mode
Step 5: Send notification: "User arrived home"

Schedule Configuration

Restrict when the access control rule is active:

Active Days

Select which days the rule is active:

Presets:

• Every day: Enable all 7 days
• Weekdays: Monday-Friday
• Weekends: Saturday-Sunday
• Clear: Disable all days (useful for testing)

Individual Days:

• Click a day to toggle it: SUN, MON, TUE, WED, THU, FRI, SAT

Use Cases:

• Weekdays only: Service personnel
• Weekends only: Weekend guests
• All days: Residents

Active Hours

Select which hours the rule is active:

Presets:

• All day: Enable all 24 hours
• Business: 8 AM - 6 PM (hours 8-17)
• Overnight: 8 PM - 6 AM (hours 20-23, 0-5)
• Clear: Disable all hours

Individual Hours:

• A 24-cell ribbon spanning midnight to midnight, ticked at 12AM / 6AM / 12PM / 6PM
• Click a cell to toggle that hour, or drag across the ribbon to paint a range
• Hour 0 = 12:00 AM - 12:59 AM, hour 13 = 1:00 PM - 1:59 PM, etc.

A new rule starts fully scheduled (every day, all hours). Clearing every day — or every hour — denies the rule at all times; the editor warns inline when the current selection does that.

Use Cases:

• Business hours only: Cleaning crew
• Night hours only: Security patrol
• All hours: Residents

Schedule Exceptions

Block access on specific dates, regardless of the day/hour schedule:

• Add exception dates using the date picker and Add button
• On an exception date, the rule will not grant access even if the day and hour would normally allow it
• Remove an exception by clicking the × next to the date
• Exceptions are sorted chronologically
• Use cases: ad-hoc maintenance windows, special events

Holiday Calendar

For dates shared across many rules — federal holidays, company shutdowns — assign a Holiday Calendar to the rule. Holiday calendars are managed in Security > Holiday Calendars and can contain individual dates or ranges (from–to).

• Calendar dates are evaluated before the day/hour mask — a holiday wins
• One calendar can be referenced by many rules, so you only have to update holidays in one place
• Per-rule exception dates and the calendar both apply (denied if either matches)

Lockdown & Duress

Allow During Lockdown

While the system is in lockdown, a PIN or RFID rule fires only if Allow During Lockdown is on. Everything else is refused and logged with reason lockdown. Useful for emergencies, after-hours, or partial lockouts.

• Activate or clear lockdown from the banner across the top of the Access Control page — Activate Lockdown / Clear Lockdown. The banner turns red and reads "System Lockdown ACTIVE" while it is on.
• Lockdown is held as the site's access_lockdown setting, so a macro can raise or clear it too — tie it to an alarm panel state, a panic button, or a site mode.

REX and call buttons ignore lockdown entirely

REX and Call Button rules fire during lockdown whether or not Allow During Lockdown is set on them — clearing the switch on those rules changes nothing. Exit buttons stay live for fire egress, and a visitor pressing a call button still produces a log row and a snapshot, which is exactly when you most want to know who is at the door.

If a door must not release from the inside during a lockdown, do not model it as a REX rule that you intend to suppress. Disable the rule, or interlock the exit device itself so the request never reaches GEM.

Duress Macro

Each rule can specify a duress macro that fires silently when a user enters their duress PIN (configured per-user in Users). The normal action still runs (door unlocks) so the attacker doesn't realise. The duress event is logged with reason='duress' for the audit trail.

• Typical duress macros: arm panic alarm, push notification to security, dial guard, capture extra snapshots
• Duress codes bypass cooldown so a panicking user mashing the keypad still triggers the alarm

Held-Open Threshold (s)

Seconds a door may stand open before GEM calls it held open. Blank or 0 disables the monitoring.

Two prerequisites

Both must be true or nothing is monitored, silently:

1. The rule's action is a Device Command with a Zone selected. A Run Macro or Log Only rule has no single door to watch, so no monitoring is registered — if you unlock through a macro, add a second, log-only rule whose command targets the door zone purely to carry the threshold.
2. That zone reports open/closed state from a real contact. The detection reads the zone's own state — opened/open, closed/locked, unlocked — so a door with no position sensor never reports anything to measure.

With both in place, the threshold turns on two detections:

• Unauthorized open (logged as result forced, reason forced_door) — the door's contact went to open without an authorized unlock in the previous 10 seconds. This is an inference: GEM knows only that it didn't see a recent unlock, not that anyone pushed on the door. It is recorded in the access log and left there — no zone attribute is written, deliberately, because the system should not assert a break-in it cannot observe.
• Held-open (result held_open) — once the door opens, GEM starts the threshold timer. If the contact hasn't returned to closed by then, an access-log entry is written and the door zone gets held_open = true. The timer re-arms, so a propped door keeps reminding rather than going quiet after one entry. When the door closes, held_open returns to false. This one is a measurement, so the zone attribute is appropriate.

Manual unlocks — the admin UI, a macro, a scene — also refresh the grace window when the zone goes to unlocked, so authorized entries made outside a credential event are not reported as forced.

These write history, not alerts

Neither detection sends anything by itself. A forced or held-open event writes an access-log row (with a snapshot) and, for held-open, sets the zone attribute — nobody is paged. To be told about it, attach an Attribute Trigger to the door zone's held_open attribute, or to the access device's last_access_result becoming forced, and give the trigger a notification profile. That is also what lets you set quiet hours and a debounce on the alert instead of getting one per door bounce.

Two attributes land on the door zone, and both are yours to build on:

• held_open — on while the door is held open past the threshold, off once it closes
• last_held_open_at — timestamp of the most recent occurrence, kept across closes so a history query can still find it

No extra wiring or pairing fields are involved; the detection reads the contact state the zone already reports. Leave the threshold blank on rules that don't own a physical door — an audit-only rule on a reader another rule already monitors, for instance.

Common Use Cases

Each block below lists the fields as they appear in the editor, top to bottom. Anything under Parameters is only sent when its checkbox is ticked.

Front Door - Family Access

Name: front_door_family
Description: Family members unlock front door
Access Device: front_door_intercom
Access Type: PIN Code
Authorized Users: mom, dad, teen_son, teen_daughter
Action Type: Device Command
  Zone:    front_door
  Device:  front_door_intercom
  Command: unlock
Days: Every day
Hours: All day
Status: Enabled

Gate - Service Personnel

Name: gate_service
Description: Service personnel gate access during business hours
Access Device: front_gate_intercom
Access Type: RFID Card
Authorized Users: housekeeper
Access Groups: service_vendors
Action Type: Device Command
  Zone:    front_gate
  Device:  gate_relay
  Command: pulse
  Parameters: delay = 30000  [x]
Days: Weekdays
Hours: Business
Status: Enabled

Garage - Arrive Home Macro

Name: garage_arrive_home
Description: Activate arrive home scene
Access Device: garage_keypad
Access Type: PIN Code
Authorized Users: homeowner, spouse
Action Type: Run Macro
  Macro: arrive_home (unlocks door, lights on, disarm security)
Days: All Days
Hours: All Hours
Status: Enabled

Office - Employee Access

Name: office_employee
Description: Office door access for employees
Access Device: office_door_intercom
Access Type: RFID Card
Authorized Users: office_manager
Roles: staff
Action Type: Device Command
  Zone:    office_door
  Device:  office_door_intercom
  Command: unlock
Holiday Calendar: company_holidays
Days: Weekdays
Hours: 6 AM - 10 PM (drag the ribbon from 6 to 22)
Status: Enabled

Temporary Guest Access

Name: guest_access_weekend
Description: Weekend guest access to pool gate
Access Device: pool_gate_intercom
Access Type: PIN Code
Authorized Users: weekend_guest
Action Type: Device Command
  Zone:    pool_gate
  Device:  pool_gate_relay
  Command: pulse
Days: Saturday, Sunday
Hours: All day
Status: Enabled

Rather than remembering to switch this rule off on Monday, set Valid Until on the guest's user record. The credential stops working at the door on its own, and the code is pulled back off any reader that had cached it.

Request to Exit (REX)

Name: front_door_rex
Description: Exit button unlocks front door from inside
Access Device: front_door_intercom
Access Type: Request to Exit (REX)
Authorized Users: (none required)
Action Type: Device Command
  Zone:    front_door
  Device:  front_door_intercom
  Command: unlock
Days: Every day
Hours: All day
Status: Enabled

How Access Control Works

System Flow

1. Credential Presentation or REX Trigger:

   • User enters PIN on keypad, or
   • User presents RFID card to reader, or
   • REX input is activated (exit button, motion sensor, etc.)

2. Device to GEM:

   • An IP intercom or reader on the LAN reports the event over its own network protocol; a hosted controller reports it through its cloud event feed
   • GEM is listening because an enabled rule named that device and that access type

3. Rule Matching:

   • Rules are bound to their access device when they load, so matching is by device + access type only — not by schedule
   • Every enabled rule on that device and type gets the event. Two rules on the same reader and type both run

4. Lockdown Check:

   • If lockdown is active and the rule is PIN or RFID without Allow During Lockdown, the attempt is refused and logged with reason lockdown, and nothing else runs
   • REX and Call Button rules skip this check

5. User Matching (PIN/RFID only):

   • The presented credential is matched against every user's PIN, RFID, and duress PIN. No match: denied, reason unknown_credential
   • The matched user must then be authorized by this rule — named in Select Users, holding one of its Roles, or a member of one of its enabled Access Groups. Any one path is enough. No path: denied, reason user_not_authorized
   • A duress PIN match proceeds exactly like a normal grant, and additionally arms the duress macro

6. Schedule & Cooldown Check (PIN/RFID only):

   • Holiday-calendar dates and per-rule exception dates are checked first — either match denies the attempt
   • Then the day mask, then the hour mask. Any failure is denied with reason schedule_mismatch
   • Finally cooldown, per user for this rule. Too soon: denied, reason cooldown. Duress bypasses cooldown

7. Action Execution:

   • The configured command or macro runs — or nothing, for a Log Only rule
   • The event is logged as granted, with reason success, duress, rex, or call_button
   • The rule's Last Triggered timestamp updates, and the snapshot capture starts

8. Access Denied:

   • The refusal is written to the access log with its reason
   • The access device's last_access_result / last_access_reason / last_access_user / last_access_at attributes update, and failed_access_count increments
   • Denial reasons: unknown_credential, user_not_authorized, schedule_mismatch, cooldown, lockdown
   • Hook an Attribute Trigger to last_access_result == 'denied' (or failed_access_count > N) to send notifications

note

Schedule is checked after the credential is recognized and authorized, which is what makes the log useful: a contractor badging in on a Sunday is recorded as that contractor, denied for schedule_mismatch — not as an unknown card. It also means an out-of-hours attempt by a known user still updates the door's last_access_user.

Credential Storage

PIN Codes:

• Stored in the user record, encrypted
• Set in Security > Users page
• GEM does not impose a length; 6 digits or more is the sensible floor. The keypad usually sets the real limit, so keep every code inside the shortest length your readers accept — otherwise a code works at one door and not another

Duress PIN:

• A second per-user PIN that also grants access but fires the rule's duress macro silently
• Must be unique across the entire user base — including other users' regular PINs

RFID Cards:

• Stored as card ID in user record (AES-256-GCM encrypted)
• Typically 8-16 character hex string
• Format depends on reader (Wiegand-26, Wiegand-37, etc.)
• Set in Security > Users page

Credential Lifecycle

Each user has three lifecycle fields that gate physical access:

• Valid From — credentials grant access only at or after this time
• Valid Until — after this time, access is blocked at the door and GEM auto-disables the user on every linked access device (so cached PINs on devices like 2N intercoms are also revoked)
• Revoked — hard stop, overrides any valid window

The expiry sweep runs every 15 minutes. Re-enabling a user (clearing revoked or extending Valid Until) automatically re-syncs credentials to the access devices the user has rights on.

note

Outside their valid window — or once revoked or disabled — a user's code is no longer recognized at all, so the attempt is logged as unknown_credential rather than naming them. If someone reports their card "suddenly stopped working" and the log shows an unknown credential at the right moment, check their lifecycle fields before suspecting the reader.

Which devices can be the access device

A rule only fires when its access device actually reports the chosen event. Add the device under System > Devices first, confirm it comes online, then build the rule against it.

Device	Reports	Notes
2N HTTP intercoms	PIN, RFID, REX, Call	The full set. Also accepts centralized user sync, so PINs and cards are pushed to the unit and keep working if GEM is unreachable.
Brivo	PIN, RFID, REX	Cloud controller; events arrive from Brivo's event feed. Card numbers for credentials Brivo doesn't recognize are passed through, so unknown swipes still log.
Dahua	Call	Door stations and doorbells — call button only.
AXIS	Call	Network door stations — call button only.

Wiring a plain Wiegand reader or a dry-contact exit button into GEM directly is not supported — those terminate on the intercom or the access controller, which then reports the event. The exit button on a 2N is the REX source; the reader on a Brivo panel is the card source.

tip

A card reader with no camera still belongs on a rule — link a nearby camera zone so the access log gets a picture. See Readers with no camera.

Image Capture

GEM captures snapshots of access events using a fallback chain:

1. External camera — set camera_zone_id on the access device to a camera zone (preferred), or camera_device_id to point at a camera/NVR device directly, optionally with camera_address for multi-camera NVRs. See Readers with no camera.
2. Device image download — if the access device supports image download natively (e.g., 2N intercoms), GEM calls it directly.
3. Device snapshot command — as a final fallback, GEM sends a snapshot command to the access device itself.

When a snapshot is captured, an Access Activity report can include its thumbnail. Click View Event in the preview to inspect the full image or video.

The picture is stored on the access-log row itself rather than as a link to a file, so a driver that overwrites one filename per camera still leaves a stable record of each visit.

Face match on the snapshot

When facial recognition is switched on, each captured snapshot is scored against the stored photo of the user whose credential was presented, and the result is filed on the same access-log row. It is advisory — an audit aid for "was that really their card" — and never grants or denies anything.

Both gates have to be on: the site-wide facial_recognition_enabled setting, and the same setting on the individual user. When no score is produced the row records why, including no user on the event (an unknown credential), the user having no usable photo, or no face found in the snapshot. See Facial recognition for how the results read in the report.

Readers with no camera

Card and PIN readers frequently have no imager at all — the 2N Access Unit family, and most wall readers. On those, step 2 above fails on every event: the device answers the camera call with an error rather than a picture. GEM logs access log snapshot unavailable with the device's own reason, and the access-log row is left without a snapshot.

To photograph those doors, borrow a nearby camera. There are two ways to link one, and the first is easier:

Link a camera zone (preferred). Set camera_zone_id on the access device to the camera's zone. Two places edit the same value:

• Security > Access Control, in the rule editor's Access Configuration section — the Snapshot Camera Zone field, next to the access device it applies to.
• System > Devices > (the access device) > Attributes — the camera_zone_id attribute.

Both show a search button that opens the zone picker, so you choose the camera by name rather than typing an identifier. Editing either writes the device attribute; a rule does not carry its own copy.

GEM reads both the device and the camera selector off the zone, because the zone address is the camera selector — the same string GEM would pass automatically for any zone command. That matters most where the selector is opaque: an axis_camera_station zone carries the ACS videoSource id (a GUID the driver writes when it auto-creates the zone), and an onvif zone carries <camera_ip>/<profile_token> identifying its camera on the coordinator. Neither is something to copy by hand. The capture also carries the zone's id, so a multi-camera driver resolves the right camera even when the zone's address has not been written yet — an onvif camera zone works here before sync_zones, capturing on its default profile.

Or name the device explicitly. Set camera_device_id to the camera device's id, and on a multi-camera NVR set camera_address to the channel, camera id, or profile token. Use this when the camera has no zone.

camera_zone_id takes precedence when both are set, and falls back to the explicit pair if the zone or its device is unavailable — so a disabled camera zone degrades to whatever camera_device_id points at rather than silently capturing nothing.

GEM then takes the picture from the camera and never calls the reader's camera API.

Which drivers can serve as the camera

Any driver whose snapshot command returns image data works. In the current tree:

Driver	Notes
onvif	Generic Profile S/T. Selector is <camera_ip>/<profile_token> — run get_profiles to list the tokens; a bare token works when the device coordinates a single camera.
vapix	AXIS cameras.
axis_camera_station	ACS backend. Selector is the ACS videoSource id, which the driver writes as the zone address — use camera_zone_id here rather than pasting a GUID.
hikvision_isapi	Selector is the channel, and it must match an existing zone on that device — the driver resolves it through its own zone map.
reolink	Selector is the channel number.
unifi_protect	Selector is the Protect camera id.
frigate	Selector is the Frigate camera name.
2n_http	Intercoms with a camera (IP Verso, IP Style, …), not the Access Unit models.
gds3710	Grandstream door station.
brivo	Cloud; returns a clip URL rather than inline image data.

The capture is stored inline on the access-log row, so a driver that writes its snapshot to a file still produces a stable record — the bytes are copied at capture time rather than referenced by path.

Reactive attributes on the access device

Every access event also writes a small set of attributes onto the access device itself, so dashboards, attribute_triggers, and macros can react without polling the access_log:

Attribute	Type	Set when
last_access_result	string	Every event — granted, denied, duress, forced, held_open, or error
last_access_reason	string	Every event — e.g. success, unknown_credential, cooldown, schedule_mismatch, lockdown, duress, held_open
last_access_user	string	Every event — username, or empty for unknown credentials
last_access_at	string	ISO timestamp of the most recent attempt
failed_access_count	int	Consecutive denied attempts since the last grant. Resets to 0 on granted or duress; increments on denied. Physical events (forced, held_open) leave the counter alone.

Pair them with Attribute Triggers for things like "alert me when failed_access_count crosses 5" or "open the gate camera when last_access_result == 'forced'".

Detecting bad credential activity

Three detections cover different shapes of the same underlying question — someone is presenting credentials that don't work. They are deliberately separate, because they call for different responses and different urgency.

note

None of these block entry. GEM observes and alarms; it does not lock a keypad after failed attempts. Locking a door on failed attempts is a denial of service against the people who live or work there, and the intercom's own device-side lockout is better placed — it keeps working when GEM is offline, which is exactly when you'd want it.

PIN scanning — several different codes at one door

The signature of someone working through combinations, as opposed to a resident mistyping one code. Raises the Access PIN Scanning alarm (severity high) against the access device.

failed_access_count can't do this: it counts consecutive denials regardless of which credential was presented, so five attempts at one wrong PIN and five attempts at five different PINs are identical to it. This detection counts distinct credentials inside a window, which separates them.

Attribute	Default	Meaning
pin_scan_alarm_enabled	true	Turn the detection on or off
pin_scan_distinct_codes	3	How many different credentials must be refused to raise. Minimum 2
pin_scan_window_seconds	300	Window the distinct codes are counted over, and the quiet period after which the alarm clears

The alarm raises once per burst, not once per keypress, and clears automatically once the door goes quiet for the length of the window.

Denied outside hours — one refusal, wrong time

Two wrong codes at 04:00 matter more than five at midday, and no count-based rule captures that. Raises the Access Denied Outside Hours alarm (severity medium) on any refusal inside the configured window.

Attribute	Default	Meaning
access_offhours_alarm_enabled	false	Off by default — set the window first
access_offhours_start	22:00	Window start, HH:MM local
access_offhours_end	06:00	Window end, HH:MM local

A window whose end is earlier than its start crosses midnight, which is the usual case. Start equal to end means never, so a half-configured window stays silent rather than alarming on every denial.

Stale credentials — the same code, for weeks

The most common of the three in practice, and the only one that isn't an alarm. One credential refused over and over, across days and often across several doors, is never an attack — an attacker doesn't present the same wrong code for a month. It's a provisioning defect: a revoked worker, a rotated PIN nobody communicated, a code that was never pushed to one particular door.

This is a work item for whoever administers credentials, not an interrupt, so it's delivered as the Stale Credentials report rather than an alarm. Schedule it weekly. See Reports.

The report groups refused attempts by credential fingerprint and shows refusal count, which doors, the first and last sighting, and how many days the credential has been active. Filter with min_attempts (default 3) and multi_door_only — a code tried at several doors is a stronger signal than one person fumbling at the door they always use.

Credentials appear as a truncated fingerprint (#ad4482a7), never as the code itself.

Setting the thresholds

Every threshold above is an attribute, resolved most-specific first:

1. the attribute on the access device — per-door override
2. the same attribute on system — the site-wide setting
3. the built-in default

Doors legitimately differ. A poolside keypad at 23:00 is ordinary where a front door at 04:00 is not, so set a narrower off-hours window on the pool device and leave the site setting alone. Leave a device attribute unset to follow the site.

tip

Before enabling the off-hours alarm, run the Access Activity report filtered to denied over the last month and look at when refusals actually happen. Setting the window from real traffic beats guessing, and a window that fires nightly trains people to ignore it.

Security Considerations

Credential Security

1. Unique PINs & RFIDs: GEM enforces uniqueness across all users (including disabled accounts) when a PIN or RFID is saved — a collision is rejected so keypad / reader input resolves to a single user
2. PIN Length: Minimum 4 digits, recommend 6+
3. Rotation: Encourage regular PIN changes
4. RFID Encryption: Use encrypted RFID formats when available

Access Logging

1. All Events: Log both granted and denied access
2. Audit Trail: Include timestamp, user, device, action
3. Retention: Retain logs per compliance requirements
4. Monitoring: Review logs regularly for anomalies

See Insights > Reports, then choose Access Activity, for access-event reporting and investigation.

Failed Access Attempts

GEM ships three detections for this — PIN scanning, denied-outside-hours, and the Stale Credentials report. See Detecting bad credential activity for what each one catches and how to set its thresholds.

None of them lock a door after failed attempts, by design. If you want a keypad lockout, configure it on the intercom or reader itself, where it keeps working when GEM is offline.

Temporary Access

For temporary users (guests, contractors):

1. Create the user and set their PIN or card
2. Set Valid From and Valid Until on that user — this is the mechanism to use, not a reminder to yourself. When the window closes, access stops and GEM pulls the credential back off any reader that cached it
3. Add them to an existing rule, or to an Access Group the rule already authorizes, so you are not creating a rule per visitor
4. Restrict the schedule if the visit is limited to certain days or hours
5. Revoke immediately if a credential is lost — Revoked overrides any valid window

For repeat visitors and deliveries, Visitors manages the same lifecycle with less handling.

Remote Access

Warning: Access control can grant physical access remotely.

Best Practices:

1. Require 2FA for users who can modify access control
2. Restrict "Access Control" page to admin role only
3. Audit changes to access control rules
4. Log all remote access control operations

Troubleshooting

Nothing happens at all — no log row either

Start here when a badge or PIN produces no reaction and the access log stays empty. A denial would have been logged, so an empty log means the event never reached a rule.

Check:

1. Access Type matches what the device reports — the most common cause. A rule set to PIN Code on a device that only reports a call button never fires. See Which devices can be the access device
2. The access device is enabled and online in System > Devices — a rule on a disabled device is never armed
3. The rule's Status is on
4. The rule points at the reader, not at the lock — a common mix-up, since the lock also appears in the device list
5. Cooldown — a REX or call-button press inside its cooldown is dropped without a log row
6. After enabling the device, reload it from System > Devices; rules re-attach automatically

Credential Not Working

The attempt appears in the access log as denied. Read the reason, which names the cause exactly:

• unknown_credential — the code presented doesn't match any user's PIN, card, or duress PIN. Re-enter it on the Users page
• user_not_authorized — the user is known, but this rule doesn't cover them. Add them to Select Users, or to an authorized group or role
• schedule_mismatch — today's day, this hour, an exception date, or a holiday calendar entry blocks it
• cooldown — they were already granted access within the cooldown window
• lockdown — lockdown is active and this rule doesn't have Allow During Lockdown

Also confirm the user isn't revoked and that Valid From / Valid Until currently permit access — an expired user is refused as unknown_credential, since their credential is no longer live.

Action Not Executing

Check:

1. Device Online: Verify target device (lock, gate) is online
2. Command Valid: Test command independently
3. Macro: If using macro, verify macro works
4. Logs: Check system logs for errors
5. Permissions: Ensure GEM can control target device

tip

When you reload an access device via System > Devices, its access control rules are automatically re-attached. No server restart is needed.

Schedule Not Working

Check:

1. Time Zone: Verify GEM server time zone is correct
2. Server Time: Confirm server time is accurate
3. Day Mask: Verify correct days are checked
4. Hour Mask: Verify correct hours are checked
5. All Days/Hours: Try enabling all to test

Multiple Users, Same Action

Expected Behavior:

• One access control rule can have multiple authorized users
• All users trigger the same action
• To have different actions per user, create separate rules on the same reader — each with its own user list and its own action

Splitting one door into several rules

Every enabled rule on that reader and access type sees every presentation, and each decides independently. So with two per-user rules on one door, each badge-in produces one grant and one denial with reason user_not_authorized from the other rule. That is not a fault, but it does mean:

• the access log carries a matching denial for every entry, which makes "show me the refusals" noisier
• the door's failed_access_count bounces up and back down, so a trigger on that counter needs a threshold above 1

Where one action fits everybody, one rule with everybody on it stays much easier to read.

RFID Not Reading

Check:

1. Reader Power: Ensure reader has power
2. Reader Connection: Verify communication to GEM
3. Card Format: Check card format matches reader
4. Card ID: Verify card ID is correctly stored in user record
5. Read Distance: Hold card closer/longer

Advanced Topics

Multi-Device Access

For locations with multiple entry points:

1. Create separate access device for each entry point
2. Create separate access control rules per device
3. Assign same users to multiple rules
4. Different schedules or actions per entry point

Example:

Front Door: All users, all hours
Back Door: Family only, no guests
Garage: Family + service, scheduled

Cascading Actions

Use macros for complex entry sequences:

Example: "Security Bypass Entry"

User enters PIN at front door:
  1. Disable security alarm (30 second bypass)
  2. Unlock front door (5 second unlock)
  3. Turn on entry lights (stay on)
  4. Send notification: "User entered via front door"
  5. Wait 30 seconds
  6. If security not disarmed, trigger alarm

Integration with Security Systems

Coordinate with security panels:

1. Disarm on Entry: Use macro to disarm when valid credential
2. Arm on Exit: Last person out triggers arm macro
3. Bypass Zones: Temporarily bypass entry zones
4. Alert on Invalid: Multiple failed attempts trigger alert

Conditional Access

A rule's own checks — schedule, groups, roles, lockdown — decide whether the action runs. To make the decision depend on something else, such as the site mode, set Action Type to Run Macro and let the macro decide whether to release the door. The macro owns the unlock, so choosing not to unlock is the same as refusing.

Example: "Mode-Based Access"

Rule: front_door_family → Run Macro: front_door_entry

Macro front_door_entry:
  1. If Attribute   Site Space "Main House", attribute effective_mode equals vacation
       When TRUE  → Email: "Front door PIN used during vacation mode"
       When FALSE → Command: unlock front_door

Two things to hold on to:

• The access log records this as granted either way — the credential was accepted, and what the macro did afterwards is the macro's business. If you need the refusal in the audit trail, have the macro set an attribute you can report on.
• A macro action has no single target door, so held-open detection cannot attach to it. Add a separate Log Only rule whose command targets the door zone if you want that monitoring as well.

Access Level Hierarchies

Create tiered access using multiple rules:

Level 1 - Resident Access:

• All entry points
• All times
• All days

Level 2 - Service Access:

• Service entrance only
• Business hours
• Weekdays only

Level 3 - Guest Access:

• Guest entrance only
• Limited hours
• Specific dates

Centralized credential sync

Some access hardware keeps its own copy of the PINs and cards so it can decide at the door with no server in the loop. GEM pushes to those devices automatically, and you never edit the device's own user directory by hand.

What happens, and when:

You do this	GEM does this
Set or change a user's PIN, duress PIN, or card	Pushes the new credential to every door that user has rights on
Save a rule after adding or removing users	Re-syncs that device's whole directory, so removals drop off too
Disable a user, revoke them, or let Valid Until pass	Disables them on the device — deleting them only if the device offers no disabled state, so history survives where possible
Re-enable a user or extend Valid Until	Pushes their credentials back out

Devices that store nothing locally (a cloud controller that decides centrally, a door station that just reports the press) are skipped — there is nothing to push.

2N intercoms additionally get the schedule pushed, not just the credential. Each rule's day and hour selection is projected onto the user as a time profile inside the unit, so the door enforces the window on its own even if GEM is offline. A user covered by several rules gets the union of their windows; if no rule allows the current time, their access on the unit is switched off rather than left open. Time profiles you configured by hand on the 2N are left alone.

Two 2N settings are worth knowing at commissioning time:

• If the unit rejects credential writes, set the device's auth_method attribute to digest to match the account configured on the unit's HTTP API page.
• Camera privacy masking is exposed as privacy_on, privacy_off, and get_privacy (which reports back into the privacy_state attribute). These use the unit's web-config login, which is a different account from the API user — fill in web_username / web_password if the API account can't reach the web configuration, and define the mask region on the unit first (Hardware → Camera → Privacy Masking), since masking with no region has no visible effect.

Brivo decides at its own cloud service and reports the outcome to GEM, so credential pushes go to Brivo rather than to a panel on site. See Brivo.

Writing a driver for access hardware

A driver joins centralized sync by implementing any subset of four calls — implement one and it participates; implement none and the device simply reports events without holding credentials.

Call	What it must do
syncUser(userId, user)	Create or update that user's credentials on the device. The driver decrypts what it needs.
disableUser(userId)	Block the user without removing them. Preferred, so the device keeps its own history.
deleteUser(userId)	Remove the user. Used only when no disable path exists.
listUsers()	Report the device's current users, for reconciliation.

To raise access events, emit pin, rfid, rex, or call from the driver with the credential value (or a port/identifier for REX). Those four names are what a rule's Access Type listens for.

Related Documentation

• Users - Managing user PINs, RFID cards, duress codes, and credential lifecycle
• Access Groups - Managing reusable groups of users for access rules
• Holiday Calendars - Shared date sets for blocking access across rules
• Roles - Role-based authorization
• Macros - Creating access automation sequences (duress, lockdown, etc.)
• Devices - Configuring access control devices
• Access Activity - Reporting and investigating access events
• Notification Profiles - Configuring denied-access alerts
• Triggers - Advanced access automation