Notifications 2.0

Overview

The Notifications 2.0 API allows applications or microservices to receive and process notifications generated by the use of the Cumulocity IoT REST or MQTT APIs (device management, measurements, alarms, events and other platform APIs) in a reliable manner.

Notifications 2.0 improves upon the Real-time notification API by providing stronger delivery semantics and ordering guarantees. It is also intended to be simpler to use than the “Bayeaux” protocol used in the Real-time notification API. New capabilities are added to Notifications 2.0 in each release of Cumulocity IoT. However, it does not yet support all of the notifications available from the Real-time notification API so it is not yet a complete replacement for the older API. See the rest of this section and the detailed API documentation for full details of the notifications supported by this release of the Notifications 2.0 API.

Topics and subscriptions

Internally, Notifications 2.0 uses a publish-subscribe pattern, allowing use-cases to organize their desired selections of measurement, event, alarm, operation and/or inventory messages into topics according to functional interest. Creating a Notification 2.0 subscription in Cumulocity IoT creates a publisher (internally), that forwards Cumulocity IoT messages that it matches (based on message qualities such as its source, type or even content, for example) to a specific topic. Each subscription can only forward messages to one topic, but multiple subscriptions can forward messages to the same topic.

The diagram ‘Notification 2.0 topics and subscriptions’ below shows three subscriptions that have been created in Cumulocity IoT and are forwarding notification messages into two topics in the Messaging Service.

The ‘temperature’ topic is receiving measurements from the leftmost and centrally depicted subscriptions. Both of these have a “mo” (managed object) context and they both include messages from the measurement API only. A subscription with a managed object context can only forward messages from a specific managed object (such as a device). The leftmost subscription is forwarding measurements from a device with source ID ‘12345’ and the centrally depicted subscription does the same but from device ‘67890’.

The ‘alarms’ topic is receiving alarms from the rightmost subscription. It has a tenant context and includes messages from the alarm API. It forwards all alarms within the tenant that creates the subscription, regardless of how they are generated (you can create finer grained topics by using filters). The forwarded alarms include those raised by Cumulocity IoT itself, and those published via REST or MQTT from other components in, or attached to, the platform, including any alarms raised by the depicted devices.

Consumers and tokens

A topic’s notification messages can be received by WebSocket based consumers that present a valid authorizing token for that specific topic when connecting to the Notification 2.0 WebSocket endpoint. This token is in the form of a string conforming to the JWT (JSON Web Token) standard. Tokens can be obtained from the Cumulocity IoT token REST API by authenticated users.

Consumers receive the topic messages reliably, with at-least-once semantics, in order and must acknowledge each message in turn. Notification order is preserved from the point of view of any given device sending in REST and MQTT API requests. The protocol is text-based and described in detail in the Consumer protocol section. In typical usage, multiple consumers of a given topic operate independently in parallel, each receiving and acknowledging separate copies of those messages.

The diagram below shows three consumers that have been created in the Messaging Service by four consumer clients.

The rightmost client identifies its consumer as “alarmmonitor” and that consumer receives messages from the “alarms” subscription topic.

The second to right client identifies its consumer as “tempaudit” and that consumer receives messages from the “temperature” subscription topic.

The leftmost two consumer clients are two shares of a (logically single) shared consumer, and so share the same copy of topic messages. They both identify the same “tempmonitor” consumer; each receives a non-overlapping subset of the messages in the “temperature” topic. Collectively, they receive all of the messages in the topic.

Consumer lifecycle

When a subscription is created, Cumulocity IoT starts to create and forward notifications within the subscription’s scope to the Messaging Service subsystem. The Message Service does not necessarily retain these messages; it only retains a subscription topic’s messages if the topic is persistent, and it has at least one consumer for the topic that is or has been connected.

Persistent subscription topic messages are only stored once in the Messaging Service, but all associated consumers' backlogs, whether the consumer is connected or not, reference each message until they have received and acknowledged it. Therefore, all consumer backlogs should be considered to have a storage cost from when they first connect until they explicitly express no further interest in the topic by unsubscribing. The Messaging Service discards a given message only when there are no backlogs that reference it anymore.

The following diagram shows the lifecycle of a consumer backlog in relation to its associated client connection(s). The backlog is created when the consumer first connects to the Messaging Service and is only destroyed when it is explicitly unsubscribed. The consumer’s backlog is maintained, even if its client connection is interrupted. This is needed for reliable messaging, allowing the consumer to not miss messages during connection outages, but comes at the cost of explicit lifecycle management.

