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:
- 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.
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:
- 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.
- 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.
- 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.