aware

Support & Troubleshooting

Common issues and their resolutions for AwareVue installations.

Paxton — ACU Beeping

Symptom: Paxton access control units produce a beeping sound.

Cause: Paxton ACUs emit an audible beep when they are actively being pinged on the network. If Paxton ACUs are beeping continuously, check for any network monitoring or discovery tools that may be actively pinging the devices

Resolution: This is expected behaviour and does not indicate a fault.

Paxton — Check-In / Check-Out Delay

Symptom: Check-in / check-out events are delayed when using a Paxton-controlled door reader. Why does this happen?

Cause: When a reader is connected to a Paxton ACU and is also used for check-in/check-out, the system waits for the “Access Granted” event before triggering the check-in or check-out action. In Paxton Net2, this timing is linked to the Door Release Time, which defaults to 10 seconds. The check-in/check-out event will not process until this door release period has completed.

Resolution: The Door Release Time can be reduced (for example, to 5 seconds) in Paxton Net2 to speed up the event. Note: Changing the Door Release Time will affect how long the door remains unlocked. If the same reader is being used for both door control and check-in/check-out, adjusting this setting may impact door operation.

Paxton — Door Not Responsive

Symptom A: Door appears greyed out in AwareVue.

Cause: The Paxton controller for that door is offline.

Symptom B: Door appears normal but commands produce no feedback.

Cause: Paxton Net2 services are not running.

Resolution:

Access the Paxton Net2.0 Virtual Machine.
On the desktop system tray, locate the green Paxton triangle icon.
Right-click the icon.
Select Stop Services.
Once stopped, select Start Services.
Return to YachtAware and check if door status and control have been restored.

If this does not resolve the issue, a full restart of the Paxton Net2 VM may be required.

Paxton — Doors Not Appearing in Discovery

Symptom: Doors not appearing in YA during discovery but visible in NET2

Causes:

The reader’s operation mode is set to Inactive in the Paxton Net2 configuration.
The API user account does not have the required access rights in Net2.

Resolution: The reader operation mode was set to Inactive setting it to something other than inactive allowed it to be returned via the API call and so showed during discovery.

API user must also have access rights to the door.

Readers are discovered in a separate way so can be discovered independently of doors.

Armatura — Lockdown Mode Triggered

Symptom: Armatura access system enters lockdown mode.

Cause: Lockdown was triggered by presenting a Super User card three consecutive times.

Resolution:

Swipe the Super User card three consecutive times again to exit lockdown.
Alternatively, disable lockdown mode in the Armatura software configuration.

Milestone — FFMpeg Authentication Issue

Symptom: Milestone NVR streams fail with FFMpeg/FFPlay/FFProbe SHA-256 authentication errors when using the Open Network Bridge.

Cause: The Milestone Open Network Bridge uses SHA-256 digest authentication by default, which is not supported by some FFMpeg builds.

Resolution (Option 1): Disable SHA-256 authentication via a Windows registry key on the Milestone server. Refer to Milestone documentation for the specific registry path.

Resolution (Option 2): Use the go2rtc stream proxy. Configure the Milestone stream through go2rtc, which handles the authentication translation transparently.

← Back to Manual