Building blocks

As we have seen in the previous section, there are many layers that constitute a typical IoT stack. In this section, we are going to explore each layer. We are going to start with the smart device layer.

Smart devices

Smart devices are the Things present on the face of the earth that can be controlled and monitored. These devices typically have a microcontroller or a microprocessor and these talk to the virtual world using a network communication module. And on the other end, the microcontroller or a microprocessor has various protocols with which it interfaces with a sensor or an actuator.

Microcontroller versus microprocessor

Before we go further, it is good to have an understanding of how a microcontroller and a microprocessor are different:

Microprocessor	Microcontroller
Only CPU; other peripherals are interfaced via the CPU bus	CPU + (Flash) Memory + RAM + ROM + I/O + Timers + UARTS + ADC + DAC and so on on a single chip
General purpose	Single purpose
High processing power	Low processing power
Power hungry	Can work on a battery
Runs an OS (for example, Linux)	Runs on a tight loop approach and can support OSs such as Real Time Operating System (RTOS)

In a typical IoT scenario, smart devices do only one job, for example reading the door sensor data and sending it to the cloud. For this kind of a solution, a microcontroller with a network module is quite sufficient.

But if we want to run an edge node as a smart device, then we need to have more processing power and that is when we turn to a microprocessor.

The following diagram explains the architecture of a smart device that is driven by a microcontroller:

