Telemetry

The simplest message type for sending device data to your application via Bosch IoT Hub is telemetry messages.

In this use-case the device sends messages to the Bosch IoT Hub with one of the supported protocols (for example MQTT). The Bosch IoT Hub will process the message in the specific Protocol Adapter and queue the message in its internal messaging network. The application that is connected to the messaging endpoint will then consume the message via the AMQP 1.0 protocol.

Bosch IoT Hub Telemetry Communication Pattern for Telemetry messages

Properties

Telemetry messages allow devices to send messages without guaranteed delivery. The message might be lost in flight or during internal Bosch IoT Hub message processing.

When to use telemetry?

Telemetry messages are well suited for high-throughput scenarios where reliability is not important. If your use-case can afford infrequent message loss, this might be a good choice.

A typical example for telemetry messages is a temperature sensor in a building which cyclically sends the temperature value. Due to the fact that the temperature in the room does not change that fast the loss of individual probes is completely acceptable.

Delivery Modes

  • QoS0 AT_MOST_ONCE

Provides best-effort delivery. Depending on the used device protocol the device will receive a confirmation that the representative Protocol Adapter received the message. However this does not cover the processing of the message in Bosch IoT Hub or your application. So for example if there is a partial service interruption or an extraordinary load peak, the message can get lost.

  • QoS1 AT_LEAST_ONCE

Provides delivery with end-to-end acknowledgement. Depending on the used device protocol the device will receive a confirmation that the application received the message. Using QoS1 will delay the message confirmation that is sent to the device until the message has been accepted by the application. Nevertheless this does not store or persist the message in any regard (if this is a requirement use Event messages instead). As a result the device will have to re-transmit the message in case the delivery didn’t work because of an outage or overload of the application.