Controlling Your IoT Home with Azure Functions Runtime

I have previously mentioned hacks to get Azure Functions running in your own lab:
(And I must stress the term "lab" as they have not really been at production level quality.)

As luck would have it Microsoft released a new preview of their "Azure Functions Runtime" a few days ago:

I tested preview 1 as well, but that was slightly shaky, so I'm taking another crack at it now. This feature is intended to solve the scenario with hosting your own Functions in a slightly more production grade way. (Still preview, so keep your expectations accordingly in check.) It is based on Docker containers below the hood; make sure that isn't an issue for your hardware, and then you can run your Functions locally to your heart's content. Another great thing for home use is that it doesn't require Windows Server, and will be equally happy running on a Windows 10 box.

In the latest Visual Studio updates there is also tooling for Functions, which obviously is a good thing, but this is not to be confused with the Azure Functions Runtime. The VS tooling is for developing Functions whereever they are running, and get the into source control, etc. The Runtime is specifically to run Functions in an environment you manage. (Without needing to go all-in with Azure Stack.)

What would be a good use case to test for this, and show why you wouldn't go cloud? After all I usually advocate putting things in the cloud if you don't have a good justification for doing otherwise 🙂

Like any self-respecting geek I checked out the Black Friday deals, and came across a Philips Hue lightstrip starter kit. (Yeah, I'm late to the smart bulb party.) The interesting part of the Hue package is of course that one can integrate through the API provided, and play around with the system that way. Sure, there's a ready made app as well, but who wants to run code they haven't written themselves 🙂

This is a fairly short and sweet Proof-of-Concept with three easy steps involved.

Hue setup
The procedure for getting started with the API is slightly convoluted on the auth-part, but fair enough. I refer you to the official pages for this one:

Ok, and in what way is this a candidate for Azure Functions Runtime? Well, the API is exposed over HTTP, and that is entirely ok. Slightly sketchy that the "authentication" is based on embedding a username in the uri though. Not to mention how consumer IoT gadgets fare when it comes to security (although I have no reason for suspecting Hue for being the worst in this department). In general you could say it works best when you are on the same network as the Hue Bridge. While you could argue that a single lightstrip isn't a hazard to put online I would rather keep it internal, and have some kind of proxy mechanism for reaching it.

I am aware of publishing through a reverse proxy, doing VPN, and all of that. I want something more lightweight though. I want to be able to publish a simple web page that I protect with Azure AD/B2C/ADFS/something OpenID Connect, and somehow have it trigger something in my home. Trigger you say? Hmmm… A trigger-based invocation of Azure Functions perhaps?

How about having a queue-triggered Function that will in turn do an HTTP-based call to the Hue Bridge? And now you can see how it makes sense having this running on a server in your own environment, and have the Function monitor a queue in Azure 🙂

While this Proof-of-Concept is intended for a small-scale setup at home you can employ the same pattern in other deployments as well mind you. Professional grade IoT equipment might support other protocols than HTTP, and even baked in support for IoT Edge ( Those scenarios require thinking about both the bigger picture, and more details than I´m considering here. In short; always try to understand the problem you are trying to solve.

Azure setup
First thing is to create an Azure Storage Queue. (Yes, this part can be hosted in the cloud since it doesn't talk to the Hue directly.)

Why Storage Queues, and not one of the other messaging solutions in Azure? I wanted something simple. I don't need to be able to ingest a million messages per second or anything advanced. It's also dead easy putting messages into the queue directly through the Azure Portal enabling you to test with a minimum of effort.

Function setup
The next part is to create the Function, and type in some code:

You'll notice that the Hue operates by having you do PUTs with some properties. (GETs are supported too, but like it should be that's for retrieving info, not applying configuration.) Apart from the Internet-unfriendly address to the Hue there's no difference between this experience and editing in the Azure Portal.

You will also probably not be impressed by the amount of verification and "proper" code I do here. Any message at all put onto the queue will trigger a call to this specific lightstrip. You probably want the option to switch it off as well, so a switch-case would be good for that.

End result - you have your IoT home accessible from the Internet, and you don't have to enable your lighs to be controlled by some script kiddie on the other side of the world to be able to have fun on your own 🙂

Comments (3)

  1. chilberto says:

    Good stuff Andreas! Thanks for putting together a use case as I was also trying to come up with a good scenario.

  2. Hi Andreas! We are currently working on a project wherein we are trying to establish a connection between Microsoft Azure and Philips Hue. As mentioned in your post, we are using a queue-triggered Function App. However, we didn’t understand how to in-turn do an HTTP-based call to the Hue Bridge. Could you kindly explain how this is done?
    Furthermore, once this setup is done, how do we operate Philips Hue by using PUT or GET through Azure?

    1. The call to the Hue Bridge is done in the Function App by using HttpClient (line 7-11 in my sample code). The queue trigger is just to “wake up” the Function and have it execute that call. As this sample is stripped down to the essentials it will just turn on one specific light, but you could easily expand the Function to cover more cases. (The “id” of the light is in the url, the IP address is to the Hue bridge.) The specifics of the PUTs you need to do should be documented in the Hue dev docs.

      As for how you expose this in Azure it depends on your use case. If it’s a web site I would have the backend put messages on the queue directly, but if you need an API I would probably expose it either through a Azure Function, or Azure API Management. API management is more capable, but also more complicated (and pricey). Either way they would translate incoming HTTP requests to a queue item on the backend. I don’t know if I would mirror the interface on the Hue, or if I’d do another layer with a slightly different design. (That is also dependent on the use case.)

Skip to main content