The Smart Valve 2049 - Devpost Microsoft U.S. Azure IoT Hack for Sustainability

Brian Dinh and myself got together for another hackathon that was on Devpost. This time it was for the Azure IoT Hack for Sustainability. When we did the Postman API hack, one of the API ideas that Brian had was for a watering system, which ultimately the team decided not to focus on since the judging was focused on Postman features. Since this new hack was about IoT and Sustainability, it seemed an appropriate time to revisit the watering system.

For our IoT devices we decided on using Raspberry Pi. Erik had given me a Pi during my last visit to Seattle -- all I had done so far was blink some lights and do some basic IR camera access, so this seemed like a good excuse to learn a little more about the hardware side. I had never used Python before, other than copying a few lines from the internet, so I asked Brian if we could do this project using Python. My personal goal for this hackathon was to learn new things and to accomplish our vision in the time allocated.

I tried to use sensors I already had rather than run out an buy a bunch of new stuff for a hackathon. I've actually managed to change my Amazon purchasing behavior so that it is now days/package instead of packages/day, which helps on the pocketbook. I still ended up buying a flow sensor (which had really huge threading so it didn't actually connect to the hose) but it worked good enough to allow me to get readings on my oscilloscope.

The frequency of the square wave changed depending on the water flow (it was a linear correlation to liters per minute.) The faster the frequency the more water was flowing through the flow meter. When the garden hose was on full and I tried to hold the hose on the sensor the frequency was a little over 100Hz. There was some back pressure (read everything got a little wet) while taking the measurements. It seemed like our faucet was running around 36 liters per minute on full blast. The function generator allows me to enter a frequency to simulate what I see on the scope, while keeping the Raspberry Pi nice and dry.

The Raspberry Pi did a good job with I2C sensors and with the DHT11/DHT22 that use a GPIO pin for communication. The relay that activates a solenoid connected via GPIO and also worked great.

The flow meter was a challenge -- on the rising and falling edges of the GPIO pin we looked at the ticks and then used the ticks_diff() function to calculate a duration which we converted to frequency. We measured 5 cycles and then took the median sample frequency. The majority of time, this resulted in a fairly accurate value - but sometimes if the pi is running other operations it can be off by a few Hertz. When the water is turned off completed, the signal is 0 Hz, so we had to add some timeout logic as well. It probably would have been easier to use an Ardunio connected to the Pi via I2C or Serial?

Our Raspberry Pi devices communicate with IoT Central, where consumption data is aggregated on a dashboard. You can click into an individual device to see information specific to the device and also send remote commands to the device, such as turning the water valve on and off via the relay.

IoT Central has evolved since I looked at it last year, but it was still missing some basic features. One example was flow rate couldn't be represented as L/min, it could only be L/sec or L/hr (we ended up doing a custom value and specifying a label of Liters/min but I'm sure that breaks some localization rules). Also when we wanted to show daily consumption there was no easy way to aggregate our telemetry data that was sent every 15 seconds to calculate total volume -- we ended up sending telemetry data once per minute instead so that the sum was the total liters. IoT Central has the ability to create rules (like run this rule when the moisture readings for last 5 minutes are below a specific value.) Unfortunately the rules can't really do basic operations without also using Azure Logic Apps. Azure Logic Apps was able to do everything we wanted, but the IoT Central v3 modules didn't work great so we ended up using just raw HTTP module and making authenticated HTTPS calls to communicate back to IoT Central. Logic Apps can't have multiple starting triggers (okay, you can fork from Recurring, but then you can't easily see past state in the dashboard) so we ended up with separate instances of Logic Apps for different rules.

Overall, it was a great learning experience and another successful hackathon. We submitted our entry last night, and tonight the hack finished (340 participants).

The gallery is open, please like our project if you have a DevPost account: https://devpost.com/software/the-smart-valve-2049