Chapter 20. Azure and the Internet of Things

For me, one of the most exciting areas of technology in the last few years is the Internet of Things (IoT). I don’t quite believe that a dishwasher or fridge needs to be connected to the internet just yet, and there are valid privacy concerns over a TV or audio device that’s permanently connected to the internet and always listening for the sound of your voice to issue a command. There are, however, a lot of a practical applications for IoT devices. You could have manufacturing equipment report on its health status, generate maintenance alerts, and allow operators to understand its efficiency across multiple factories around the world. A trucking company could stream telemetry from its vehicles about loads being carried and average driving times, and be able to more intelligently reroute drivers as needed. Shipping companies can track each container and help their customers better manage their supply chain by knowing where their resources are.

In Azure, you can integrate IoT devices with a range of services. Azure Web Apps can provide a frontend for your data to be visualized, Storage can be used to log data streamed from devices, and serverless features like Azure Logic Apps (discussed in the next, and final, chapter) can process the data received. In this chapter, we examine what IoT is and how to use Azure IoT Hub to centrally manage and collect data from devices. You then see how to use an Azure web app to view real-time data from an IoT device.

20.1. What is the Internet of Things?

Interest in the Internet of Things (IoT) has grown considerably the last few years, but it’s a vague term and can be applied to many different scenarios. At a basic level, IoT is an approach where many interconnected devices—typically small, low-cost electronic devices—connect back to central systems and applications. The connected devices usually report information they collect from attached sensors or inputs. This information can then be processed by a central system—perhaps with AI or ML as discussed in chapter 17—and carry out appropriate actions. Figure 20.1 shows a high-level approach to IoT.

Figure 20.1. Messages are sent between many connected IoT devices and a central system. Your applications and services can then process the data received and send device instructions to perform additional actions in response to their collected data.

Some examples of IoT in action include the following:

• Parking garage—A small sensor above each parking bay detects whether a vehicle is parked there. A light above each bay can then illuminate green if the parking bay is empty, or red if it’s occupied. Drivers entering the parking garage can see real-time information boards on each floor that let them know how many open parking spots there are. The red and green lights above each bay help drivers quickly determine the location of open spots as they drive along each aisle.
• Factory—Machinery on a factory floor can report back information on operating output, consumable levels, and maintenance needs. A central system can then schedule a maintenance technician to proactively repair equipment or resupply consumables, which reduces any downtime in the production line. When combined with AI and ML, maintenance schedules can be predicted, and the correct amount of supplies or raw materials can be delivered just before they’re needed in production.
• Transportation—Public transportation buses or trains can include GPS sensors that report on location and speed. Ticketing information can also be collected to report on how many people are being transported. Passenger information boards at a train station or bus terminal can then provide real-time information about when each vehicle will arrive. When combined with AI and ML, this means waiting passengers can receive suggestions for alternate routes based on traffic conditions, delays, or heavy passenger volume.

IoT often works alongside other applications and services. The factory and transportation scenarios could use AI and ML to better inform production decision or make suggestions to passengers. Web applications can use information received from IoT devices to provide access from mobile devices or generate alerts and notifications. Data received from IoT devices could be logged to a database system like Cosmos DB that’s then processed by business intelligence applications and generate reports.

More future-looking ideas around IoT include things like your refrigerator sensing food levels and generating a shopping list or even ordering food from a local grocery store. Your car could report data back to the dealership and have any required parts or consumables ready when you take the vehicle in for service. Or what if, when your alarm clock goes off to wake you up in the morning, your coffee maker turns on and gets ready for breakfast?

One big area of concern with IoT is device security. With so many devices outside of your primary network infrastructure and often connected to the public internet, being able to provision, maintain, and update those devices is a challenge. Many IoT devices are low-power, simple electronics and may not have the storage or processing capabilities to update themselves with security and application updates the way a traditional desktop or laptop does. It’s not enough to deploy a bunch of IoT devices, especially consumer-level devices, without a plan to adequately secure them and provide updates and maintenance.

