The Internet of Things is a state where the things on the face of the earth connect to the internet and start talking to each other. Things here can be electronic, electrical, mechanical, or electro-mechanical objects.

Imagine waking up in the morning to your favorite music playing in the background; once you walk into the bathroom, the lights come on automatically and the mirror greets you with the latest Instagram or Twitter feed while it analyzes your sleep pattern to see how well you have slept to show you a feed based on your mood.

You wash and move to the kitchen to find the coffee machine has already turned on a few minutes ago to serve you a cup of hot coffee. Your toaster has auto-inserted the last couple of slices of bread from its tray and checked with the refrigerator to see there is any more bread. The refrigerator checks its inventory and discovers that it is out of bread and adds the bread to your shopping cart and places an order with an online grocery store.

Meanwhile, your self-driven car is reading your calendar for meetings that you need to attend across town and plans the routes for an optimal and smooth journey. The moment you walk out of your home, the environment sensors detect the lack of humans, shut down everything that is consuming power, and move into a hibernate mode.

Now, this is Internet of Things, where all the things talk to each other and make your life an absolute pleasure.

What I have described is no longer a vision or a dream. It is how we may live one day in the very near future. There are already things such as smart fridges, smart washing machines, and smart water purifiers on the market today and people are buying them one at a time to get acquainted with the technology. Soon, we will have a system in place that will interface with all these devices; that is when we will realize the true power of IoT.

The example I have given centers around a smart home. It is very important to understand that IoT is not limited to smart homes. The same technology that we used to make our refrigerator order groceries online can be used to tell us when our car needs to be serviced next, the duration of traffic light signals at a particular hour of the day, or when a conveyer belt in a factory floor needs to be changed.

With IoT, you no longer need to worry about a diet plan; you can tell your refrigerator, your stove, and your weighing scales that you are on a diet and they will take care of that for you.

There are two sides to any coin. IoT can be very helpful and at the same time can be very annoying.

Imagine every move of yours is monitored and relayed to other services so everything is connected and in sync; this may be a bit of a challenge at times. Imagine your doctor calling you when you are going to eat a second serving of a cake... pretty annoying, right?

We rely heavily on connectivity and synchronization between devices and if things don't sync well, then the chaos will be in the order of n, where n is number of devices that this device needs to sync with.

On the lighter side of things, imagine a world where all your smart devices have an active online presence posting information about themselves and all you need to do is follow them on social media and you will know everything about them.

And if any two devices do not want to talk to each other, because they have an ego issue, we are doomed for sure.

The next key thing in the world of IoT is data privacy and security. Since all the devices talk to each other and share this information over the internet there is always an onlooker who is interested in that data. They may be monitoring your door sensor data that is being transmitted and then may act in your absence. Or they can tamper with the data by intercepting the packet and sending a spoofed packet on behalf of the door sensor itself.

Imagine a time and age where you need to buy a firewall for your toaster, because someone is tampering with the crispness of your toast.

We will talk more about security and data privacy in the coming chapters.

All this loosely summarizes the major part of what IoT is. We will deep dive into various areas as we go along.

In the next section, we are going to look at the history of IoT.

In the last section, we have seen what IoT is and we have looked at a few examples as well. In this section, we are going to take a look at the history of IoT.

Even before Kevin Ashton coined the term Internet of Things in 1999, this technology existed in other forms and shapes, pretty much doing the same thing.

