Well Tap – Physical Computing Final

In ITP, Physical Computing

For my Physical Computing final, I created Well Tap—a network of wireless sensors that quantifies peoples’ water usage, and in turn, encourages those people to be more mindful about their water consumption at home.

Well Tap is a combination of my Computation Media and Physical Computing Final Projects. As this post will focus mainly on the physical computing side of things, you can visit Well Tap Dashboard – ICM Final for more details on the computational aspects of the project.



WHY Well Tap?

Water waste is a big problem but it’s a hard one to wrap your head around for those that don’t live in affected areas. It’s very hard to know what your actual footprint is and that actually creates a lack of accountably to oneself and the greater community. By providing people with clear data on their daily and weekly usage, and comparing that data to average numbers for the various household sizes, users will immediately get some context on their water usage. The goal is not to make anyone feel bad by pointing fingers, but simply to make people more conscious as I believe we are inherently good. I hope something like Well Tap could influence people to make small efforts, and in turn, create systemic change.


The Principal Physical Interactions

While the dashboard I made in Processing is a nice compliment to the system of networked sensors, and allows people to track their usage on an ongoing basis, the more important interaction happens when the person is using water. The objective of Well Tap is to help people make small efforts to reduce their water consumption, and you need to reach them during the actual act of using water to have any potential impact on them. Therefore, I decided that my main levers of influence would be two different forms of feedback from the console. The fist one is a light that turns on when water starts running through the sensor to remind the person that their water usage is being recorded and that they should be conscious of how much they use. The second is an LCD screen that tells them how much water they’ve used each time to start giving the person some reference as to how much water is used for various tasks. This could help people realize how much water they use unnecessarily for certain things.


Now that I’ve highlighted the two main desired touch points with my users, I’m going to bring you through how I executed them and the challenges that I faced in trying to do so.


Well Tap Sensor Production and code

For a look at the early stages of production, please refer to Progress Report 11.11 – Well Tap. In that post, I had already hooked up the LCD and flow meter sensor, however, still had not refined to Arduino code to output data in the way I wanted. As a first step, I wanted to have the LCD display the values of each individual use and then reset to the value of liters consumed to 0 after 3 seconds. It required a little work as the default behavior of the sensor was simply to output the sum of all the water you’ve used while the Arduino was running. This logic is what brought about one of the trickier challenges I faced with the code. First, I needed to be able to determine when the sensor was actually reading values (i.e. water was running or not) and then I needed to trigger a timer once I determined water was no longer flowing to eventually reset the liter value on the LCD to zero.


How To Gauge Whether The Sensor is Reading?

Here is the code below that allowed me to determine whether the sensor was actively reading water or not. The reference to “Pulses” has to do with how the sensor passed data back to the Arduino. Using a bit of math provided by the flow sensor library, I was able to determine the volume of water flowing through based on how many pulses the sensor passed back to the Arduino within a certain amount of time.

In order to see whether the sensor was actively reading or not, I created an extra variable (lastPulse), which I could compare to the already existing variable pulses. The pulses variable would continually increment every time you put water through the sensor, so I just needed to figured out when there was a discrepancy between the current pulses and the last pulse to see if the sensor was actively reading or not. I essentially used the time it took my program to go from the bottom line of the function back to the top to measure if there was any variance between the two variables. If lastPulse equaled pulses, then there clearly was not any water going through, however, if there was any difference, then that meant that water was running.



This was super important as it allowed me to determine when to turn on the feedback LED and when to engage my timer.

More on the Timer

I’ve used timers before but only at the start of programs, where they continually measure increments of time in perpetuity. I had never used a timer that was set off by some trigger event. As a result, I struggled to get this working for some time but finally found a solution using the toggle switches, which you can see first appear in the conditional statement form the section above. The toggle switches allowed me to say that I wanted to start the timer only when the faucet turned off the water after having used water. Above, I initially increment the toggle variable from 0 to 1 when water starts running, and then I increment toggle to 2 when the water stops running (flow=false)and toggle equals 1. This allows me to tell the difference between the “false” flow state when the system is simply idle waiting for people to use the faucet, and when the system is in the false flow state immediately following water use.


Once I determine that water stopped running following a use, I set previousMillis to currentMillis, which allows me to start the timer and execute specific tasks once the difference between previousMillis and currentMillis is greater than the interval I’ve set (in this case 3 seconds). These tasks include:


  • setting previousPulseRead equal to pulses (this resets the liters value on the LCD to zero as I am calculating the value based on the difference between the two variables. This is how I get the value for the individual session vs. the total sum.
  • reset toggle to zero to allow the logic I created to be valid for the next use.
  • Lastly, send the values for each use to dweet.io so I can eventually parse them in Processing. (You can refer to the attached code below to see how I do that.)

These tasks that are being executed illustrate how essential the timer is to some of the program’s core functionality.


Entire Code

I’ve uploaded the code to Github for both the Arduino Uno and Arduino Micro.



I went through several circuit iterations for the Well Tap system but I’ve posted the two main ones I put together for the Arduino Uno and Arduino Micro. I initially tested the circuit using the Uno and then adapted the code and circuit to the Micro for the prototype I submitted.


Arduino UNO



Well Tap Schematic_bb


Arduino Micro




Well Tap Schematic - micro_bb



Submit a comment