These security concerns shouldn’t stop you from building applications and services that use IoT devices. IoT brings a new set of challenges to traditional device maintenance, but there are solutions that allow you to centrally provision and maintain devices, and secure device communication. By now, I’m sure you may have guessed that Azure has such an IoT solution! It offers a suite of IoT services; let’s see how you can start to explore IoT with Azure.

20.2. Centrally managing devices with Azure IoT Hub

Azure IoT Hub lets you centrally manage, update, and stream data from IoT devices. With this service, you can perform actions such as configuring application routes for data received from devices, provisioning and managing certificates to secure communication, and monitoring health with Azure diagnostics and metrics. You can connect your IoT devices to other Azure services and applications to let them send and receive data as part of a wider solution. As with all things in Azure, access can be controlled with RBACs, and diagnostic data can be centrally collected for troubleshooting and monitoring or alerts. Figure 20.2 outlines how an IoT hub acts as the central place for IoT devices to connect to the wider Azure services and applications.

Figure 20.2. With an IoT hub, you can centrally provision and manage many IoT devices at scale. Two-way communication exists between devices and Azure to read and write data. You can process data received from devices and route it to other Azure services such as Web Apps and Storage. To monitor and troubleshoot issues, you can route information to Azure Event Grid, which we look at in the next chapter, and then link to other monitoring solutions.

You control access to an IoT hub with shared access policies. These policies are like user accounts and permissions. Default policies exist that allow devices and services to connect to the IoT hub, or to read and write information from the device registry that tracks connected IoT devices and security keys. Each policy can be assigned one or more of the following permissions:

• Registry read
• Registry write
• Service connect
• Device connect

Shared access keys are used by applications and services to connect to an IoT hub. As with Storage, discussed in chapter 4, shared access keys allow you to define connection strings to identity the host, access policy, and access key. A connection string combines the access key, access policy type, and the IoT hub hostname. Here’s a sample IoT hub connection string:

HostName=azuremol.azure-devices.net;SharedAccessKeyName=registryRead;
SharedAccessKey=6be2mXBVN9B+UkoPUMuwVDtR+7NZVBq+C7A1xCmQGAb=

Primary and secondary keys exist, which can be rotated and updated for security purposes, just like regularly updating passwords. Solutions such as Azure Key Vault, discussed in chapter 15, are great ways to track and store these keys for applications to obtain when needed. This approach to key management means you can frequently rotate access keys without the need to also update all of your application code.

Digital certificates can be stored in an IoT hub and automatically provisioned to IoT devices. Remember, IoT devices are often outside of your core infrastructure and may connect directly over the internet without any form of secure network connection like a VPN. Make sure all the data between your devices and the IoT hub is encrypted. Azure Key Vault can generate and store SSL certificates that are then added to the IoT hub. Or you can use an existing certificate authority to request and issue certificates. The important thing is to make sure all communication between your IoT devices and Azure is encrypted where possible.

IoT hub routes let you send data from IoT devices to other Azure services. You can define criteria, such as the message content containing a certain keyword or value, and then route the messages to be stored in Azure Storage or processed by a web app. In one of the following exercises, you simulate a basic temperature sensor connected to an IoT device. You could define a route in the IoT hub to watch the incoming data and, if the recorded temperature exceeded 100°F, route the data to a logic app to send an e-mail alert. We discuss the wonderful world of serverless computing and logic apps in the next chapter!

1.  Open the Azure portal, and then launch the Cloud Shell. Create a resource group, such as azuremolchapter20:

az group create --name azuremolchapter20 --location eastus

2.  Create an IoT hub. Enter a name, such as azuremol. For these exercises, you can use a free-tier IoT hub, f1:

az iot hub create
--resource-group azuremolchapter20
--name azuremol
--sku f1

Note

You can create only one free-tier hub per subscription, but they’re great for testing communication between devices and integrating with other Azure services. The free-tier hub is currently limited to 8,000 messages per day. This may sound like a lot, but depending on what you’re doing, a single device that sends a message to the IoT hub approximately every 12 seconds would max out that 8,000-message limit!