To put things into perspective, the first TCP/IP communication was made in 1974 (https://en.wikipedia.org/wiki/Internet_protocol_suite), which stemmed from the success of ARPANET (https://en.wikipedia.org/wiki/ARPANET) in 1969.

Automated Teller Machines (ATMs) one of the first connected devices, were launched in 1969. It was a very exciting time in the banking domain, where people could get instant cash.

Take a look at this demo of an ATM from 1969 named 'Instant money': ATM comes to Australia (1969): https://www.youtube.com/watch?v=yuClDSofyJs.

Then there came the famous Internet Coke Machine, built by four students of Carnegie Mellon University in 1982. This machine used ARPANET to communicate and could be queried in real-time remotely using a finger interface. This machine lets you know about the stock of Coke in the machine along with the information about the Coke's coldness.

The next notable and documented incident that happened in the connected devices space was The Internet Toaster in 1989. John Romkey connected a toaster to the internet using a TCP/IP protocol and controlled it using a Simple Networking Management Protocol Management Information Base (SNMP MIB). This internet toaster could be turned on remotely and the darkness of the toast was controlled by the duration of the toaster being powered on.

In 1991, Sir Timothy Berners Lee and CERN announced the World Wide Web (WWW) outside the CERN. Do note that until this time no one had seen a web page or HTML document in the outside world; it was all packets of data transmitted over wire.

With the invention of the WWW, people started working with the world of connected things with more ease.

The next event in history that brought in a new dimension to the connected things world was the Trojan Room coffee pot created by Quentin Stafford-Fraser and Paul Jardetzky in 1993. Using a video frame-grabber present inside the Trojan Room, they were able to take pictures of a coffee pot present inside the Trojan Room every few seconds and then send these to a server. The client application on the other side could show these images and if the coffee in the coffee pot was low, people could remotely get to know and then refill the coffee pot.

As you see from this series of incidents, the concept of connected devices is quite old. And the industrial sector is no stranger to it. Machines connected to each other over PLC can each be controlled, monitored, and managed from far away.

As you can see, the world of connected devices and the Internet of Things is evolving faster than ever. The motivation is: laziness. I believe that in this time and age, laziness is the mother of invention!

That concludes this walk down memory lane. In the next section, we are going to look at IoT and the market.

In the last section, we went through the history of IoT. In this section, we will take a brief look at the IoT market and reports published by Gartner and Forbes.

IoT is identified as one of the key emerging technologies and is currently in the Peak of Inflated Expectations phase, as per Gartner (July 2017): https://blogs.gartner.com/smarterwithgartner/files/2017/08/Emerging-Technology-Hype-Cycle-for-2017_Infographic_R6A.jpg and https://www.gartner.com/smarterwithgartner/top-trends-in-the-gartner-hype-cycle-for-emerging-technologies-2017/.

Given the report, one can only imagine how this technology could evolve into a market, where a world of connected things leads to intelligent things.

Take a look at the Gartner Top 10 Strategic Technology Trends 2018: https://www.youtube.com/watch?v=TPbKyD2bAR4. David W. Cearley, VP and Gartner Fellow, Gartner research explains how intelligent devices are key items in emerging technology trends in 2018 and how they are going to impact overall growth in the next 5 years.

Here is an interesting article published on Forbes by Louis Columbus, titled 2017 Roundup Of Internet Of Things Forecasts: https://www.forbes.com/sites/louiscolumbus/2017/12/10/2017-roundup-of-internet-of-things-forecasts. It provides some really encouraging facts about the growth and market for IoT.

The numbers mentioned in the article look quite promising for people or organizations that want to get into the world of Internet of Things, either by building it or supporting it.

In another article published by Louis Columbus, titled The Era Of Integrated IoT Has Arrived In The Enterprise: https://www.forbes.com/sites/louiscolumbus/2017/09/29/the-era-of-integrated-iot-has-arrived-in-the-enterprise), Louis Columbus talks about the adoption of IoT in enterprises.

You can read more Vodafone fifth annual IoT Barometer report in the previous URL.

Here is an interesting take from my dear friend on IoT and enterprises:

As we can see , the market is huge; there is a lot of potential in terms of opportunities and revenue.

The way I look at it is that all existing enterprise clients are getting into the world of IoT in one way or another. And this is where I see a lot of potential for proposing IoT solutions to clients to make the process, as well as systems, more intelligent and smart with the help of IoT.

With this, we conclude this section on IoT and the market.

Before we start building IoT solutions using various out-of-the-box IoT platforms, I would like to talk about the various building blocks of an IoT solution. That includes smart devices, storage, API management, as well as intelligence.

This diagram represents an end-to-end IoT stack:

The stack consists of various layers that will be part of any typical IoT solution.

The bottommost layers in the stack are the smart devices or The Things. These communicate with the real world and gather the information around them to actuate things. And through the gateway, the smart devices talk to the device management software to keep them integrated with the remaining world.

With the help of the storage layer, the device management software persists the communications and data that arises between the smart devices and the API management layer. The API management layer is responsible for creating an interface between the device, its data, and the applications that want to control and manage these smart devices.

The applications here can be any entity that has the capability of consuming the exposed APIs and managing and monitoring smart devices. Applications here can include a mobile app, a web dashboard, a voice assistant, or an IVR service, to name a few.

On the other hand, rules engines and schedulers can also consume the data exposed by the APIs. Rules here can be simple actions when a certain type of threshold is reached and a schedule is where an action can be performed on a device at a certain configured time.

This data can also be used for analysis as well as for adding intelligence on top of the existing system. Technologies such as big data, machine learning, and artificial intelligence fall under this category.

On top of these layers is where third-party integrations take place.

In the subsequent sections, we will go into each of the layers and explore them further.

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

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

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 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:

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.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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

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

Here are a few popular communication protocols.

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-SN) caters for more non-TCP/IP embedded devices, where MQTT runs using a TCP/IP stack.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

Did you know that the first IoT murder was supposed to happen in 2014? Don't believe me, check out: First IoT-mediated murder could occur in 2014, experts warn http://www.itpro.co.uk/hacking/23242/first-iot-mediated-murder-could-occur-in-2014-experts-warn.

