I am trying to understand why there is a vast difference with alarms when you apply history tracking and with history tracking enabled, it condenses the alarms down to just 4 per instance?
If it is the same alarm that is coming and going (due to rain fade in this case) there were some 67 alarms. Once history tracking was applied as a filter, the alarm count had reduced to just 16.
This has caused some confusion and misdiagnosis of faults as there were clearly more alarms to indicate there was an issue onsite.
Does anyone else experience the same kind of filtering in Cube?
I'm asking this because we still have users on System Display (Plan is to migrate them over very soon and upgrade) who have been interpreting alarms a particular way in System Display and moving over to Cube is displaying or highlighting alarms very differently which is probably why the current operators a hesitant to move over.
Hi Nathan,
History tracking is a feature which combines all the alarms records related to the same alarm together in one entry in the UI. This single entry can then be expanded to see all the underlying entries.
An alarm can start as a warning alarm, further escalate to a critical, and other actions like masking or ownership can also be executed on an alarm. This is all part of the history or life cycle of an alarm.
In the active alarms tab of the alarm console, this is activated by default. If you fetch history alarms, this feature is by default disabled so that you can see the individual records more easily. But it can be enabled or disabled easily in the hamburger menu on the upper left-hand side of the alarm console.
I believe the history tracking in System Display works in the exact same way, but maybe it is by default enabled in history tab pages, not sure about that anymore.
The transition from System Display to Cube should be very smooth as this works in the same way...
Let us know if you have any additional questions or concerns.
Thanks Ben!
Great information!