Eclipse Ditto™

The Eclipse Ditto teams is proud to announce the availability of Eclipse Ditto 3.3.0. Version 3.3.0 contains features improving merge/PATCH commands, skipping modifications of a twin if the value would be equal after the modification and a more ... [More] production ready Ditto Helm chart. Adoption Companies are willing to show their adoption of Eclipse Ditto publicly: https://iot.eclipse.org/adopters/?#iot.ditto When you use Eclipse Ditto it would be great to support the project by putting your logo there. Changelog The main improvements and additions of Ditto 3.3.0 are: Support replacing certain json objects in a merge/PATCH command instead of merging their fields Implicitly convert a merge/PATCH command to a “Create Thing” if thing is not yet existing Provide option to skip a modification in the “twin” if the value “is equal” to the previous value Addition of the DevOps API endpoints to Ditto’s OpenAPI definition Improve DittoProtocol MessagePath to be aware of message subject Support alternative way of specifying “list” query parameters UI enhancements: Enhance Ditto-UI to dynamically configure log levels of Ditto Building and packaging the UI with esbuild The following non-functional enhancements are also included: Provide official Eclipse Ditto Helm chart via Docker Hub and move its sources to Ditto Git repository In addition, provide a lot more configuration options and hardening of the chart to make it more feasible for productive use The following notable fixes are included: Fix that redeliveries for acknowledgeable connectivity messages were issued too often Fix WoT dispatcher starvation by adding timeouts to fetch models Please have a look at the 3.3.0 release notes for a more detailed information on the release. Artifacts The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central. The Ditto JavaScript client release was published on npmjs.com: @eclipse-ditto/ditto-javascript-client-dom @eclipse-ditto/ditto-javascript-client-node The Docker images have been pushed to Docker Hub: eclipse/ditto-policies eclipse/ditto-things eclipse/ditto-things-search eclipse/ditto-gateway eclipse/ditto-connectivity The Ditto Helm chart has been published to Docker Hub: eclipse/ditto – The Eclipse Ditto team [Less]

The Eclipse Ditto teams is proud to announce the availability of Eclipse Ditto 3.2.0. Version 3.2.0 brings a new History API, Eclipse Hono connection type, case-insensitive searches and other smaller improvements, e.g. on the Ditto UI and in the JS ... [More] client. Adoption Companies are willing to show their adoption of Eclipse Ditto publicly: https://iot.eclipse.org/adopters/?#iot.ditto When you use Eclipse Ditto it would be great to support the project by putting your logo there. Changelog The main improvements and additions of Ditto 3.2.0 are: New History API in order to be able to: access historical state of things/policies/connections (with either given revision number or timestamp) stream persisted events of things/policies via async APIs (WebSocket, Connections) and things also via existing SSE (Server-Sent-Events) API configure deletion retention of events in the database for each entity Addition of new Eclipse Hono connection type for Ditto managed connections Option to do case-insensitive searches and addition of a new RQL operator to declare case-insensitive like: ilike UI enhancements: Push notifications on the Ditto UI using SSE (Server-Sent-Events), e.g. on thing updates Autocomplete functionality for the search slot Added configuring Bearer auth type for the “devops” authentication JavaScript client: Support for “merge” / “patch” functionality in the JS client The following non-functional enhancements are also included: None in this release. The following notable fixes are included: Undo creating implicitly created policy as part of thing creation if creation of thing failed Please have a look at the 3.2.0 release notes for a more detailed information on the release. Artifacts The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central. The Ditto JavaScript client release was published on npmjs.com: @eclipse-ditto/ditto-javascript-client-dom @eclipse-ditto/ditto-javascript-client-node The Docker images have been pushed to Docker Hub: eclipse/ditto-policies eclipse/ditto-things eclipse/ditto-things-search eclipse/ditto-gateway eclipse/ditto-connectivity – The Eclipse Ditto team [Less]

