Editor’s note: Our team participated in many of the Summer of Innovation events held by Laurie (@lsptahoe) and her team. Here’s Part 1 of Mark’s (@mvilrokx) project from the IoT Hackathon held at Oracle HQ, July 30-31. Enjoy.
Last week I participated in the IoT Hackathon at HQ which is part of “The Summer of Innovation,” a series of events that Laurie Pattison’s team is organizing to stimulate ideas and creative thinking.
Unfortunately our entry didn’t win any prizes but of course that wasn’t the reason I entered (no really, it wasn’t!) I am trying to learn more about the Internet of Things and what better way to improve my skills then to test them against my peers. In this post I’ll delve into what I learned and how I am planning to us this knowledge going forward.
A few weeks before the Hackathon, I was approached by Diane Boross with an idea for the Hackathon which intrigued me because it was simple, but could have far reaching consequences. California is suffering it’s worst drought in over a century and we are all asked to reduce our water usage by an average of 20% over previous years.
The problem is that, as a consumer, be that an individual or a company, you have no clue how much water each individual appliance is using; you only know the total amount of water your house or company is consuming. So how can you know what to use less, or turn of completely, in order to save 20%?
The answer is you can’t, it’s a process of trail and error. Oh sure, there are lots of tips and suggestions from the state and the water utility companies, but those are very generic and not at all tailored to individual situations.
A very concrete example: I stopped watering my lawn a few months ago and it is now very dead indeed, however, this turned out to be nowhere near enough to save 20% as I thought it would be, in fact it barely made a dent (I have a very small lawn), it’s quite possible I let it die for no good reason.
Image from Kevin Cortopassi from flickr used under CC.
And now, I have to figure out where else to save water and I don’t know where to start.
Diane’s idea was to create a device that can measure the water usage of each individual appliance, something you can already do for electricity usage, but for some reason not for water.
It would be a smart device that connects to the internet and transmits this data in real time to a central hub that would collect this data and present it in a user friendly manner to the consumer. This would allow that person to then make much more informed decisions about how to save water.
Once you have this data, you can conjure up many other use cases, e.g. you could pit individuals or even whole neighborhoods against each other in a friendly competition of “Who can save the most water in August?”
You could also give much more tailored advice to consumers, e.g. if their lawn watering system is using 50% of their overall water usage you can tell them to turn it a bit lower, preserving the lawn but still saving a bunch of water. Or in my case they could have told me not to even bother and instead shorten my shower routine.
Unusual high water usage of an individual appliance, e.g. due to a leak, would also be much easier to detect, instead of being drowned in the noise – pardon the pun.
You could create a waterbudget per device and provide a feedback mechanism at that device that in real time can tell you where you are in relationship to your budget. As you can see, once you have this data at your disposal, the possibilities are endless.
My initial thought was to use a Water Flow meter to measure the flow through the pipe, connect it to a Raspberry Pi which would in turn connect to the Internet and send the data to a backend server for processing and eventually a database for storage.
The problem with that solution however was that it required plumbing; each device would have to be installed by a plumber, inline with the water pipe that runs to the appliance you want to measure the flow of. I consulted with Joe Goldberg in the next door office who agreed that this would never scale and he proposed instead to “listen” for water running through the pipe using a simple and very cheap piezo.
A piezo measures vibrations, kinda like a microphone, and since water that runs through a pipe causes that pipe to vibrate, putting a piezo on that pipe should, in theory, allow us to not only verify that water is flowing through the pipe, but also how much water is flowing through it.
The latter turned out to be a bit harder than we theorized and was the subject of many experiments over the course of a few weeks leading up to the Hackathon. For his efforts, Joe was recruited by our team which by now consisted of Diane, Joe and myself.
During these experiment, we tried to correlate the vibrations of the piezo with the actual flow rate through the pipe, which we were measuring precisely using a flow meter, using some regression analysis.
Once we would establish this correlation, we could then use that as a model to extrapolate flow rates using just a piezo stuck to a pipe, no plumbing needed. We assumed that we probably would need several models for different environmental circumstances, like e.g. the type of pipe that was used, how long the pipe is etc., but for the Hackathon obviously proving the concept would be enough.
Unfortunately we never found a significant correlation using the cheap piezos, all we were able to do was determine that water was running through the pipe, or not, i.e. whether the device was on or off. It turns out that in practice, in most cases, this can actually be used to measure flow rate as well.
Most appliances that use water either use it all (on) or none (off). Think about it, when you flush your toilet, it fills up again as quickly as it can, basically at the maximum flow capacity the pipe can handle. The same is true for a dishwasher, a washing machine and even most showers. I cannot turn down my shower, it always flows at the same rate, all I can control is the temperature.
The only exception to this rule is a tap where you can manually control the flow. Considering this and our failure to establish a good model, we fell back on assuming that if we measure vibrations, the device is using the maximum amount of water that can flow through a 1/2 inch pipe, which was about 23 liters per minute (or for the decimally challenged, about 6 gallons per minute).
We would simply measure the duration the appliance is “on” and then calculate the actual flow, e.g. if the appliance would be on for a minute, we would calculate that it used 23 liters.
We then had to figure out how to connect the piezo to the internet. Initially I was thinking of using the provided Raspberry Pi’s, but in the margin of the Scavenger Hunt that we ran for KScope15, Noel (@noelportugal) mentioned to me the existence of a the ESP8266 chip.
This is essentially a dirt cheap wifi chip that comes with a bunch of GPIO pins and is powerful enough to be programmed, right on the chip.
There are a bunch of breakout boards that use this chip as their basis and make development even easier. I went for the NodeMCU board, partly because I thought it would allow me to code in node.js (which is incorrect, it uses Lua, a language that has a lot in common with JS, but is not JS).
More importantly though was the prize, the breakout development boards cost ~$10 but the actual chip costs less than $3 (and dropping). Given that our piezo cost 20 cents, we would have a potential IoT product that costs less than $4 to produce.
Once we settled on the sensor and the board, we started to focus on our use case.
We contacted Oracle Facilities, explained what we were trying to do and asked them if they could give us some real numbers of water usage at Oracle to use in our presentation and as a base line for our product.
To our surprise, not only did they provide us the information we needed, they also wanted 1,500 devices from us to test themselves. We had to disappoint them at that point explaining to them what a Hackathon is, however, this clearly demonstrated to us that this would be a useful product, regardless of what would happen during the Hackaton.
We also got another interesting use case from them, essentially A/B testing for water using appliances; they are in the process of installing low flow toilets and faucets on some floors and they immediately realized that this would be the perfect device to confirm whether these expensive upgrades are cost effective, compared to regular appliances.
This is very hard to do right now as, again, sometimes the savings get lost in the overall usage, which is all they can currently measure.
That concluded al the investigative work we did for the Hackathon. In the second part of this blog post I will drill down into the technical aspects of the solution we eventually presented to the judges.