YachtAware — Product Documentation

YachtAware is an intuitive IoT platform for physical security surveillance and automation created by AwareVue. It connects to a wide range of devices, hardware controllers, and third-party access control and CCTV systems, presenting everything through a unified, touch-first web interface optimized for kiosks and tablets. The platform runs in any modern browser — Chrome is recommended.

User Manual

For step-by-step operating instructions, device callout references, how-to guides, and troubleshooting, see the YachtAware User Manual.

Table of Contents

  1. Core Concepts
  2. Third-Party Integrations
  3. CCTV & Video Surveillance
  4. Access Control
  5. Access Paths
  6. Visitor Management & Presence
  7. Device Control & Monitoring
  8. IO Boards & Virtual Devices
  9. Events & Notifications
  10. Automation Rules
  11. Alarms
  12. Automation & Alarms — How They Work Together
  13. Macros
  14. Views & Layouts
  15. Casting to Displays
  16. Security Levels
  17. Citadel Mode
  18. Users, Roles & Permissions
  19. Configuration & Extensibility

Core Concepts

Devices

Every physical piece of hardware — cameras, doors, readers, motion sensors, panic buttons, intercoms, displays, NVR recorders, IO boards — is modelled as a Device in YachtAware. Devices have a type, a name, optional tags, and belong to one or more device groups. They can be related to each other (e.g., a camera observes a door, a controller controls a reader).

Devices communicate with the platform through providers — adapters for different protocols and systems. YachtAware’s integration model is described in detail in the Third-Party Integrations section.

Events

Everything that happens in the physical world is captured as a Device Event — a timestamped record tied to a specific device. Standard event kinds include:

Category Event Kinds
Doors door-force, door-unlock, door-lock, door-left-open, door-tamper, door-tamper-restored, door-relock
Door controller health door-mains-failed, door-mains-restored, door-acu-not-responding, door-acu-online
Motion motion-detected, motion-cleared
Panic panic-button-pressed
Cameras object-detection-started, object-detection-ended
Access person-in, person-out, credential-used, credential-invalid
System notification-created, notification-acknowledged

Not every device reports every kind - the exact set depends on the hardware and integration. For access control controllers (for example Paxton ACUs), the door controller health events are how operators learn that a controller has lost mains power or dropped off the network.

Events are the central nervous system of the platform. They feed the Event Journal, trigger Automation Rules, generate Alarms, and update Presence records — all in real time.

People & Credentials

A Person is anyone who interacts with the facility — staff, visitors, contractors. Each person can hold one or more Credentials: physical tokens or digital identifiers that access control readers recognize. Supported credential types include:

  • RFID — proximity cards and fobs
  • PIN — numeric keypad codes
  • Biometric — fingerprint
  • Mobile — smartphone-based credentials
  • Face — facial recognition
  • Badge — visual/printed badges

People are organized by Person Types — two are built in (Crew and Visitor) and more can be created freely (e.g., Contractor, Delivery, VIP). Person types control visitor management behavior, security check requirements, agreement mandates, and whether the platform pushes credentials to hardware controllers.

Zones

A Zone is a logical grouping of devices representing a physical area (e.g., “Server Room”, “Main Entrance Lobby”). Zones are used to:

  • Scope access rules to areas rather than individual doors
  • Track presence — when someone checks in through a door in a zone, they appear as present in that zone
  • Organize the facility into meaningful security regions

One special zone — the Global Zone — spans the entire facility.

Schedules

A Schedule defines a recurring time window (days of the week, time ranges, specific dates, with optional exclusions). Schedules are attached to access rules to make permissions time-limited — e.g., a contractor may have access only on weekdays between 08:00 and 18:00.

Third-Party Integrations

YachtAware is designed to work with heterogeneous physical security infrastructure. It does not lock you into a single vendor — instead it provides a hub that third-party systems connect to, each translated into the platform’s unified device, event, and command model.

Agent Architecture (Current Approach)

