3

We've encountered a baffling issue with cumulocity's Alarm types.

We've found that when we create an Alarm with an agent, either through HTTPS or MQTT, the "type" field of the very first alarm creation (for a given type) determines the severity and text fields of any subsequent calls with the same type.

For example, if the first time that an MQTT agent runs, it runs:

client.publish('s/us', '301,Critical,TextA');
await waitFor(400);
client.publish('s/us', '302,Major,TextB');
await waitFor(400);
client.publish('s/us', '303,Minor,TextC');
await waitFor(400);
client.publish('s/us', '304,Warning,TextD');

If the same lines of code are subsequently altered to read:

// Note that 301 is used for all alarms, indicating severity critical
client.publish('s/us', '301,Critical,Apple');
await waitFor(400);
client.publish('s/us', '301,Major,Banana');
await waitFor(400);
client.publish('s/us', '301,Minor,Coconut');
await waitFor(400);
client.publish('s/us', '301,Warning,Durian');

The alarms created will all have the severity AND text corresponding to their severity and text in the first set of calls, irrespective of the fact that we are now specifying severity CRITICAL and different text for each; for example a new alarm with {severity: "MAJOR", text: "TextB"} will be created.

What is stranger, this behaviour appears to work based on prefixes. If the code is altered to read:

client.publish('s/us', '301,Critical1000,Apple');
await waitFor(400);
client.publish('s/us', '301,Major1000,Banana');
await waitFor(400);
client.publish('s/us', '301,Minor1000,Coconut');
await waitFor(400);
client.publish('s/us', '301,Warning1000,Durian');

The alarms created will again retain the severity and text from the first alarm creation, e.g. a third alarm with {severity: "MAJOR", text: "TextB", type: "Major1000"} will be created.

OK, so some sort of caching based on prefixes is going on. Maybe there's a way to clear it?

However, I have yet to describe the most mystifying phenomenon. Everything I have thus far related is on a per-ManagedObject basis. The caching doesn't carry over to a new device/managed object.

However, across our entire tenancy, for any source, any alarm with {type: "Warning"}, or whose "type" begins with the prefix "Warning", will have {severity: "WARNING", text: "WOAHDUDE"}.

To recapitulate, if we try to create an Alarm with type "Warning" issuing from ANY source, a new "WOAHDUDE" shows up in our dashboard.

At some point, I created an alarm with {severity: "WARNING", type: "Warning", text: "WOAHDUDE"}. I have no idea how this established some sort of "WOAHDUDE" template across the entire tenancy, but it seems to have. How can I undo this?

PoolOfPeas
  • 383
  • 2
  • 11

1 Answers1

3

I think what you are experience is just alarm de-duplication (https://www.cumulocity.com/guides/reference/alarms/ search for de-duplication).

Whenever there is an active alarm for a device with a give type x and you create a new alarm for the same device with the same type the alarm is completely discarded and in the first alarm the counter is increased.

So if the second alarm has different severity, text or anything else this information is not updated into the existing alarm.

Regarding the issue with all alarms with prefix "Warning" in the type getting the same text. Maybe you created an alarm mapping in administration. Those mappings are tenant wide and will overwrite severity and text of alarms when created.

TyrManuZ
  • 2,039
  • 1
  • 14
  • 23
  • You are absolutely correct, there was exactly such a rule in the Alarm Mappings. I must have created it months ago to test the functionality and forgotten about it entirely. – PoolOfPeas May 03 '18 at 07:44