Off-The-Shelf Hacker: A Methodology for Automated Yard Watering
Last week we discussed my friend’s OIP (output, input, process) methodology, focusing on the input and output parts. This week we’ll use that insight to take the first swing at a process that guides us through designing, building and running the “water the yard” physical computing project.
Let’s summarize our output and input data so there is context for a possible process.
The objective or output is to automatically water the yard on a flexible schedule. Other outputs are knowledge and examples derived during the project that will be turned into Off-The-Shelf Hacker columns and physical computing conference tech talks.
Inputs include the desire to set the schedule using a simple list of areas and on/off times, be able to turn the water on manually and have it stop after a certain period and use standardized techniques, also known as best practices to allow future expansion of the system. Updating the state of the system and interacting with it over my home network would be useful, too.
Those are the basics for the system and how it should act. Developing a process, is the next step. This is the spot where most geeks get excited and usually actually begin their project.
How do we water the yard?
Pick a Process
Watering the yard is simple.
Look at the daily watering list and realize that you need to water. Put the nozzle on the end of the hose. Point the nozzle toward what you want to water. Turn it on. Move the hose to evenly soak the area. Turn the water off when you think you’ve watered enough. Repeat for different areas of the yard.
That’s one way.
A slightly more sophisticated way is to translate your daily watering list into the settings on a little mechanical timer that attaches to the spigot. The hose then runs over to a sprinkler that’s pushed down into the ground. At the prescribed time, the water turns on and saturates the area. After a designated time the water turns off. You’d need several of these “zones” to take care of the various parts of the yard.
That is another way.
These scenarios take care of our desire for watering. One depends on your remarkable memory and the other on a mechanical timekeeping device. They also cover the requirement of following a list of on/off cycles, more or less. Finally, future expansion is certainly wide open since we could go crazy with a trip to Home Depot and some credit card purchases from Banggood or Spark Fun.
There are a million ways to accomplish our objective of watering the yard using a list, that can be upgraded in the future. Just pick one and go.
This part of our OIP methodology, especially in a business setting can be overwhelming and have serious consequences. Nevertheless, we must forge ahead, pick our best path and get the job done. Will we always be right? Probably not. Knowledge, experience and inspiration all come into play, when picking a process.
Picking a Process or Picking Parts? Yes!
There have been discussions of robots and artificial intelligence affecting jobs of the future. I think the combination of knowing what to use, when to use it and connecting those things together in a useful way is a uniquely human trait. In my humble opinion, there will always be jobs for people who can create good processes, especially in the physical computing niche.
Crafting a good physical computing process is absolutely a dark art. Do you start with mapping out exactly how you want everything to work, then pick parts? Or, do you have parts in mind and use your knowledge, experience and behavioral sense to shape the process around the parts? The answer is tricky and adds to the fun of getting that critically important version 1.0 to the demo stage.
For example, watering the yard involves water. The water pressure itself could be used in a mechanical computer to turn valves on and off, keep track of the time and switch itself between zones. Conventional solutions don’t use hydraulic principles in this way, they use electronics. Water leaks are messy. Of course, implementing a schedule list that is easy to edit would be out of the question. A ridiculous example perhaps. This kind of solution, in the 1880’s steampunk era might be interesting and actually appropriate. So we’ll go with electronics.
Electronics means a microcontroller. Knowledge and experience, coupled with standardized products point to using an Arduino or Raspberry Pi microcontroller.
I’ll rule out the Arduino at this point because it has limited user interface possibilities. Push buttons might work for input and menus. We could use a little serial display for system and status messages. All of that is great. That solution is exactly what I currently have hanging on the wall in my garage. I don’t like it because I have to reprogram the darned thing every time the power goes off. The battery backup, on that antique controller never really worked right. It definitely can’t be adjusted remotely. We’ll go with a late model Raspberry Pi.
A shiny new Raspberry Pi Zero wireless should fill the bill nicely. The requirement for being able to build/maintain a list of the scheduled times is easily accomplished using a simple text file. The Raspberry Pi also controls general purpose input/output pins (GPIO) directly from a program. Turning water on and off lends itself to the binary nature of the Raspberry Pi GPIO pins. We don’t really need any continuously variable analog capabilities for watering a yard. Variations in the amount of water delivered is simply controlled by time.
The Raspberry Pi is also capable of communicating with my home network using an onboard wifi radio. Network connectivity, keeping time and automatic restarts after a power outage round out the argument for the Pi as our computing element. It runs Linux, so we’ll be able to use various programming languages and even applications, like MQTT for future enhancements.
Lastly, the Raspberry Pi Zero wireless module is available from Adafruit for a paltry $10.
Whatever microcontroller used, there has to be a way to switch the electric water solenoid valves on and off. For this, I’ve already ordered an 8-channel relay board. The board will take orders from the Raspberry Pi and manage the flow of water to the sprinklers.
The Raspberry Pi and relay board make up the main parts of the system, along with the existing in-the-ground water valves and sprinklers. There will also be wall warts to power everything and some kind of case to keep the system alive in the harsh garage environment. No A/C, dirt and maybe even… bugs.
Don’t laugh. In Florida, for some reason, ants find their way into electrical devices. They then build nests that short out the wiring. Rodents cause the same chaos, except they gnaw the insulation off the wires, sometimes leading to a fire. I’ve seen it happen. Competent off-the-shelf hackers take these sort of things into account.
Where Is the Process?
Physical computing processes are woven intricately with the parts. The process dictates the parts and the parts influence the process. I think this haziness is what makes developing real-world projects interesting and frequently quite a challenge.
Keep in mind, that the first version of a gadget is usually a best guess. When we hack off-the-shelf things together, there will be experimentation, discovery and even failure. We want to engineer the best process from the beginning. We can’t possibly know all the particulars and nuances, before we have something we can hold in our hands. We’ll then have to adjust things and it becomes an iterative organic cycle.
We have a basic process. Use a microcontroller, to manage a text file that turns GPIO pins on and off to a set schedule. The system will keep time and restart at the right place after a power outage. Programming will let us manually turn the water on and then back off again when I forget. Finally, we’ll use the power of the built-in Raspberry Pi networking to adjust the system remotely. From here we’ll build and adjust to get to a working prototype.
That’s physical computing OIP in a nutshell.
I’m waiting on the parts so we’ll return to the project soon.
Feature image via Pixabay.