The modern integration model is agent-based. A lightweight agent process runs alongside a third-party system and connects to the YachtAware hub over WebSockets. The agent is responsible for:

  • Translating the external system’s events into standard YachtAware device events
  • Forwarding commands from YachtAware to the external system
  • Reporting device discovery and capability information

This architecture means integrations are decoupled from the core platform and can be developed, deployed, and updated independently.

Supported Third-Party Systems

YachtAware currently integrates with:

System Category
ONVIF IP camera protocol (discovery, streaming, PTZ, events)
RTSP Direct stream ingestion
Aware-vms AI-powered NVR — object detection, recording, WebRTC streaming
Milestone XProtect Enterprise VMS - Live camera viewing, Recorded video playback, Camera status monitoring, Alarm and event integration, Exporting footage
Orchid Video Management System
Paxton / Net2 Access control - doors and readers, door control, access and controller-health events
2n-Intercom Integrated camera feed, SIP-based calling, Access control functionality
ZkTeco/Armatura Integrated camera feed, SIP-based calling, Access control functionality
Inner Range Access control
Biostar-Suprema Biometric readers
AXIS Intercoms and IP cameras
Asterisk SIP / telephony for intercom audio
Advantech-ADAM I/O Modules, I/O Controllers, Allows control of various devices via I/O boards

For step-by-step setup of individual providers, see the Integrations guides in the User Manual.

Camera & VMS Integration

For camera and VMS integrations, YachtAware maps each connected camera to a device in its registry and subscribes to its event stream. Object detection results, motion events, and recording timelines flow through to the platform in real time. Streams are proxied for live playback and connected to the playback timeline for recorded footage.

Intercom Integrations

YachtAware supports several intercom integrations, including 2n IP Style and ZKTeco/Armatura Omni AC30. Depending on the model, these intercoms can provide integrated camera feed, SIP-based calling and Access control functionality. The intercom used will depend on the specific requirements of the yacht or project.

CCTV & Video Surveillance

Cameras

YachtAware connects to IP cameras using standard protocols (ONVIF, RTSP) and third-party AI-capable systems. Each camera is a device that can expose multiple streams — for example a high-resolution main stream for recording and a lower-resolution sub-stream for live monitoring. You choose which streams to display or record independently.

Supported camera types:

  • Standard fixed cameras
  • PTZ (Pan-Tilt-Zoom) cameras
  • 360° / fisheye cameras with scene dewarping
  • Camera lifts (height-adjustable mounts with lift-state tracking)

Live Monitoring

The live view renders camera feeds inside configurable dashboard views. The interface is grid-based — you arrange cameras into panels of any size. For PTZ cameras, on-screen controls let you pan, tilt, and zoom. For 360° cameras, the UI renders an interactive dewarped scene you can navigate with touch or mouse.

Recording

Streams can be bound to NVR (Network Video Recorder) devices. The recording configuration maps a specific camera stream to a specific recorder, giving you fine-grained control over which footage is stored and where. Playback uses a timeline scrubber to seek through recorded footage.

Bookmarks

Any operator can place a Bookmark on the timeline — a labelled marker tied to a specific camera and timestamp. Bookmarks are searchable by label, camera, author, and time range. They serve as a lightweight incident documentation tool: spot something in a recording, bookmark it, add a label, come back to it later.

AI Object Detection

When connected to an AI-capable backend (such as aware-vms), cameras emit object detection events when recognized objects enter or leave the scene. Detected object classes include: person, vehicle, car, motorcycle, bicycle, animal, dog, cat, package, and more.

Object detection events feed directly into the automation engine — for example: “if a person is detected on Camera 3 after 22:00, trigger an alarm.”

The media module includes a semantic search engine over recorded footage. Instead of manually scrubbing through hours of video, operators can search for recorded segments by describing what they are looking for. Search results are ranked by relevance.

PTZ Presets

