Posted December 26, 2015
http://www.microsofthelden.nl/2015/12/26/connecting-wipy-to-microsoft-azure-service-bus/
In the jungle of IoT devices, a new device, initially a Kickstarter project, caught my attention: the WiPy. Particularly because it can run programs written with MicroPython. There are many ways to play with your WiPy. Of coarse you can explore controlling GPIO pins or the I2C capabilities and other nice stuff. Currently my focus is on communicating with the outside world.
Architectural decisions
There are many ways to integrate your WiPy in a network. And although every project is different, a solution that probably fits many projects is to have your WiPy act as a dumb client of a (web) server. Most of the logic should be put on the server.
Even though this post is about the WiPy, the following considerations apply to many IoT devices.
Let’s start with the WiPy being a dumb client. It all has to do with updating. The more logic your WiPy contains, the more likely it is you need to update your WiPy. Moving that logic to the server, you probably would need to update your server more often. Most of the times, it is easier to update a centralized server farm, than possibly hundreds or thousands of devices. Yes, you can update your WiPy over the wire, but with large numbers of devices, some updates will fail.
Another reason is security. From a security point of view, it is better to have only outgoing traffic from the (local) network your WiPy connects to. You can run a web server on the WiPy. However, I don’t think the WiPy is designed to run a web server: you would not be taking advantage of the low energy consumption in stand-by modus or even better, in deep sleep, it would be easy to flood your WiPy with requests. And is that web server able to include proper security measures (taken in consideration the small – at least for a web server – application footprint), like full blown, proven web servers do? Most likely not.
Windows Azure
Now, lets make some decisions on the server part. If you want to expose an endpoint over the internet, you have to make sure only authorized clients can consume that endpoint, e.g. by an API key. Then you would need some kind of management to revoke an API key when it is compromised. When numbers are counting, geographic location, availability, scaling and cost might be relevant issues. I choose to go with an cloud platform I already know that comes with features to address (some of) the aforementioned issues: Microsoft Azure, specifically Event Hub of Azure Service Bus. Also check out Azure IoT suite (I have to…)!
A few of the reasons to choose Azure Service Bus include:
- Elastic capacity: scale regarding your needs
- Cost effective: pay per use
- Automated management using REST services
- Security (defining authorization tokens with read, write or full access, and the ability to withdraw them)
- Easily extendable to full fledged solution, including:
- Applying filters e.g. for alerting
- Connect to Azure Stream Analytics and Power BI for real-time data processing eg. for graphs / dashboarding
Configure Azure Service Bus
Azure Service Bus contains several features. The feature I will be using here is Event Hubs. You can read more on Event Hubs on the documentation page. Azure Service Bus is easily setup using the “old” azure portal. There are numerous good articles on creating new Event Hubs, for example Getting started Azure Service Bus Event Hubs: building a real-time log stream.
I created an Event Hub in Azure Service Bus called wipy.
Selecting ‘wipy’ will show the Event Hubs dashboard:
And then select Configure.
Configuring is easy. I set up a DataConsumer and DataProvider with according permissions.
The WiPy will be a DataProducer. To keep the primary and secondary key secret, the WiPy can’t use these to authenticate. So to let each WiPy authenticate with a unique credential, we have to generate a Shared Access Signature (SAS). The easiest way to do this, is using the Event Hubs Signature Generator (thanks to Sandrino Di Mattia) . You can read about it on IoT with Azure Service Bus Event Hubs: authenticating and sending from any type of device.
Having a SAS generated, we can head over to start programming the WiPy.
Let’s write some Python
Before trying to connect to Microsoft Azure, ensure:
- To familiarize yourself with the MicroPython forum;
- That the time is correctly set on the WiPy (needed for SSL certificate validation). One way to do it, is using a NTP server, see NTP library for WiPy;
- To connect your WiPy to a wifi network with internet access, also see MicroPython documentation on WLAN step by step.
- To validate the SSL server certificate, upload the root certificate (of the SSL certificate) to /flash/cert/ca.pem as DER encoded file. For Azure Service Bus the root certificate is Baltimore CyberTrust Root certificate, with thumbprint “d4 de 20 d0 5e 66 fc 53 fe 1a 50 88 2c 78 db 28 52 ca e4 74”;
- To use a recent firmware WiPy version with support for TLSv1;
From this point on, it is straightforward: just make your HTTP request. For simplicity, I will focus on constructing and sending an HTTP POST request, with an arbitrary payload.