How the Mercury driver works
About Mercury and Niagara data exchange
The NiagaraAX Station functions as a client and the Mercury panel as the server. NiagaraAX sends a message and the panel replies. You can modify Boolean statuses. Relays light up when BooleanWriteables are sent to a panel.
The Mercury driver is especially suited to monitoring security and air handling. Virtual outputs in the panel receive alarms from the station. The acknowledgment is sent back from the panel to the station.
About Mercury Panel discovery
Each Mercury panel is represented as a Mercury device in the station’s Mercury network. The network provides device discovery when adding panels for most recent platforms such as the and series, or any Windows-based platform. If your network includes a or other “non-Hotspot VM” platform, Mercury Devices must be added manually. User credentials for a panel are required whenever adding a Mercury Device to the network.
About Mercury proxy points
All added Mercury proxy points are Boolean types, as either BooleanPoints (for inputs and portal elements) or BooleanWritables (for outputs).
Once the Mercury’s portal points and output points are added to the NiagaraAX station, any number of configurations are possible. For example, you could:
- Use the portal points to control an output device in the ACS, such as a siren.
- Use the virtual points to communicate the status of the BAS proxy point to the ACS for monitoring by the security guard.
In a NiagaraAX station, a portal is a container (folder) for the status of each door. Status values include IsLatched, IsOpen, IsTampered, etc.
How virtual points work
Virtual points are points that are added to the Mercury panel that do not correspond to a physical switch or relay. Two virtual points associated with each device proxy point in the station are used to exchange Boolean (alarm status and acknowledgment) with the Mercury panel.
A physical device, such as a boiler, uses a single proxy point to report its status to a Niagara station. To pass this alarm information on to a Mercury panel, and to receive an acknowledgement back from the panel, two virtual Boolean points must be set up in each Mercury panel and discovered by the station.
- The Mercury Panel gains awareness of what is happening in the Niagara side using a virtual output proxy point. This point communicates alarm status from the device (boiler, HVAC system, etc.) in the Niagara system to the Mercury ACS.
- Likewise, the panel acknowledges an alarm using a virtual input proxy point, which is sent as a Boolean status from the Mercury ACS to the NiagaraAX station.
The configuration process involves connecting the single proxy point that reports status from the source device in the NiagaraAX station to the virtual points that communicate with the Mercury panel.
When defining the Name or Description properties for the virtual points in the station, you should use the term “virtual” to indicate clearly which points are being used solely for communication between the BAS and ACS.
About Niagara alarms to Mercury Panels
Providing an alarming function is not part of the PSIA protocol. The alarming portion of the driver has been added to allow third-party vendors to see and acknowledge alarms.
The mercury palette provides specialized alarm extensions, by data type, which you can add to any control or proxy point in the station (or any component that accepts regular alarm extensions). The purpose is to export an offnormal state (alarm) to a Mercury Panel, as defined by the Alarm Point Ord or Ack Point Ord property of the extension.
The Alarm Point Ord must reference a BooleanWritable (output) Mercury proxy point in a Mercury device, and the Ack Point Ord must be another Mercury proxy point in the same Mercury device—typically also a BooleanWritable (output) type, but possibly a BooleanPoint (input) type. This pair of points makes a loop.
When an offnormal state occurs in the component with the Mercury alarm extension, the Mercury Panel receives the alarm via the proxy point mechanism. Using the normal access control interface (Open Options) to the Mercury Panel, a user can then acknowledge the alarm, which is passed back to the alarming subsystem of the Niagara station.
Configuration of the Mercury alarm extensions is identical to standard alarm extensions, with the addition of two properties to reference Mercury proxy points. One referenced point is for sending the alarm to a Mercury panel, while the other referenced point is for receiving an acknowledgment from the Mercury panel.