PTZ cameras support presets — named camera positions you define and recall on demand. Presets can also be recalled automatically in response to events through the automation engine (e.g., move a PTZ camera to the “Gate” preset when the gate door is forced).

Access Control

People Directory

The People directory is the central registry of everyone who needs to interact with the facility. Each person record contains:

  • Name and position
  • Person type (staff, visitor, contractor, etc.)
  • Avatar photo
  • One or more credentials
  • Access validity window (valid from / valid to dates)
  • Custom fields
  • Access suspension flag

People can be archived rather than deleted, preserving their event history.

Access Rules

An Access Rule is a named policy that grants a set of people access to a set of doors or zones, optionally constrained by a schedule. The model is:

Access Rule
  ├── People (many) ← who
  ├── Door/Zone Permissions (many) ← where
  │     └── Schedule (optional) ← when

A single person can belong to multiple access rules, and a single rule can cover multiple people. This makes it straightforward to manage large groups — for example, add a new employee to the “Office Staff” rule and they immediately inherit all associated door permissions.

Zones in Access Control

Instead of assigning access to individual doors, you can assign access to a Zone — then all doors in that zone inherit the permission. This is especially useful for large facilities where areas are more meaningful than individual door lists.

Schedules

Access rules support time constraints through schedules. A schedule can be:

  • Always — access at any time
  • Never — explicitly blocked
  • Custom — specific days of the week, time windows, or calendar dates with optional exclusions

Credential Management

Credentials are managed independently of people. A credential can be:

  • Assigned to a person (normal use)
  • Unassigned / floating (e.g., a pool of visitor RFID cards not yet issued)
  • Enabled or disabled individually without affecting other credentials

Each credential type has a unique token. The uniqueness constraint is per type, so the same numeric PIN cannot be registered twice, preventing accidental conflicts.

Access Control Authorities

YachtAware can synchronize its access control data with external identity providers — third-party access control systems that act as the authoritative source for people and credentials. Synchronization is configurable and the platform tracks the last sync timestamp per authority.

Agreements

You can define Agreements (e.g., NDA, site safety induction) and track which people have signed them. Agreement status appears on a person’s profile and can be used as a gate in workflows.

ID & Report Templates

The platform supports HTML-based templates for generating printed ID cards and access reports. Templates are stored in the file store and associated with person or access data.

Visitor Management & Presence

How Presence Works

When a credential is used at a door belonging to a zone, the platform determines the direction of travel (entry or exit) and updates the person’s presence in that zone. Each presence record tracks:

  • Last check-in timestamp
  • Last check-out timestamp
  • Whether the person is currently inside (online)
  • Whether the person is on leave
  • Whether a security check has been completed

The Presence view groups people by zone and shows who is currently on-site, who has left, and their movement history.

Visitor Flows

Visitors are persons of a type configured for visitor management. When a visitor arrives:

  1. A person record is created (or retrieved if they have visited before)
  2. A temporary credential may be issued
  3. The visitor checks in through a reader or visitor station
  4. Their presence is tracked in real time
  5. On departure, checkout is recorded

Security Checks

Person types can require a security check — a manual confirmation by a security operator before the person’s presence is marked as verified. This is useful for facilities with manned security desks where badges are physically inspected.

Device Control & Monitoring

Supported Device Types

Type Description
Camera IP camera (fixed, PTZ, 360°, lift)
Door Physical door with lock/unlock control
Reader Access credential reader (entry/exit)
Motion Sensor PIR or similar intrusion detector
Panic Button Manual alarm trigger
Intercom Terminal Two-way audio/video intercom
IO Board Physical input/output controller
Display External screen for casting views
NVR Recorder Network video recording unit

Real-Time Status

The device list shows each device’s live state. Devices that are armed show a visual armed indicator; devices in a triggered alarm state show a highlighted warning style.

Devices that are offline or unreachable are greyed out - both in the device list and on Layout maps. This applies to every device type (cameras, doors, readers, motion sensors, panic buttons, intercoms, IO boards), not just access control hardware. See Device Availability.

