Hands-On IoT Solutions with Blockchain

Let's take the example of an autonomous car. With this, automakers can monitor general driver behavior and improve various aspects of the driving experience, as well as security. They can also detect failed components sooner, leading to earlier recalls and thereby improving customer satisfaction while reducing the production costs of problematic components. From the perspective of an automobile owner, this could be beneficial as they could monitor the wear and tear of the car parts and spend less money on maintenance costs.

If you are a sports practitioner, you have probably already used a smartwatch to monitor your fitness. If all of that information was properly stored and analyzed, then medical studies could obtain more data that could predict diseases and maybe even improve overall quality of life.

Furthermore, connecting health devices (such as scales, heart monitors, and blood meters) and sharing data using blockchain could create a unified medical report for each person. Doctors could improve diagnostics and medical decisions as a result. This would also enable disease profiling and prediction.

IoT played a major role in the 2016 Olympics held in Rio de Janeiro.  Many connected items were used to gather information and process which factors had an effect on athletes' bodies during matches. This was also helpful for creating new equipment, such as bikes, and new regeneration strategies for intense competition.

These simple examples of how IoT will change our entire way of life provide us with more than one reason as to why we should care about it so much. 

Devices are located at the edge of the IoT solution. In fact, these devices are what we call Things in the context of IoT. They are usually capable of sending and receiving data events.

As an example, a device with an embedded soil moisture probe can detect that the monitored soil has 43% moisture. It can then report this informative event to the platform it's connected to. The platform can then send an action event to the device, triggering a water valve to open and restore the soil moisture. This interaction depends on other aspects related to the device, which will be covered in upcoming sections. For now, let's focus on the device.

In order to handle these types of interactions, you may think of a device as a computing unit that has analog or digital (or both) processing capabilities. This means that it is able to read and write analog and digital signals to their probes and actuators.

An analog signal is a signal that can vary in a range of values. Let's take an Arduino Uno board, for example. Arduino Uno has a 10-bit resolution analog-to-digital converter (ADC), which means that it can read voltages from 0V to 5V and map them into integer values between 0 and 1,023 (2¹⁰ = 1,024). Analog signals are generally used to read data from analog sensors.

A digital signal is a binary signal, which means that it has only two possible values: 0 or 1, high or low. This kind of signal is mostly used to identify or change on and off states, for example, turning an LED bulb on or off.

Devices are also capable of handling some actions by themselves. This could either be a simple decision: for example, if the moisture level of the soil is below 50%, open the water valve for a minute and check the moisture level again after five minutes.

Alternatively, it can be a complex task: for example, determining whether an object detected by the camera of an autonomous car is a person waiting to cross the street or a tree.

Devices that have to process these kinds of analyses cannot always rely on a network or an application for information or assistance. What if one of them is out of service? This could cause an accident.

Therefore, such devices are provided with a different type of capability called edge computing, which is the capability of processing analytics at the very edge of the solution: the device itself. Basically, edge computing allows the device to perform some actions and calculations "offline," without an active connection to a network.

When selecting the device or devices that will be part of your IoT solution, the best method is to ensure that all capabilities are present in the device.

Since there is a very high number of devices in an IoT network, exceeding capabilities can lead to different problems related to cost, power supply, connection protocol, user experience or even solution complexity. 

Another important element of any IoT solution is networking. Today there are several ways to connect devices, so this is an important aspect that has to be considered when choosing your device. The most common networking standards used today are cabled networks or Wi-Fi, cellular/mobile, LPWAN, and LoRa. All of these have pros and cons, so let's take a closer look at their uses.

Wireless (Wi-Fi) or cabled network

Wi-Fi is the most common standard communication model on the internet. It assumes that the device or object being connected to is capable of connecting to an IEEE 802.x network and therefore is able to handle IP-based networks.

There are many wi-fi capable devices available in the market. Some examples of Wi-Fi modules are the ExpressIf ESP-8266 and ESP-32 modules, Texas Instruments CC3200, Microchip ATSAMW25, Intel Edison, and Galileo. This is not the complete list of devices and there are many other combinations that combine a Wi-Fi capable controller and an MCU.

Wi-Fi modules are relatively cheap and are generally good options for when it's possible or desirable to use an available network and support high-payload transfers, given their reliability and connection speed (up to 6.7 Gbps).

A Wi-Fi-based IoT solution looks pretty much like the following diagram:

Multiple devices can connect to a node, such as a router, which in turn connects to the internet and allows connected devices to access the internet. 

Cellular/mobile network

A cellular network is the same connection that any mobile phone uses. The basic idea with this kind of network is to divide a territory into a number of cells, each one with a wireless network connection served by a base station and a number of transceivers. The network provides a number of services, such as voice, text, and data.