To unsubscribe its consumer, pass its token as the token parameter to the /notification2/unsubscribe REST endpoint.

Creating subscriptions

The JSON fields sent in a create subscription request determine which Cumulocity IoT messages are forwarded to a topic, and the forwarded message content. This request must be made by an authenticated Cumulocity IoT user with the ROLE_NOTIFICATION_2_ADMIN role.

The context field broadly determines the type of Cumulocity IoT message a subscription might match and forward. There are two valid context values: “mo” (managed object) and “tenant”. Some subscription fields have constraints that vary according to the value of the context field. Where this is the case, it is pointed out in that field’s documentation in the create subscription documentation.

The source field can only be used if the context is “mo”. It must have a nested id field containing the value of a managed object’s global identifier (sometimes referred to as a “device ID” or “source ID”). This is used to target inclusion of messages from the given managed object.

subscription is the first of two fields that identify which topic this subscription will forward messages to. Multiple subscriptions contribute to a single topic if they have the same values for both the subscription and nonPersistent fields.

The nonPersistent field determines if the topic is persistent or non-persistent. Subscriptions with the same subscription field value, but different nonPersistent values forward to two different topics. It is, therefore, the second of the two fields that identifies the subscription topic.

The filter field can provide a subscription filter, allowing more finely grained selection of the included messages, based on the message type and API (is it a measurement or alarm, for example).

The fragmentsToCopy field allows the forwarded messages to be transformed so that they contain only a specific subset of the fragments present in the original Cumulocity IoT messages they are generated from. This can be useful, for example, for security, bandwidth saving or functionality scoping reasons.

The following summarizes the subscription fields.

Notifications for new managed objects creations can never be forwarded by subscriptions with an “mo” context as the managed object is only given an ID when it is created and that ID is needed as a field to create the subscription. Therefore, to receive notifications informing of new managed object creations, create a subscription with “tenant” context to listen for them. An application can use this to discover new managed objects. It can then choose to create subscriptions with “mo” context for those managed objects.

Notifications for managed object deletions are forwarded to topics by subscriptions with “mo” (managed object) context that include the “managedobjects” API, and by subscriptions with “tenant” context that include the “managedobjects” API.

Subscriptions with “tenant” context can also use the alarms API and/or the events API to forward all alarms and/or events, respectively, which occur within the tenant, applying filters as desired.

Subscription filters

Subscription filters provide fine-grained selection of the Cumulocity IoT messages a subscription will forward. Filters can be provided as the subscriptionFilter field in a subscription’s JSON object at creation time. It is a JSON object with apis and typeFilter fields.
Filters specified by subscriptions with “tenant” context must provide a typeFilter value. Filters specified by those with “mo” context can provide either or both filter fields.

The apis field is a JSON array that specifies which Cumulocity IoT API messages to include. Use an array containing just the wildcard value, “*”, to include messages from all APIs. To include messages from a subset of the APIs, use an array containing any single or multiple selection from “alarms”, “alarmsWithChildren”, “events”, “eventsWithChildren”, “measurements”, “managedobjects” and “operations”.

For example, to include messages from all APIs:

{
  "context": "mo",
  "subscription": "subscription01",
  "source": {
    "id": 2468
  },
  "filter": {
    "apis": ["*"]
  }
}

To include only messages from the measurements and alarms APIs:

{
  "context": "mo",
  "subscription": "subscription02",
  "source": {
    "id": 2468
  },
  "filter": {
    "apis": ["measurements", "alarms"]
  }
}

The “alarmsWithChildren” and “eventsWithChildren” apis values allow subscriptions with managed object context to filter in, respectively, alarms or events for all recursively descendant child managed objects of the source.id managed object in addition to those from the source.id managed object itself.

The typeFilter string field is matched against the original message’s type field. It can be a single value, or a limited (supporting only or) OData expression.

For example, to include messages with type “temperature” and messages with type “pressure”:

{
  "context": "mo",
  "subscription": "subscription03",
  "source": {
    "id": 2468
  },
  "filter": {
    "type": "'temperature' or 'pressure'"
  }
}

To include messages of type “temperature” only:

{
  "context": "mo",
  "subscription": "subscription04",
  "source": {
    "id": 2468
  },
  "filter": {
    "type": "'temperature'"
  }
}

Persistent and non-persistent subscriptions

