When a signal is received into stages™, Signal Processing applies an Event Code. The event code determines whether the signal is an alarm, the Priority of the event, the Action Plan to be taken and how the event is reported. Signal Processing looks for event codes first on the Device Configuration (Zoning) and then the Signal Code Default Event Code. If no event code is found, stages™ will apply the Event Code ‘!001 – Undefined Signal Code’.
Event Codes can trigger an Auto Process to send an outbound notification.
Event Code Setup
Event Code setup is accessed by (Setup > Alarm Processing Setup > Event Code).
For ease of access to the large number of event codes, the Event Codes Window features an search on the left side. Event Codes can be searched by any combination of the code, the description, and the service type. All event codes will be returned (within the max rows) when the search fields are left blank. Selecting a row from the results populates the Detail, Report Code, and Action Plan panes.
Event Code Setup requires other Setup tables to be configured, including Priority, Service Type, Abort Group, and Report Code.
Event Code Detail
The Event Code label is used to identify the Event Code in setup windows such as the Device Configuration and Signal Code setup and cannot be edited. The Description is how the Event Code will display in the Alarm Buffer and Site History.
The Priority of the event code determines which Dispatch Queue the event code will be entered into and the order that the alarm is displayed on the Alarm Buffer and set via Auto Feed to an Operator.
The event code Service Type and the site type can be setup to default to an Action Plan. For example, a service type of Burg and on a Residential site can default to a Standard Residential Burg action plan. Entering in a specific action plan for the event code below will bypass the default. The lookup opens the list in (Setup > Alarm Processing Setup > Service Type).
Delay Seconds is how long before an alarm is fed to an operator via auto feed or the alarm buffer. If there is another signal that cancels the alarm in the delay period, the alarm will be suppressed. The event will still be entered into Site History, but no alarm condition will be initiated.
An event code with the Alarm flag checked will be sent to a dispatch queue. It can then be accessed through the alarm buffer or auto fed to an operator. Events without the alarm flag checked will be log only.
An event code with the Verify Schedule flag checked will verify the event against the site schedule. If an open or close comes outside the normal schedule, it can trigger another event. This is set up in the schedule detail within the site in the early/late open/close event fields. If an alarm is desired for an open/close outside the normal schedule, setup an event code with alarm checked in these fields.
An event code with the Verify User flag checked will verify that the user who entered the open or close signal into the panel has the authority to do so. If the user is unauthorized to do so, it will generate an alarm.
Events can be flagged to act as a Timer Test. Events that are flagged will trigger the timer test for a device set up with a timer test type of Specific Signal.
Events can be assigned to an Abort Group with one or more event in the group assigned as an Abort. For instance, a sensor restore signal can abort a tripped sensor signal. This typically occurs for alarms with a delay. If the restore is received during the delay, the signal will not go to an alarm.
Events can be flagged to Ignore Tests and generate an alarm even when the device in placed On Test.
Events with Ignore Status Change enabled do not cause the Status Change window to appear when they are received.
Events marked with Alarm During Delay (and not marked as alarms) will not normally be an alarm event, but will when another alarm has been delayed.
Events marked with 'Signal Code Description' will use the description of the signal code instead of the event code description. This can be used for generic Restore event codes so that the signal code information is not lost.
Events for failed timer tests can use the Related Event Code and Escalate Interval Count to log a different event code when multiple timer tests have failed in a row. For example, a 'FTT-3' can relate to an 'FFT' with an interval of '3' so that a third failed test can be handled differently than the first failed test.
Events can be assigned an Alarm Category to include the event in the Alarm Bar and customize the Status Change message.
Events can be assigned an Alarm Confirmation to enable double knock or escalation.
A Stages™ Option 'Disallow Abort if Operator Accessed', under the Dispatch tab, can be set to make an accessed alarm unabortable. This will apply to both the Standard and Abort During Delay options and prevent the fail to abort event from being logged when the account has been accessed by an operator.
Event Code Report Code
In the report code pane, the Event Code can be assigned to Report Codes. Some reports can be filtered to only show certain report codes. Report Codes can be used as a trigger for an Auto Process. Report codes can also be used to suppress stages™ from displaying the event code in specific areas.
Event Code Action Plan
If an event code is an alarm, it can be applied as an Action Plan by Site Type or Dispatch Type. A Hierarchy is followed when applying action plans. When an operator accesses the Alarm Dispatch window for the site in alarm, the Dispatch Action Wizard will automatically display the action plan for structured dispatch.
Implementation
A signal coming into stages™ is applied an event code in the Signal Codes window. The Signal Codes window is accessible at (Utilities > Processing > Signal Formats) by double clicking on a format row. If no event code is applied, the signal will generate a default stages™ event code based on the signal status.
Event Rules
Event Code values can be overridden by Event Rules.