As part of the contribution from Luminem, we are developing a full implementation of the Web of Things.

We are developing it using rust giving a real-life field-test for the developer guidelines and tools we are co-developing with the Software Engineering group @ PoliTO.

Web of Things

Web of Things is a set of W3C specification that aim to address a number of shortcomings around Connected Devices pretty much in the same way the Web specifications solved the problems regarding browser interoperability.

The key concept is that a connected device (in WoT jargon Thing) should be fully controllable by having just the knowledge of its Description.

A Thing Description uses JSON-LD to provide the full information on how to interact with a generic Thing, exposing its capability through the concept of Affordances.

There are three kind of affordances:

  • Property, a directly exposed state, that can be directly read or wrote.
  • Action, a mean to give an arbitrary complex task to the Thing and then get the result of its execution.
  • Event, an informative message that a Thing may emit at will.

Every Affordance offers information on how to reach the mapped interaction point and how to format data via Forms and DataSchemas.

It looks like this:

{
    "@context": "https://www.w3.org/2022/wot/td/v1.1",
    "id": "urn:dev:ops:32473-WoTLamp-1234",
    "title": "MyLampThing",
    "securityDefinitions": {
        "basic_sc": {"scheme": "basic", "in": "header"}
    },
    "security": "basic_sc",
    "properties": {
        "status": {
            "type": "string",
            "forms": [{"href": "https://mylamp.example.com/status"}]
        }
    },
    "actions": {
        "toggle": {
            "forms": [{"href": "https://mylamp.example.com/toggle"}]
        }
    },
    "events":{
        "overheating":{
            "data": {"type": "string"},
            "forms": [{
                "href": "https://mylamp.example.com/oh",
                "subprotocol": "longpoll"
            }]
        }
    }
}

And being a JSON-LD, its @context can be used to add additional information and extend its expressivity, e.g supporting additional protocols or providing more details.

In SIFIS-Home we try to make so that every potential hazard related to the use of a Connected Device is evident to the user and the to the system controlling it.

The Thing Description can easily use our hazard ontology by adding it to the @context, and any program using it (Consumer in WoT jargon) can use or ignore the additional information as it see fit. A SIFIS-Home WoT Device can be still used by any WoT implementation.

wot-rust

We split our implementation in multiple crates, to keep the different concers separated:

  • wot-td Only focuses on building, serialising and deserialising the Thing Descriptions
  • wot-serve Simplifies the creation of the application server that exposes the Thing affordances to the world. As the first release we only support HTTP via axum.
  • wot-discovery Let you find and keep a Directory of Things available in your network.
  • wot-consume Simplifies using a Thing by abstracting away as many details as possible. It is the moral dual of wot-serve and it is a wrapper around reqwest.

During the next weeks we'll publish more blogpost about our implementation journey, our interaction with the larger WoT-wg community and how this technology is being used in SIFIS-Home.

Author

Luca Barbato is a long-time Open Source contributor, member of VideoLan, Gentoo, X.org and a few other organizations. He participates in SIFIS-Home with his company, Luminem SRL.