The simplest example of an MCU is Arduino (https://www.arduino.cc/) and a network module example is Espressif ESP8266 (https://www.espressif.com/en/products/hardware/esp8266ex/overview).

This is the most common architecture for hardware in IoT. The three blocks that are shown are replaced as per the solution. We will look at each of the blocks in the next sections.

On the other hand, a microprocessor runs an OS, which has defined network interfaces and a communication module that come on a single board. For example, the Raspberry Pi (https://www.raspberrypi.org/products/).

In this book, we are going to use Raspberry Pi as the smart device for our examples.

Sensors

Sensors and actuators are the backbones of IoT. These are the entities that bridge the gap between the real world and the virtual world. In this section, we are going to look at sensors and in the next section, we are going to look at actuators.

Sensors are devices that can measure a particular property of nature. To simplify things, take a temperature sensor. A temperature sensor generally uses a thermistor. A thermistor is an electronic component whose resistance changes with changes in temperature.

In most thermistors, the resistance decreases as the temperature increases. These are called Negative Temperature Coefficient (NTC) thermistors.

Now, this resistance can either be converted to voltage and be read by a microcontroller or there are thermistor to digital converters available that can also do the job of feeding the temperature to a microcontroller.

The previous explanation is an example of how a temperature sensor works. Similarly, other sensors have different mechanisms using which they sense a property.

Examples of a few sensors follow:

Sensor name	Datasheet link
Temperature and humidity sensor (DHT11)	https://akizukidenshi.com/download/ds/aosong/DHT11.pdf
Door sensor or reed switch	https://standexelectronics.com/wp-content/uploads/OKI_Reed_Switch_ORD213.pdf
Passive Infrared (PIR) sensor or motion detector	https://cdn-learn.adafruit.com/downloads/pdf/pir-passive-infrared-proximity-motion-sensor.pdf

There are plenty of other sensors that you can explore yourself, right from leak detection to fire detection.

You can find a compiled list of all sensors here: https://en.wikipedia.org/wiki/List_of_sensors.

Actuators

While sensors sense the environment around them, an actuator is responsible for controlling a system by actuating (open/close or on/off). For example, a switch that can be used to turn a light on or off can be controlled via an actuator.

An actuator generally takes a signal which indicates the nature of an operation. For example, if we need to turn a switch on or off, we use a relay.

A relay is an electromagnetic switch that takes in the AC mains power supply at one end and a digital signal at other. The general state of the relay is open and that means there is no power supply flowing through from the mains to our load. Once there is a digital high or a digital low signal (depending on the type of relay), the relay moves to a closed state where the load and mains are short and the power flows through.

To get a better understanding of how a relay works and how to use it, take a look at How to use a relay, the easy way: https://www.youtube.com/watch?v=T1fNQjelojs.

A relay is one of several core actuator components, which are then reused in other actuators such as a solenoid valve.

Controllers

In the last section, we looked at what a sensor and an actuator are and how they work. In this section, we look at the controllers that are going to read data from these sensors or control the actuators.

We are going to look at three types of controller:

• Integrated controllers
• Assembled controllers
• System on Chips

The first two types are not industry-standard names. I have used this nomenclature to explain the concepts better.

Integrated controllers

Integrated controllers, also known as microprocessor-based controllers, are those pieces of hardware that have the complete landscape needed to interface with a sensor or an actuator and relay it to the outside world.

For instance, Raspberry Pi: https://www.raspberrypi.org/documentation/. One single board has all the features that we need to interface with the sensors as well as with the outside world.

Another example is a BeagleBone board: http://beagleboard.org/bone.

As you can see, these credit card-sized mini computers can be a simple solution for a remote sensor that needs to be deployed. They have all the built-in capabilities that we need for doing all the tasks. They are for sure overkill and a poor choice if these remote nodes need to run on scarce battery power.

That is where the next type of controller comes in: assembled controllers.

Assembled controllers

Assembled controllers, as you may have guessed, are where we pick and choose the various components that we need to build an efficient and a power-optimized sensor node.

As we have seen earlier, their setup would look like this:

Now, this is where things get interesting. Depending on the compute needed, the power requirements, and the functionality, we can choose a combination of the microcontroller and the network module.

Here the network module acts as a slave to the microcontroller.

Possible combinations

Some possible combinations are:

• Arduino UNO for microcontroller and Espressif ESP8266 (Wi-Fi) for the network module. You can read more about this setup here: https://medium.com/@manrick01/arduino-uno-esp8266-esp-12e-uart-wifi-wireless-shield-3a39858e5f25.
• Arduino UNO for microcontroller and Arduino Ethernet Shield for the network module. You can read more about this setup here: http://www.instructables.com/id/Arduino-Ethernet-Shield-Tutorial/.
• Arduino UNO for microcontroller and SIM900A (GSM) for the network module. You can read more about this setup here: http://www.instructables.com/id/GSM-SIM900A-With-Arduino/.
• TI MCP430 for microcontroller and TI CC3100 (Wi-Fi) for the network module. More information here: https://www.youtube.com/watch?v=sCB80DsJfig.

There can be other possible combinations as well, but these are a few to get you started. Do refer to the datasheets of these ICs to understand how they work and their capabilities and power consumption for a better design of your smart device.

System on Chips

System on Chips (SoCs) are ideal for an IoT solution, where power and processing are very critical. Since they come with their own network module, they are quite self-contained.

You can read more about SoCs here: https://internetofthingsagenda.techtarget.com/definition/system-on-a-chip-SoC.

Popular SoCs in market

Here are a few SoCs that are quite popular in the market:

• Espressif ESP8266: This module is a Wi-Fi SoC that has the full TCP/IP stack as well as microcontroller capabilities. More about this module here: https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf.
• Espressif ESP32: This module is a low-power SoC that has both Wi-Fi as well as Bluetooth capabilities and has a dual core Xtensa LX6 microprocessor. More about this module here: https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf.
• Texas Instruments CC3200: With an ARM Cortex-M4 processor and a complete Wi-Fi stack, this module is another popular choice in the IoT industry. More about this module here: http://www.ti.com/lit/ds/symlink/cc3200.pdf.

There are many other options including the likes of NXP, Qualcomm, or STMicroelectronics in this space. Do explore them.

Hardware communication protocols

Now that we have seen what a sensor, actuator, and controller are, we are going to look at how the sensor/actuator interfaces with the controller.

There are multiple protocols with which communications can happen. The most commonly used ones are:

• GPIO
• Analog/voltage reading
• UART
• SPI
• I²C

Let's get an overview of what each of these are and how they work.

GPIO

General Purpose Input Output (GPIO) is a simple communication mechanism that involves one pin between the controller and the sensor/actuator. This protocol is pretty good for sending a few bits of data.

A relay can be controlled via a GPIO pin. DHT11's temperature can be read using the digital pin.

Analog reading

Sensors sometimes expose their metrics in the form of voltage and a controller can use its internal analog to digital converter to read the data voltage and map it to the datasheet.

For example, the Texas Instruments LM35 temperature sensor works this way. Every 10 millivolts of voltage it generates while sensing, it represents 1 °C in temperature. For instance, if the voltage reading is 235mV, then the ambient temperature is 23.5V. You can read more about LM35 here: http://www.ti.com/lit/ds/symlink/lm35.pdf.

UART

The Universal Asynchronous Receiver and Transmitter (UART) is probably one of the oldest ways to talk to a chip. The transmitter of the controller will be connected to the receiver of the sensor and the receiver of the controller will be connected to the transmitter of the sensor.

This mode supports huge amounts of data being transmitted.

An example of the UART-based sensor is the fingerprint scanner. The data from the fingerprint scanner is sent to the controller over UART for further processing, after a user scans a finger. You can read more about the fingerprint scanner here: https://cdn-learn.adafruit.com/downloads/pdf/adafruit-optical-fingerprint-sensor.pdf.

SPI

The Serial Peripheral Interface (SPI) protocol allows a sensor and a controller to exchange data via two communication lines. SPI is a bus which supports multiple sensors or actuators being controlled on a single bus. The protocol uses three pins connected between the sensor and controller.

For example, the Bosch BME280 temperature humidity pressure sensor supports the SPI protocol to communicate between the controller and sensor. Read more about BME280 here: https://www.bosch-sensortec.com/bst/products/all_products/bme280.

I2C

Inter-Integrated Circuit, pronounced as I-Squared-C or I-two-C, uses a single data line and a clock to communicate between multiple sensors connected to the controller. This protocol is very good for on-board or short-range communication.

For example, the BH1750 from the ROHM semiconductor is an ambient light sensor that measures the ambient light around the sensor in Lux. This sensor exposes its data to the controller over the I²C bus. Read more about BH1750 here: http://www.mouser.com/ds/2/348/bh1750fvi-e-186247.pdf.

This protocol can be used for controller-to-controller communication as well.

This wraps up our exploration of the smart device layer.

In this book, we are going to work with Raspberry Pi 3 as our controller and the DHT11 temperature and humidity sensor as the sensor module.

Gateway and cloud communication

In the last section, we looked at the essentials of hardware or smart devices that form the backbone of the entire IoT solution. In this section, we are going to look at gateways and how the smart device communicates with the cloud over the internet.

Here are the possible ways for a controller connected to a sensor to send data to the cloud over the internet:

• Ethernet cable: https://www.lifewire.com/what-is-ethernet-3426740
• GSM/cellular: https://www.tutorialspoint.com/gsm/gsm_overview.htm
• Wi-Fi: https://www.lifewire.com/what-is-wi-fi-2377430

These three are quite common protocols that we use almost daily.

These communication protocols are more popular in an IoT stack that works using a cloud computing-based approach. If we were using a fog computing-based approach, we would use the following popular protocols to connect to the gateway and then the gateway would relay the data to the cloud using the Ethernet, GSM, or Wi-Fi:

• Bluetooth Low Energy (BLE): https://www.mikroe.com/blog/bluetooth-low-energy-part-1-introduction-ble
• Z-Wave: https://www.smarthome.com/sc-what-is-zwave-home-automation
• Zigbee: http://www.radio-electronics.com/info/wireless/zigbee/zigbee.php
• NFC: https://www.androidauthority.com/what-is-nfc-270730/
• RFID: https://www.epc-rfid.info/rfid

We will talk about this more when we discuss cloud computing and fog computing in the later part of this chapter.

Device Management Software

Device Management Software (DMS) is a very crucial piece of software that takes care of device management. Device management includes:

• Device authentication and authorization
• Device connection status
• Device data management
• Quality of Service (QoS)

Any TCP/IP-based communication that we make between the smart device and the DMS would satisfy these requirements.

In the next section, we are going to look at the various protocols available for smart devices and cloud communication.

Device to cloud communication protocols

Here are a few popular communication protocols.

Message Queuing Telemetry Transport

The Message Queue Telemetry Transport (MQTT) protocol is a battery-friendly, small footprint message broker that implements an extremely lightweight publish/subscribe protocol. MQTT is suitable when working with power- and computation-constrained devices.

MQTT for Sensor Networks

MQTT for Sensor Networks (MQTT-SN) caters for more non-TCP/IP embedded devices, where MQTT runs using a TCP/IP stack.

MQTTS and MQTT-SN are different. MQTTS is MQTT over SSL.

Constrained Application Protocol

The Constrained Application Protocol (CoAP) is a web transfer protocol for use with constrained nodes and constrained networks, which are low-power and lossy. This protocol is designed for machine-to-machine (M2M) applications, primarily focused on the IoT space.

Simple Text Oriented Messaging Protocol

STOMP is the Simple (or Streaming) Text Oriented Messaging Protocol.

STOMP provides an interoperable wire format so that STOMP clients can communicate with any STOMP message broker to provide easy and widespread messaging interoperability among many languages, platforms, and brokers.

Advanced Message Queuing Protocol

AMQP or Advanced Message Queuing Protocol is an open standard for passing messages between applications. This protocol is centered around message management rather than on device management.

Representational state transfer

REST or Representational state transfer, or RESTful web services are a methodology using which two systems or one system and a user can exchange information. Using a predefined set of stateless operations, REST-compliant web services allow requesting systems to exchange and manipulate data.

WebSockets

The WebSocket protocol was designed to work well with the existing web infrastructure. As part of this design principle, the protocol specification defines that the WebSocket connection starts its life as an HTTP connection, guaranteeing full backwards compatibility with the pre-WebSocket world. The protocol switch from HTTP to WebSocket is referred to as the WebSocket handshake.

As we can see, there are various options available for communication between smart devices and the cloud. Of them all, MQTT (secure) is the most popular and you would see a lot of platforms and solutions preferring MQTT to other protocols.

Of course, there is always raw TCP/IP communication, but this would mean we would end up implementing the entire device management stack all over again, in our own way.

Storage

So far, we have seen how data originates in a sensor and how the controller reads the data using one of the supported protocols. The controller attempts to transmit that data over any of the communication protocols to the Device Management Software.

Now the data is in the cloud. The basic functionality of connecting the real world with the virtual world ends here and the next level of data processing begins from here.

Storage is a very big part of the IoT Stack that we discussed earlier. The database needs to be scalable, highly available, flexible, secure, fast, and highly optimized to process thousands of reads/writes per second.

Here are a few options for storage software.

MongoDB

MongoDB is a document database with the scalability and flexibility that you want along with the querying and indexing that you need. MongoDB is a distributed database at its core, so high availability, horizontal scaling, and geographic distribution are built in and easy to use. MongoDB is free and open source, published under the GNU Affero General Public License.

Apache Cassandra

Apache Cassandra is one of the best highly scalable and highly available databases, without compromising on performance. Its linear scalability and proven fault tolerance on any kind of hardware makes this a perfect database for mission-critical applications.

Time series databases

A time series database (TSDB) represents a data point as a time and value, the value being the sensor value and the time being the time of record origination. Time series databases are pretty fast at data filtering and executing aggregation functions. In IoT, a lot of activity starts after the data is persisted in the database. Most of these activities involve generating dashboards and running queries to analyze the data and that is where a TSDB plays a major role.

Some of the popular time series databases are outlined next.

InfluxDB

InfluxDB is one of the most popular TSDBs and is one of the ideal solutions for use cases involving large amounts of time-stamped data, including DevOps monitoring, application metrics, IoT sensor data, and real-time analytics. InfluxDB also offers an SQL-like query language for interacting with data.

KairosDB

KairosDB is a fast time series database on Cassandra. The API provides operations to list existing metric names, list tag names and values, store metric data points, and query for metric data points. Aggregators perform an operation on data points and down samples. Standard functions such as min, max, sum, count, mean, and more are available.

Netflix Atlas

Atlas was developed by Netflix to manage dimensional time series data for near real-time operational insight. It has in-memory data storage, allowing it to gather and report very large numbers of metrics very quickly. Atlas captures operational intelligence and provides a picture of what is currently happening within a system.

RIAK TS

RIAK TS is an enterprise-grade NoSQL time series database optimized specifically for IoT and time series data. It can transform, store, and analyze massive amounts of time series data and claims to be faster than Apache Cassandra.

This wraps up the section on data storage and the choices we have.

In the next section, we will move one layer above storage into the API management layer.

API management

Once the data is persisted, the next step is to expose the data to the virtual world, where other applications and interfaces can consume it.

Technologies such as Node.js, Go, and Python are a good choice for exposing APIs. But gone are the days where one needed to sit and stitch together APIs to expose secure data. There are ready-made Backend as a Service (BaaS) available in the market that one can deploy quite easily.

API gateway administration

Once our microservice to expose data has been set up, the next step is to make sure the data is secured and that only the intended applications get the access to the data.

That is where software such as Kong (https://github.com/Kong/kong), Istio (https://istio.io/), or Tyk (https://tyk.io/) take the burden away from you. They provide an entire API gateway where things related to security—authorization and authentication, rate limiting, audit, and logging—can be done quite easily at the same time as monitoring the entire API microservice layer.

This is pretty good solution in modern times, not only for IoT-related stacks.

This concludes our section on API management. In the next section, we are going to look at applications that consume the APIs exposed.

Applications

Now that the data is exposed in the form of APIs, it can be consumed by an interface such as a mobile app, a web dashboard, or a smart watch.

Since the data is exposed over REST APIs or WebSockets, any client that is capable of interfacing with these web technologies can extract the data/metrics and provide an overview of what is happening on the device.

The purpose of these applications is to represent sensor data and provide an interface to control the actuator.

Intelligence

The powerful part of IoT is its ability to read data provided by various sensors, make sense of it, and then act on it. This is where intelligence comes into picture.

A typical flow would be as follows:

The data originates at the sensors and then is saved to the Storage. The huge sets of data in Storage are then cleaned and normalized and put into a Big Data system. Then Machine Learning is done on top of this data and, based on the derived data models, we act on the results using Artificial Intelligence.

Using technologies such as machine learning, we perform various analyses on the data. Analysis can range from simple predictions to understanding users, behavior based on their interaction with the sensors. Then, using these predictions, we can propose possible automations to the user. Apart from pattern recognition, we can also perform cross-sectional data analysis, such as the time versus power consumption of a specific device. If we see any anomaly in that data, we can alert the users.

Rules and alerts

Now that we have the setup to get the sensor data into the cloud, we can show it in a dashboard or run intelligence on top of that data as well as execute certain user-defined rules on the incoming data.

The rule here can be as simple as: if the temperature sensor data is greater than 25 °C, send me a notification on my mobile or if the temperature sensor data is less than 18 °C, turn off the air conditioner.

These rules can be created by the user and automate a lot of things based on context and needs.

Inspired by this thought, a popular service named IFTTT came to life.

IFTTT

If This Then That (IFTTT) provides an interface to chain events. Events can be data coming into the system or a certain schedule that has been fired or any such activity. Using an applet, one can chain various events to perform automation.

For instance, if movement is detected in the hallway then turn on the lights: a simple If This Then That scenario.

The IFTTT service can be used for non-IoT activities as well. You can read more about IFTTT here: https://ifttt.com/discover.

Scheduling

There may be times when you want certain activities to happen at certain times of the day and you are not always available to execute them.

For instance, every day at 6 P.M. turn on the backyard light and at 5 A.M. turn it off. A very mundane task and a human presence is really not required.

That is where a scheduling engine comes into picture. You set up a schedule, similar to a wake-up alarm, defining when the schedule should fire and what action should happen at that time. This will take care of getting the job done.

There are services such as cron-job.org (https://cron-job.org/en/), EasyCron (https://www.easycron.com/), or Getcron (http://www.getcron.com/index_EN.html) that can be leveraged to run jobs.

You can always build your own scheduler in any of the popular programming language as well; you can find plenty of libraries for this.

This concludes our section on utilizing data exposed by the API management layer.

In the next section, we will look at how the data as well as intelligence can be consumed by third-party services.

Third-party integration

So far, we have seen how to consume data and make sense of it, and how to work with manual automation using rules and schedules. In this section, we are going to look at how third-party services can integrate with our stack.

Imagine you want to have Amazon Alexa or Google Assistant as one of the interfaces to the smart devices that we built. These third-party services do not play well with our APIs directly and that is where this integration layer comes into the picture.

This is a custom layer that we will be using to write wrapper functions that act as a bridge between our API management layer and the third-party service. All this layer does is massage and accept data from Amazon Alexa APIs, and then it converts it to a format the API management layer understands; it then reads the response from the API management layer and converts it to a format Amazon Alexa API understands. This way, the core of the stack need not change for every integration with other services.

In IoT, integrating with third-party services is bound to happen at some point or another because one entity/organization cannot build everything needed for IoT.

For instance, in a smart home, you may have built a smart device that can sense the temperature along with a few other parameters. Now you want your customer/user to able to integrate their Nest thermostat with your temperature sensor values. We set up a rule to control their thermostat from our stack.

This layer makes sure that our stack is scalable and integratable with other services as well.

With this, we wrap up the section on building blocks. We have seen various layers, their components, and how all of them form a complete IoT stack when stitched together.

In the next section, we will be looking at the security aspects of IoT.