3.  You’ve done a lot of work with the Azure CLI in this book, because the Cloud Shell and CLI commands make it quick to create and manage resources. As mentioned in earlier chapters, the Azure CLI can also use additional modules, called extensions. These extensions add more functionality and often update outside the regular release cycle of the main Azure CLI. Azure IoT is rapidly expanding and adding new features, so the main commands to interact with IoT Hub come from an Azure CLI extension.

To get the full functionality you need for later exercises, install the Azure CLI IoT extension:

az extension add --name azure-cli-iot-ext

Your IoT hub is pretty empty right now. There’s not much you can do with it without one or more connected IoT devices. A common device used for IoT is the Raspberry Pi. This is a low-cost minicomputer that can connect to Wi-Fi networks and use common off-the-shelf sensors for temperature, humidity, and pressure. You can also use it to control small motors, lights, and timers. You don’t need to rush out and buy a Raspberry Pi to work with an IoT hub, though—you can simulate one in your web browser!

20.2.1. Creating a simulated Raspberry Pi device

IoT devices are great, but there’s a barrier to entry in that you need an actual device to use, right? Nope! There are a few different ways that you can simulate an IoT device with software. This software-based approach lets you focus on building your application quickly and then transitioning to real hardware. You still need to pay attention to how your code runs on real IoT hardware, especially low-power devices, because they may not have access to all the required libraries, or even memory resources, that your simulated application does.

Microsoft provides a free Raspberry Pi simulator through GitHub at https://azure-samples.github.io/raspberry-pi-web-simulator. A common BME280 sensor that collects temperature and humidity readings is simulated in software, along with a simulated LED to show when the device transmits data to the IoT hub. You can’t customize this much, but it does let you see how a basic Node.js application can run on the Raspberry Pi, poll data from a sensor, and send that back to Azure.

Note

If things like the Raspberry Pi, electronics and temperature sensors, and Node.js seem daunting, don’t worry. As with the chapters on AI and ML, containers, and Kubernetes, we’re not going to get super deep into IoT devices and programming. If you feel like you want to plug in a soldering iron and geek out with electronics by the end of this chapter, though, you’re more than welcome to!

Before you can use the Raspberry Pi simulator, you need to create a device assignment in Azure IoT Hub. This process creates a unique device ID so your IoT hub understands which device it’s communicating with and how to process the data. In more complex scenarios, you could provision additional settings for the device and push digital certificates. For this exercise, you just create a device identity.

1.  In the Azure Cloud Shell, create a device identity in your IoT hub, such as azuremol. Provide a name for the device, such as raspberrypi:

az iot hub device-identity create
--hub-name azuremol
--device-id raspberrypi

2.  Remember the shared access policies from the previous section? Each IoT device also has its own access key and connection string that are used to identify it when it communicates back to the IoT hub. To use your device with the Raspberry Pi simulator, you need the information for the device connection string. This unique identifier includes the hostname of your IoT hub, the ID of the device, and an access key:

az iot hub device-identity show-connection-string
--hub-name azuremol
--device-id raspberrypi
--output tsv

3.  Copy the contents of your connection string—you need it in the next step. The output is similar to the following:

HostName=azuremol.azure-devices.net;DeviceId=raspberrypi;
SharedAccessKey=oXVvK40qYYI3M4u6ZLxoyR/PUKV7A7RF/JR9WcsRYSI=

4.  Now comes the fun part! Open the Raspberry Pi simulator in your web browser: https://azure-samples.github.io/raspberry-pi-web-simulator. Look in the code section at right in the simulator. Around line 15, there should be a connectionString variable, which already prompts you for [Your IoT hub device connection string]. Copy and paste your connection string from the previous step, as shown in figure 20.3.

Figure 20.3. Copy and paste the connection string for your Azure IoT device into the Raspberry Pi simulator. The connectionString variable is used to connect to transmit the simulated sensor data to Azure.

5.  Select the Run button just below the code window to start the simulator. Every 2 seconds, the console window displays a message that shows the data sent to the IoT hub. The red LED on the circuit diagram also flashes when this happens, to simulate how outputs connected to the Raspberry Pi can be controlled. The output message in the console window is similar to the following:

