I’ve had a Raspberry Pi sitting around since the holidays, along with a ton of ideas on how to make use of it. The ideas aren’t the problem, the lack of time has been. Since I have a whole extra day in 2016 given that it’s leap year, I thought why not use the additional day to finally tinker with my Raspberry Pi? I’ve been so busy recently building and announcing some great improvements to the Azure App Service tools for Visual Studio 2015, so why not use some of our teams’ creations and knowledge to do something new and fun?

So I broke out my Raspberry Pi and my Azure SDK 2.8.2-enabled Visual Studio 2015 Community Edition and worked up a quick-and-dirty application that can send sensor data to an API App running in Azure App Service. This post walks through the creation of this sample, the code for which is stored in this GitHub repository.

Prerequisites

This post assumes you have all of the pieces to build and run the sample code in App Service and on your device. Below are the prerequisites for both the hardware and software you’ll need:

1. A Raspberry Pi 2 Model B+ running Windows IoT. The process of setting up your Raspberry Pi with Windows IoT is simple, yet beyond the scope of this post. There’s a great Getting Started article on the Windows IoT site, so start there if you need to install Windows on your device. The whole process takes less than an hour and requires very little heavy lifting, so if you’re new to IoT, don’t worry, the setup process is very basic via a simple wizard.
2. Visual Studio 2015 Community
3. The Azure SDK 2.8.2 for .NET, which contains some great new improvements for Web, Mobile, and REST API developers
4. You’ll need an Azure account to deploy code to App Service. If you don’t already have one, sign up here or join Visual Studio Dev Essentials and get a $25 monthly Azure credit.

In addition to these items, you’ll also need a network cable to connect your Raspberry Pi to the network. Once it’s connected you’ll be able to deploy code from Visual Studio to the device, debug your code while it’s running live on the device. Ideally, you’ll be able to connect a mouse and keyboard to your Raspberry Pi. I used a wireless mouse/keyboard combination from my desktop computer, but many options exist for enabling human interface devices to your Raspberry Pi.

An app service to record sensor data

The first step is to create a very basic REST API to deploy and run in Azure App Service. Using the Azure API Apps template available in Visual Studio, it’s easy to get started with a blank project. This template essentially provides you with an empty ASP.NET Web API project, so if you’re an experienced ASP.NET developer this part should be familiar. The Azure API Apps project template also adds in the Swashbuckle NuGet package, which lights up the ability for your Web API endpoints to be dynamically described using Open API Specification (formerly known as Swagger) metadata.

I chose to update my Swashbuckle package to reap the benefits of features added since the package was included in the API Apps template. Some of the new features in Swashbuckle include annotations that can be used to decorate Web API action methods. For more information on these and other techniques and how Swashbuckle can be customized, check out the article Customizing Swashbuckle-generated API definitions on the Azure.com documentation center.

The code for the Sensor and Device Web API controllers is deliberately basic. It isn’t actually storing anything but is more designed to provide a basic starting point so that you can plug in your own storage paradigm. You could use a SQL Server database, the App Service file system, or Azure Storage to persist the data however you want.

The Sensor controller, for example, has one method, a Post method, which takes in an instance of a simple SensorReading model. Using the SwaggerResponse attribute, I can specify all of the possible HTTP response codes the API might return based on the business rules of the Post method:

1. If a user tries to send in a sensor reading for an unknown device, the controller returns an HTTP 404 indicating the device doesn’t exist.
2. If a user sends in a sensor reading for a known device, the reading is recorded and an HTTP 200 is returned to the client.

The code provided in the GitHub sample is perfectly self-contained and needs very little tweaks to provide a basic getting-started point for you to extend the code with your own business rules, storage capabilities, and so on. For now, let’s get this API running in Azure App Service!

Publishing to App Service

Publishing a Web API project to App Service as an API App is quite simple. Right-click on the project and select Publish from the project context menu. Once you do, the Publish Profile dialog appears. Not surprisingly, I’ll be publishing this code to Azure App Service.

Next, I’ll use the App Service Creation dialog to name the App Service into which I’ll be publishing the Web API code. As demonstrated in the screen shot below, the App Service Creation is smart enough to guess that I’m publishing an API App, so it’s the default selection in the App Type menu.

I clicked the New button to create a new Resource Group, as well as creating a new Free App Service plan. Once I click the Create button on the App Service Creation dialog, the Resource Group will be created along with the App Service Plan and the actual App Service that hosts my code.

Once the resources have been created in Azure App Service Visual Studio will download the publish profile and add it to my project. Then, the publish process will complete and the code will be running in the cloud.

Connecting the Raspberry Pi

