News and noteworthy

Since Dec 2018, deletion of a namespace includes the full deletion of all entities within this namespace, such as things, policies, topology schemas and topologies. Deleting the entities will erase them from our data store without an option to restore.

In order to avoid that some authorized subject could delete all data just by trying out our interactive HTTP API documentation, the Solutions resource does not offer any longer the operations:

  • PUT /solutions/{solutionId}/namespaces
    Creates or Updates the namespaces of a Solution
  • DELETE/solutions/{solutionId}/namespaces
    Delete all namespaces of a specific Solution

However, in case you need to delete a namespace, please use the UI. The deletion of a namespace will require a second confirmation by the user. Then, it triggers the full deletion of all entities within this namespace. The progress bar displays an estimation on how long the procedure might need.

 

Bosch IoT Things is prepared to support the command-and-control pattern of Bosch IoT Hub. This allows business applications to invoke operations on the devices connected via the Hub service.

A message sent via our HTTP Messages resource can be forwarded as a command to a specific Hub address, which you can configure at the connections. The result (from the device, via Hub) is matched to the request via correlation IDs.

As message buffering is not provided. Your message can only be delivered successfully, if the Hub connection is open and a consumer is ready to receive the command at the respective point in time (e.g. within a still open HTTP adapter request timeframe).

Hub-specific configurations (e.g. special reply-to headers, subject headers, source addresses) are prepared by selecting “Bosch IoT Hub” as the connection type in the “new connection wizard”. See Manage your connections.

 

Our new interactive HTTP API description comes with a new look and feel.

Compared to Swagger version 2, the main difference at the user interface is, that “Try it out” does not submit the request any longer, but only enables the entry fields. Enter at least all “required” parameters and submit the request by clicking “Execute”.

Find details provided by the Swagger team at their online presence:
https://swagger.io/blog/news/whats-new-in-openapi-3-0/

Find our API description at https://apidocs.bosch-iot-suite.com.


 

The HTTP Relations endpoint will be deprecated.
However, in case you still need to preserve some relation information, here are some alternatives:

  • For a simple parent-child-relation - you can use a parent property whithin the child thing instead.
  • For a source-target relation - use the things HTTP endpoint and store the information directy whithin a thing entity.
    The content could be for example the same as the things service has internally used in previouse versions:
      {
        "thingId": "my.namespace:relation-example-01",
        "attributes": {},
        "features": {
          "relation": {
            "properties": {
              "source": "my.namespace:ID-of-the-source-Thing",
              "target": "my.namespace:ID-of-the-target-Thing"
            }
          }
        }
      }
  • For more complex relationships use Topologies - BETA.
 

Bosch IoT Things supports a new option to connect your Things service instance to external MQTT brokers. Using these connections, you can integrate with existing brokers or set-up new MQTT servers/services and configure them for incoming as well as outgoing communication.

Such connections can be used “south-bound”, i.e. for communication with IoT devices, as well as “north-bound” for the communication towards end users and their business applications (web apps, mobile apps, etc.).

You can use this functionality to connect to the MQTT endpoint of AWS IoT in order to use Amazon’s web services for its device connectivity functionality and combine it with Bosch IoT Things' functionality to manage your digital twins. You can also use it to connect to other standard MQTT servers/services like Mosquitto, HiveMQ, CloudMQTT, Solace or others implementing MQTT 3.1.1.

Find an overview on all channels we support at Which API to use?
Our solution management UI was enhanced respectively.

Sometimes it is convenient and more fault-tolerant to create, modify or delete Things or elements of Things only if these elements either already exist or not exist or are on a specific revision state prior to the execution of the request. Therefore, we introduced support for “conditional requests” based on RFC-7232.

Using conditional requests, you can define a condition - or a list of conditions - and pass these via headers to the Things service. Our system checks the conditions and only processes the request in case they match.

The supported conditional headers are:

  • If-Match
    Read or write the resource only
    • if the current entity tag matches at least one of the entity tags provided in this header
    • or if the header is * and the entity exists
  • If-None-Match
    Read or write the resource only
    • if the current entity tag does not match any of the entity tags provided in this header
    • or if the header is * and the entity does not exist

Find examples on using such headers at
How to work with conditional requests?

Sometimes your application might prefer to only be notified upon a specific kind of changes.
For such a scenario, you can apply filtering and help to reduce traffic load.

The logic on how to express your filtering criteria is very similar with the syntax for filtering at our search endpoint.

  • Namespace selection
    • allows to specify one or several namespaces you are interested in
    • is applied server side on events and messages
  • RQL filter
    • allows to specify sophisticated expressions using relational and logical operators
    • is applied server side on events

Find details regarding the filtering at Event filter.

The new client supports the concepts of

  • Conditional requests - via new put methods,
    and
  • Event and message filtering - via new options.

Find details regarding the client at Things-client 3.2.

New placeholders allow more fine-grained per-device access control. Subjects for incoming messages (sources) can now be configured separately to subjects for outgoing messages (targets).

Find details about placeholders, which can be used for authorization subjects for sources, and placeholders, which can be used for targets.

The new client supports managing feature “definitions” via the Java API, which was previously only available via the HTTP API.

Find details at Things-client 3.1

We are happy to present you a new user interface, which allows to configure permanent connections of your Things service instance with external systems.

