AwareVue is an intuitive IoT platform for physical security surveillance and automation. 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.
For step-by-step operating instructions, device callout references, how-to guides, and troubleshooting, see the AwareVue User Manual.
Every physical piece of hardware — cameras, doors, readers, motion sensors, panic buttons, intercoms, displays, NVR recorders, IO boards — is modelled as a Device in AwareVue. 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. AwareVue’s integration model is described in detail in the Third-Party Integrations section.
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 |
| 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 |
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.
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:
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.
A Zone is a logical grouping of devices representing a physical area (e.g., “Server Room”, “Main Entrance Lobby”). Zones are used to:
One special zone — the Global Zone — spans the entire facility.
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.
AwareVue 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.
The modern integration model is agent-based. A lightweight agent process runs alongside a third-party system and connects to the AwareVue hub over WebSockets. The agent is responsible for:
This architecture means integrations are decoupled from the core platform and can be developed, deployed, and updated independently.
AwareVue 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 |
| Orchid | Video Management System |
For camera and VMS integrations, AwareVue 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.
AwareVue 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:
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.
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.
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.
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 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).
The People directory is the central registry of everyone who needs to interact with the facility. Each person record contains:
valid from / valid to dates)People can be archived rather than deleted, preserving their event history.
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.
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.
Access rules support time constraints through schedules. A schedule can be:
Credentials are managed independently of people. A credential can be:
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.
AwareVue 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.
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.
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.
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:
online)The Presence view groups people by zone and shows who is currently on-site, who has left, and their movement history.
Visitors are persons of a type configured for visitor management. When a visitor arrives:
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.
| 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 |
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.
Operators can send commands to devices directly from the interface — for example:
Commands can also be issued programmatically through automation rules and macros.
Devices can be organized into named Device Groups for easier bulk management and selection in automation rules.
Devices can be linked to each other with typed relationships:
isObservedBy — a door is observed by a cameraisControlledBy — a reader is controlled by a controllerisPartOf — a device is part of a system or groupThese 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.
Each device supports freeform notes — useful for recording installation details, maintenance history, or special operating instructions.
If a device reports incorrect capabilities or specifications, operators can manually override them on a per-device basis.
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 AwareVue platform and physical electrical circuits: relays, sensors, locks, light indicators, and any other on/off electrical element.
Because not every physical installation uses a dedicated smart controller per device, AwareVue 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 AwareVue and wire it as follows:
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.
The Event Journal is a searchable, filterable chronological log of all device events across the facility. Operators can filter by:
Events include rich metadata — for access events, the person and credential used are linked; for detection events, the object class is recorded.
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.
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.
You configure an Access Path by defining:
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.
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.
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 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.
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.
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
Any device event kind can be a trigger — door events, motion detection, panic button presses, access events, camera object detection, and notification lifecycle events.
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.”
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 |
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.
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.
Each rule has an enabled flag. Disabled rules are stored but never fire. This lets operators temporarily suspend a rule without losing its configuration.
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 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 |
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.
When an alarm fires, operators see a modal overlay displaying:
Acknowledging the alarm records the operator’s identity and timestamp, then clears the active alarm state.
Past alarms are retained with full trigger records. Operators can search alarm history by device, person, time range, and kind.
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 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
Suppose you want the system to:
You would configure:
door-force on the server room door with behavior trigger-alwaysdoor-force event with three actions: lock-door targeting the fire exit, move-to-preset targeting the PTZ camera, and send-notification with severity criticalBoth rules fire simultaneously when the door is forced. The alarm brings every connected operator to attention while the physical responses happen automatically.
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.
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
├── 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.
Macros can be associated with a module (automation or access-path) to scope their management permissions.
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.
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:
Layouts can be embedded as panels inside Views, giving operators a spatial overview alongside live feeds.
A typical operator screen might combine:
All within a single View that the operator recalled with one tap.
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:
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.
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.
Security levels currently govern visitor management policies:
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.
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.
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 is an emergency lockdown capability. When activated:
citadel-mode permission are immediately logged outCitadel 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.
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.
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.
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.
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.
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.
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 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:
Person types are fully user-configurable — you can create, rename, and delete them (with the exception of the two built-in types).
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.
Operators can define Agreements (consent forms, safety inductions, NDAs) and track acceptance per person. This provides an audit trail for compliance purposes.