Security is a very important part of IoT, be it as simple as stealing data or monitoring your door sensor to know when you have left your home or spoofing a data record to indicate an unwanted event to create havoc. Security is essential.

Now we need to invest in a firewall for our toaster.

IoT devices are being used to perform DDoS attacks on other entities. Stealing data from a sensor is one thing, but reprogramming/hacking a smart device to think it is something else is a new level of disaster.

On Friday October 21, 2016 there was a Distributed Denial of Service (DDoS) attack that took place on a DNS provider named Dyn, bringing down major websites such as Etsy, GitHub, Netflix, Twitter, and Spotify.

This was a Mirai bot attack (https://www.corero.com/resources/ddos-attack-types/mirai-botnet-ddos-attack.html). All this malware does is convert devices running Linux into remotely controlled Bots that can be used as part of the botnet for performing large-scale network attacks.

Old router and IP cameras were the major source of devices that were used in the attack that brought down part of the USA.

You can read more about the attack from Dyn here: https://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/.

This is just one of a few attacks that have happened in the recent past. You can find plenty more on the internet.

The new trend in IoT hacking is ransomware. Hackers get into IoT systems or software and block it or disrupt it. In order for the device or the system to work properly again, the owners need to pay a ransom (mostly through cryptocurrency such as Bitcoin).

Imagine a world where your coffee machine blackmails you into paying money or it will brew only decaf.

In this time and age, what is the best way to be secure? Just turn things off?

Jokes aside, this is a pretty serious issue. Do remember that systems are built to be hacked. So, what might seem a security solution today may be a new attack name tomorrow.

In the world of IoT, our primary goal is to keep data safe and the secondary goal is to keep our devices and servers updated.

For data communication security, we can use a standard such as X.509, where we encrypt the transported data using public/private keys. If needed, the data that is being transmitted can be scrambled and encrypted.

All of the data stored in databases needs to be encrypted. This definitely causes overhead but will save us from attacks.

Check out this article on how MongoDB databases were attacked and how ransoms were required to get them back: https://www.networkworld.com/article/3157766/linux/mongodb-ransomware-attacks-and-lessons-learned.html.

In the next section, we will start looking at the two types of IoT stacks that the world is moving towards: cloud computing and fog computing.

Now that we are aware of the building blocks for a typical IoT solution, we will look at the two different types of architecture for building solutions, their pros and cons, and which setup is suitable for what application.

Microsoft Azure defines cloud computing as:

In IoT, cloud computing is used when the devices talk directly to the cloud. Take a look at this IoT stack built using cloud computing:

The sensor data needs to reach the cloud finally. So, what means do we have? We can connect an Ethernet cable to our controller to talk to a router and then send the data via the router or use a Wi-Fi module to interface with a local router access point. We can also use a GSM module to send the data via a GSM network.

Now let's quickly look at the pros and cons of this approach:

• Pros:
  • If we have only one or two devices in an environment (for router-based communication)
  • If devices are closely positioned to each router (for wireless and router-based communication)
  • If the network strength of the SIM/GSM is better than good (for GSM-based communication)
  • If the battery life of the smart device is not a factor, as both GSM and Wi-Fi modules consume high power (for wireless-based communication)
• Cons:
  • If there is no internet access, these devices are literally dumb devices. No rules or schedules can be run on these devices if they are offline. No intelligence can be gathered.
  • If more devices are connected in the same environment, then we may not have enough Ethernet ports on a router or the router capability to access more devices as Wi-Fi clients (for router-based communication).
  • If the devices are far away from the router, they cannot contact the router or may struggle to keep their connection alive (for wireless and router-based communication).
  • If a particular GSM network is patchy in an area, the connectivity with the cloud is a major issue, again making this device a dumb device till the internet comes on.
  • GSM and Wi-Fi modules consume a lot of power and are not capable of running on a battery for long (not even 6 months).

The biggest issue among all this is the necessity for these devices to be always connected to the internet. If the network goes down, these devices will still function but the data they gather will be quite useless.

Imagine a smart home with about 40 to 50 smart devices deployed; here, all of them need to be connected to power at all times and moving them around might not be an option. Placing them at remote places where there is no power is a breaking factor. The distance between the Wi-Fi router and the device needs to be small.

In developing nations, both internet connectivity and power may be a challenge. This approach may not be a suitable approach for those nations.

These are some of the key challenges when working with cloud computing and IoT.

Now, let us look at fog computing.

Fog computing, fog networking, or fogging is a computation paradigm where the cloud comes closer to the earth or the fog layer. This layer has the computational infrastructure needed to run most essential operations and has all the features that a typical cloud would have but runs locally.

The primary difference between cloud computing and fog computing is that the sensor/actuator network does not heavily rely on the internet to work.

Take a look at this IoT stack built using fog computing:

In the stack, the sensor nodes do not directly talk to the gateway. Instead, they talk to an Edge Router, which is responsible for locally collecting all the data from various sensors, and this Edge Router sends the data to the Cloud when the network is available.

We can think of the edge router as a mini-cloud which can execute almost all basic functions such as storing data, running rules, executing schedules, and managing the devices offline if the internet is not available.

Now let's quickly look at the pros and cons of this approach.

• Pros:
  • Ideal for multiple devices connected to a network.
  • The range between the edge router and hub is not a factor because these smart devices or edge nodes use long range or mesh-based communication.
  • All the edge nodes run a protocol such as Bluetooth, Zigbee, or Z-Wave, which are power-efficient and can run a CR2032 battery for years together.
  • The availability of the internet is not a factor for this smart network to work. The edge router is capable of taking on the role of a mini-cloud to emulate all its features.
• Cons:
  • The biggest con in a system like this is the necessity for a consumer to buy an edge router even though they would like to use just one node
  • Inventory management for an organization would be higher because they need to maintain multiple devices now
  • The initial purchasing cost is on the higher side as the user needs to purchase the edge router along with the actual smart device

If we are looking at building a system where there are plenty of devices connected close to each other and they need to work seamlessly irrespective of the internet connection, then fog computing is better.

Do take a look at Edge Computing vs Fog Computing here: https://medium.com/@rshariffdeen/edge-computing-vs-fog-computing-5b23d6bb049d. This article talks about the subtle differences between fog- and edge-based computing.

Fog computing pushes intelligence towards the smart devices, reducing the amount of data that needs to go to the cloud and decreasing operational latency between the user and the smart device. Cloud computing is a centralized system that can scale on demand and can perform on-demand analysis in real time, among other things.

Here is a table from Cisco's blog, written by Maher Abdelshkour, explaining the differences between cloud and fog computing:

Another table with a high-level comparison follows:

To summarize, depending on the scale, cost, and real-time nature of the application you are planning to deploy, you can pick between cloud computing and fog computing.

We have covered almost all topics related to IoT and its technology stack. The final topic in this chapter is going to be about standards in IoT.

As we have seen so far, there are way too many ways in which one can build their IoT solution stack and there are plenty of masters in this field who think their approach is better. This leads to multiple ways of implementing solutions in IoT.

Be it hardware standards, software standards, communication standards, or data computation standards, there are plenty of options available. As we start looking at various platforms in the book, you will come to realize how each of them is different from the other internally, but that they end up with a similar solution stack.

Take a look at this excellent article named IoT Standards and Protocols - An overview of protocols involved in Internet of Things devices and applications. Help clarify with IoT layer technology stack and head-to-head comparisons here: https://www.postscapes.com/internet-of-things-protocols/. It will give you a high-level understanding of all the possible protocols and standards in each layer.

In this chapter, we have gone through all the key building blocks of an IoT stack. Then we looked at security, the differences between cloud computing and fog computing, and finally we talked a bit about IoT standards.

In the next chapter, we are going to look at the real-world applications of IoT.

• Internet Coke Machine: http://knowyourmeme.com/memes/internet-coke-machine
• Internet Toaster: https://www.livinginternet.com/i/ia_myths_toast.htm
• The Trojan Room coffee pot from Quentin Stafford-Fraser himself: https://www.cl.cam.ac.uk/coffee/qsf/coffee.html
• You can find a compiled list of all sensors here: https://en.wikipedia.org/wiki/List_of_sensors
• SoCs: https://internetofthingsagenda.techtarget.com/definition/system-on-a-chip-SoC
• GPIO: https://techterms.com/definition/gpio
• ADC: https://wiki.analog.com/university/courses/electronics/text/chapter-20
• UART: http://www.circuitbasics.com/basics-uart-communication/
• SPI: https://www.allaboutcircuits.com/technical-articles/spi-serial-peripheral-interface/
• I²C protocol: https://learn.sparkfun.com/tutorials/i2c
• MQTT: http://mqtt.org/
• MQTT-SN: http://mqtt.org/2013/12/mqtt-for-sensor-networks-mqtt-sn
• STOMP: https://datatracker.ietf.org/doc/rfc7252/
• AMQP: http://www.amqp.org/about/what
• REST: https://www.codecademy.com/articles/what-is-rest
• WebSocket: https://websocket.org/aboutwebsocket.html
• MongoDB: https://www.mongodb.com/what-is-mongodb
• Apache Cassandra: http://cassandra.apache.org/
• InfluxDB: https://www.influxdata.com/time-series-platform/influxdb/
• KairosDB: https://kairosdb.github.io/
• Atlas: https://github.com/Netflix/atlas/wiki
• RiakTShere: http://basho.com/products/riak-ts/
• IoT, from Cloud to Fog Computing: https://blogs.cisco.com/perspectives/iot-from-cloud-to-fog-computing