A subscription can be persistent or non-persistent, implying that the Messaging Service topic for it is either persistent or non-persistent, respectively. These have different qualities which can be useful to satisfy the varying needs of differing use-cases.

Persistent subscriptions are the default. They are used for reliable messaging, ensuring that consumers never miss a message if their connection is interrupted. They use replicated secondary storage to maintain backlogs (within the constraints of any configured storage limits) and to maintain the consumers' positions in their topics. When a consumer of a persistent subscription topic has their connection interrupted, whether that is due to network issues or deliberate actions by the consumer, upon reconnection they will continue to receive notifications from the topic position they were at before the outage (specifically, from the message after the last one they acknowledged successfully before the outage).

Non-persistent subscriptions are only buffered in memory. A client consumer’s position is not persisted across interruptions of the client connection. When a consumer of a non-persistent subscription has their connection interrupted, upon reconnection they will start receiving notifications from the most recent message of the subscription, missing all other notifications that occurred during the connection outage. This is the case for all such temporarily disconnected consumers, even if other consumers of the same non-persistent subscription are still receiving older messages that occurred while it was not connected.

Deleting subscriptions

Deleting a subscription prevents it from adding further notification messages to its associated topic. Many subscriptions can contribute notifications to a given topic so this does not control the topic lifecycle. Deleting all the subscriptions associated with a topic ensures no more notifications are added to it. This does not delete the topic either.

Even though the topic no longer accumulates new messages, there may still be consumers draining the last of the messages from it. When all messages are consumed by all consumers, the topic is empty and consumes negligible space in the Messaging Service.

Subscriptions can be deleted by sending a delete subscription request, using the subscription’s id as the URL filename. For example, to delete the subscription with ID 8765:

 DELETE /notification2/subscriptions/8765 HTTP/1.1
 Host: <HOST>
 Authentication: Basic: <AUTHENTICATION>

When a tenant is deleted from Cumulocity IoT, all its subscriptions are deleted. However, topics and consumers may still be active in the Messaging Service until all messages are consumed.

Creating Tokens

The JSON fields sent in a create token request determine which subscription topic a consumer can receive messages from, the token’s duration, the shared nature of the consumer, and an identifier for the consumer. This request must be made by an authenticated Cumulocity IoT user with the ROLE_NOTIFICATION_2_ADMIN role.

The subscription field aligns with the same field in the subscription object, so broadly specifies the subscription topic the consumer will receive notifications from. The nonPersistent field is also a factor in identifying the topic.

The nonPersistent field aligns with the same field in the subscription object so identifies whether the subscription topic is persistent or non-persistent and therefore is a factor in identifying the topic only. There is no such thing as a peristent or non-peristent consumer and tokens cannot affect the nature they experience of topics using this field.

The subscriber field provides a unique (within the scope of this topic) identity for the consumer, allowing it to be recognized across connection interruptions, so allowing message delivery to be resumed after such interruptions and thus be reliable.

The shared field determines if multiple clients can connect in parallel as the consumer identified in the subscriber field, acting collectively to share the notification message processing load.

The expiresInMinutes field is the period that this token remains valid for, defaulting to 1440 minutes (1 day).

The following summarizes the token fields.

Token expiration

The period a token remains valid for (its lifetime) is determined at creation time by the optional expiresInMinutes field, which defaults to 1440 minutes (one day). This can be used to limit exposure to potential security issues related to them being leaked to parties that are not authorized to access the system. Consequently, tokens may need to be re-created or refreshed periodically.

Tokens can be refreshed by calling the token create request with the same parameters as originally (a different expiresInMinutes value can be given if a different duration is desired). The token string is a JWT (JSON Web Token) token so if the parameters used are not easily kept available, they can be extracted from the token string as outlined in the Java code below:

// The token string's sections are delimited by dots
String[] tokenParts = token.split("\\.");
// Base64 decode the second section
byte[] decoded = Base64.getDecoder().decode(tokenParts[1]);
// Create a string from the decoded bytes to get a JSON string of the token fields
String tokenJson = new String(decoded);
// ... optionally create an Object from the string or bytes using a JSON  parser

If you are using the Cumulocity IoT Java SDK TokenApi class, it has a public refresh method which does the above for you, internally on the client side.

Shared consumer tokens

Shared consumer tokens allow parallelization of the consumer client workload. This is useful if the notifications would otherwise arrive at a higher rate than a single consuming client application can process them. It has no impact on the rate of notification throughput within, and thus their egress from, Cumulocity IoT core.

