WiFi Connected Temperature and Humidity Sensor

This project was our final assignment; an environmental sensor capable of sending data over https to Tom Igoe’s sever. I attempted this project with two different kinds of sensors on a Raspberry Pi Zero W. My first attempt was with the Pimoroni Enviro sensor hat, which required programming in Python, and communicated over the i2c protocol. My second, successful attempt was using a DHT-11 temperature and humidity sensor, with a built-in pull-up resistor, which required programming in Node.js, and communicated over the 1-wire protocol.

I set up my raspberry pi using Tom’s guide.

Attempt 1 – Pimoroni Enviro Hat

The Pimoroni Eniviro Hat came with its own GitHub code, including scripts to run its various sensors. I tried cloning this repository twice, and as I rebooted my pi, my pi crashed both times. I believed my SD card was corrupted both times, and reset my SD card completely both times. Before trying the third time, I backed up a copy of wifi-accessible, set up SD card on my computer.

The third time I cloned the repository, my pi seemed to crash on the reboot again. However, I decided to try to ssh into my pi and it turned out that the files, cloned repository and all, were not corrupted. I tried to run the various pre-programmed files that were supposed to get my sensors to run. The only file that worked was the screen file.

After some unhelpful feedback from the Pimoroni manufacturers, I discovered that my pi was not reading the hat’s sensors over the i2c protocol.

The bottom portion of this code indicates that my pi did not recognize any of the sensor’s pins

After talking to Tito, we figured that the issue was a higher-level computer engineering issue, related to the types of pre-programmed communication protocols my respective hat and pi had. Unsure of how to proceed from here, I decided to go the easier route and use the Node.js based DHT-11 sensor, that my classmate, Cy Kim, was using.

Attempt 2 – DHT-11 Sensor

I. Hardware fallout from enviro

I adapted the code that I used from Tom’s Github repository and the repository for my device. However, I could not return a reading from my sensor.

I took the following steps to debug my circuit:

1. I unit tested my sensor, this gave me back values of 0 for humidity and temperature
2. I checked whether or not I was receiving integer values using a format similar to the temp-humidity-client.js from Tom’s code
3. Tried test examples from my sensor’s repo which do not provide any insight or solutions
4. Used a multimeter (which indicated that my sensor was fine)
5. Swapped out my wires and breadboards

To no avail, frustrated and defeated, I took a break, and when I returned I:

6. Wiped my pi clean of all code, Raspian Lite and all
7. Rewrote and re-downloaded all of the code from scratch
8. In the process, I fried my zero w and switched to my non-wifi zero just to see if I could get a sensor value

I should note that at this step I believe I fried my sensor as well

9. Switched my sensor with Jason Tse
10. Switched my code with Jason Tse

Again, to no avail.

The following day, I arrived with a new sensor and new Raspberry Pi and was almost immediately able to get sensor readings.

II. Functional, but too “chatty”

Once I got my sensors reading, I combined the sensor reading file with a file that was set up to send HTTPS put request strings to Tom’s server.  After sending a get request to make sure that I had sent data to Tom’s server, I attached a SSD1306 display screen and adapted Tom’s code from his pi recipes to get the whole circuit to work.

Then came cron. I spent about an hour trying to figure out why cron would not work – it turns out that I put the wrong path to the file I wanted to run with cron. I then realized that I didn’t want to run my https transmission function with the same frequency as my screen display function, so I separated the two into separate files. I set the screen file to turn on as the device was powered (@reboot) and for my send function to run every 5 minutes (*/5 * * * *). I forgot to check if the latter function was operating at the speed I wanted it to function at, and as a result, accidentally spammed Tom’s server with upwards of 30,000 sensor readings. I’m still unsure why my 5 minute cron function was overridden by the readInterval function that I had written in my function sending code. I am also unsure if I should have written my cron script in the regular cron or sudo cron file, so I wrote my script in both for posterity.

After all of this, I had a device that would display humidity and temperature, and send readings every 15 minutes.

III. Self-Sabotaged in the Finishing Stretch?

I ended up trying to get my network SSID and IP represented on my pi’s screen. My screen transmitted that information, but would only do so by flashing for every update, which I programmed to occur each second.

In trying to debug this, I ended up only being able to get my screen to run when I ran it through ssh. This led me to believe that I was running into transmission speed issues more complicated than I anticipated.

I will consult with Tom Igoe and update my blog to reflect future directions.


  1. In my transmission code, I accidentally changed my set interval to once a second
  2. I did not realize that cron jobs “overlap” – essentially when I ask to run 1 time, the script I want to run will actually run 1 x the interval I set for it to run, each time I asked for it to run.

Finished Product

Here is a final video of my sensor when it was working, a photo of my sensor when it was working, and a link to my GitHub repository for this project.

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.