This offer is only addressed to commercial customers including freelancers and entrepreneurs. All prices are exclusive of value added tax (VAT).
  • Share via email
  • Subscribe to blog alert

Bosch IoT Things: automatic creation of things, consumption of messages from managed Apache Kafka connections, and enhanced policy expiration announcements

Our latest service release comes with various changes:

Automatic creation of things

Stand-alone devices and gateway devices which use proper device certificates for authentication can auto-register as things, based on a template, which can be configured at the “Device via Bosch IoT Hub” connection.

In combination with Bosch IoT Hub – the device connectivity layer of Bosch IoT Suite – the automatic creation of a thing is done automatically, when the device connects for the first time.

The feature can easily be enabled and disabled via the Bosch IoT Things UI and via HTTP API.
See Concepts > Connections > Automatically create things when a new device is registered.

Automatically create things

Examples: See Bosch IoT Device Management documentation

Consume incoming messages from managed Apache Kafka connections

For managed Apache Kafka connections, you can now configure “sources” in order to consume messages from Kafka topics.

You can use Apache Kafka for ingesting messages/events/operations into the Bosch IoT Things service as well as emitting them from the Bosch IoT Things service. Currently consuming from Kafka is only supported with at-most-once semantics (QoS 0). We are working on to also support at-least-once semantics (QoS 1).

The “Device via Bosch IoT Hub” connection is subject to change from AMQP to Apache Kafka in the future. The migration will be prepared thoroughly and will be announced separately.

Enhanced policy expiration announcements with acknowledgements

To guarantee an “at-least-once delivery” semantic for policy expiration announcements we have extended the respective APIs.

A policy entry with expiring access for a specific subject now looks like in the following example.

   "subjects": {
       "integration:<iot-things-solution-id>:<jwt-client-id>": {
           "type": "my-custom-connection",
           "expiry": "2021-08-01T12:00:00Z",
           "announcement": {
               "beforeExpiry": "1d",
               "whenDeleted": false,
               "requestedAcks": {      
                 "labels": ["my-connection-id:my-issued-acknowledgement"],
                 "timeout": "5s"}
   "resources": {
       "thing:/": {
           "grant": [
           "revoke": []

The example shows a timely limited “guest” entry of a client, which authenticated with a JWT. The subject will be automatically deleted from the policy once the expiry timestamp is reached.

tip To give the subject a chance to prolong the access he can configure a connection to get announcements. Policy announcements are published to websockets and connections that have the relevant subject ID.

The settings under announcement control when a policy announcement is published (before expiry or when deleted). If the field requestedAcks is set, then the announcements are published with at-least-once delivery until the acknowledgement requests under labels are fulfilled.
If a beforeExpiry announcement was sent without acknowledgement requests, or the a beforeExpiry announcement was acknowledged, the “whenDeleted” announcement will not be triggered, even if it was set true in the policy.

tip The previous configuration to round up the timestamp for the expiry has also been changed, to avoid massive announcements for clients with JWTs, which are about to expire at nearly the same time.

At this occasion, various minor bugs have also been fixed.