The Eclipse Ditto teams is proud to announce the availability of Eclipse Ditto 3.1.0. Version 3.1.0 brings policy imports, AMQP 1.0 message annotation support, conditional message sending and other smaller improvements, e.g. regarding ... [More] shutdown/restart improvements. Adoption Companies are willing to show their adoption of Eclipse Ditto publicly: https://iot.eclipse.org/adopters/?#iot.ditto When you use Eclipse Ditto it would be great to support the project by putting your logo there. Changelog The main improvements and additions of Ditto 3.1.0 are: Conditional message processing based on a specified condition targeting the twin state Support for reading/writing AMQP 1.0 “Message annotations” in Ditto managed connections Policy imports: Reference other policies from policies, enabling reuse of policy entries Several Ditto explorer UI enhancements Support for configuring an audience for Ditto managed HTTP connections performing OAuth2.0 based authentication The following non-functional enhancements are also included: End-2-End graceful shutdown support, enabling a smoother restart of Ditto services with less user impact Support for encryption/decryption of secrets (e.g. passwords) part of the Ditto managed connections before persisting to the database IPv6 support for blocked subnet validation The following notable fixes are included: Fixing that known connections were not immediately started after connectivity service restart Please have a look at the 3.1.0 release notes for a more detailed information on the release. Artifacts The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central. The Ditto JavaScript client release was published on npmjs.com: @eclipse-ditto/ditto-javascript-client-dom @eclipse-ditto/ditto-javascript-client-node The Docker images have been pushed to Docker Hub: eclipse/ditto-policies eclipse/ditto-things eclipse/ditto-things-search eclipse/ditto-gateway eclipse/ditto-connectivity – The Eclipse Ditto team [Less]

With the upcoming release of Eclipse Ditto version 3.1.0 it will be possible to process live messages based on conditions. Conditional live messages Ditto now supports conditional message sending based on a specified condition in the request. This ... [More] functionality can be used via the HTTP API with an HTTP header or query parameter, as well as via the Ditto protocol, and the Ditto Java Client. For all three ways there is an example provided in this blog post. This turns useful, if you want for example to send a message to your device, but only if its digital twin has a specific attribute set. To be more concrete let’s say we have a thing with a feature that is measuring carbon monoxide levels, and we only want to send an alarm live message to the corresponding device, if the particle level is over 10. To achieve this the following HTTP request can be used: POST /api/2/things/org.eclipse.ditto:coffeebrewer/inbox/mesages/co-alarm?condition=gt(features/carbon-monoxide-level/properties/ppm,10) CO Level too high! Open your windows! Conditions can be specified using RQL syntax to check if a thing has a specific attribute or feature property value. In case the condition does not match to the actual state of the thing, the request will fail with HTTP status code 412 - Precondition Failed. And the message will not be processed. If the given condition is invalid, the request will fail with HTTP status code 400 - Bad Request. More documentation for this feature can be found here: Conditional Requests Permissions for conditional requests In order to execute a conditional request, the authorized subject needs to have WRITE permission at the resource that should be changed by the request. Additionally, the authorized subject needs to have READ permission at the resource used in the specified condition. Given the condition from the introduction gt(features/carbon-monoxide-level/properties/ppm,10), read access on the single attribute would be sufficient. However, the condition can also be more complex, or include other sub-structures of the thing. Then of course, the authorized subject needs READ permission on all parameters of the specified condition. Examples The following subsections will show how to use conditional requests via the HTTP API, Ditto protocol, and Ditto Java Client. To demonstrate the new conditional request, we assume that the following thing already exists: { "thingId": "org.eclipse.ditto:carbon-monoxide-alarm", "policyId": "org.eclipse.ditto:carbon-monoxide-alarm", "attributes": { "manufacturer": "ACME demo corp.", "location": "Wonderland", "serialno": "42" }, "features": { "carbon-monoxide-level": { "properties": { "ppm,": 2 } }, "alarm": { "properties": { "lastTriggered": "2021-09-23T07:01:56Z", "confirmed": false } } }, "ConnectionStatus": { "definition": [ "org.eclipse.ditto:ConnectionStatus:1.0.0" ], "properties": { "status": { "readySince": "2022-11-04T14:35:02.643Z", "readyUntil": "2022-11-04T16:35:03.643Z" } } } } Condition based on alarm/confirmed In this example a live alarm message from the device should only be sent, if the alarm confirmed property is set to false by the end user application. This is done to prevent duplicate received alarms by the customer. POST /api/2/things/org.eclipse.ditto:carbon-monoxide-alarm/inbox/mesages/co-alarm?condition=and(gt(features/carbon-monoxide-level/properties/ppm,10),eq(features/alarm/properties/confirmed,false)) Another use case could be to i.e. only send a message to a device when the device is connected: POST /api/2/things/org.eclipse.ditto:carbon-monoxide-alarm/inbox/messages/doSomething?condition=gt(features/ConnectionStatus/properties/status/readyUntil,time:now) Permissions to execute the example For this example, the authorized subject could have READ and WRITE permissions on the complete thing resource. However, it is only necessary on the path thing:/features/alarm/properties/confirmed and thing:features/carbon-monoxide-level/properties/ppm. Conditional requests via HTTP API Using the HTTP API the condition can either be specified via HTTP Header or via HTTP query parameter. In this section, we will show how to use both options. Conditional request with HTTP Header POST /api/2/things/org.eclipse.ditto:carbon-monoxide-alarm/outbox/messages/co-alarm Content-Type: application/json condition: eq(features/alarm/properties/confirmed,false) CO Level too high! Open your windows! Conditional request with HTTP query parameter POST /api/2/things/org.eclipse.ditto:carbon-monoxide-alarm/outbox/messages/co-alarm?condition=eq(features/alarm/properties/confirmed,false) Content-Type: application/json CO Level too high! Open your windows! Conditional request via Ditto protocol It is also possible to use conditional requests via the Ditto protocol. Applying the following Ditto command to the existing thing will lead to the same result as in the above HTTP example. { "topic": "org.eclipse.ditto/carbon-monoxide-alarm/things/live/messages/co-alarm", "headers": { "content-type": "application/json", "condition": "eq(features/alarm/properties/confirmed,false)" }, "path": "/outbox/messages/co-alarm", "value": "CO Level to high! Open your windows!" } Using conditional requests in the Ditto Java Client The conditional requests are also supported via the Ditto Java Client with the upcoming (Ditto Java Client version 3.1.0). Example for a conditional update of a thing with the Ditto Java client: String thingId = "org.eclipse.ditto:carbon-monoxide-alarm"; // initialize the ditto-client DittoClient dittoClient = ... ; dittoClient.live().message(Options.condition("eq(features/alarm/properties/confirmed,false)")) .from(thingId) .subject("co-alarm") .payload("CO Level to high! Open your windows!") .send(String.class, (response, throwable) -> { if (throwable != null) { LOGGER.error("Received error while sending conditional update: '{}' ", throwable.toString()); } else { LOGGER.info("Received response for conditional update: '{}'", response); } }); Feedback? Please get in touch if you have feedback or questions towards this new functionality. – The Eclipse Ditto team [Less]