Commands

Operators can send commands to devices directly from the interface — for example:

  • Door: lock, unlock, request to exit
  • PTZ Camera: move to preset, pan, tilt, zoom
  • Display: cast a view

Commands can also be issued programmatically through automation rules and macros.

Device Groups

Devices can be organized into named Device Groups for easier bulk management and selection in automation rules.

Device Relations

Devices can be linked to each other with typed relationships:

  • isObservedBy — a door is observed by a camera
  • isControlledBy — a reader is controlled by a controller
  • isPartOf — a device is part of a system or group

These relationships are used by the layout editor (e.g., drawing a camera cone on a map) and by the automation engine when selecting target devices dynamically.

Device Notes

Each device supports freeform notes — useful for recording installation details, maintenance history, or special operating instructions.

Custom Specs Override

If a device reports incorrect capabilities or specifications, operators can manually override them on a per-device basis.

IO Boards & Virtual Devices

An IO Board is a hardware unit that exposes assignable binary signals — each signal is either on or off. IO boards are the bridge between the YachtAware platform and physical electrical circuits: relays, sensors, locks, light indicators, and any other on/off electrical element.

Virtual Devices

Because not every physical installation uses a dedicated smart controller per device, YachtAware supports virtual devices — software-defined devices whose state and behavior are mapped to one or more IO board signals.

For example, suppose a door does not have a dedicated access control panel. You can define a virtual door in YachtAware and wire it as follows:

  • State reading: map the door’s open/closed sense to an IO board input signal — when that signal goes high, the door is reported as open
  • Unlock command: map the unlock action to an IO board output signal — sending the command pulls that signal high, energizing the electric strike

From the rest of the platform’s perspective, this virtual door behaves identically to any other door device. It generates door-unlock, door-force, and door-left-open events; it can be targeted by automation rules and macros; it appears in access rules and on layouts.

The same pattern applies to motion sensors, alarm outputs, or any device type that can be modelled as binary state changes. IO board wiring is configured per device through the device’s custom settings in the UI.

Events & Notifications

Event Journal

The Event Journal is a searchable, filterable chronological log of all device events across the facility. Operators can filter by:

  • Device
  • Event kind
  • Person
  • Time range

Events include rich metadata — for access events, the person and credential used are linked; for detection events, the object class is recorded.

Notifications

Notifications are system-generated messages with a severity level. They differ from raw device events in that they are explicitly addressed to operators and require acknowledgment.

Severity levels range from debug through info and warning to critical. Notifications can be filtered by severity, device, time, and acknowledgment status. Real-time delivery is handled over WebSockets.

Access Paths

An Access Path solves a common physical security problem: when an authorized person passes through a secured area, the motion sensors and doors along their path should not trigger an alarm — even if those devices are armed.

How Access Paths Work

You configure an Access Path by defining:

  1. Trigger — a reader authorization event or door access event that indicates a person has legitimately entered an area
  2. Disarm targets — a collection of motion sensors and/or doors that should be temporarily disarmed to allow safe passage

When the trigger fires (e.g., an authorized card swipe at the entrance reader), the platform automatically disarms the nominated devices so the person can move through without setting off alarms. Once passage is complete, the devices return to their armed state.

Why This Matters

Without Access Paths, every authorized person moving through a monitored area would need to remember to manually disarm sensors — or the alarm would fire on legitimate access. Access Paths automate this entirely: the act of authorized entry is itself the signal to create a safe corridor.

Under the Hood

Access Paths are implemented as a specialized category of automation rules with the access-path module tag. This means they share the same engine as general automation — they can be viewed alongside other rules and follow the same enable/disable mechanism — but they are managed and displayed through a dedicated, purpose-built configuration interface rather than the general automation builder.

Automation Rules

Automation rules are the platform’s event-response engine. Each rule listens for a specific device event and, when the event occurs, optionally evaluates a condition and then executes one or more commands.