These connections allow the messaging-based integration of other services or applications for the purpose of device integration or interaction of business applications with the Things service.

You can configure connections with the Bosch IoT Hub as well as generic endpoints using AMQP 1.0 or AMQP 0.9.1 (e.g. RabbitMQ).

Things UI to manage your connections

The connection management also supports to apply payload mappings/transformations for incoming and outgoing messages.

Using JavaScript code you can define transformations from and to arbitrary binary or text representations of message payloads without the need for you to setup/provide a separate runtime environment.

Find details at Manage your connections.

In case you are using a free or starter service instance and need to manage your namespace, you might be affected of our latest change. Find details at Manage your namespace.

The Bosch IoT Suite portal offers the possibility to subscribe a free service instance of various services of the Suite family.
Starting May 21, setting the namespace is not any longer enforced while booking the Bosch IoT Things free plan, but you can do it at a later point in time.
Find details at How to book the service?

We are happy to announce a new step towards harmonizing the look and feel of our user interfaces to those of the Bosch world. Customers who have subscribed to our service via Bosch IoT Suite portal will find out the differences once they click the dashboard link of the Things service instance.

Bosch IoT Things

Additionally to the previous support for WebSocket and AMQP 1.0 messages, Bosch IoT Things now supports communicating with AMQP 0.9.1 brokers.

All credits go to the new connectivity microservice powered by Eclipse Ditto. It is designed to also support connecting via other protocols in the future.

The AMQP protocol binding is only usable after activation for your solution. This activation can be requested by contacting us: info-things@bosch-si.com.
The UI to activate such channels and manage your connections in self-service is on top of our agenda. Stay tuned!

In case a service subscription for a Free plan exceeds the agreed data volume, further PUT and POST requests are hindered.
However, DELETE requests are still handled, as such actions might help to reduce the data volume and overcome the situation.

Find details on alternative options at FAQ > How to avoid limited data volume?

 

The Bosch IoT Suite portal offers the possibility to subscribe a Free service instance of various services of the Suite family.
Starting February 20th the Bosch IoT Things free plan is also bookable there.
Find details at How to book the service?

As announced in January, setting a namespace is now mandatory for creating new thing entities.
In order to support you to easily find things of a specific namespace, we have introduced a new search parameter. Setting the namespaces parameter allows to specify one or multiple namespaces where to apply your search criteria.
Find details at Search > namespaces.

Here an excerpt of the refined concept:

A Definition can optionally be related to a thing's feature.
It holds a list of fully qualified identifiers:

  • The pattern for a valid identifier is namespace:name:version ,
    while the namespace does not necessarily need to be the thing's namespace but can be any namespace (Java package namespace).
  • The list must not be empty, but can contain one to multiple identifiers.
 

Please note however, that at the moment we can store but not apply such definitions.
Find an example at https://www.eclipse.org/ditto/basic-feature.html.

All sub-resources provide now the optional timeout parameter. (In previous version this was available for claiming messages only). The value defines the time (in seconds) how long to block the HTTP request and wait for a response:

  • Default value (if omitted): 60 seconds.
  • Maximum value: 600 seconds.
  • Minimum value: 0 seconds (i.e. fire-and-forget)

As a result, the Messages resources now support the request-response pattern as well as fire-and-forget semantics.

 

The new things-client provides more and more functionality offered by Things HTTP API 2 as a Java client.
Find a simple overview of all our API featues at Which API to use?

All details regarding the Java client can be found at Bosch IoT Things Java API.
The examples at GitHub and our tutorial will be adapted as soon as possible.

At this occasion the previous Java integration client (artifacts cr-integration-client, cr-integration-api, cr-modeland cr-json) are deprecated. The migration steps are detailed at Bosch IoT Things Java API > Things-client 3.0.

Our Things protocol based on the new Eclipse Ditto code base provides a new communication channel: live.

While previous versions focused on the twin channel - in order to actually create, read, update and delete thing entities as a digital twin representation of your device - the new live channel provides you the possibility to talk to your devices directly, bypassing the digital twin.

Twin

Live

The new client-to-client communication pattern, the live channel, is fully supported by the new things-client.

In order to separate Things from different Solution spaces from each other, each Thing is required to be created in a specific Namespace (see Namespace concept).
Our latest HTTP API change will enforce this requirement.

The rules in a nutshell:

  • A default namespace can be defined per solution account, see Manage your solution.
    The Things service makes sure that the namespace is not already reserved by another solution.
  • A POST thing request without namespace will use the “default” namespace as prefix and generate a unique thing ID within this namespace.
  • A PUT request for a new thing will require a namespace as a prefix of the thing ID. The Things service will verify that the namespace was reserved for your solution.
  • A PUT request for a new thing will fail if the namespace of the thing is reserved by another solution.

The change will affect all new solution bookings.
In case you have registered things (or other entities) with a namespace not explicitly listed at your solution management area, we encourage you strongly to reserve it now.

Ditto - Eclipse project

Our digital twins gain ground at the Eclipse IoT incubator.
As the main contributors, we now work intensively on integrating the Eclipse Ditto sources back in our service.
Bosch IoT Things will soon be powered by Ditto.

The Bosch IoT Things service will use Ditto dependencies under Eclipse Public License - v 2.0.

Find the project website at https://www.eclipse.org/ditto/.