When you create a token, you can add the optional Boolean body parameter shared to the request. If it is set to true, the created token is shared. If it is not present or false, the token is exclusive (not shared).

If a consumer’s token is not shared, the consumer is an exclusive consumer. Only one consumer client can connect using an exclusive token. An attempt to connect further consumers with the same exclusive token results in an error. An exclusive consumer receives a copy of all notifications from the subscription topic its token is for.

If a consumer’s token is shared, the consumer is a shared consumer. Additional consumer clients can connect using the same token. If only one shared consumer client is connected, it receives a copy of all notifications from the subscription topic. As additional consumer clients connect using the same token, the consumer notification load is rebalanced so that each consumer client receives a non-overlapping subset (share) of the notifications from the subscription topic. The set of consumer clients sharing a token can be thought of as a single logical consumer. Collectively, the set receives all notifications for the subscription topic.

The notification load is spread across the shared consumer clients according to the id of the source that generated the notification, typically a device id. All notifications for a given id are delivered to the same consumer. Each consumer may receive notifications for many different ids. This means that there is no benefit using shared tokens unless the notifications feeding the subscription topic are coming from multiple sources. Note that the load spreading algorithm may result in an asymmetric balance of notification load across the shares when there are few source ids in the subscription topic. The load should generally become more evenly distributed as the number of sources increases.

To keep the messages from a given set of source ids ‘sticky’ to a specific consumer client in the share in the face of connection interruptions, the consumer clients can provide an optional consumer parameter in their connection URL string, in addition to their usual token parameter.

For example: two consumers identifying themselves as instance1 and instance2 connect using URL paths notification2/consumer?token=xyz&consumer=instance1 and notification2/consumer?token=xyz&consumer=instance2.

Subscriptions are always unaware of the nature and number of their consumers: any number of shared and exclusive tokens can be created for the same subscription topic and they all operate independently, each receiving their own copy of the notifications. This means you can have multiple shared tokens for the same subscription topic and their load is only divided within the scope of each shared token.

Building consuming applications and microservices

A consumer client requires only a valid URL and JWT string to connect. It can be implemented using any WebSocket library or programming language as the protocol is text-based and relatively simple. The implementation can be a microservice running internally to, or an application running externally from, Cumulocity IoT.

Java developers do not need to code to the protocol specification directly. The API and the protocol have been implemented in the Cumulocity Clients Java API . Examples using that can be found in the cumulocity-examples repository.

Consumer protocol

The Cumulocity IoT Notifications 2.0 API uses a secure WebSocket to consume notifications generated by the Cumulocity IoT API.

The new endpoint is accessible using the external Cumulocity IoT fully qualified domain name of your Cumulocity IoT environment and the standard SSL port 443 using a secure WebSocket connection. It is also available on the unsecured port 80 and to microservices using “cumulocity:8111” but in most cases a secure connection is preferred.

The URI scheme therefore is “wss” and consumers use URLs starting with “wss://” followed by the fully qualified domain name of the Cumulocity IoT environment or tenant, followed by a fixed URL path and a query string.

The fixed URL path is /notification2/consumer/ and there are only two query string arguments:

• token (required). Its value must be a valid token in the form of a JWT token string as returned by a create token request to the Tokens methods of the Notifications 2.0 API. Including the token as a query string parameter avoids having to set an HTTP header which can be an issue for some WebSocket clients or proxies.

• consumer (optional). Its value is a non blank unique name for the consumer.

In summary, the URLs used by consumers follow the following patterns:

wss://your.cumulocity.environment.fullqualifieddomainname/notification2/consumer/?token=yourJwtTokenRequestedFromNotification2TokenService

or

wss://your.cumulocity.environment.fullqualifieddomainname/notification2/consumer/?token=yourJwtTokenRequestedFromNotification2TokenService&consumer=aUniqueNameForThisConsumer

WebSocket timeouts

There is a timeout of 5 minutes set on idle WebSocket connections after which the connection will be closed by the server side. Therefore the consumer must be prepared to handle closed connections which is required for fault tolerant operation in any case. All consuming microservices or applications should handle the WebSocket being closed and re-connect as necessary.

Notification acknowledgements

The WebSocket established with such an URL is a textual bi-directional connection using UTF-8 encoding. The WebSocket service sends a sequence of notifications to the consumer and the consumer should send back a short acknowledgement over this connection for each notification received. This acknowledgement is for a particular notification and the server will periodically resend a notification until it is acknowledged. This will cease once the server has received and processed an acknowledgement for a particular notification.

Notification message header and content

A notification (transmitted service to client) consists of a header and a body (similar to an HTTP request). The header is one or more (in practice at least 3) lines of text, separated by a \n (newline) character. The end of the header is demarcated by a double new line \n\n.

The notification body follows the header. This also consists of UTF text - for example a JSON document. If the notification is binary data or includes binary data then it will be Base64 encoded.

The header lines for a notification are as follows (separated by \n newlines):

• Required message identifier for message acknowledgement. This opaque value is an encoded binary 64 bit value. It must be returned as part of the acknowledgement for the notification as described below.

• The notification description on the second header line. This is a string describing what type of notification this is and its source. Measurements (“measurements”), events (“events”) and alarms (“alarms”) are examples of notifications, as are inventory creates, updates and deletes (“managedObjects”). There is a direct correspondence with realtime notifications which features similar notification descriptions. These are not enumerated here and are expected to increase in number in the future. For REST API notifications, they follow a 3 part format, separated by “/”. More details on notification descriptions is given below.

• An action string is the third header. Examples are CREATE, UPDATE and DELETE. More actions may be added in the future. Together with the notification type they describe the logical event that generated the notification, such as a CREATE of an alarm or measurement.

Depending on the second header there may be further headers to follow but currently notifications only use the above three. In order to be future proof and forward compatible, we encourage consumer code to cope with more headers by parsing them out but ignoring them.

See the hello-world-notification-microservice example in the cumulocity-examples repository on how to do this.

After the headers, the notification body follows as UTF-8 text. Typically a JSON document is carried in this text.

Notification description header

The second header line is the notification description string in the form of a /-separated path. For API notifications descriptions have three parts: tenantId, type and sourceId.

• tenantId - this the identifier for the tenant under which the notification was generated.

• type - the platform type of notification generated. For example, event, measurement, alarm or managed object.

• sourceId - the identifier of the “source” object that generated or is the subject of the notification. Source is a very loose term here, much as in “event sourcing” but generally indicates which managed object the notification is about.

Some examples are provided in Traces and backwards compatibility to real-time notifications is provided for.

Also see the rest of the documentation, examples and experiment to get values for events that you are interested in.

Processing notification acknowledgements

The first header line in each notification consists of an opaque, encoded binary identifier that must be returned as is in a reply to the Notification 2.0 service in a message acknowledgement.

See the hello-world-notification-microservice example in the cumulocity-examples repository on how to do this. It involves sending the identifier back to the service in a self-contained WebSocket text message, that means, send back the first header without the trailing \n to the server.

Dealing with notification duplication

Until a notification is acknowledged, the WebSocket service will attempt to re-deliver it. It is therefore desirable that a notification is acknowledged as soon as possible (to help avoid duplicates). However, this should not be done until the notification has been successfully processed to make use of the at-least-once semantics that the Notification 2.0 service provides.

Simply process the message and only return the acknowledgement identifier when that processing completes successfully. If processing is longer than a minute or so, the service will resend the notification so the WebSocket client application must be prepared to deal with duplicates. Duplicates can also occur due to underlying network failures, consumer crashes or perceived failures (slow transmissions) and subsequent failure masking re-transmission attempts.

A duplicate can be delivered out of order if several notifications are unacknowledged but only after follow-on notifications so should be easy to deal with.

For example, in the logical sequence 1,2,3,4, the notification number 2 can be duplicated after 3 or even 4 as in 1,2,3,2,4 or even several times, as in 1,2,3,4,2,3,2.

The notifications don’t contain any unique identifier or timestamps to aid in de-duplication. Some events are easy to de-duplicate, such as inventory events where a unique source object is first CREATED and then DELETED. But inventory UPDATES or logically sequenced events such as alarms and measurements require application-specific sequencing.

This can be achieved by including unique identifiers, sequence numbers or timestamps in the notification JSON (body) as required. An alternative is to look up the current value in the Cumulocity IoT database, treating the notification as a signal only and ignoring the value carried.

As can be seen from the notification Traces, some notifications do carry timestamps. If the timestamps are not generated by the device client, then they may only be loosely synchronized between notifications and therefore should be used carefully or not at all for de-duplication.

Traces

The following is a sample of a trace of messages without showing the first header line which consists of the acknowledgement (encoded string that must be returned to acknowledge the notification).