The code that will run on the Raspberry Pi is also extremely simple, deliberately so that you can use your own imagination and add functionality however you want. Here’s a picture of my Raspberry Pi running in our team room, on the big screen. As you can see the app is quite basic – it consists solely of a toggle button, when clicked, kicks off a timer. Each time the timer fires, a request is made to the App Service I just deployed.

Thanks to the new REST API Client generation features available in Visual Studio’s App Service tools, I don’t have to write boring or complex code to call out to the API and parse the responses. Since Windows IoT apps are apps built using the Visual Studio Universal Windows Project (UWP) templates, I can use the REST API Client Generation feature built into Visual Studio to generate code directly into my UWP project.

To do this, I simply right-clicked my UWP project in Visual Studio and selected the Add > REST API Client gesture in the Solution Explorer. Similar to the Add Service Reference feature that’s been available in Visual Studio for years but focused on basic HTTP REST APIs, the REST API Client generator drops in strongly-typed code that makes it super-simple (and logical) to call an App Service via HTTP methods.

When the REST API Client generation dialog opens, I can click the Select Azure Asset button to see a list of the existing App Services I have which are enabled with an API Definition (you can set API Definitions for any type of App Service, not just API Apps).

I select my recently-deployed Azure App Service in the Select Existing App Service dialog. Note the handy Search box, which provides me the ability to filter my App Services by name.

Once I select the App Service and click the OK button, the metadata is downloaded, code generated, dependencies installed via NuGet, and the code is dropped right into my project.

Note: The GitHub repository containing the code for this sample already has the REST API Client code generated into it so you won’t need to do this if you’re walking through on your own. The only thing you’ll need to do [unless you change the shape of the APIs is to change the base URL for the App Service you’ve deployed to Azure. In the code for MainPageViewModel.cs you’ll see where to change the URL so that it points to your own App Service rather than the demonstration URL.

Now that the code finalized for the Raspberry Pi app I’ll need to deploy it to the Raspberry Pi where it can run continuously, pinging my App Service on intervals.

Deploying to the Raspberry Pi

For the most part, deployment to and debugging live on the Pi is relatively simple. The UWP project containing the device’s app code is already ready and configured to run on an ARM processor, so you won’t have to do that yourself. What you will need to do is to configure the project to run on your own device. To do this, double-click the Properties node of your UWP project to open the Project Properties pane in Visual Studio.

Once it’s open select the Debug tab, and specify the IP address of your Raspberry Pi. This way, Visual Studio will know how to connect to your device when you want to deploy or debug live on the device. Make sure to select the Remote Machine option from the Target Device menu, and Universal (Unencrypted Protocol) from the Authentication mode menu.

Once I’ve got this set you can right-click the UWP project and select Deploy to push the code to my Raspberry Pi. The deployment process can take a few minutes, but once I’ve deployed the code the Visual Studio output window will inform me of the package name of the UWP app just deployed to the Raspberry Pi, as demonstrated in the screenshot below.

Using the Raspberry Pi’s browser-based App Manager, located at , I can select the newly-deployed app and click the Start button to start it.

Now, I can see my UWP app is indeed running on the device. If I want to turn it off, I can click the X in the right-most column next to the LeapDayTinkering.RaspberryPi app.

As soon as the app starts running it’ll appear on the monitor connected to the Raspberry Pi. Clicking the Start Sending toggle button enables the timer in the code, which results in messages being sent to the App Service every 20 seconds. To see the requests coming into the REST API, I can attach the remote debugger by using the Cloud Explorer window’s Attach Debugger command on the App Service node I just deployed.

By placing a breakpoint in the Web API controller code I’m able to see the messages arriving at my App Service as they’re sent up from the Raspberry Pi. The screenshot below shows a breakpoint active in a debugging session, with Visual Studio connected to my remote App Service live in Azure.

Summary and next steps

This post introduces the idea of using App Service as a back-end for your IoT projects, and the code provides you a great getting-started point for allowing your creativity to flourish. Grab the code, customize it, and feel free to submit branches or pull requests if you add to the sample. Some future ideas could include abstractions around storage layers, additional sensor functionality, or even sensor providers and extensions to the UWP app running on the Raspberry Pi.

Once your IoT projects evolve past the point of simple REST API access and you need serious telemetry or data-collection techniques, there are a multitude of options for IoT on Azure. The Azure IoT Developer Center has a wealth of information on all the options available like the recently-made IoT Hubs, which have recently become general available. Along with Event Hubs, Push Notification options, and Machine Learning to analyze the data your devices collect, there’s no limit to what you can do with embedded devices on Azure.