Full Hue Control Outside Of The Local Network

by dcinglis

As I mentioned in my last post, the Philips Hue system has the design limitation that it can only be controlled while connected to the same network as the bridge. Personally I turn off my phone’s wifi while on-the-go to save battery, and I don’t want to have to turn wifi on each time I come home just to control my lights. Or maybe I’ve just left the house and forgotten to turn the lights out, but am not quite in wifi range anymore to control them from my phone. Whatever the reason, there’s no point in saddling the Hue service with this network limitation when the technology exists for an easy fix.

My last project already demonstrates that it is possible to control the Hue from outside the local network. However, it was only performing two very specific actions with the bulbs: changing color to red/green and blinking the lights a few times. For this project I set out for full control of the lights: changing their color, brightness, and saturation, as well as being able to blink the lights or switch them to ‘gradient mode’, where the light slowly cycles through its color spectrum. This is pretty much the extent of the Hue API, and I wanted to control it all from one simple app.  

The architecture for this project is pretty much identical to the last project. The iOS app sends instructions to the Modulus Node server, which updates its Mongo database. Every few seconds, the local Node server, hosted on the same network as the bridge, pings the Modulus server, which queries the database and returns its contents. If the database has been updated since the local Node server last checked, it will parse those updated contents and send the appropriate update instructions to the Hue bridge. The Hue bridge then updates the lightbulbs. Here’s the architecture diagram:

The architecture diagram for the project.

As there wasn’t too much architectural innovation to figure out for this project, I decided to polish it a bit and streamline a few elements of the system. I stopped hosting the local Node server on my laptop, since I would have to restart the server each morning when i brought my laptop in. Instead, the server is now hosted on a BeagleBone Black, a pocket-sized microcomputer running the Angstrom Linux distribution. The BeagleBone is nice since it supports Node out of the box, but you could switch it out for a Raspberry Pi or Arduino and achieve the same result with a bit more legwork (node.js on Arduino likely requires a bit of hacking). To the BeagleBone I added a system daemon startup service that runs the service upon booting, which means the server can now run 24/7 with no human involvement.

The BeagleBone in action

In addition, I’ve added a security layer to the project so some random person reading over my code couldn’t just bombard my server with http requests and cause the lights to freak out. Now, each request is authenticated with the server before being processed. Right now I’m just using a simple app key to authenticate requests since the system is built for use on one single Hue bridge, but if I were to expand the server to support multiple users and multiple bridges I would likely use passport.js to authenticate multiple users.

One other thing of note is that I’m running both the Roll Call and Hue Controller apps in one single Node.js server hosted on Modulus. Because Node is non-blocking, the two programs can coexist side-by-side and the server can handle simultaneous calls to both processes without any problems. Of course, when multiple requests are being sent rapidly to the Hue bulbs they might appear to be acting strangely to the user, but if I were using separate bulbs for each project you would never know the two were sharing a server. 

To finish, here’s a screenshot of the app in action: