Bosch IoT Device Management - will be discontinued by mid 2024

Events

Event messages provide a way to send messages from a device to your application via the device connectivity layer with guaranteed delivery.

An IoT device sends an event message to the device connectivity layer using an IoT protocol. The message will be queued to the persistent internal messaging infrastructure and an acknowledgement will be sent to the device. The application receives the message via the messaging endpoint of the device connectivity layer.

images/confluence/download/attachments/1982727065/events.png

Properties

Event messages provide a way to send messages from a device to an application with guaranteed delivery. Due to the fact that the device connectivity layer provides a message acknowledgement to the IoT device and it will queue up all messages until the application is ready to consume them, a message loss might only happen under unforeseen conditions.

There might be the case that messages queues in the device connectivity layer run full. E.g. the application might be down for maintenance or might be to slow to process all messages in time. Then the device connectivity layer will not accept any further event messages from devices. Depending on your use-case the device must take care of this situation and perform a retry or queue up events for later delivery.

Event messages are set with a time to live (TTL) that represents the storage time of the event. Events which are not consumed within the TTL will be discarded from the persistent storage.
The storage time of the persisted messages varies depending on your service plan.

When to use events?

Events are the communication pattern of choice if reliability is crucial for your business or functional requirements. Due to the involved overhead for assured delivery and reliable processing and queuing this approach has drawbacks considering latency and throughput.

A typical example for event messages is a fire alarm. This type of incident will happen only very rarely. But if it happens it’s absolutely crucial that the message is send and processed successfully.

Delivery modes

QoS1 AT_LEAST_ONCE

Provides guaranteed delivery, messages are either acknowledged or rejected. The device connectivity layer persists the event messages on highly durable storage which will even endure large-scale outages or disasters in the cloud data center. On the application side reliable protocols are used and messages will only be removed from the queues if the application has acknowledged its receipt. As the name states there might be more that one delivery of a message - the application must be capable of handling duplicate deliveries.

This does not provide confirmation of end-to-end delivery. That means that the device will see a successful post of the event even though the application has not yet received or processed the message. There might be the situation that the application is not online at this very point of time. In this case the device connectivity layer will hold all messages available until the application is operational again and starts processing the persisted messages.

Empty notification events

An empty notification can be used to indicate to your application that a device is currently ready to receive a command by setting the ttd property. The body of the empty notification messages must be without any payload.