Escalations

• Top-Level
• Devices

1.0 Introduction

Escalations are a feature of ICON Signals that has been implemented for Monnit and "Standard Device" (a.k.a. WebRelay) devices

An escalation is a signal which is raised when a sensor has been in alarm state or missing for "too long". Three levels of escalation are supported. The initial escalation for a sensor is level 1 (ESC1), the next one is level 2 (ESC2), and all subsequent escalations are level 3 (ESC3).

For example, suppose a device named WebRelay-1 goes into alarm state.

• ICON Signals immediately raises a signal named WR-ON-%WebRelay-1%
• a matching rule in the rule list is found and executed
• people are notified about the alarming device

If WebRelay-1 is configured with an Escalation value of 10 minutes, then approximately ten minutes after remaining in alarm state:

• ICON Signals raises a signal named WR-ESC1-%WebRelay-1%

• a matching rule in the rule list is found and executed

• (possibly different) people are notified about the alarming device

Subsequent escalations can occur if WebRelay-1 remains in alarm state and parameters EscalationLimit and EscalationResend are set to non-zero values.

• The second escalation will raise a signal named WR-ESC2-%WebRelay-1%

• Additional escalations will raise a signal named WR-ESC3-%WebRelay-1%

When a device leaves alarm state, the escalation is cleared. If it later enters alarm state again, the escalation level will start at 1.

The same process applies for a device that is considered to be missing. Once the Escalation time interval for the missing device has been reached, ICON Signals raises a signal named: WR-ESC{n}-%WebRelay-1%, where n is 1, 2 or 3.

There are several ways to set up escalation rules. Some example sets of rule expressions are shown below.

WR-ESC    // matches all escalations for StdDev (WR) devices

WR-ESC1-%West  // 1st escalation for sensors named West{something}
WR-ESC2-%West  // 2nd escalation
WR-ESC3-%West  // 3rd and subsequent escalations

MON-ESC1-%Central     // 1st esc for Monnit sensors named Central{something}
MON-ESC[23]-%Central  // 2nd and subsequent escalations

The last example makes use of the fact that rule expressions are actually regular expressions and matches to signal names are governed by regular expression matching rules.

2.0 Configuration

Escalations are configured for individual devices. A separate 'Escalation Reset' parameter can be configured for device types and enables a daily reset of escalation state for devices currently in escalation mode or having completed their escalations.

2.1 Device Escalation Parameters

For supported devices, three values in the Param tab control escalations.

2.2 Escalation Reset

An advanced parameter in the 'Workflow > Sensor Types' page, esc_reset, supports a daily reset of ongoing or completed escalations for all devices of that type. This can be useful if the escalation is serving as a "nag" and the recipient is not paying attention. This can and has happened for "missing" devices where the notification doesn't seem as urgent as an actual alarm.

The parameter value is in 24-hour HH:mm format.

2.3 Monnit Gateways

One concern with Monnit is that we don't want to generate a bunch of "missing device" notifications if the actual problem is that the Monnit gateway went offline. So, a separate signal MGW-MISSING is raised for Monnit gateways that are considered to be missing. This is controlled by advanced properties in the Monnit section of 'Workflow > Sensor Types'. (See orange rectangle in previous screenshot.)

This is not the same as a device escalation, but the signal is raised repeatedly.

3.0 Status

One shortcoming of this design is that a single "clear" rule is executed when a device leaves alarm or missing state.

Imagine if one group of people is notified for an initial alarm and additional groups are notified for an escalation. Who should receive a notification when the device state is cleared?

Currently a "clear" rule is like any other rule - you explicitly indicate who is to receive the notification message. The approach we will likely take in the future is to provide some mechanism in the "clear" rule to instead send notifications to those groups what were notified during the most recent alarm.

2018-2022 ICON Voice Networks