Say WoT? Connecting devices using standard APIs, or: the „Web Of Things“
As of now, probably most of IoT solutions have a simple device communication strategy: Up to the cloud. This widespread pattern requires end devices to connect to some form of gateways, or directly to server endpoints, typically with protocols such as MQTT or sometimes CoAP. Communication between devices is primarily a thing within the smart home, where e.g. a temperature display talks to a thermostat to adjust heating. And quite a bit of this communication is proprietary, at least on the level of constrained devices.
From an „API“-ish point of view most of these solutions are directly coupled and locked-in. Sometimes they can be broken up on gateway level, making a lot of adapters and plugins necessary. But from the last 10 years of efforts in the internet industry we know that things really started to take off when vendors offered open, documented APIs, based on standards and a well-accepted technology stack.
In this area, the World-Wide-Web Consortium W3C worked out a lot of standards: HTML, XML, RDF, OWL, CSS, just to name a few. I’d like to shed more light on two of them, RDF and OWL. The Resource Description Format aims to add metadata to web resources, and thus allows to express logical relationships. OWL, the Web Ontology Language, is based on RDF and additionally allows to add formal semantic on top. As one IoT-related example imagine an end device that delivers data enriched with metadata about what it does (i.e. being a coloured light bulb), what it’s properties are (light colour, brightness), and in what protocols it can be addressed to.
Both of these standards can be of great help when designing systems where machines talk to each other. This is true for web-based systems (i.e. web hooks), and also for the Internet of Things, where myriads of devices are expected to communicate with each other. So no wonder, W3C has a working group for this area called Web Of Things. The latter link gives a good overview of the goals that the working group is aiming at.
Being a developer, what are the interesting parts of WoT, and which can already be tried out and used in software? Let’s look at some resources W3C is working on.
Terminology and Architecture
One of the first good documents to look at when getting started with WoT is the Architecture Overview. It’s a concise description of all the building blocks of a WoT architecture. The document starts with some use cases and requirements, describes the core WoT building blocks (Things, the Thing Description, Bindings to APIs and data formats, and scripting), goes on to the Architecture (how core building blocks are related to each other) and shows some deployment scenarios.
Let’s look at the core of WoT: a Thing is an abstraction of an entity (either a physical or virtual one). To be part of an IoT architecture, this Thing needs to have a network interface to interact with others. All of these entities, including interfaces need a formal representation, so that machines are able to parse these representations and start to interact with it.
How to describe what a WoT thing is? The Thing Description is a formal model for doing this. A Thing can have so called interactions: Properties, actions and events. Let’s take an automated windows sunblinds motor controller as an example.
- It could have a single property „BlindsPosition“, where 0 means „completely open“ and 100 means „completely closed“. This property can be read to know the current position of the blinds, and be set to move the blinds to a specific level, so that the motor starts moving.
- There could be actions such as „OpenFully“ and „CloseFully“, which set the level to 0 and 100.
- An event „FullyOpened“ or „FullyClosed“ can be triggered by the device to indidicate that a motor process has been finished.
There is a formal interaction model behind this, and a good visual representation (read: UML) is a available here. One of the most important things for now and for developers: Thing Descriptions are serialized as JSON-LD, which is a superset of JSON. So it’s quite easy to parse or produce these documentations, from a development point of view.
Now, how can a Thing Description come to life? Instead of abstract representations of something we need concrete implementation options. Looking at the OSI/ISO stack, two devices which want to communicate typically need
- a common physical and logical network substrate, i.e. WiFi, BLE, TCP/IP, yes, too many options for IoT :)
- some form of application-level protocols, i.e. HTTP, MQTT, ...
- the same data format(s)/media types to exchange data in (Web: JSON/XML/YAML, IoT: JSON, CBOR, EXI, ProtoBuf, ...)
WoT specifies so called Binding Templates for this. A „binding instance“ is the combination of an IoT Platform, a transfer-protocol, a media type, and security options. Instances need to be provided by more concrete binding implementations, i.e. one that understands HTTP+JSON, and connects devices to Mozilla’s Project Things, as one example.
Mozilla’s Project Things is a framework of software pieces that is very similar to the constructs from above. It includes a Gateway Software (which can run on a RaspberryPi out of the box), a collection of cloud services hosted by them, and a software framework. Mozilla takes part in the W3C Interest Group about Web of Things, and they're aiming for an easier approach to connecting devices. Their Web Thing API specification is a more direct model which is easier to implement and to adapt.
Most of the above mentioned W3C’s standard documents are up-to-date, but still in draft status. So all of this is not finalized yet and can change, but there’s already enough material out there to start tinkering with embedded boards, gateways and cloud software. Personally i believe that the next interaction level of IoT needs to work with open APIs AND the web, and the Web Of Things approach looks really interesting. That’s what inspired me to build THNG:STRUCTION, a service which lets you model a Web Thing Description and create a binding implementation for specific embedded targets, such as Arduino, the ARM mbed framework, or more modern language approaches such as MicroPython or JerryScript. Stay tuned for more updates, in the meanwhile, why not get started with your own WoT-enabled device? :-)