Hotlist Overview

The Innomesh Portal Hotlist uses real-time data gathered from the live environment to detect potential issues, and notify users to these issues by means of “hotlist alerts”.

 Generally, hotlist alerts have the following properties:

• Alert name and description
• Alert creation and resolution time
• Alert severity
• Information for the room against which the alert is created, if applicable
• Information for the device against which the alert is created, if applicable
• Alert trigger condition and resolution condition/s
• Alert owner and claim time

Hotlist Operation

Hotlist alerts are displayed under the Innomesh Portal “Hotlist” menu. The Hotlist is divided into several tabs: “Critical”, “High”, “Medium”, “Low”, “Resolved” and “Suppressed”. Each tab is explained in detail in the sections below.

Alert Grouping

Each Hotlist tab can be grouped by room if desired using the “Group by Room” toggle switch, which will provide a view of alerts of a given severity related to each room. By default, the “High”, “Medium”, “Low” and “Suppressed” tabs have “Group by Room” enabled.

Once alerts are set to “Group by Room”, it is possible to perform mass operations on the room’s alerts by hovering over the room’s hamburger icon.

Alert Details

To get a more detailed view of an hotlist alert, simply click on the alert.

In this “Alert Details” view, hovering over the alert detail view’s hamburger icon will bring up a list of operations that can be performed on the alert, such as claim the alert, suppress the alert, assigning the alert to a team, and force resolving the alert.

The create ticket action shown above is the result of the ServiceNow integration, where alarms can be used to create ServiceNow tickets. For more information, click here.

Alert Searching & Mass Operations

The search bar allows you to filter alerts based on any of their top level properties, such as alert category, room name, asset type, alert owner and alert description. Search results are displayed in real time as the search term is entered.

Once the search term is entered, it is possible to perform mass operations on all matching alerts, by clicking on “Options >”.

The Alert Lifecycle

Detection

An alert is first generated when an issue is detected in the environment. This occurs when the alert’s trigger condition is met.

Grace Period

To avoid false positives, some alerts have a prescribed grace period, during which it is classed as “pending”. Pending alerts are not shown on the hotlist until their grace period has expired. If the alert is automatically resolved within the grace period, they are not surfaced to the Hotlist.

Presently, the grace period is 2 minutes.

Active

Alerts that do not have a grace period, or whose grace period has lapsed, are surfaced to the Hotlist’s “Critical”, “High”, “Medium” or “Low” tabs and classed as “active”. The Innomesh Portal conducts continuous checks on active alerts to check if their resolution conditions are met.

Resolved

Once the Innomesh Portal determines that an active alert’s resolution conditions are met, the alert is reclassed as “resolved”, and moved to the Hotlist’s “Resolved” tab. Resolved alerts stay in the “Resolved” tab for a minimum of 15 minutes, after which they are permanently deleted.

It should be noted that while most alerts on the Innomesh Portal will resolve within 5 minutes of the problem actually resolving in the environment, there are some cases when alerts may take longer to resolve, or need to be manually resolved. These include:

• Alerts against rooms or devices that have been deleted. These may take up to 30 minutes to resolve, and can be manually resolved if desired – see the “Resolving Alerts” section below.
• Alerts against devices that have been substituted for another model. These need to be manually resolved.
• Alerts that have been specified here as unable to be resolved automatically by the Innomesh Portal.

Resurfaced

If an alert on the “Resolved” tab has its trigger condition met again, it is either reclassified as “active” if it has no grace period, or as “resurfaced” if it does have a grace period. Alerts reclassified as “active” are moved back to the “Critical”, “High”, “Medium” or “Low” tabs, while alerts reclassified as “resurfaced” remain on the “Resolved” tab, but are tagged as “Resurfaced”.

“Resurfaced” alerts are reclassified again as “active” once their grace period has lapsed, and moved to the “Critical”, “High”, “Medium” or “Low” tabs. The grace period is presently 2 minutes.

Suppressed Alerts

The Innomesh Portal Hotlist has a mechanism to suppress alerts, to cater for cases where the trigger condition for alerts are expected to be met and do not represent issues in the environment. Suppressed alerts are held in the “suppressed” tab within the Innomesh Portal Hotlist.

Suppressed alerts fall under 2 categories:

Permanently Suppressed Alerts

The following alerts are permanently suppressed:

• “Device not connected” alerts for XPanels. XPanels are designed to be launched and closed at any time, so a disconnected XPanel does not represent an error. Note that alerts for disconnected XPanels are permanently dropped, and do not appear in the “Suppressed” tab at all.
• Room and device alerts, where the room has been set as “In Maintenance” within Innomesh.
• Room and device alerts, where the room has been set as “Portable” within Innomesh. These are usually mobile AV systems that can be disconnected when unused.
• “Device not connected/communicating” alerts, where the device has been set as “In Maintenance” within Innomesh.
• “Device not connected/communicating” alerts, where the device has been set as “Portable” within Innomesh.
• “Device not connected/communicating” alerts, where the device has been set as “PDU Connected” within Innomesh, AND the room is currently powered off. This means that the device has its power cut off at the PDU, and would therefore not be responsive. Note that “PDU Connected” device alerts are permanently dropped, and do not appear in the “suppressed” tab.

User Defined Suppressed Alerts