The Eclipse Ditto teams is proud to announce the availability of Eclipse Ditto 3.0.0. With 3.0.0, the required amount of different service roles was reduced from 6 to only 5 as the “ditto-concierge” service’s responsibilities (performing ... [More] authorization) was moved to other services. That reduces the overall resource consumption and network traffic of a Ditto installation. The other big topic for version 3.0.0 is the new search index which does not only respond much quicker to search queries, but also brings lots of performance improvements regarding MongoDB utilization and also a huge stabilization regarding consistency of the search in Ditto. Many other new features and improvements are also part of the release, e.g. a new HTTP API for managing connections and even the first version of a Ditto UI. Adoption Companies are willing to show their adoption of Eclipse Ditto publicly: https://iot.eclipse.org/adopters/?#iot.ditto From our various feedback channels we however know of more adoption. If you are making use of Eclipse Ditto, it would be great to show this by adding your company name to that list of known adopters. In the end, that’s one main way of measuring the success of the project. Changelog The main improvements and additions of Ditto 3.0.0 are: Ability to search in JSON arrays and thus also for feature definitions Several improvements around “metadata” in Ditto managed things Creation of new HTTP API for CRUD management of Ditto managed connections Addition of Ditto explorer UI for managing things, policies and connections Support for EC signed JsonWebKeys (JWKs) W3C WoT (Web of Things) adjustments and improvements for latest 1.1 “Candidate Recommendation” from W3C Make “default namespace” for creating new entities configurable Provide custom namespace when creating things via HTTP POST Make it possible to provide multiple OIDC issuer urls for a single configured openid-connect “prefix” Addition of a “CloudEvents” mapper for mapping CE payloads in Ditto connections The following non-functional work is also included: New Ditto “thing” search index massively improving write performance; reducing the search consistency lag and improving search query performance Removal of former “ditto-concierge” service, moving its functionality to other Ditto services; reducing overall resource consumption and improving latency+throughput for API calls Creation of common way to extend Ditto via DittoExtensionPoints Rewrite of Ditto managed MQTT connections to use reactive-streams based client, supporting consumption applying backpressure Further improvements on rolling updates and other failover scenarios Consolidate and simplify DevOps command responses The following notable fixes are included: Passwords stored in the URI of connections to no longer need to be double encoded Using the Normalized connection payload mapper together with enriched extra fields lead to wrongly merged things Adding custom Java based MessageMappers to Ditto via classpath was no longer possible Please have a look at the 3.0.0 release notes for a more detailed information on the release. Artifacts The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central. The Ditto JavaScript client release was published on npmjs.com: @eclipse-ditto/ditto-javascript-client-dom @eclipse-ditto/ditto-javascript-client-node The Docker images have been pushed to Docker Hub: eclipse/ditto-policies eclipse/ditto-things eclipse/ditto-things-search eclipse/ditto-gateway eclipse/ditto-connectivity – The Eclipse Ditto team [Less]

