The Cumulocity API documentation explains the alarm de-duplication behaviour as follows:
If an ACTIVE or ACKNOWLEDGED alarm with the same source and type exists, no new alarm is created. Instead, the existing alarm is updated by incrementing thecount
property; thetime
property is also updated. Any other changes are ignored, and the alarm history is not updated [emphasis added]. Alarms with status CLEARED are not de-duplicated. The first occurrence of the alarm is recorded in thefirstOccurrenceTime
property.
This behaviour causes confusion with our users, as they expect a new, ACTIVE alarm, to be raised even if they have already acknowledged a previous alarm of the same type. If the alarm is de-duplicated, two things should happen when it is raised:
Transition the alarm state model from ACKNOWLEDGED to ACTIVE
Create an audit record to show that the alarm has been raised again, so that this appears in the audit logs and alarm history.
Dear Martin, thanks a lot for the feedback.
For us it would be important to understand where the users are getting confused in order to improve the behaviour. Sharing screenshots might be helpful for us to better understand where the confusion arises. Alternatively, we could also have a short call.
In general, an Acknowledged alarm should be still treated as an active alarm. The main difference is that it has been acknowledged as someone is working on resolving the alarm. If a user believes that an Alarm is resolved and wants to get notified when it happens again, he should set the alarm status to cleared.
The main challenge with changing the behaviour as propsed by you is that there are many devices who repeatedly (e.g. every 5 min) send all active alarms to the platform. With the proposed behaviour there would be little value in acknowledging such an alarm.