Important: While the automation engine is a single unified system, three distinct types of rules run within it — each with its own purpose and management interface:

  • Custom Automation — general-purpose rules built by operators
  • Alarm configuration — rules that define which devices trigger the alarm and under what conditions
  • Access Paths — rules that disarm devices when authorized access events occur

Alarm configuration and Access Paths are both encoded as automation rules behind the scenes and share the same execution engine, but they have dedicated configuration interfaces that abstract the underlying rule structure.

Building Custom Automation Rules

The automation rule builder lets operators create rules entirely through the UI — no scripting required. You pick a trigger event, optionally add a condition, then build a list of actions.

Rule Structure 

Automation Rule
  ├── Trigger: on event kind (e.g., door-force)
  ├── Condition: optional expression (e.g., time of day, device state)
  └── Actions: list of commands
        ├── command (e.g., arm-device, send-notification)
        ├── target: expression selecting devices (e.g., devices.by-type("camera"))
        └── params: command-specific parameters

Trigger Events

Any device event kind can be a trigger — door events, motion detection, panic button presses, access events, camera object detection, and notification lifecycle events.

Conditions

Rules can include a condition expression (runIf) evaluated at execution time. This allows rules to be selective — for example, “only run this rule if the current security level is High” or “only if it is outside business hours.”

Actions / Commands

Available command types include:

Command Description
arm-device Arms a device for alarm monitoring
disarm-device Disarms a device
send-notification Creates a notification for operators
unlock-door Unlocks a door
lock-door Locks a door
toggle-device Toggles a device state

Target Expressions

Commands use expressions to select which devices they apply to — rather than hardcoding a single device, you can write devices.by-type("door") to target all doors, or devices.by-group("perimeter") to target a group. This makes rules reusable across many devices.

Exclusivity Groups

Rules can be assigned to an exclusivity group with a priority score. When multiple rules in the same group would fire simultaneously, only the highest-scoring rule executes. This prevents conflicting responses to the same event.

Enabling & Disabling

Each rule has an enabled flag. Disabled rules are stored but never fire. This lets operators temporarily suspend a rule without losing its configuration.

Alarms

What Is an Alarm?

An Alarm is a formal incident state that the system enters when a security event occurs that requires operator attention. Unlike a notification (which is informational), an active alarm is a modal condition — the platform surfaces it prominently in the UI and plays an audible alert.

Only one alarm can be active at a time. When an alarm fires, the platform records which device events triggered it.

Alarm Triggers

Alarm triggers are device events that the system is configured to treat as alarm-worthy. Each armed device has a behavior configuration:

Behavior Meaning
trigger-always This device always triggers an alarm when its alarm event occurs
trigger-when-armed Only triggers when the device is in armed state
ignore This device’s events never trigger an alarm

Armed State

Devices can be individually armed or disarmed by operators. There is also a bypass state — a device that is bypassed is temporarily excluded from alarm triggering without being fully disarmed. Bypass is useful when a sensor is malfunctioning or a zone is under maintenance.

Global arm/disarm controls allow an operator to arm or disarm all monitored devices at once.

Acknowledging an Alarm

When an alarm fires, operators see a modal overlay displaying:

  • The list of triggering events with device names, event kinds, and timestamps
  • An Acknowledge button
  • A Minimize button (hide the panel without acknowledging)
  • A Do Not Disturb toggle to silence the audio alert

Acknowledging the alarm records the operator’s identity and timestamp, then clears the active alarm state.

Alarm History

Past alarms are retained with full trigger records. Operators can search alarm history by device, person, time range, and kind.

Alarm Matrix

The Alarm Matrix view provides a bird’s-eye configuration table showing every device’s alarm behavior and arm state. From this view, administrators can review and change the behavior setting for each device at once.

Automation & Alarms — How They Work Together

Automation and alarms are deeply connected. Here is the complete flow from physical event to operator response:

Physical event (e.g., door forced open)
        │
        ▼