Sending message: {"messageId":1,"deviceId":"Raspberry Pi Web
Client","temperature":24.207095037347923,
"humidity":69.12946775681091}

Where did the temperature and humidity readings come from? This device is a simulated Raspberry Pi, and there’s no real BME280 sensor, so the application generates these values in software. If you look at the rest of the code in the simulator window, around line 99 the application defines the sensor. The simulator then replicates how the real sensor would act, and generates data returned from the sensor to the application. It’s a basic example, so think what else you could read in here: revolutions per minute (RPM) of a motor or engine, or GPS coordinates of a shipping container or truck, and so on. This is where there’s a balance between simulating a device in software and building a functional application with real hardware and sensor data. At some point, you need to purchase or borrow equipment if you want to get into more depth with Azure IoT.

6.  To confirm that your simulated device messages are being received by the IoT hub, examine the quota status. Provide the name of your IoT hub, such as azuremol:

az iot hub show-quota-metrics --name azuremol

The output is similar to the following example, which shows that 5 messages out of the maximum 8,000 total messages per day have been received, and that there’s 1 connected device from a maximum of 500 total devices. It may take a few minutes for these metrics to populate, so don’t worry if you don’t see any data right away:

[
{
"currentValue": 5,
"maxValue": 8000,
"name": "TotalMessages"
},
{
"currentValue": 1,
"maxValue": 500,
"name": "TotalDeviceCount"
}
]

You can also look in the Azure portal: choose your resource group, and then select your IoT hub. On the Overview page, the usage display reports the number of messages received and connected devices. Again, it may take a minute or two before the messages appear and are recorded against the quota. Any applications would be able to immediately use the messages received, as we look at in the next section.

20.3. Streaming Azure IoT hub data into Azure web apps

A device that connects to an IoT hub isn’t useful if you can’t do anything with the data. This is where you can start to integrate many of the services and features you’ve learned about in this book. Want to stream to Azure Storage tables or queues? You can do that. Process data from IoT devices in Azure VMs or containers? Go right ahead! Use Azure Cosmos DB to replicate your data and then access it with globally redundant Azure web apps and Traffic Manager? Sure!

In the example scenario, the IoT hub is the connection mechanism and entry point for your IoT devices into Azure. The hub itself doesn’t directly do anything with the data. A default endpoint exists for events, which is a big bucket for any messages received from the IoT device. Your simulated Raspberry Pi device sends messages to the IoT hub, which hit this events endpoint. The flow of messages from devices through the IoT hub to an endpoint is shown in figure 20.4.

Figure 20.4. An IoT hub receives messages from connected IoT devices and sends the messages to an endpoint. These endpoints can be used by other Azure services to consume data from the IoT devices. A default endpoint for events exists, which services like web apps can read from.

You can create custom endpoints that route messages directly to Azure services such as Storage and Service Bus. In chapter 4, we looked at Azure Storage queues for a way to pass messages back and forth between applications. A more robust and scalable enterprise messaging platform is Azure Service Bus. Messages can be added to the service bus, such as data received from IoT devices, and other applications can then listen for these messages and respond accordingly.

If you don’t need the complexity of reading messages from a message queue like a service bus, you can use consumer groups with the default events endpoint. A consumer group allows services like Azure Web Apps to read data from the endpoint, as shown in figure 20.5.

Figure 20.5. Messages are sent from IoT devices to the IoT hub, which then directs the messages to an endpoint. In each endpoint, consumer groups can be created. These consumer groups allow other Azure services to access the device messages, which they otherwise wouldn’t have access to. With consumer groups, you don’t have to use message queues to allow external applications to read IoT device data.

Let’s create an Azure web app that uses a consumer group to read message data in real time from your simulated Raspberry Pi device. This basic example shows how you can stream data from IoT devices and access them from web applications.

1.  Create an Azure App Service plan for your web app in the Azure Cloud Shell. Provide a name, such as azuremol. For these exercises, the free tier (f1) is good enough and keeps costs down:

