Roll Call v2: Adding Philips Hue Lights

by dcinglis

This next project incorporates Philips Hue smart lightbulbs into my previous Roll Call project. The bulbs are set up in a row with nametags on them for the members of our office. Now, when a user enters or exits the building, their corresponding lightbulb will blink for a few seconds and change color (green for entering, red for exiting). So instead of having to open a website to check who is in the building, I can simply glance at the panel of lightbulbs. In addition, the blinking is an attention-grabbing way to notify me whenever someone enters or exits the building. Here is what the setup looks like:

Normally the lights would be red or green for each user, I turned them off for this picture since the lights were washing out everything.

Now to explain the technology that makes this possible. The Philips Hue lights communicate through Zigbee, a low-power radio transmission protocol. The lights are controlled through a central hub called the bridge, which plugs directly into a wireless router. Zigbee is a mesh network, so any signal transmitted by the bridge spreads through the lightbulb network until it reaches its target. Thus, bulbs can receive signals from the bridge even if they aren’t directly in range with it. Hue users can talk to the bridge through mobile or web apps.

Philips provides a fully-featured API for controlling the lighbulbs through the bridge, allowing you to manipulate the color, brightness, and saturation of individual lightbulbs, as well as supporting special events like color gradients or light blinking. While this API is powerful, it has the downside of requiring any application utilizing it to be on the same network as the bridge. When I started this project, I wanted to communicate directly from my Modulus-hosted Node server to the bridge, but because of the Hue architecture this isn’t possible. As an added challenge, I was working on this project at the Progress office, which has a private enterprise network with a firewall that blocks TCP connections, preventing the bridge from being controlled through external Hue servers (another feature of the product).

Thus, if I wanted to manipulate the lights from outside the network, I would need some sort of go-between that resided within the network in order to talk to the bulbs, but was also capable of spanning the firewall to communicate with external servers. I decided to use a locally-hosted instance of Node to bridge this gap. This is able to reach beyond the firewall as it relies on HTTP requests, which the firewall allows. With this decision in place, the architecture for our project looks like this:

The architecture diagram for the project.

Let’s dissect this a bit. When the user walks into the building, the iPhone in their pocket detects the Bluetooth signals transmitted from the Gimbal beacons positioned around the office. This triggers the phone to open the Beacon Receiver app in the background, which sends a POST request to the Modulus server with updated position/time data for the user. The Modulus server stores this information in a Mongo database.

While this is going on, the locally hosted Node server has been sending a GET request to the Modulus server every few seconds, asking for user location data. Each time this occurs, the Modulus server queries the database and responds to the GET request with this data. (I use the Cron package in Node to perform this repeated action). Since the database has been updated, the local server is now receiving information that differs from its local data. The server has to correct for this difference by updating the light in the Hue network corresponding to this user. It sends a PUT request to the bridge telling it to update the color and blink for a few seconds (I couldn’t do this from the Modulus server since it’s not on the same network as the bridge, hence the need for a local server). Once the bridge receives this information, it sends it back out to the Zigbee network, where it eventually reaches the lightbulb and causes its color to change.

Sounds complicated, doesn’t it? Surprisingly, the whole process only takes a few seconds. The limiting factor is how often you set the local Node server to ping the Modulus server. I’ve set the local server to ping the Modulus server every second, so it takes about a second for the lightbulbs to change. But if I pinged more frequently the response time would shrink accordingly.

I can definitely see the market for a set of lightbulbs that can easily be controlled through HTTP requests. At the scale of my project, I could’ve achieved the same result with an Arduino and a set of LEDs, but in a real household the Philips bulbs look much more presentable and their API packs a good deal of power. I was a little frustrated that I couldn’t control the bulbs from outside the network, as it seems like this should be possible with the current hardware setup given that the bridge plugs into the router itself. I get the sense that the Hue just “isn’t quite there” yet, but it certainly provides a taste of what is to come in the home automation industry. I’m looking forward to doing more projects like these as the technology gets more powerful and streamlined.

Bonus low-quality GIF of the project in action, Eduardo’s light is blinking red indicating that he has just left the building: