Today's Hardware Friday post comes to us via MSDN Magazine and is an "internet of things" kind of project, meshing Azure with a smart thermostat (making it Smart++?
Here’s a bold prediction: Connected devices are going to be big business, and understanding these devices will be really important for developers not too far down the road. “Obviously,” you say. But I don’t mean the devices on which you might read this article. I mean the ones that will keep you cool this summer, that help you wash your clothes and dishes, that brew your morning coffee or put together other devices on a factory floor.
In the June issue of MSDN Magazine (msdn.microsoft.com/magazine/jj133825), I explained a set of considerations and outlined an architecture for how to manage event and command flows from and to embedded (and mobile) devices using Windows Azure Service Bus. In this article, I’ll take things a step further and look at code that creates and secures those event and command flows. And because a real understanding of embedded devices does require looking at one, I’ll build one and then wire it up to Windows Azure Service Bus so it can send events related to its current state and be remotely controlled by messages via the Windows Azure cloud.
Until just a few years ago, building a small device with a power supply, a microcontroller, and a set of sensors required quite a bit of skill in electronics hardware design as well as in putting it all together, not to mention good command of the soldering iron. I’ll happily admit that I’ve personally been fairly challenged in the hardware department—so much so that a friend of mine once declared if the world were attacked by alien robots he’d send me to the frontline and my mere presence would cause the assault to collapse in a grand firework of electrical shorts. But due to the rise of prototyping platforms such as Arduino/Netduino or .NET Gadgeteer, even folks who might do harm to man and machine swinging a soldering iron can now put together a fully functional small device, leveraging existing programming skills.
To stick with the scenario established in the last issue, I’ll build an “air conditioner” in the form of a thermostat-controlled fan, where the fan is the least interesting part from a wiring perspective. The components for the project are based on the .NET Gadgeteer model, involving a mainboard with a microcontroller, memory and a variety of pluggable modules. The mainboard for the project is a GHI Electronics FEZ Spider board with the following extension modules:
- From GHI Electronics
- Ethernet J11D Module to provide wired networking (a Wi-Fi module exists)
- USB Client DP Module as power supply and USB port for deployment
- Joystick for direct control of the device
- From Seeed Studio
- Temperature and humidity sensor
- Relays to switch the fan on or off
- OLED display to show the current status
Together, these parts cost around $230. That’s obviously more than soldering equivalent components onto a board, but did I mention that would require soldering? Also, this is a market that’s just starting to get going, so expect prices to go down as the base broadens.
Implementing local thermostat functionality for this sample is pretty straightforward. I’ll check temperature and humidity on a schedule using the sensor and switch the fan connected via one of the relay ports off or on when the temperature drops below or rises above a certain threshold. The current status is displayed on the OLED screen and the joystick allows adjusting the target temperature manually.
In the beginning, the device is in “factory new” state—the device code has been deployed but the device hasn’t yet been initialized and therefore doesn’t have any current settings. You can see this state reflected in the GetSettings method when the settings object is still null and is therefore initialized with default settings.
Because I want to let the device communicate with and through an Internet infrastructure—Windows Azure Service Bus—I need to equip the device with a set of credentials to talk to that infrastructure and also tell it which resources to talk to. That first step of setting up a factory new device with the required network configuration and setting up the matching resources on the server side is known as provisioning; I discussed the basic architectural model for it in the previous article.
Sending Events and Receiving Commands
With provisioning completed, the device is now ready to send events to the Windows Azure Service Bus events Topic and to receive commands from its subscription to the devices Topic. But before I go there, I have to discuss a sensitive issue: security.
As I mentioned earlier, SSL/TLS is an expensive protocol suite for small devices. That is to say, some devices won’t ever be able to support SSL/TLS, or they might support it only in a limited fashion because of compute capacity or memory constraints. As a matter of fact, though at the time of this writing the GHI Electronics FEZ Spider mainboard based on the .NET Micro Framework 4.1 I’m using here can nominally speak SSL/TLS and therefore HTTPS, its SSL/TLS firmware apparently can’t deal with the certificate chain presented to it by Windows Azure Service Bus or the Access Control service. As the firmware for these devices gets updated to the new 4.2 version of the .NET Micro Framework, these limitations will go away for this particular device, but the issue that some devices are simply too constrained to deal with SSL/TLS remains true in principle, and there’s active discussion in the embedded device community on appropriate protocol choices that aren’t quite as heavyweight.
The goal of this series on the Internet of Things is to provide some insight into the kinds of technologies we’re working on here at Microsoft to enable connected-device prototyping and development. We also want to show how cloud technologies such as Windows Azure Service Bus and analytics technologies such as StreamInsight can help you manage the data flow from and to connected devices; how you can create large-scale cloud architectures for handling a great many devices; and how to aggregate and digest information from them.
On the way, I built an embedded device that you can place on any home network and control remotely from any other network, which is pretty cool if you ask me.
I believe we’re in the very early stages of this journey. In talking to Microsoft customers from all over, I’ve seen that a huge wave of connected and custom-built devices is on the way, and this is a great opportunity for .NET developers and innovative companies looking to build cloud offerings to connect to these devices and to combine them with other connected assets in inventive ways. Let’s see what you can do.
As you would expect, the source for the project is available here. Here's a snap of the Solution.
What's the story behind all these Projects? RTFR (Reading The Fine Readme
The solution contains several directories and sub-projects:
/AzureBackend – This is the Windows Azure deployment project for the cloud backend service.
/BackendRoleTest – This is a very simple one-shot command line test to talk to the provisioning endpoint, configured to talk to the local dev-fabric.
/BackendWebRole – This is the backend web role hosting the Provisioning.svc endpoint as well as the Passthrough.svc custom-gateway endpoint implementing a simple hash-based model as a replacement for SSL to be used alternatively to talking directly to Service Bus.
In the web.config file you will find the following <appSettings>
* sharedSignature – replace the value with a base64 encoded 256-bt (16 byte) random binary key or with the same value as ‘managementKey’ below. This is the shared signing key used for the non-SSL scenario.
* serviceBusNamespace – replace the value with the name of a Service Bus namespace you provisioned. Just use the prefix (i.e. myownnamespace) and not the .servicebus.windows.net suffix. As you create the namespace in the Windows Azure Portal, you should create two Topics, named ‘devices’ and ‘events in that namespace.
* managementKey – replace the value with the ‘owner’ key of the Service Bus namespace, which you can also obtain from the portal.
/Microsoft.ServiceBus.AccessControlExtensions – This is a set of utility classes for managing Service Bus Access Control taken from the Windows Azure Service Bus SDK ‘Authorization’ scenario sample
/Microsoft.ServiceBus.Micro – This is a .NET Micro Framework client for Service Bus implementing Send and Receive operations and token acquisition from ACS over HTTPS and the alternative non-SSL model that’s using the Passthrough.svc gateway included in this sample. It also includes a SHA-256 implementation by Elze Kool (http://www.microframework.nl/2009/09/05/shahmac-digest-class/) and an NTP client written by Michael Schwarz from https://mschwarztoolkit.svn.codeplex.com/ which is included under its own license as expressed in the file.
/ServiceBusApp – is the actual Air Conditioner code for .NET Gadgeteer requitring the setup explained in the article. The ‘serverAddress’ in Program.cs must be set to the deployment location of the backend web role. This application will only function when run on the actual hardware.
/ServiceBusMicroTest – is small test app to run in the .NET Micro Framework emulator to call the provisioning logic and send/receive messages.
Also in the readme are additional URL's if you don't have the .NET Gadgeteer SDK installed or need an Azure account.
If you're been wondering what it would take to create a "smart, internet of things" kind of device, are interested in see how a .NET Gadgeteer can talk to Azure, or interested in building interconnected devices and service using the power of the Service Bus, this article and source is just a quick click away...