Today, I uploaded a project to github that I wrote in the last weeks in order to simplify things with the Azure IoT hub for demos, makers etc.
If you haven’t heard about Azure IoT hub, this is a very nice service you can use to hook up your IoT devices to a central service that you can use to receive data, send commands and, in general, manage your devices.
https://azure.microsoft.com/en-us/documentation/services/iot-hub/ is the official starting point for the documentation, but basically, the Azure IoT hub has a device and a service API. Through the device api, you can basically send messages to the cloud and receive messages from the cloud. The cool thing about this is that the device side only does outbound connections (e.g. this works through firewalls, through NAT devices such as DSL routers and even through IP connections provided by mobile phone providers. Read this again: Back channel to your device works through mobile phone network!
And the best thing: This service incudes a free tier that allows you to register 500 devices and send 8.000 Messages of 0.5k per day. See here https://azure.microsoft.com/en-us/pricing/details/iot-hub/ for details.
But in order to get to all this goodness, you need to manage the IOT hub via its service API. You can do that through the Device Explorer tool (see https://github.com/Azure/azure-iot-sdks/tree/master/tools/DeviceExplorer ) but that’s a manual process that involves creating devices on the hub and then copying the device connection strings manually into the device configuration. Or you can deal with the standard management API which is a bit tricky to use and actually would require you to keep the management keys where ever you would like to manage it.
Wouldn’t it be nice if the devices could actually manage themselves?
So I wrote a little API Proxy service that the device can query to get a connection string. The service just implements four calls.
GET /api/Device get just returns the list of devices configured in a JSON form
GET /api/Device/(id) returns the JSON just for this device
POST /api/Device/(id) creates a new device in the IOT hub and returns a JSON that includes a connection string
DELETE /api/Device/(id) deletes the device in the IOT hub.
In order to secure these, they all require an API key send in the query string.
The implementation I made is really simple and not very secure. But it can be used as a starting point to think about more complex authentication schemes, e.g. one could implement a one-time token mechanism that would only allow a single device registration for each token.
To try out the implementation, I added a swagger interface, so if you go to /swagger/ you can play around with the API yourself. You should disable that for production use.
The service can easily be run in an Azure Web App. And again, there is a free tier that is sufficient to run this service. See here https://azure.microsoft.com/en-us/pricing/details/app-service/ Azure app services also support SSL that you should use in order to protect your API key. (SSL is not supported for custom domains, in the free tier so your website will all end on “azurewebsites.net”)
To get started, clone the project from github https://github.com/holgerkenn/AzureIotHubProxy and then go to https://azure.microsoft.com/free/ to start a free trial on azure in case you don’t have a subscription yet. Through this link, you will also get some free credit to use the paid azure services for a limited time, but since everything presented here also works on the free tiers of the services, you can actually run all this even after the free trial credits expire.
Go to https://azure.microsoft.com/en-us/develop/iot/ to see how to create your first IoT hub, then get its connection string from the Azure Portal and add it to the web.config file in the repository. Then create a web app on Azure as explained here https://azure.microsoft.com/en-us/documentation/services/app-service/web/ and publish the service to this app. In Visual Studio, this is as simple as right-clicking the project, selecting publish and then “Microsoft Azure App Service”. This will then guide you to select or create a new Azure web app for your service. After the publish, your service should be up and running. And since the swagger api is enabled, you will find the trial api on “https://<yourservicename>.azurewebsites.net”
Then you can go and compile the test client. Enter the name of your web app in program.cs. When you run it, it will connect to the service, create a device named “1234567” and send a few messages to the IoT hub. If you have device explorer connected, you can receive those messages and send a few back.
And now you should probably change that default API key (“1234”) and republish.
Hope this helps,
H.