In this presentation, Chris Briggs will teach you how to jump head first into Windows Internet of Things (IoT) development by using the Universal Windows Platform (UWP), allowing developers to build one solution across Microsoft hardware platforms.
You will learn the basics of Windows Universal app development with a focus on building apps for devices running Windows 10 IoT Core, through to how to integrate the solution with Windows Azure.
You will see Chris build a simple Universal app, deploy it to Raspberry Pi 2, then expand upon the application to read input from sensors and finally establish communication with Azure. This will demonstrate how to take a simple “hello world” thing and make it a useful citizen of IoT.
Windows IoT development using Universal apps will make it obvious that there is no better time as a .Net developer to jump into IoT!
- DDD Melbourne
- Pasted : 08/08/2015 - Melbourne, Australia
Really excited to be presenting ‘Jumping into Windows Internet of Things development by using the Universal Windows Platform’ at @DDDmelb— Chris Briggs (@ChrisBriggsy) June 18, 2015
- Brisbane .Net User Group
- Pasted : 21/07/2015 - Brisbane, Australia
- Dev Superpowers Webinar Series
- Pasted : 25/06/2015 - SSW TV
So before we jump into this Dev Superpowers, I want to talk about my own experiences. I’m a day one adopter. As soon as that image came out, I downloaded it, put it on my Pi and start writing code and it’s a bit of a mixed bag. So on one hand, been able to write C# code and have it work is wonderful. Async awaits, garbage collection, all the nice things that we are used to as .Net Devs makes life so easy when you’re writing IoT but then there’d be other times when I’ve had Visual Studio crash or the Pi play up. See, there’s been a range of experiences. So why should you be interested in jumping into Windows IoT, simple, because when this works, when the universal windows platform works, it’s just magic. It all just falls into place so nicely. I still truly believe that this is a great place to start off, getting into IoT. You may need to wait a little bit of course until everything comes out of beta. So without further ado, let’s jump in.
Hi, my name is Chris Briggs and today we’ll be jumping into Window IoT using the universal Windows platform. So before we begin, let’s have a brief look at the agenda. So we’re going to start off by creating & deploying a simple universal app and then we’re going to learn and make the sensor sing and lastly, we’re going to learn to make the Pi dance with Azure.
So what is IoT Core? It is a special cut-down version of Windows that can be used on the range of IoT devices. Now, it’s not what we traditionally think of as a full operating system, rather we deploy universal applications to it and best of all, it’s free to maker community. This means any dev can sign up and get started.
There are many devices that run Windows IoT Core, here are some of the most popular, the Intel Galileo, a first in the line Arduino certified Development Board based on Intel’s x86 architecture and the other, one of my personal favourites the Raspberry Pi 2, a low-cost credit card sized computer which is six times more powerful than its predecessor. Now today, we’re going to be deploying onto a Raspberry Pi 2. So now let’s jump to the Visual Studio.
Let’s create a new universal app and we’re going to call it Superpowers IoT. So what is Windows universal platform? It provides one core API layout across devices which allows .Net Devs to write once and deploy to a number of different devices, this includes IoT devices such as the Pi and Galileo, desktop, mobile and eventually even the Xbox One.
So firstly, we’ll going to have a look at creating a simply universal Windows platform app. Now, because this talk is about IoT, let’s have one thing talk to another thing. So this app is going to go and get weather data on the existing weather API online. Now, a simple universal app like this could even be used as dashboard for your office. But what we’re going to see is at first, we’re going to build it like really any other universal app and it’s going to run across many devices without needing to change the code at all and then when they take this app and deploy it to my local machine and into the Raspberry Pi and see what the deployment experience is like.
Now, let’s create a quick but functional UI for this app. So hop in to switch the explorer, go into the mainpage.Xaml. Now, there’s two important things to check, the first is that it’s x86 and secondly, but this 5-inch phone we go down and select 10-inch IoT device. We’re going to need to zoom out a little bit. So a quick way or making a really functional UI is using a grid. So if we click here, when we see the outline, it will actually add all the boilerplate code to do the grid rows. So we’re going to modify this to create the grid we need. So I use this grid quite regularly when I’m going my IoT development. I always find six or so rows at 125 pixels high, normally it’s enough to hold all your information whilst still been really readable.
We need to add a few text blocks to finish our UI and a couple of those text blocks, we need to set names for so we can go in and change their values as we receive the updated values from the API. So we’ll start off by dragging a text block from the toolbox into the code. Now you can drag it onto the designer but it will generate a lot of property, you usually don’t want to. So come in here and go font size and we’ll set that to 32, we’re going to set the text to humidity. Now, we want to put it inside the grids, we have to set the row. Excellent.
Now that we’ve got one, we can copy and paste it and you just make the rest of it. So we’re going to copy, paste, and I see the word humidity just got bold, the reason is because there are now two text blocks sitting on top of each other. So let’s add the horizontal alignment to fix this. Now, this text block, we’re going to be updating the information we get from the API, so we have to give it a name, and so now that one row is done, we can just do copy and paste to make our second row.
So you’re going to see here, now we get a blue underline and the reason for this is that you can’t have duplicate names of elements in Xaml and you have to fix this straight away because this is actually going to break the Xaml designer.
So we just type temperature and we change the text and we noticed right now there’s a bit of a mishmash because they’re still in the same row, so we’re just going to drop it down the row and now that we’ve made these few small tweaks, we’re ready to go and flesh out the code behind this UI.
The way API were communicating with, will return its data in Json format, that means we need to go and Json.NET package to this universal app. So there’s no different to install package then you would normally do. Just click here, click install and we’re ready to go. Just click okay, and the package was downloading and install.
So that’s one of the really great things about universal application development is you get the leverage a wide range of NuGet packages. Now we have the Json.NET package. We’re going to need a model to deserialised our data to. So I’ve prepared one earlier and we have a look inside this main object and we find that’s where the API, we’ll put all the data that we want to get our hands on and want to display on the screen.
Now, let’s actually jump back to that file which is code behind the MainPage.Xaml. Now to save time, instead of typing the entire get data from the API using the Http client, I’m going to put a code sample and quickly explain it. So we’re going to just need to add the required namespaces.
So what this does is it goes off and makes a get request to the API, pulls it back and then we deserialize the object. Okay. We just had Visual Studio fall over, so we’re going to need to restart Visual Studio and have a look at where our progress is. So we’re just going to cancel this and let it restart. So the issue we’re going to run into is even though we can recover the selected files, we may not be at the same place we were before. So just wait a little bit. Okay, let’s have a look. We’re going to hop back in to our MainPage.cs. We’ll have a look. Yeah. Okay. So we’re going to see that that code we just wrote has disappeared because Visual Studio crashed. So luckily for us, it was a code sample, so we then go back into the toolbox and re-grab our sample out. And of course we’re going to now have re-add all the name and spaces that we just lost. So that does happen semi-regularly with the new Visual Studio. Okay. And one more name space.
So all the code does is go and make a REST call to the API and pull back the data. Once we get the data back, we’re going to use the Json.NET package to deserialize it into an object and we can then use and pull the data out of to display on the screen. Now I’m going to quickly create an update UI method.
Now we can use the tooling to quickly generate the method for us. Now, this method is going to need to be asynchronous and in it, we’re going to call get data and then we’re going to update those couple of text blocks. Okay, and it was Temperature.Text and that’s going to equal sampledata.main…Ahh were going to need to await this method, otherwise we’re going to get only back the IntelliSense for the task. So let’s await the get data and try again. So main.temperature and we’ll come down here, copy and paste, we need ToString this and we’ll come down here and go Humidity.Text equal sample.humidity.ToString, and that’s all there is to it. Now we’re ready to test this application locally and then on the Pi.
So we’re going to start debugging, our app pops up, also some app is running. Okay. “System.IO.FileNotFoundException”. Okay. This shouldn’t have happened but I know exactly what’s caused it. If we actually have a look in the output window, we see that the exception was found in the Newtonsoft.Json.dll. So the cause of this is actually like currently the latest pre-released version of Json.NET is actually not compatible with the Windows universal platform. So if we just hop into our NuGet references, we’re going to need to downgrade it back to the latest stable release. Downgrade to 6.0.8.
So now if we re-run the app again, they’ll pop right up and we’ll be able to see the data from the API. Awesome. We can see we’re now successfully making a get request, deserializing the object and writing it out to the screen.
So let’s try this now on the Pi. So now I’m going to stop this app from debugging and go have a look at our Pi. Now, via our Pi we can see that it’s IP address is 192.168.1.24 and it’s really important we take note of that. So we’re going to come back to Visual Studio, change our targeted platform to ARM and select remote machine. Now we’re going to enter that IP address into the boxes, and we’ll set the authentication mode to none. And you’re going to notice at the moment is actually we don’t find any connections on your subnet, just ignore this warning message and click select. Now, we’re going to click remote machine, it’ll start deploying. So it’s really important when you’re working with the Raspberry Pi especially, but you make sure you have that screen up because if you don’t, the device may not be ready to receive the connection and you’re going to have a few different errors occur.
Now there’s couple of ways dealing with them. The three common ways is either redeploying, logging in with PowerShell and restarting it or my personal favourite, power cycling the Pi. I find that that fixes currently most of the issues, you just turn it off, give it a minute plug it back in and then you’re ready to go again.
So isn’t that cool? We run an application in C#, we deploy it to our local machine and then without changing any code, we just retargeted it and deploy to the Pi. So as you can see, it’s really quick and easy to make a simple universal app that gets data from a web API. The range of possibilities is nearly limitless; you can do anything from a bug bash leader board to a table tennis scoring card updated by Twitter. But what if I want to know the temperature in this room instead of some random weather station?
We’re going to need something custom, we’re going to need a sensor, introducing the SparkFun Weather Shield. Now, this shield is a combination of many different sensors on one board which we communicate with via GPIO.
GPIO stands for the general purpose input output pins, they can either set or read a voltage and they allow the Pi to communicate over a wide-range of electronics. Now, while the pins are very useful, to be able to communicate with anything more complicated than a simple led, you’re going to need an interface. So what are interfaces? Well, they’re just simply predefined ways to communicate between electronic devices and the reasons we need them is because they greatly expand the IO capacities of the Pi. Most external devices you want to integrate would also require one because they simplify integration. Once you understand one type, it’s easy to implement other sensors of the same type and the common types are I²C, SPI and Serial.
So today, we’re going to be communicating with the SparkFun Weather Shield via I²C. Now, I²C a single master device, in this case the Pi, communicates with a range of slave devices via two-line data bus, one line is serial data and one line is serial clock. Now this two-line bus allows 120 devices to connect roughly. As can be seen in this image, you have your two-line bus for data and clock but you also still need to supply power from other GPIO pins in order to actually power the SparkFun Weather Shield.
Now that were back in Visual Studio. We’re going to add the required references to the get the SparkFun Weather Shield going. Right click, add reference, extensions, then we need to add the Windows IoT SDK. This allows us to use the GPIO pins and communicate via interfaces with hardware electronics. We also need to add a library that was created to make interfacing simple with a SparkFun Weather Shield. So we’re going to go add existing item, go to documents, GitHub SparkFun and add the CS file.
So we now have a poke around that C# file we added and have a look at it from high level of prospective. So with every sensor you buy common there is a data sheet, and in this data sheet, it would tell you important byte commands such as I²C addresses or the required read commands for different sensors. So you see, they’re pre-set as our constants. We look down and we that there’s initialisation method that’s going to take care of all the protocol communication for us. Effectively, once we call this and get the object back, the Extension SDK worries about all the slave-master relationship for us which simplifies development greatly. Now if we look at the humidity method, it’s going to write that command byte onto the sensor, read back the data and then validate it using a validation check. Once the data is validated, it will then be converted to the correct unit and passed back to us, the same thing for temperature.
Now, the validation check is really common on most good sensors. So in this case, it’s a CRC check. So very similar check to what’s used in zipped files is used to prove that the data we’re reading, those bytes, are the bytes that were be intended to be sent from the weather shield mathematically.
Now that we had it a poke around here, let’s jump back into the MainPage.cs. So now we’re going to update this file, so instead of it going and gaining data from API, it’s going to get data from the SparkFun Weather Shield. So first up, let’s declare our SparkFun Weather Shield. So let’s go up here and say using the SparkFun namespace. SparkFun, hop down here and say private SparkFun Weather Shield and then we’ll go shield equals new and then just SparkFun Weather Shield. And then I kind of update the UI, I’m going to change this get data instead to if(shield.Setup) and I’ll put these in brackets. So what we’re doing is once we await the setup, it will say, once the setup is completed and we’re sure it’s okay, then we’ll going to read the data because what can happen otherwise is that you’re going to try and read the data before you’ve properly initialised it and you’ll run to all sorts of problems. So let’s just quickly change these to shield.Temperature.ToString and this one to shield.Humidity.ToString. There we go. So first few small tweaks, now we can read from the SparkFun Weather Shield and we’re ready to deploy.
So now let’s deploy to the Pi. And as we can see, the Pi is now reading the data from the SparkFun Weather Shield, instead of going and getting the data from the cloud. So now we’re going to stop debugging and move on to the next stage.
We’re now able to read the local temperature here in my office which is useful if I want a local thermometer but let’s think bigger. What if I build 10, 20, 100 of these devices and deploy them all around the school or a factory? We could get each of these devices extend their data to the cloud so we could aggregate and gain more meaning. So next, let’s see how we can get this device to push its data to Azure via a web API.
Now the first step in getting this to become a useful thing in getting the data into Azure is we need to add a device ID. Now, when you’re starting off, I really recommend that this device ID Guid is randomise each time and regenerate it, that way it’s a lot easier to debug and find out if the data is correct. So I’m just going to add it now, Guid deviceID and go Guid.NewGuid. Now we’re going to jump over to the UI and make a quick change so we’re going to be able to see it. So you see when we’re actually targeting ARM, we can’t use the designer, so quickly I’m going to retarget to x86 and I’ll come down here, copy my temperature and I’ll make a new row. Okay. So we’ll set this to row 4. We set this to ID, DeviceID and then we scroll down, excellent. Just going to clear that. So now, we’re just going to make one more change and we’re ready to start implementing the rest.
Come over here and go. After we initialised the component, we’ll go DeviceID.Text. Now, this DeviceID is actually that textbook element equals deviceid.ToString which is the Guid we just created.
So as like before instead of writing out the laboriously the Http client, I’m going to pull in a code snippet. So what this method does is it’s going to go and make a REST call to our API and when you do this, you need to make sure that you create a key pairs for each value you want to send and make sure that the left most value, the key of the pair exactly matches what your API is expecting.
So I’m just going to add this method on to where we’re updating the UI, and now we’re ready to go. So I’m really excited to see this data in Azure, so let’s deploy. I’ve made a mistake and I’ve accidentally deployed to my own machine. This is something you really care for especially when you go and you change the UI, you’ve always got to retype it back. So while we’re getting System.IO.FileNotFoundException, it all comes down to the Catch22 of the Windows IoT extension SDK. Once we started using it, our app became a whole lots less universal, the reason for this is that all the code we’re calling needs to first find the GPIO controller and have a reference to it, otherwise it’s unable to operation and will throw exceptions.
So we’re just going to stop the app and we’ll target the correct platform this time. So we’re going to retarget. Promising signs, the Pi has come to life. Okay. We could see we’ve got the Guid but we don’t have the value. The code is broken again and if we have a look in the output window, invalid operation in System.Net.http. So our post call has failed. Awesome. So we’re going to try to fix that and I have a feeling it’s because I don’t have Http before I actually have the URL. So I’m just going to copy and paste that over.
Let’s give it a try and deploy again. Excellent. We see the correct values now on the screen. So we got to be really careful with the Http client, so make sure you always put the Http in before the web address and also whenever something breaks, quickly check your outputs cause there’s a lot of error messages that looked the same but whenever you look at, you can actually really clearly see what’s happening. So let’s have a look on the web API by using the Postman REST tester. We just going to send the get request, and there, we can see the exact same data that was on our Pi is in our web API.
So what we’ve achieve in this Dev SuperPowers, we learn how to create a simple Windows universal app, we’re able to deploy it to the Pi and to a normal computer without changing a single line of code, we will then able to interact the SparkFun Weather Shield and lastly push the data out to Azure. Thank you for watching and feel free to tweet me any comments, feedback or questions to @ChrisBriggsy.