Cumulocity告警类型异常：首次创建的类型锁定后续告警属性

I’ve run into this exact behavior with Cumulocity’s alarm system before, so let me break down what’s happening and how to fix it.

The Root Cause #

Cumulocity automatically creates a default AlarmType metadata entry the first time you submit an alarm of a new, undefined type. This entry locks in the severity and text values from that first alarm. Any subsequent alarms of the same type will inherit these locked values unless you explicitly override the behavior.

In your example, when you run:

client.publish('s/us', '301,Critical,TextA');

Cumulocity generates a default AlarmType for your implicit type (since you didn’t specify a custom type parameter here) with Critical severity and TextA as the default text. The second publish either tries to update the same alarm (without the required alarm ID for the 302 command) or creates a new alarm of the same locked type—so it falls back to the pre-set default values instead of using your new Major severity and TextB text.

Fixes & Workarounds #

1. Explicitly Define Alarm Types Upfront

Pre-create your alarm types via Cumulocity’s UI or API to avoid automatic locking:

• Go to Device Management > Library > Alarm Types in the Cumulocity UI.
• Create a new alarm type with a unique identifier (e.g., my-custom-alarm), and leave the severity/text fields unset or configure them to allow overrides. This lets you adjust these values per alarm later.

2. Specify Custom Type & Override Fields in MQTT Messages

When publishing alarms, include the custom type and explicitly set severity/text every time. The full MQTT create alarm command (301) supports additional parameters:

// Format: 301,<severity>,<text>,<type>,<time>
client.publish('s/us', '301,Critical,TextA,my-custom-alarm');
await waitFor(400);
client.publish('s/us', '301,Major,TextB,my-custom-alarm');

By specifying the <type> parameter, you ensure Cumulocity uses your pre-defined (or dynamically configurable) type instead of creating a locked default.

3. Update the Auto-Generated Alarm Type

If you already have a locked default type, you can modify it via the API:

• Send a PUT request to /inventory/managedObjects/<alarm-type-id> (find the ID via the UI or by querying for AlarmType objects).
• Set the c8y_IsAlarmType property’s severity and text to null to un-lock them:

{
  "c8y_IsAlarmType": {
    "severity": null,
    "text": null
  }
}

This will let you override severity and text for future alarms of that type.

4. Use Alarm Update Commands Correctly

If you’re trying to update an existing alarm (not create a new one), the 302 command requires the alarm ID as an additional parameter:

// Format: 302,<alarm-id>,<severity>,<text>
client.publish('s/us', '302,12345,Major,TextB');

Make sure you capture the alarm ID from the initial 301 response (sent on the s/ds topic) to use for updates.

内容的提问来源于stack exchange，提问作者PoolOfPeas