Device Event stored in journal
        │
        ▼
Automation Rules evaluated
   ├── Alarm-module rules → may trigger the alarm
   ├── General rules → may send notifications, lock doors, move cameras
   └── Access-path rules → may update access state
        │
        ▼
Alarm state becomes active (if alarm rule fired)
        │
        ▼
Alarm overlay appears in all connected operator sessions
Audible alert plays
        │
        ▼
Operator reviews triggering events → Acknowledges alarm
        │
        ▼
Alarm cleared, acknowledgment logged

A Practical Example

Suppose you want the system to:

  1. Sound an alarm if the server room door is forced open at any time
  2. Lock the adjacent fire exit automatically
  3. Move a PTZ camera to the server room preset
  4. Send a critical notification to all operators

You would configure:

  • An alarm rule triggered by door-force on the server room door with behavior trigger-always
  • A general automation rule triggered by the same door-force event with three actions: lock-door targeting the fire exit, move-to-preset targeting the PTZ camera, and send-notification with severity critical

Both rules fire simultaneously when the door is forced. The alarm brings every connected operator to attention while the physical responses happen automatically.

Security Levels & Automation

Automation rule conditions can reference the active security level. This lets you define rules that only fire during specific postures — for example, motion detection in the parking lot might only trigger an alarm when the security level is set to “High”. During normal operations the same motion event would be silently logged. Support for security level conditions in the automation UI builder is planned for an upcoming release.

Macros

A Macro is a named, ordered sequence of device commands that an operator can execute in one action. Where automation rules fire automatically in response to events, macros are triggered manually.

Macro Structure 

Macro
  ├── Step 1: device + command + params
  ├── Step 2: device + command + params
  └── Step N: ...

Each step targets a specific device and sends a specific command with parameters. Steps execute in sequence.

Use Cases

  • Opening sequence: unlock the lobby door, turn on the entry camera’s flood light, move the PTZ to the entrance preset
  • Lockdown sequence: lock all perimeter doors, arm all motion sensors
  • End-of-day sequence: lock all doors, set the security level to “Night”

Macros can be associated with a module (automation or access-path) to scope their management permissions.

Views & Layouts

Views

A View is a configurable dashboard — a grid of panels where each panel displays a widget. Widget types include:

Widget Type Description
Device View Live feed or status of a single device
Device Carousel Rotating slideshow of multiple devices
Layout View A full floor-plan layout embedded in a panel
Playback Track Video timeline scrubber for recorded footage

Views are fully user-defined. You create a view, define the grid dimensions and panel arrangement, and assign content to each panel. Views are saved and can be recalled instantly.

Layouts

A Layout is a floor-plan or map with interactive device overlays. You upload a background image (your facility’s floor plan, a site map, or any reference image) and place device objects on top of it.

Layout features:

  • Drag-and-drop editor — position device markers precisely on the map
  • Callout annotations — attach labels to any position
  • Camera cones — visualize a PTZ camera’s field of view on the map
  • Layers — organize overlaid objects by layer for visibility control
  • Hotspots — interactive areas on the layout that trigger actions or navigate to another view when clicked

Layouts can be embedded as panels inside Views, giving operators a spatial overview alongside live feeds.

How Views & Layouts Work Together

A typical operator screen might combine:

  • A layout panel showing the full building floor plan with armed/triggered device indicators
  • Several camera panels showing live feeds from key areas
  • A notifications panel

All within a single View that the operator recalled with one tap.

Casting to Displays

Casting lets you push a view — or a composition of camera streams — to a physical display device connected to the platform. This is useful for:

  • Security operations center display walls
  • Reception desk monitors showing visitor cameras
  • Public-area screens

From the Cast dialog, the operator selects which camera streams to include and which display device should receive them. The display then shows the selected streams in a grid.

Security Levels

A Security Level is a named system-wide security posture. At any given moment, exactly one security level is active. Operators switch between levels from the top app bar.