Mobile networks are an option when a device type in a solution is not in the range of a Wi-Fi network, such as in a car. Another application that may require a mobile network device is when the solution cannot depend on the user's network, for example, if you are using a subscription for the device, and the device's activity depends on a network connection. When using the subscription network, the device will continue to do its job even if the user disables their own connection to the network.

The image below depicts the working of a standard cellular network:

We can see that a cellular antenna provides a signal to a limited region. The devices in range can then connect through a wireless network to the antenna and use the services provided by the mobile service provider, including the available internet connection.

Low-power wide-area network (LPWAN)

LPWAN is a type of wireless network designed to work in wide areas at very low bitrates, which means that the exchange in this type of network is really small.

LPWAN uses low-power, low-bitrate, and low-frequency devices that are very powerful when used to connect to things. This is because it enables the use of long-lasting batteries and smaller devices. But there are still many restrictions, such as small data payloads or a limited number of messages per day.

Having lower frequencies allows an LPWAN to be very reliable and unsusceptible to interference, even when propagating messages for very large ranges. LPWAN providers normally have a limit for the number of messages sent in the network. There are many providers of LPWANs, and the most famous of these is probably Sigfox. 

LPWANs do not have a direct connection from the device or gateway to the internet. Instead, they usually have a pre-provisioned network, where at one end of the network you will have the devices and at the other end you would have a number of web hooks and functions that allow you to connect to your application or platform:

Different from a cellular network, LPWAN networks do not provide internet connection to the devices, instead they provide means to create triggers on events received from the devices to the network. As an example, you can create an application and a trigger at the edge of the LPWAN provider network to the internet that whenever a data event is received from a device, it calls a service available at the internet with given data from the even published by the device.

LoRa or LoRaWAN

A LoRa network diagram is similar to an LPWAN network, except that instead of using service provider infrastructure, LoRa networks can have a gateway that allows devices to connect to the internet. The person responsible for a LoRa network infrastructure is the owner of the network, meaning that you do not rely on a network service provider. You create your own network:

There are a few technologies that work on the same model as LoRA, with different protocols, such as ZigBee. Phillips Hue uses the same approach to connect light bulbs, LED stripes, and other Hue devices to a gateway using ZigBee, and the gateway then connects to the Hue cloud.

After deciding the most adequate device for your IoT solution, it's important to define the protocol that will be used to communicate with devices. IoT solutions tend to use lightweight protocols, such as MQTT. This is not the only protocol that can be used in IoT, but since the IBM Watson IoT Platform relies on MQTT and REST—and REST is very popular—let's focus a little on MQTT.

MQTT

MQTT stands for Message QueuingTelemetry Transport. It is an extremely lightweight messaging protocol based on the publish and subscribe pattern. As with any message queuing model, it is an asynchronous protocol.

As shown in the following diagram, publish and subscribe (pub/sub) models rely on three actors:

The three actors are explained as follows:

• The publisher is the actor that produces any content and publishes it to a given subject (known as a topic).
• The subscriber is an event consumer. The subscriber subscribes to its subjects (topics) of interest and gets the event published every time a publisher creates a publication to one of its subscriptions.
• The Broker is responsible for receiving publications and notifying the subscribers of a topic of interest.

Now let's move on to the next important technical element.

Having an analytics or artificial intelligence software component in your IoT solution is not required, but it's really interesting to use them to process data collected from devices to extract patterns and insights that could lead to predictive maintenance, a better understanding of user behavior, and so on.

For example, let's look at some data that is captured through washing machines. Someone may have bought the appliance because it was supposed to save energy. However, after processing the data collected, it becomes clear that the appliance is consuming more energy than thought. The root cause is the lubricant as it was inadequate for its motor in non-tropical countries.

Later, let's say you compare that information with sales data and realize that 1 million washing machines were sold in Europe approximately eight months ago. The manufacturer of the washing machine can get the benefit of early shipping rates for the spare parts that must be exchanged. The manufacturer can also get a predictable amount of new lubricant for their supplier, and this could perhaps lead to a new appliance design.

In this section, we will discuss the following main features of the IBM Watson IoT Platform:

Let's begin!

Dashboard

This is the first thing that you will see when you access the IBM Watson IoT Platform. This dashboard can be a combination a number of boards and cards, offering several visualization options for your IoT solution:

Explore the boards and cards available in this screen to get familiar with the interface.

Devices, gateways, and applications

Another feature available in the platform is device management control. This feature makes it possible to create and remove devices, gateways, applications, and device types. It also makes it possible to check and trigger actions to the device, such as a firmware upgrade request or reset:

You can also create API keys so that your applications can connect to the IoT organization and interact with the other components of the solution.

The first task of the job is to create an IoT organization. If you do not have an IBM ID and IBM Cloud account, the sign-up process is very intuitive and only takes a couple of minutes. If you already have an IBM Cloud account and an IBM ID, access the IBM Cloud platform at http://bluemix.net. First, log in and create a space for the exercises in this book.

After logging in to the IBM Cloud platform and accessing the designated space, select the Create resource option to access the service catalog:

SelectInternet of Things in the menu and create a service called Internet of Things Platform. Now, select the option to Create:

When the service is created, you can select the Launch option and access the IoT Platform:

When you access the IoT Platform, notice that the address is https://xxxxxx.internetofthings.ibmcloud.com/.

Here, xxxxxx is your organization ID; make a note of it as it will be used during the entire process.

Creating an application means that you're allowing an actual application or service to connect to a specific Watson IoT Platform organization:

npm install ibmiotf --save

{
  "name": "sample-application",
  "version": "1.0.0",
  "description": "Hands-On IoT Solutions with Blockchain - Chapter 1 App",
  "main": "index.js",
  "scripts": {
    "start": "node .",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Maximiliano Santos",
  "license": "ISC",
  "dependencies": {
    "ibmiotf": "^0.2.41"
  }
}

{
  "org": "<your iot org id>",
  "id": "<any application name>",
  "auth-key": "<application authentication key>",
  "auth-token": "<application authentication token>"
}

var Client = require("ibmiotf");
var appClientConfig = require("./application.json");

var appClient = new Client.IotfApplication(appClientConfig);

appClient.connect();

appClient.on("connect", function () {
  console.log("connected");
});

$ npm start
> sample-application@1.0.0 start /sample-application
> node .
connected

Congratulations, you just created your first application connected to IBM Watson IoT Platform!

var Client = require("ibmiotf");
var appClientConfig = require("./application.json");

var appClient = new Client.IotfApplication(appClientConfig);

appClient.connect();

appClient.on("connect", function () {
  appClient.subscribeToDeviceEvents();
});

appClient.on("deviceEvent", function (deviceType, deviceId, payload, topic) {
  console.log("Device events from : " + deviceType + " : " + deviceId + " with payload : " + payload);
});

Now, whenever a device publishes an event, you will get the event printed to stdout. In the next section, we will create a device to publish the events.

In this section, you'll run through similar steps to create a fake device that connects to IBM Watson IoT Platform and publishes an event.

npm install ibmiotf --save

{
  "name": "sample-device",
  "version": "1.0.0",
  "description": "Hands-On IoT Solutions with Blockchain - Chapter 1 Device",
  "main": "index.js",
  "scripts": {
    "start": "node .",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Maximiliano Santos",
  "license": "ISC",
  "dependencies": {
    "ibmiotf": "^0.2.41"
  }
}

{
  "org": "<your iot org id>",
  "type": "DeviceSimulator",
  "id": "DeviceSimulator01",
  "auth-method" : "token",
  "auth-token" : "<device authentication token>"
}

var iotf = require("ibmiotf");
var config = require("./device.json");

var deviceClient = new iotf.IotfDevice(config);

deviceClient.log.setLevel('debug');

deviceClient.connect();

deviceClient.on('connect', function(){
  console.log("connected");
});

$ npm start
> sample-device@1.0.0 start /sample-device
> node .
[BaseClient:connect] Connecting to IoTF with host : ssl://3nr17i.messaging.internetofthings.ibmcloud.co
m:8883 and with client id : d:3nr17i:DeviceSimulator:DeviceSimulator01
[DeviceClient:connect] DeviceClient Connected
connected

var iotf = require("ibmiotf");
var config = require("./device.json");

var deviceClient = new iotf.IotfDevice(config);

deviceClient.log.setLevel('debug');

deviceClient.connect();

deviceClient.on('connect', function() {
  console.log("connected");
  setInterval(function function_name () {
    deviceClient.publish('myevt', 'json', '{"value":' + new Date() +'}', 2);
  },2000);
});

Device Event from :: DeviceSimulator : DeviceSimulator01 of event myevt with payload : {"value":Sun May 20 2018 21:55:19 GMT-0300 (-03)}
Device Event from :: DeviceSimulator : DeviceSimulator01 of event myevt with payload : {"value":Sun May 20 2018 21:55:21 GMT-0300 (-03)}
Device Event from :: DeviceSimulator : DeviceSimulator01 of event myevt with payload : {"value":Sun May 20 2018 21:55:23 GMT-0300 (-03)}
Device Event from :: DeviceSimulator : DeviceSimulator01 of event myevt with payload : {"value":Sun May 20 2018 21:55:25 GMT-0300 (-03)}

Congratulations again, your device simulator is now publishing events and your application is receiving them!