The upcoming Eclipse Ditto version 3.0.0 will ship with a major refactoring of the MQTT connectivity module. In this post we want to highlight what’s new and why this could be interesting for you. Backpressure via throttling The most noteworthy ... [More] innovation is that Ditto now consumes incoming publish messages by using the reactive API flavour of the HiveMQ client. This, together with throttling, effectively enables backpressure for inbound MQTT publishes for protocol version 3.x and 5: connectivity.conf … throttling { enabled = true enabled = ${?MQTT_CONSUMER_THROTTLING_ENABLED} # Interval at which the consumer is throttled. Must be > 0s. interval = 1s interval = ${?MQTT_CONSUMER_THROTTLING_INTERVAL} # The maximum number of messages the consumer is allowed to receive # within the configured throttling interval e.g. 100 msgs/s. # Must be > 0. limit = 100 limit = ${?MQTT_CONSUMER_THROTTLING_LIMIT} } … This kind of throttling applies to all in-flight messages – no matter what their QoS is set to. Backpressure protects Ditto from congestion caused by a too high amount of incoming publishes. Of course the broker has to deal with backpressure as well when throttling in Ditto is enabled because the amount of unprocessed messages would pile up at the broker. Flow Control with Receive Maximum (MQTT 5) With MQTT 5 it is possible to specify a Receive Maximum when the client connects to the broker. For QoS 1 or 2 this value determines how many unacknowledged incoming messages the client accepts from the broker. Apart from throttling this is an additional approach how Ditto can be protected from excessive load – at least for MQTT 5 connections. The (client) Receive Maximum can be set for Ditto either in configuration or via environment variable: connectivity.conf … receive-maximum-client = 65535 receive-maximum-client = ${?CONNECTIVITY_MQTT_CLIENT_RECEIVE_MAXIMUM} … For more details, please have a look at HiveMQ’s MQTT 5 Essentials, Part 12 that covers just this topic. Unified implementation Under the hood, almost anything related to MQTT changed. With the previous implementation most of the logic was divided into a common base implementation and a concrete implementation for protocol version 3.1.1 and 5. Obviously this worked. However, the algorithms were scattered over multiple classes which made it difficult to understand what is going on (hello, maintainability 😉). Now, the distinction between protocol version 3.x and 5 is made on the level of data structures. Luckily the evolution of the MQTT protocol from version 3.1.1 to version 5 as well as the design of HiveMQ’s client library made this very easy. For example, instead of dealing with a Mqtt3Publish and a Mqtt5Publish in parallel all the time we introduced a GenericMqttPublish which can be converted from and to the specific types at the time when they come in contact with the client. The rest of the time Ditto can work with the generic representation. – The Eclipse Ditto team [Less]

The upcoming Eclipse Ditto version 3.0.0 will ship with a major refactoring of the MQTT connectivity module. In this post we want to highlight what’s new and why this could be interesting for you. Backpressure via throttling The most noteworthy ... [More] innovation is that Ditto now consumes incoming publish messages by using the reactive API flavour of the HiveMQ client. This, together with throttling, effectively enables backpressure for inbound MQTT publishes for protocol version 3.x and 5: connectivity.conf … throttling { enabled = true enabled = ${?MQTT_CONSUMER_THROTTLING_ENABLED} # Interval at which the consumer is throttled. Must be > 0s. interval = 1s interval = ${?MQTT_CONSUMER_THROTTLING_INTERVAL} # The maximum number of messages the consumer is allowed to receive # within the configured throttling interval e.g. 100 msgs/s. # Must be > 0. limit = 100 limit = ${?MQTT_CONSUMER_THROTTLING_LIMIT} } … This kind of throttling applies to all in-flight messages – no matter what their QoS is set to. Backpressure protects Ditto from congestion caused by a too high amount of incoming publishes. Of course the broker has to deal with backpressure as well when throttling in Ditto is enabled because the amount of unprocessed messages would pile up at the broker. Flow Control with Receive Maximum (MQTT 5) With MQTT 5 it is possible to specify a Receive Maximum when the client connects to the broker. For QoS 1 or 2 this value determines how many unacknowledged incoming messages the client accepts from the broker. Apart from throttling this is an additional approach how Ditto can be protected from excessive load – at least for MQTT 5 connections. The (client) Receive Maximum can be set for Ditto either in configuration or via environment variable: connectivity.conf … receive-maximum-client = 65535 receive-maximum-client = ${?CONNECTIVITY_MQTT_CLIENT_RECEIVE_MAXIMUM} … For more details, please have a look at HiveMQ’s MQTT 5 Essentials, Part 12 that covers just this topic. Unified implementation Under the hood, almost anything related to MQTT changed. With the previous implementation most of the logic was divided into a common base implementation and a concrete implementation for protocol version 3.1.1 and 5. Obviously this worked. However, the algorithms were scattered over multiple classes which made it difficult to understand what is going on (hello, maintainability 😉). Now, the distinction between protocol version 3.x and 5 is made on the level of data structures. Luckily the evolution of the MQTT protocol from version 3.1.1 to version 5 as well as the design of HiveMQ’s client library made this very easy. For example, instead of dealing with a Mqtt3Publish and a Mqtt5Publish in parallel all the time we introduced a GenericMqttPublish which can be converted from and to the specific types at the time when they come in contact with the client. The rest of the time Ditto can work with the generic representation. – The Eclipse Ditto team [Less]

The Eclipse Ditto teams announces availability of Eclipse Ditto 2.4.0. The main topics in this release were the move from Java 11 to Java 17 (and the switch in Ditto’s pre-built Docker containers from OpenJ9 to Hotspot runtime), W3C WoT (Web of ... [More] Things) integration and enhanced placeholder capabilities, e.g. used in JWT claim extraction and signal enrichment. Adoption Companies are willing to show their adoption of Eclipse Ditto publicly: https://iot.eclipse.org/adopters/?#iot.ditto From our various feedback channels we however know of more adoption. If you are making use of Eclipse Ditto, it would be great to show this by adding your company name to that list of known adopters. In the end, that’s one main way of measuring the success of the project. Changelog The main improvements and additions of Ditto 2.4.0 are: W3C WoT (Web of Things) integration SSE (ServerSentEvent) API for subscribing to messages Recovery status for connections indicating when e.g. recovery is no longer tried after max backoff Enhance placeholders to resolve to multiple values Advanced JWT placeholder operations Support for a wildcard/placeholder identifying the changed feature in order to enrich e.g. its definition The following notable fixes are included: Several fixes and improvements regarding consistency and performance of search updates Don’t publish messages with failed enrichments and issue failed ack Filter for incorrect element types in jsonArray of feature definitions Fix of placeholder resolvment in “commandHeaders” of “ImplicitThingCreation” mapper Fix fn:substring-after() function returning incorrect data The following non-functional work is also included: Upgrade of compiler target level for service modules from Java 11 to Java 17 Switch of used Java runtime in pre-built Docker containers from OpenJ9 to Hotspot Publication of pre-built multi-architecture Docker images for linux/amd64 (as always) and now in addition linux/arm64 Removal of rate limiting / throttling limits as default Update of several used dependencies Please have a look at the 2.4.0 release notes for a more detailed information on the release. Artifacts The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central. The Ditto JavaScript client release was published on npmjs.com: @eclipse-ditto/ditto-javascript-client-dom @eclipse-ditto/ditto-javascript-client-node The Docker images have been pushed to Docker Hub: eclipse/ditto-policies eclipse/ditto-things eclipse/ditto-things-search eclipse/ditto-gateway eclipse/ditto-connectivity eclipse/ditto-concierge – The Eclipse Ditto team [Less]

The Eclipse Ditto teams announces availability of Eclipse Ditto 2.4.0. The main topics in this release were the move from Java 11 to Java 17 (and the switch in Ditto’s pre-built Docker containers from OpenJ9 to Hotspot runtime), W3C WoT (Web of ... [More] Things) integration and enhanced placeholder capabilities, e.g. used in JWT claim extraction and signal enrichment. Adoption Companies are willing to show their adoption of Eclipse Ditto publicly: https://iot.eclipse.org/adopters/?#iot.ditto From our various feedback channels we however know of more adoption. If you are making use of Eclipse Ditto, it would be great to show this by adding your company name to that list of known adopters. In the end, that’s one main way of measuring the success of the project. Changelog The main improvements and additions of Ditto 2.4.0 are: W3C WoT (Web of Things) integration SSE (ServerSentEvent) API for subscribing to messages Recovery status for connections indicating when e.g. recovery is no longer tried after max backoff Enhance placeholders to resolve to multiple values Advanced JWT placeholder operations Support for a wildcard/placeholder identifying the changed feature in order to enrich e.g. its definition The following notable fixes are included: Several fixes and improvements regarding consistency and performance of search updates Don’t publish messages with failed enrichments and issue failed ack Filter for incorrect element types in jsonArray of feature definitions Fix of placeholder resolvment in “commandHeaders” of “ImplicitThingCreation” mapper Fix fn:substring-after() function returning incorrect data The following non-functional work is also included: Upgrade of compiler target level for service modules from Java 11 to Java 17 Switch of used Java runtime in pre-built Docker containers from OpenJ9 to Hotspot Publication of pre-built multi-architecture Docker images for linux/amd64 (as always) and now in addition linux/arm64 Removal of rate limiting / throttling limits as default Update of several used dependencies Please have a look at the 2.4.0 release notes for a more detailed information on the release. Artifacts The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central. The Ditto JavaScript client release was published on npmjs.com: @eclipse-ditto/ditto-javascript-client-dom @eclipse-ditto/ditto-javascript-client-node The Docker images have been pushed to Docker Hub: eclipse/ditto-policies eclipse/ditto-things eclipse/ditto-things-search eclipse/ditto-gateway eclipse/ditto-connectivity eclipse/ditto-concierge – The Eclipse Ditto team [Less]

The upcoming Eclipse Ditto version 2.4.0 will add support for W3C WoT (Web of Things) integration by referencing WoT Thing Model in Ditto managed twins describing the Things’ capabilities. Using this integration, Ditto managed digital twins can be ... [More] linked to WoT “Thing Models” from which Ditto can create WoT “Thing Descriptions” containing the API descriptions of the twins. By integrating WoT, Ditto takes a big step forward towards: increased interoperability introspection of twins to find out their capabilities which properties are provided and their data type and format which actions can be invoked on the devices, including their expected input/output data type and format which events the devices are able to emit, including their data type and format addition of semantic context to Ditto managed digital twins and their capabilities description of Ditto twin HTTP APIs in an open, established, well specified, “web optimized”, active IoT standard backing Ditto managed twins with WoT models, also supporting “brownfield” setups, without the need for actual devices to be aware of WoT opening the door to a new ecosystem of tools To learn more about WoT (Web of Things), please visit: Web of Things in a Nutshell WoT integration in Ditto The WoT integration in Ditto covers several aspects: referencing HTTP(s) URLs to WoT Thing Models in Thing Definitions and in Feature Definitions generation of WoT Thing Descriptions for Thing and Feature instances based on referenced Thing Models resolving potential extensions via tm:extends and imports via tm:ref resolving potential Thing level compositions via tm:submodel resolving potential TM placeholders upon creation of new Things, generation of a “JSON skeleton” following the WoT Thing Model, including referenced TM submodels as Features of the Thing For additional details about the WoT integration, please check the full WoT integration documentation. The WoT integration is still marked as “experimental” as the WoT Thing Description version 1.1 is not yet published as “W3C Recommendation” and may still change - as well as the implementation of the standard in Ditto. Note: In order to enable the experimental support for WoT in Ditto 2.4.0, please configure the environment variable DITTO_DEVOPS_FEATURE_WOT_INTEGRATION_ENABLED to true. Example For a full example of the different aspects of the WoT integration, please check the full WoT integration example. To summarize: “link” a Thing with a publicly available WoT Thing Model by specifying the URL in its Thing Definition. creation of a new Thing can use a Thing Model (e.g. the example model https://eclipse-ditto.github.io/ditto-examples/wot/models/floor-lamp-1.0.0.tm.jsonld) in order to generate a JSON skeleton: curl --location --request PUT -u ditto:ditto 'https://ditto.eclipseprojects.io/api/2/things/io.eclipseprojects.ditto:floor-lamp-0815' \ --header 'Content-Type: application/json' \ --data-raw '{ "definition": "https://eclipse-ditto.github.io/ditto-examples/wot/models/floor-lamp-1.0.0.tm.jsonld" }' which results in a Thing like this: { "thingId": "io.eclipseprojects.ditto:floor-lamp-0815", "policyId": "io.eclipseprojects.ditto:floor-lamp-0815", "definition": "https://eclipse-ditto.github.io/ditto-examples/wot/models/floor-lamp-1.0.0.tm.jsonld", "attributes": { "manufacturer": "", "serialNo": "" }, "features": { "Spot1": { "definition": [ "https://eclipse-ditto.github.io/ditto-examples/wot/models/dimmable-colored-lamp-1.0.0.tm.jsonld", "https://eclipse-ditto.github.io/ditto-examples/wot/models/colored-lamp-1.0.0.tm.jsonld", "https://eclipse-ditto.github.io/ditto-examples/wot/models/switchable-1.0.0.tm.jsonld" ], "properties": { "dimmer-level": 0.0, "color": { "r": 0, "g": 0, "b": 0 }, "on": false } }, "Spot2": { "definition": [ "https://eclipse-ditto.github.io/ditto-examples/wot/models/dimmable-colored-lamp-1.0.0.tm.jsonld", "https://eclipse-ditto.github.io/ditto-examples/wot/models/colored-lamp-1.0.0.tm.jsonld", "https://eclipse-ditto.github.io/ditto-examples/wot/models/switchable-1.0.0.tm.jsonld" ], "properties": { "dimmer-level": 0.0, "color": { "r": 0, "g": 0, "b": 0 }, "on": false } }, "Spot3": { "definition": [ "https://eclipse-ditto.github.io/ditto-examples/wot/models/dimmable-colored-lamp-1.0.0.tm.jsonld", "https://eclipse-ditto.github.io/ditto-examples/wot/models/colored-lamp-1.0.0.tm.jsonld", "https://eclipse-ditto.github.io/ditto-examples/wot/models/switchable-1.0.0.tm.jsonld" ], "properties": { "dimmer-level": 0.0, "color": { "r": 0, "g": 0, "b": 0 }, "on": false } }, "ConnectionStatus": { "definition": [ "https://eclipse-ditto.github.io/ditto-examples/wot/models/connection-status-1.0.0.tm.jsonld" ], "properties": { "readySince": "", "readyUntil": "" } }, "PowerConsumptionAwareness": { "definition": [ "https://eclipse-ditto.github.io/ditto-examples/wot/models/power-consumption-aware-1.0.0.tm.jsonld" ], "properties": { "reportPowerConsumption": {} } }, "SmokeDetection": { "definition": [ "https://eclipse-ditto.github.io/ditto-examples/wot/models/smoke-detector-1.0.0.tm.jsonld" ] }, "Status-LED": { "definition": [ "https://eclipse-ditto.github.io/ditto-examples/wot/models/colored-lamp-1.0.0.tm.jsonld", "https://eclipse-ditto.github.io/ditto-examples/wot/models/switchable-1.0.0.tm.jsonld" ], "properties": { "color": { "r": 0, "g": 0, "b": 0 }, "on": false } } } } the WoT Thing Description of Things containing a Thing Model in their "definition" may then be retrieved by invoking the existing endpoint GET /api/2/things/ with the Accept header application/td+json: curl --location --request GET -u ditto:ditto 'https://ditto.eclipseprojects.io/api/2/things/io.eclipseprojects.ditto:floor-lamp-0815' \ --header 'Accept: application/td+json' Features of Things are handled as WoT “submodels” and also can describe themselves with the same approach, e.g.: curl --location --request GET -u ditto:ditto 'https://ditto.eclipseprojects.io/api/2/things/io.eclipseprojects.ditto:floor-lamp-0815/features/Spot1' \ --header 'Accept: application/td+json' Ditto WoT Java model As part of the integration of WoT in Ditto, a Java module has been added to provide a Java API for the WoT “Thing Description”/”Thing Model” and their parts - this module can also be used separately from Ditto in order to e.g. have a builder based API for building new objects or to read a TD/TM from a string: org.eclipse.ditto ditto-wot-model ${ditto.version} Please have a look at the added ditto-wot-model module to find out more about example usage. Feedback? Please get in touch if you have feedback or questions towards this new functionality. – The Eclipse Ditto team [Less]