Bridging Device Protocols to ARM mbed Device Server with wot.io

Dec 2015/ Posted By: wotio team

In a <a href="/using-wot-io-protocol-adapters">previous post</a> we demonstrated how the <a href="http://wot.io">wot.io</a> operating environment can be used to translate between a number of different message protocols.
Today, we will build on that with a concrete example demonstrating how the protocol bridging capabilities and device management integrations of wot.io can actually be used to extend the capabilities of device management platforms to encompass those other protocols!
In particular, we'll show how to take devices that only speak <a href="http://mqtt.org/">MQTT</a>, manage them with <a href="https://www.mbed.com/en/development/cloud/mbed-device-server/">ARM mbed Device Server</a>, which does not speak MQTT, all while maintaining the ability to route notification data to and from the usual full complement of data services on the wot.io data service exchange™. Just for grins, we'll even subscribe to the notification data over a <a href="https://tools.ietf.org/html/rfc6455">WebSocket</a> connection to show that the protocol conversions can be performed on the "inlet" or the "outlet" side of the data flows.
<h2 id="iotm2minteroperabilitymiddlewarefortheenterprise">IoT/M2M Interoperability Middleware for the Enterprise</h2>
While the problem statement above may not sound all that interesting at first blush, consider that:
<ul>
<li>the devices are speaking MQTT</li>
<li>potentially, to a separate message broker</li>
<li>MQTT is a stateful, connection-based protocol that runs over TCP/IP</li>
<li>ARM mbed Device Server expects devices to speak <a href="http://coap.technology/">CoAP</a>*</li>
<li>CoAP is a stateful, connectionless protocol that runs over UDP by default</li>
<li>WebSocket is a stateful, connection-based protocol that runs over TCP/IP</li>
<li>that gets upgraded from the stateless HTTP protocol that runs over TCP/IP</li>
</ul>
and it should start to become apparent pretty quickly how impressive a feat this actually is. (* the newest version of ARM mbed Device Server appears to also support HTTP bindings in addition to CoAP, but it's still a protocol impedance mismatch either way)
Because the real world is made up of multiple device types from multiple vendors. Making sense of that in an interoperable way is the problem facing enterprises and the Industrial IoT. It is also what separates real IoT/M2M solutions from mere toys.
<blockquote>
the real world is made up of multiple device types from multiple vendors. Making sense of that in an interoperable way is the problem facing enterprises and the Industrial IoT. It is also what separates real IoT/M2M solutions from mere toys.
</blockquote>
In fact, it would be extremely uncommon for enterprises not to have devices tied to multiple device management platforms. Managing them all separately in their individual silos and performing separate integrations from each of those device management platforms to data services representing analytics or business logic would be an absolute nightmare.
Let's see how wot.io's composable operating environment makes it possible to solve complex, enterprise-grade interoperability problems.
<h2 id="buildingautomationandinstrumentationwithbbsmartworxdevices">Building Automation and Instrumentation with B+B SmartWorx Devices</h2>
Recently, one of our partners were showing off how they had outfitted their office with a bunch of IoT devices. And of course (as always happens any time you get more than one engineer together), it wasn't long before we had their devices connected up to the wot.io operating environment so they could analyze with their IoT data to make it actionable.
The actual devices they were using were a collection of <a href="http://bb-smartworx.com/product-technology/iot-and-network-edge-platforms/wzzard/">Wzzard Wireless Sensor</a> nodes connected to <a href="http://bb-smartworx.com/product-technology/cellular-routers-and-gateways/spectre/">Spectre Industrial Routers</a> acting as gateway devices. These devices from wot.io partners <a href="http://bb-smartworx.com/">B+B SmartWorx</a> not only comprise a rock-solid, industrial-grade IoT platform, but they also speak MQTT—a common IoT/M2M device level communication protocol. As such, they were perfect candidates for our protocol interoperability demonstration.
<h2 id="overview">Overview</h2>
The following diagram represents a high-level overview of our interoperability demonstration:
<img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/mqtt-mds-demo.png" alt="" />
<ul>
<li>device <code>[1]</code> is located outside our partner's engineering area, and has a thermocouple, voltmeter, and x,y,z-axis motion sensor</li>
<li>device <code>[2]</code> is located in our partner's server room, and has a thermocouple, voltmeter, and two analog inputs corresponding to ambient temperature and relative humidity</li>
<li>device <code>[3]</code> is located in our partner's front conference room and has a thermocouple, voltmeter, and two digital inputs corresponding to motion sensors</li>
</ul>
For demonstration purposes, we have only modeled a few of the many devices and sensors that are installed on our partners' premises. All three of these physical devices communicate with a local MQTT broker <code>[4]</code> to which our MQTT adapter <code>[5]</code> is subscribed. An example message looks something like
<pre><code>TOPIC: BB/0013430F251A/data,
PAYLOAD: {"s":6,"t":"2015-11-30T15:18:33Z","q":192,"c":7,"do2":false,"tempint":48.2}
</code></pre>
In addition, we have simulated a fourth device, <code>[6]</code>, just to demonstrate how the wot.io operating environment can also act as an MQTT broker <code>[7]</code> in order to support scenarios where a separate broker does not already exist.
Irrespective of the originating device, sensor data from these devices is routed through a series of adapters that ultimately:
<ul>
<li>model the data as logical resources on the wot.io message bus,</li>
<li>register "virtual devices" in ARM mbed Device Server <code>[14]</code> to represent the original devices</li>
<li>close the loop by subscribing to notifications for the new "virtual devices"</li>
<li>route data to wot.io data services like <a href="http://bip.io">bip.io</a></li>
</ul>
<h2 id="modelingdevicedata">Modeling Device Data</h2>
One of the more powerful capabilities of the wot.io operating environment is its ability to model device data streams as one or more <a href="https://en.wikipedia.org/wiki/Loose_coupling">loosely-coupled</a> logical layers of connected data resources. These data resources form a <a href="https://en.wikipedia.org/wiki/Directed_graph">directed graph</a> of nodes and edges representing the sources/destinations as connected device data streams, and the processes (or data services) that operate upon them. One data resource is transformed by a data resource into another resource which can, in turn, serve as the input for one or more other data services.
<img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/simple-2.png" alt="" />
A result of this architecture is that one can target any data resource as the source of any data service.
For our present demonstration, this means, for example, that we can represent the physical devices <code>[1-4]</code> as "virtual devices" in a device management platform of our choosing—ARM mbed Device Server in this case—whether or not it even supports devices of that make and manufacturer.
In fact, at a high level we will perform the following mappings between different representations of the device topology:
<ul>
<li>physical device data represented as MQTT topics of the form <code>BB/<deviceId>/data</code> are mapped to</li>
<li>logical wot.io data resources of the form <code>/bb/<deviceId></code> which are further mapped to</li>
<li>logical wot.io data resources of the form <code>/bb-data/<deviceId>.<sensorType>.<virtualDeviceId></code> which are registered and managed as</li>
<li>ARM mbed Device Server endpoints and resources of the form <code><deviceId>, <sensorType></code> which are then subscribed to and made available again to wot.io data services as</li>
<li>wot.io data resources of the form <code>/bb-stream/<deviceId>.<sensorType></code></li>
</ul>
Now that's some serious interoperability. Let's zoom in even a little closer, still.
<h2 id="managingvirtualdeviceswitharmmbeddeviceserver">Managing Virtual Devices with ARM mbed Device Server</h2>
Recall that earlier we described significant impedance mismatch between the protocols involved in this interoperability exercise. Let's examine the other adapters involved and see how they can be cleverly combined to resolve our impedance issues and allow us to manage virtual devices in ARM mbed Device Server.
Picking up where we left off earlier in reference to our architecture diagram,
<ul>
<li>adapters <code>[9]</code>, <code>[10]</code>, and <code>[11]</code> compose and send messages requesting the creation of new logical wot.io data resources. The adapter <code>[9]</code> maintains or references a mapping of virtual CoAP endpoints (more on these later) provisioned for each device. Specifically, an example message sent to the HTTP request adapter <code>[10]</code> might look like this</li>
</ul>
<pre><code class="language-prettyprint lang-javascript">[
"request",
"POST",
"http://demos.wot.io/demos/bb-data/tempint.virtual7/tempint.virtual7.#",
"",
{ "Authorization": "Bearer <token>" }
]
</code></pre>
<ul>
<li>the same messages emitted from <code>[8]</code> that are used to create new resource bindings are also routed to a simple controller <code>[9]</code> that composes a message for the CoAP adapter <code>[13]</code> to send to ARM mbed Device Server <code>[14]</code>. This CoAP message registers a virtual device and supplies a custom UDP context endpoint <code>[15]</code> as the location of said virtual device. (Notice that in actuality, our virtual CoAP device is actually spread across several different adapters in the wot.io operating environment!) An example CoAP pseudo-message (since CoAP is a binary protocol, I'll save you the raw <code>tcpdump</code> output) is basically</li>
</ul>
<pre><code>POST: /rd?ep=0013430F251A&et=BBSmartWorx%20Sensor&con=coap://172.17.42.1:40010&d=domain
BODY: </tempint>;obs
</code></pre>
In order to maintain the registration, <code>[13]</code> will also send CoAP registration update messages as required by ARM mbed Device Server once the initial registration has occurred.
With just these few adapters, we have successfully used CoAP to registered virtual devices to represent our real MQTT-based devices in ARM mbed Device Server. You can see they now appear in the endpoint directory of mbed Device Server's administration interface:
<img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/Screen-Shot-2015-11-30-at-3-08-29-PM.png" alt="" />
<h2 id="subscribingtovirtualdevicenotifications">Subscribing to Virtual Device Notifications</h2>
Now that our devices have been virtualized in our device management platform of choice, we can treat it as any other fully integrated wot.io data service. That is, we could choose to subscribe to notifications for one or more of the device resources and route them to one or more data services.
<ul>
<li>first, we would need to subscribe to mbed Device Server notifications by sending a message to the mbed Device Server adapter <code>[17]</code>. For our example, we just used a <code>curl</code> call <code>[16]</code> to the HTTP adapter <code>[11]</code> for simplicity.</li>
<li>the mbed Device Server adapter <code>[17]</code> will subscribe to the indicated endpoint and resource</li>
<li>in response, ARM mbed Device Server <code>[14]</code> will send a CoAP <code>GET</code> message to its registered endpoint (which you will recall is one of the CoAP adapters <code>[15]</code> that were provisioned by <code>[9]</code> and registered by <code>[12]</code>). These CoAP messages between mbed Device Server <code>[14]</code> and the CoAP adapter <code>[15]</code> look something like this (again resorting to pseudo-code to convey the binary message details):</li>
</ul>
<pre><code>GET /tempint
OBSERVE=0, TOKEN: <token>
</code></pre>
NB: <code>observe=0</code> means observable is true! Also, notice that the device identifier is missing and only the resource name is specified. This is because back in <code>[9]</code>, we mapped the stateful, UDP-based endpoint for a specific physical device to a specific virtual CoAP adapter <code>[15]</code>--the one that is receiving this <code>GET</code> request.
The response sent back to ARM mbed Device Server <code>[14]</code> from the CoAP adapter <code>[15]</code> would look something like this:
<pre><code>CODE: 2.05
TOKEN: <token>, OBSERVE=<observationSequence>
BODY: 42.1
</code></pre>
<ul>
<li>next, ARM mbed Device Server sends these notifications to its registered callback: namely, the HTTP adapter <code>[11]</code></li>
<li>after we route the messages through one more simple transformation <code>[18]</code> to return the deviceId and sensorId metadata to the logical wot.io resource path,</li>
<li>we can consume the device notifications through the WebSocket adapter <code>[19]</code> using and/or route it on to other data services like <a href="http://bip.io">bip.io</a> <code>[22]</code> for further transformation or analysis.</li>
</ul>
<h2 id="routingtowotiodataservices">Routing to wot.io Data Services</h2>
Now that our notification data is once again represented as a wot.io data resource, we can route it to any of the services in the wot.io data service exchange™.
For example, if we create a "bip" in the web API workflow automation tool, <a href="http://bip.io">bip.io</a> we can pick off specific attributes and send them to any of a number of other 3rd party service integrations. For example, see the steps below to append rows to a Google Sheet spreadsheet where still more analysis and data interaction can occur. For example, column D in our spreadsheet contains a custom base64 decoding function written in JavaScript.
<img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/Screen-Shot-2015-12-01-at-2-26-27-PM.png" alt="" /><img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/Screen-Shot-2015-12-01-at-2-27-04-PM.png" alt="" /><img src="http://idfiles.leveelabs.com/55bd0288af0b0930ba599bd0c4b7ca38/resources/img_new/labs_wot_io/Screen-Shot-2015-12-01-at-2-25-56-PM.png" alt="" />
<h2 id="conclusion">Conclusion</h2>
Today, we have demonstrated an extremely powerful capability afforded by the wot.io operating environment whereby we can combine a several protocol and data service adapters to extend device management services from IoT platforms like ARM mbed Device Server to devices that speak unsupported protocols like MQTT.
In a future post, we will build on this concept and show how we can turn any wot.io data resource into a "virtual device" managed by a device management platform—even ones that don't originate from devices at all!
It is through powerful capabilities like these that <a href="http://wot.io">wot.io</a> can truly claim to offer real-world IoT/M2M interoperability middleware for the enterprise.!

Bridging Device Protocols to ARM mbed Device Server with wot.io

Related Content