az appservice plan create
--resource-group azuremolchapter20
--name azuremol
--sku f1

2.  Create your web app. Provide a name, such as molwebapp, and enable it for use with Git so that you can deploy the sample application:

az webapp create
--resource-group azuremolchapter20
--plan azuremol
--name molwebapp
--deployment-local-git

3.  You need to define the consumer group for your IoT hub, along with some web app application settings. These settings let your web app connect to the IoT hub. Figure 20.6 shows what you build in the next few steps.

Figure 20.6. To let your web app read the data from your simulated Raspberry Pi IoT device, you create a consumer group in the IoT hub. You then define two application settings for your web app that let you connect to the consumer group. To let your web browser automatically receive the stream of data from the Raspberry Pi as new data is received, you also enable a setting for WebSockets.

4.  Create a consumer group that allows your web app to access the event data streamed from your IoT device. Provide your IoT hub, such as azuremol, and then enter a name for your consumer group, such as molwebapp. Your consumer group is created in the default events endpoint:

az iot hub consumer-group create
--hub-name azuremol
--name molwebapp

5.  You need to tell your web app what the consumer group is called. Create a web app application setting that’s used by the sample application you deploy at the end of the exercise. Application settings in web apps allow you to define specific settings, such as the consumer group name and connection string, without those values being hardcoded into your application.

Provide the name of the consumer group created in the preceding step, such as molwebapp:

az webapp config appsettings set
--resource-group azuremolchapter20
--name molwebapp
--settings consumergroup=molwebapp

6.  To connect to the IoT hub, your web app needs to know the connection string for the hub. This connection string is different than the one you copied for your simulated Raspberry Pi device in the previous exercise. Remember, there’s a connection string for your IoT hub, which uses shared access policies to define access permissions; and there’s a connection string for each IoT device. Your web app needs to read from the IoT hub endpoint consumer group, so you must define a connection string for the IoT hub itself.

Get the IoT hub connection string, and assign it to a variable named iotconnectionstring. This variable is used in the next step:

iotconnectionstring=$(az iot hub show-connection-string
--hub-name azuremol
--output tsv)

7.  Create another web app application setting, this time for the IoT hub connection string. The variable defined in the preceding step is used to let the sample application connect to and read data from the IoT device:

az webapp config appsettings set
--resource-group azuremolchapter20
--name molwebapp
--settings iot=$iotconnectionstring

8.  The final step is to enable WebSockets. A WebSocket is a two-way means of communication between a browser and server. The sample application automatically updates the web browser with the data received from the Raspberry Pi device. To perform this automated update, the application uses WebSockets. The server can then push data to the browser and cause it to automatically update:

az webapp config set
--resource-group azuremolchapter20
--name molwebapp
--web-sockets-enabled

Let’s pause here and discuss what you’ve done so far. You’ve worked with web apps in many of the previous chapters, but the web app application settings and WebSockets are new. Figure 20.7 recaps how your web app and IoT hub are connected.

Figure 20.7. As messages are sent from IoT devices, they pass through the IoT hub to an endpoint. Your application code reads in web app application settings that define the IoT hub connection string and consumer group to use. Once connected to the IoT hub, the consumer group allows web apps to read the IoT device messages. Each time a new message is received from an IoT device, your web app uses a WebSocket connection with web browsers that access your site to automatically push updates. This connection allows you to view real-time data streamed from IoT devices, such as temperature and humidity information, from your simulated Raspberry Pi device.

Now let’s finish the exercise and deploy the sample application from the GitHub repo to your web app. You can then open the web app in your browser and see the real-time data streamed from your simulated Raspberry Pi!

1.  If needed, clone the GitHub samples repo in your Cloud Shell as follows:

git clone https://github.com/fouldsy/azure-mol-samples.git

2.  Change into the directory for chapter 20:

cd azure-mol-samples/20

3.  Initialize the Git repo, and add the basic web page:

git init && git add . && git commit -m "Pizza"

