Building a Philips Hue Bulb Controller

For this assignment, we were tasked with building an Arduino-based device capable of connecting to and manipulating a Philips Hue Bulb via its Zigbee radio control hub. This assignment was our class’ foray into HTTP protocols – the week prior, we had completed this assignment in the command line of our computers.

I intended for my device to have 4 features – an on/off button, and three sensors which could control the hue, saturation, and brightness values of the bulb respectively. Initially, I intended on using three rotary encoders to manipulate these values, but I ended up using three potentiometers as I discovered that my rotary encoders were broken. Unfortunately, I documented poorly for this assignment, but I will do my best to communicate the two biggest problems I ran into in trying to complete this assignment:

  1. Putting the Cart Before the Horse in Wiring

Once I developed what I believed to be functional code based on an amalgamation of Tom Igoe’s Hue Control examples, I soldered my rotary encoders and wired them to my breadboard with my prototype on/off button. This was a mistake because in testing the inevitable bugs that ensued from my untested code, I was unable to discern which issue to solve first: the noise from my rotary encoders that made their values useless or my inability to send any HTTP put requests to the hue hub.

I ended up deconstructing my circuit and adapting my code to a switch to test if my put request code worked – first by turning the bulb on and off, then by having the bulb change between two colors in response to my switch being flipped. After realizing that it did, I scrapped the idea of working with my (poorly soldered) rotary encoders and decided to switch to working with a potentiometer. Before continuing, I wrote code that tested if I could manipulate the hue bulb’s brightness characteristics with one potentiometer, tested it, and made sure it worked.

2. Integrating Multiple Sensors Poorly

I spent the brunt of my time trying to integrate my on/off switch, and my potentiometers as separately read entities in the concatenated string HTTP put request that determines the condition of the hue bulb.

Test of one potentiometer for brightness, one on/off button prototype

First, I realized that my switch code was providing too much feedback, or “pinging” the hue hub too frequently, particularly in conjunction with the strings coming from my one potentiometer. I ended up changing the code and hardware to that of an “on/off” push button.

Second, in including two other variable changing potentiometers I somehow disrupted my code in a way that represented the potentiometers’ values in Arduino’s console log but did not put request their values to the hue hub – I have left the code that I used to confirm that my potentiometer values were sent in my final code file.

Had I pre-written conditions within each loop that debounced the put requests from the respective sensors I would have saved myself a lot of time in the integration of my sensor code into one file.

I still have not understood what aspects of my code have prevented me from cleanly and consistently manipulating different hue variables with all of my potentiometers. I will meet with Tom Igoe and update my blog to reflect this understanding.

What I’d Want to Do Moving Forward With This Project:

I would like to implement the following:

  1. Make the LED in my on/off push button work to represent if the bulb I’ve connected to is on or off- I ran out of time and could not figure out how to write the code that would accomplish this.
  2. Add a feedback screen – though I would not have had time to add it to this project while I was working on it, I had ordered one and it came too late for me to even attempt to integrate.
  3. Try and make my hue-bulb connection feedback faster, and more consistent. Even though I included debounce code in Millis, and took out much of the delays in my code my device had a noticeably slow “influence” on the bulb, I believe in part because I was still overwhelming the hue hub with my put requests.

Final Product:

Circuit Diagram

Ball Drop Game Client

For this assignment, our class was tasked with creating a device that could connect to a server via a TCP network socket in order to play a “ball drop game”. Our device needed to be able to indicate when it was connected to the server, to move a platform character within the game, and to connect to the server with a button press. After registering my Arduino nano’s MAC address with NYU’s Wifi Network, I started building the hardware for my device with a simple four-button layout, to ensure that I could transmit the messages necessary to interact with the game platform/character.

Four-button controller

I struggled most with troubleshooting this step – I discovered that the breadboard I had been working with was partially broken and that my Arduino was broken and could not use its built-in wifi capabilities. I ended up using a new smaller breadboard, a new Arduino nano and connected my directional buttons via a PCB board.

The separate soldered 4-button PCB board

From there, I adapted an example code provided by Tom Igoe to use a push-button with a built-in LED to fulfill my network connection button, and network connection indicator requirement. This code also required me to integrate my 4 button controls (instead of Tom’s joystick code) and the WIFININA Arduino library to Arduino Nanos (the original code was intended for a different type of Arduino). Once my circuit and code were sufficiently debugged, I was able to play the ball drop game, and I moved on to fabrication. I tried two iterations of my controller enclosure with two kinds of cardboard.

My final circuit diagram, system diagram, and final product images can be found below:

System Diagram
Circuit Diagram

Below is a video of my controller in action:

I have linked my code in a GitHub repository, note that for security purposes I have not included the file with my network name and password, and the IP address written into the code will vary.