Protocol - examples
Twin communication pattern
The typical communication pattern when interacting with the Bosch IoT
Things service using the Ditto protocol is composed of multiple
Therefore, each part has a
correlation-id header which can be used to
-  A command is sent to the Bosch IoT Things service which is then processed.
-  The response given to the issuer of the command would be either a success response or an error response.\ Any response contains a “status” and an “error” field which identify the error that occurred.
-  In addition an event is triggered.\ The event describes that the change was applied to the thing.\ Interested parties can subscribe for such events and follow the evolving thing.
A schematic view for the communication flow:
Events caused by commands from a connection are not published to the same origin. The connection can receive a response, but will not additionally get an event.
Examples at Eclipse ditto
Find the Eclipse Ditto examples online https://www.eclipse.org/ditto/protocol-examples.html
They are structured as follows:
All protocol examples are prepared for the
In case you need to communicate to the device simply replace it with
Devices can report their changed values via merge or modify commands.
- merge: The new value provided in JSON merge patch (RFC-7396) format will be merged with the existing thing.
In case the path does not match to the existing thing, the sub-structures will be added.
Notice that the
nullvalue in the JSON body will delete the specified JSON key from the thing. For further documentation of JSON merge patch see RFC 7396.
- modify: The new value provided in JSON will update the existing thing. In case the path does not match to the existing thing, you will get an error.
In case your application needs to react on changes of a thing, please note that since introducing merge commands additionally to modify, your application should be able to react on “events/merged” and “events/modified” likewise.