------------------------
header /tenant-a170/managedobjects/111
header CREATE
notification {"additionParents":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/additionParents"},"owner":"admin","childDevices":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/childDevices"},"childAssets":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/childAssets"},"creationTime":"2021-09-03T12:28:58.692Z","lastUpdated":"2021-09-03T12:28:58.692Z","childAdditions":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/childAdditions"},"name":"a switch","assetParents":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/assetParents"},"deviceParents":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/deviceParents"},"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111","id":"111","com_cumulocity_model_BinarySwitch":{"state":"ON"}}
------------------------
header /tenant-a170/measurements/111
header CREATE
notification {"self":"http://cumulocity.default.svc.cluster.local/measurement/measurements/117","time":"2021-09-03T12:29:01.664Z","id":"117","source":{"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111","id":"111"},"type":"c8y_TenantUsageStatisticsMeasurement","resourcesUsage":{"memory":0,"cpu":0,"usedBy":[]}}
------------------------
header /tenant-a170/events/111
header CREATE
notification {"creationTime":"2021-09-03T12:29:01.932Z","source":{"name":"a switch","self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111","id":"111"},"type":"com_cumulocity_model_DoorSensorEvent","self":"http://cumulocity.default.svc.cluster.local/event/events/118","time":"2021-09-03T12:29:01.664Z","id":"118","text":"Door sensor was triggered"}
------------------------
header /tenant-a170/eventsWithChildren/111
header CREATE
notification {"creationTime":"2021-09-03T12:29:01.932Z","source":{"name":"a switch","self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111","id":"111"},"type":"com_cumulocity_model_DoorSensorEvent","self":"http://cumulocity.default.svc.cluster.local/event/events/118","time":"2021-09-03T12:29:01.664Z","id":"118","text":"Door sensor was triggered"}
------------------------
header /tenant-a170/managedobjects/111
header UPDATE
notification {"additionParents":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/additionParents"},"owner":"admin","childDevices":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/childDevices"},"childAssets":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/childAssets"},"creationTime":"2021-09-03T12:28:58.692Z","lastUpdated":"2021-09-03T12:28:58.692Z","childAdditions":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/childAdditions"},"name":"a switch","assetParents":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/assetParents"},"deviceParents":{"references":[],"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111/deviceParents"},"self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111","id":"111","c8y_ActiveAlarmsStatus":{"major":1},"com_cumulocity_model_BinarySwitch":{"state":"ON"}}
------------------------
header /tenant-a170/alarms/111
header CREATE
notification {"severity":"MAJOR","creationTime":"2021-09-03T12:29:02.092Z","count":1,"history":{"auditRecords":[],"self":"http://cumulocity.default.svc.cluster.local/audit/auditRecords"},"source":{"name":"a switch","self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111","id":"111"},"type":"com_cumulocity_events_TamperEvent","self":"http://cumulocity.default.svc.cluster.local/alarm/alarms/119","time":"2021-09-03T12:29:01.664Z","id":"119","text":"Tamper sensor triggered","status":"ACTIVE","com_mycorp_MyProp":{"key1":"value1"}}
------------------------
header /tenant-a170/alarms/111
header CREATE
notification {"severity":"MAJOR","creationTime":"2021-09-03T12:29:02.092Z","count":1,"history":{"auditRecords":[],"self":"http://cumulocity.default.svc.cluster.local/audit/auditRecords"},"source":{"name":"a switch","self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111","id":"111"},"type":"com_cumulocity_events_TamperEvent","self":"http://cumulocity.default.svc.cluster.local/alarm/alarms/119","time":"2021-09-03T12:29:01.664Z","id":"119","text":"Tamper sensor triggered","status":"ACTIVE","com_mycorp_MyProp":{"key1":"value1"}}
------------------------
header /tenant-a170/alarmsWithChildren/111
header CREATE
notification {"severity":"MAJOR","creationTime":"2021-09-03T12:29:02.092Z","count":1,"history":{"auditRecords":[],"self":"http://cumulocity.default.svc.cluster.local/audit/auditRecords"},"source":{"name":"a switch","self":"http://cumulocity.default.svc.cluster.local/inventory/managedObjects/111","id":"111"},"type":"com_cumulocity_events_TamperEvent","self":"http://cumulocity.default.svc.cluster.local/alarm/alarms/119","time":"2021-09-03T12:29:01.664Z","id":"119","text":"Tamper sensor triggered","status":"ACTIVE","com_mycorp_MyProp":{"key1":"value1"}}