4.  To upload the sample application, create a connection to your web app. The following command gets the web app repository and configures your local samples Git repo to connect to it. In previous chapters, I made you dig around for this address; but by now I hope you’ve started to explore what else the Azure CLI can do and realized that much of this information can be quickly obtained:

git remote add molwebapp
$(az webapp deployment source config-local-git
--resource-group azuremolchapter20
--name molwebapp
--output tsv)

5.  Push the HTML sample site to your web app with the following command:

git push molwebapp master

6.  When prompted, enter the password for the Git user you created and have used in previous chapters (the account created in chapter 3).

If you didn’t write your Git password on a Post-It note

If you’ve forgotten the password, you can reset it. First, get the username of your local Git deployment account:

az webapp deployment user show --query publishingUserName

To reset the password, enter the name of your account from the previous command, and then answer the prompts to set a new password. The following example resets the password for the user account named azuremol:

az webapp deployment user set --user-name azuremol

7.  View the hostname for your web app, and then open the address in a web browser:

az webapp show
--resource-group azuremolchapter20
--name molwebapp
--query defaultHostName
--output tsv

It may take few seconds the first time that you open the site in your web browser, as the web app connects to the IoT hub, starts the WebSocket connection, and waits for the first device message to be received. Every 2 seconds, the web browser should automatically update with the latest simulated data from the Raspberry Pi device, as shown in figure 20.8.

Figure 20.8. The sample application uses a WebSocket connection between your web browser and web app to automatically update every 2 seconds with the latest data from your simulated Raspberry Pi device.

If your web app instance doesn’t show any data, make sure the Raspberry Pi simulated device is still running. If needed, start the simulated device and make sure it connects to Azure IoT and sends messages. The data should then begin to appear in your web app instance.

20.3.1. Azure IoT component review

I hope the exercises in this chapter have given you an idea of what services are available in Azure for IoT solutions:

• Azure IoT Hub provides a great way to provision, connect, and manage many IoT devices and then integrate with other Azure services.
• Azure IoT solution accelerators provide prebuilt scenarios that automatically integrate many different Azure services to provide a complete application environment.
• Azure IoT Edge lets you deploy Azure services in your local environment to process data from IoT devices without the need to stream all the data centrally back to Azure.

To really dig into Azure IoT and IoT devices in general, I recommend that you purchase a basic Raspberry Pi or similar device. They’re relatively cheap, often come with a few different basic sensors or electrical components to test out different ideas, and give you a great learning platform as you see what’s possible when integrating hardware and software. Just remember the warnings from chapter 17 about AI and ML and building Skynet! Manning also has some excellent books, such as Building the Web of Things (Dominique D. Guinard and Vlad M. Trifa, 2016, www.manning.com/books/building-the-web-of-things) and JavaScript on Things (Lyza Danger Gardner, 2018, www.manning.com/books/javascript-on-things), that go into more depth on the Raspberry Pi, IoT best practices, and JavaScript and Node.js programming on IoT devices.

20.4. Lab: Exploring use cases for IoT

This chapter discussed a lot of new stuff, and without a real IoT device, you’re limited in what you can do. Chapter 21 builds on Azure IoT Hub and the simulated Raspberry Pi, so I don’t want to configure too much more right now. Here are a couple of things you can do to think further about IoT:

1.  What areas can you think of where IoT devices could benefit your business? If you don’t work in a business right now, think about the fictional Azure Month of Lunches pizza store:

1. What could you do to improve things for customers with IoT?
2. Would you use Azure IoT Edge? Why or why not?
3. What other Azure services would you likely integrate to run your applications?

4.  If you have time left in your lunch break, try one of the Azure IoT solution accelerators from www.azureiotsolutions.com/Accelerators. There’s a Device Simulation scenario that creates a VM and simulated sensors, which is like the simulated Raspberry Pi device but much bigger! It takes a few minutes to provision all the required resources, but then look around in the Azure portal to see what was created and how all the parts work together:

1. Can you see how services from earlier chapters, such as Storage and Cosmos DB, are used?
2. What other IoT solution accelerators are available? Do any of them align with ideas you had for your own applications?