Connecting devices using standard APIs, or: the „Web Of Things“

As of now, probably most IoT solutions have a simple device communication strategy: Up to the cloud. This widespread pattern requires end devices to connect to some form of gateway 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, for example, a temperature display talks to a thermostat to adjust heating. 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. For 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 which 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 a myriad of devices are expected to communicate with each other. So it's no wonder that 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 working towards.

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.

Thing

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.

Thing Description

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 blind 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 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.

Bindings

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 typical 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.

Project Things

Mozilla’s Project Things is a framework of software pieces that is very similar to the constructs mentioned 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.

Conclusion

Most of the above mentioned W3C’s standard documents are up-to-date, but still in draft status. None of this finalized yet and can change, but there’s already enough material out there to start tinkering with embedded boards, gateways and cloud software. This "Open API" approach can make much sense,e specially in prototyping sessions and workshops, since it allows participants and developers to really play around not only with device firmware, but also with a network of devices. At least that's what we're trying at our ThingForward Workshops!

Andreas

This post is CC-BY-SA 4.0 Parts appeared first here

Follow ThingForward on Twitter, Facebook and Linkedin!