Mercury native area control limitations

2024-05-08Last updated

The Mercury native area control, which includes interlock, max occupancy, and antipassback, has some limitations.

Soft antipassback
The Antipassback violation event for soft antipassback is generated when the door opens instead of when access is granted.

If you configure soft antipassback on a door without a door sensor, Antipassback violation events are never generated because the door never opens.

Soft antipassback on Mercury does not support a presence timeout.

Hard antipassback
Mercury does not support the following:
  • Hard antipassback that is not also set to Strict.
  • Strict and hard antipassback when the Activate global antipassback setting is enabled on the Access Manager role in Config Tool.
Antipassback timeout
Mercury supports a timeout on hard and strict antipassback. If Presence timeout is configured on an area, hard antipassback denies access to a cardholder until the timeout elapses, after which the cardholder can be granted access to the area again.

This triggers an Antipassback violation event for soft antipassback, and then hard antipassback re-applies to the cardholder until the timer elapses again. This configuration is not compatible with areas controlled by Synergis™ Softwire.

Mercury's one-to-one model for cardholders and credentials
If a cardholder in Security Center has multiple card credentials, each credential is considered belonging to a separate cardholder at the Mercury level.

This means that each credential can be used to enter the same area once without causing an antipassback violation. Similarly, if the cardholder uses two different credentials to enter an antipassback area with max occupancy, that cardholder is counted as two people in the max occupancy count.

Bypass antipassback
No Antipassback violation events are generated by cardholders that have the Bypass antipassback rules option enabled.
Interlock and antipassback
Interlock and antipassback only work if all doors configured in the area using these features are controlled by the same Mercury controller.

A Mercury controller can have doors in many areas with any combination of these features, or none of them. In areas where you are not using these features, you can have doors controlled by multiple Mercury controllers.

A Mercury controlled door can only be used as the entrance and exit of one area using either interlock or antipassback, even though in Security Center, you can configure multiple areas for the same door.

Interlock
If only part of the interlock is offline due to failure of a single SIO board, the interlock prevents other doors in the interlock area from being unlocked or opened.

When native interlock is enabled, the Override and Lockdown options in Config Tool are not supported. The options can be configured, but will not change anything.

Scheduled antipassback
Scheduled antipassback is not supported at the Mercury level. Synergis Softwire will enable and disable antipassback on schedule as long as the Mercury controllers are connected or when they reconnect, and the schedule is not set to Always. Mercury does not transition on the schedule itself, so it remains in its state at the time of the disconnect.
People counting discrepancies
Because Mercury tracks its own areas, the people count might not always match on the Synergis™ Cloud Link, in the Security Desk People counting task, and on the Mercury controller. To prevent these discrepancies from causing issues, it is recommended that you regularly reset the people count by doing the following:
  • In the Synergis™ Appliance Portal, navigate to Configuration > Unit-wide parameters > Area configuration , and then schedule a daily or weekly reset.

    This resets the people count on the Synergis Cloud Link and on the Mercury controllers it manages.

  • In Config Tool, reset the count in the People counting task, using the Reset area people count action in scheduled tasks or event-to actions for each area you want cleared.