What Security Levels Control

Security levels currently govern visitor management policies:

  • Bag check mandates — whether visitors are required to undergo a bag/item inspection upon entry
  • Agreement requirements — which agreements (NDAs, safety inductions, etc.) must be acknowledged at each security level

When an operator elevates the security level, the platform enforces stricter visitor management procedures automatically — security staff see updated requirements for incoming visitors without any manual reconfiguration.

Security Levels & Automation

Automation rule conditions can reference the active security level, allowing rules to behave differently depending on the current posture. For example, the same motion event could trigger an alarm at “High” security but only log silently at “Normal”. Direct security level support in the automation UI builder is planned for an upcoming release.

Roadmap

Security levels are designed to become a broader policy control mechanism. Future releases will expand their scope to include alarm sensitivity settings and additional automation behaviors.

Citadel Mode

Citadel Mode is an emergency lockdown capability. When activated:

  • All operator sessions on workstations that do not have the citadel-mode permission are immediately logged out
  • The system enters a restricted operating state

Citadel Mode is activated from the app bar by authorized operators. A confirmation dialog warns about the session-termination effect before proceeding. The mode can be exited by the same authorized operators.

This feature is designed for situations requiring immediate isolation of the facility management system — ensuring that only trusted, authorized personnel can interact with the platform during a critical incident.

Users, Roles & Permissions

Users

Each operator has a user account with credentials (username/password or email-based). User accounts can be activated or deactivated. User records are separate from Person records — a person in the access control directory is not automatically a system operator.

Roles & Permissions

Access to platform features is controlled by a fine-grained permission system. Permissions follow the pattern resource:action, for example:

Permission Meaning
alarm:read View alarms
alarm:arm Arm/disarm devices
alarm:bypass Bypass sensors
device:delete Remove devices
camera:stream View live streams
automation:create Create automation rules
security-level:update Change the active security level
citadel-mode:toggle Enter/exit Citadel Mode
person-type:create Define new person types

Permissions are grouped into Roles. Users are assigned roles. The UI automatically hides or disables controls that the current user does not have permission to use.

UI Profile

Each user’s interface can be tailored — for example, the security level picker and Citadel Mode toggle in the app bar can be shown or hidden per user based on their role’s relevance to those features.

API Keys

For programmatic integration, the platform supports API Keys — long-lived credentials that external systems use to authenticate API calls. API key management is available to administrators.

Configuration & Extensibility

Custom Fields

Both Person and Device records support user-defined custom fields. Field types include string, boolean, number, and date. This allows operators to extend the data model without code changes — for example, adding an “Employee ID” field to persons or a “Cabinet Location” field to devices.

Custom fields appear in the detail views of the entity they extend.

Device Groups

Devices can be organized into named Device Groups (with optional short codes). Groups make it easy to select sets of devices in automation rules and macros, and to filter the device list.

Person Types

Person Types define categories of people in the facility. Two types are built into the platform — Crew and Visitor — and you can create as many additional types as your facility requires (e.g., Contractor, Delivery, VIP).

Person types control:

  • Visitor management behavior — whether people of this type participate in the presence and check-in/check-out workflow
  • Security requirements — whether a bag check or security inspection is mandated upon entry for this type at the current security level
  • Agreement requirements — which agreements must be signed before access is granted
  • Access entitlements — whether people of this type receive their access rights from door controllers and intercoms (i.e., whether the platform pushes their credentials to hardware access control systems)
  • Presence registration — whether a presence record is automatically created when a person of this type is added

Person types are fully user-configurable — you can create, rename, and delete them (with the exception of the two built-in types).

Schedules

Schedules are reusable time-window definitions. The same schedule can be attached to multiple access rule permissions, so updating a schedule (e.g., changing business hours) automatically applies to all rules that reference it.

Agreements

Operators can define Agreements (consent forms, safety inductions, NDAs) and track acceptance per person. This provides an audit trail for compliance purposes.