Besides permanently suppressed alerts, it is also possible to suppress alerts from the Innomesh Portal, by defining “suppress rules”. Alerts can either be suppressed at the “room” level, in which case all alerts are suppressed for that room, or at a “device” level, in which case all alerts are suppressed for a single device within a room.

Suppressing Room Alerts

To suppress all alerts for a room, click on “Suppressed Alerts >”:

In the “Suppressed Alerts” prompt that appear, ensure that the “Rooms” tab is selected. Type in or select a room name, specify a date and time when the alert should be suppressed from and to, then click on “Add Room”.

Alternatively, if the room is already on the Hotlist, click on the hamburger menu for the room, select the “suppress alert” option from the hamburger menu, then select “Suppress all room alerts”.

If an alert remains on the Hotlist after the the specified “Suppressed until” date and time, the alert will be moved back to the “Critical”, “High”, “Medium” or “Low” tabs.

Suppressing Device Alerts

To suppress all alerts for a device, click on “Suppressed Alerts >”:

In the “Suppressed Alerts” prompt that appear, ensure that the “Assets” tab is selected. Type in or select a room name and an asset ID, specify a date and time when the alert should be suppressed from and to, then click on “Add Asset”.

The “asset ID” can be found under the “Alert Details” view for the alert you wish to suppress.

Alternatively, open the “Alert Details” view of the alert you wish to suppress by clicking on the alert, hover over the hamburger icon, then click “Suppress Alert”. This will prepopulate the Suppressed Alerts window. Select a date and time to suppress the alert until, then click on “Add Asset”.

When an alert is suppressed, it does not immediately move to the “Suppressed” tab, but will move at the next alert resolution check cycle, typically within 2 minutes.

Claiming & Adding Comments to Alerts

Claiming an Alert

Claiming an alert allows you to take ownership of an alert, informing other Hotlist users that the alert is being taken care of by you. 

To claim an alert, open the “Alert Details” view of the alert you wish to claim, hover over the hamburger icon, then click “Claim Alert”.

In the next window, click on “Claim”. You can also add notes to the alert here if desired.

Once claimed, your name appears against the alert. 

Only active and suppressed alerts can be claimed. Resolved alerts cannot be claimed.

Also note that unclaimed alerts appear in red, and appear at the top of the Hotlist.

Assigning an Alert

Besides claiming an alert, it is also possible to assign an alert to a group or a team within your organisation. To do this, first select “Assign Alert” from the hamburger menu on the “Alert Details” view.

Then select the group or team you wish to assign the alert to.

It is not currently possible to assign an alert directly to another user.

Adding Alert Notes

It is possible to add notes to an alert to inform others of your progress, and to provide any other updates related to the alert. Alert notes are viewable when hovering over the alert in the main Hotlist view, and can be updated after the alert is claimed.

To add a note to an alert, open the “Alert Details” view of the alert you wish to add a note to, hover over the hamburger icon, then click “Update Alert”.

Add the note under the “Notes” text box, then click “Update”.

Unclaiming an Alert

You can unclaim an alert that you have claimed, by clicking on the “Unclaim Alert” option under the alert’s hamburger menu, then clicking “Yes, Unclaim”.

When an alert is unclaimed, comments added to the alert will be retained.

Resolving Alerts

When an underlying issue causing an alert has been resolved, the alert will generally automatically move to the “Resolved” tab within 5 minutes, where it will stay for a minimum of 15 minutes before being deleted.

Alerts can also be manually resolved, by hovering over the hamburger icon in the “Alert Details” view, then clicking on “Resolve Alert”.

If the underlying issue causing the alert is not resolved, the alert trigger condition will be met again and the alert will be resurfaced. It is therefore recommended that the underlying issue causing the alert is resolved first.

Alert History

The “Hotlist Alert History” feature is now generally available. This allows users to view the event history of a specific alert, of all alerts for a specific asset, and of all alerts for all assets in a global view.

For the alert history of individual alerts, access this by selecting “Alert History” under the “Alert Details” view:

For the Global Alert History, this can be accessed by selecting the options menu adjacent to the search bar:

Diagnosis

The ability for the Innomate/UXT support team to diagnose and add notes to an alert is now generally available. The diagnosis will be visible to Innomesh Hotlist users, and will show that the Innomate/UXT team has looked into an alert, with notes to assist your on-site team to troubleshoot and resolve the alert.

Mass Resolve (Room Alerts)

The ability to mass resolve Innomesh Hotlist Alerts has been added.

Purge Alerts (Resolved Alerts)

The ability to “purge” a resolved Hotlist Alert has been added. This is useful in scenarios where users would like to start “afresh” for a room and would like to clear out all old alerts, such as when a room is being rebuilt from the ground up.

Refined “Alert Details”

The “Alert Details” view of Hotlist alerts is now constantly updated to reflect the current states of the room or asset. Previously the alert will show the states of the room or asset as they were at the creation time of the alert only. States that are now updated include:

• The current value of the room or asset property causing the alert. E.g. the current projector lamp hour value for lamp hour alerts.
• The current zone the room belongs to. This means that a room that has changed zones will now have its new zone shown correctly.
• The current IP address or hostname for the asset.
• The current maintenance state of the asset.

Resurfaced Alerts

Hotlist Alerts that have resurfaced are now permanently tagged as “resurfaced”. A resurfaced alert is one whose fault is detected to have resolved, but recurs within 60 minutes.

Alerts Threshold

The threshold value of Hotlist alerts is now shown in the Hotlist “Alerts Details” view.