Mercury native area control limitations
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 , 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.
- In the Synergis™ Appliance Portal,
navigate to , and then schedule a daily or weekly reset.