The summer is pretty much over so I decided to finish up my summer auto irrigation project with a post.  I’ve had a few posts about the progress I have made on my summer project to implement an automatic irrigation system.  I have not had a summary post describing the different components.

The Goal

The goal of this post is to document the project.  Included:

  • a high level documentation of the auto irrigation system I implemented.
  • links to the code and anything else needed to rebuild the system.

Thanks To Those That Went Before

  • Adafruit for great products and services.  Their prototype stuff and made this project possible.  What an excellent company.  THANK YOU.
  • Ray’s DIY Electronics Hobby Projects – An exceptional open sourced open sprinkler hardware and software project.  In particular, Ray provides thoughtful blog posts on stuff like how to use a 24VAC irrigation directed power source to also power a microcontroller.  THANK YOU.

Open Source

The Arduino sketches for the Controller, Moisture Puck and Watering Puck are located at this GitHub location.

High Level Diagram

The Job of the Auto Irrigation System is to water the plants when the soil is dry.  It is “smart” about this by not overwatering and watering at the best time of day to do so.  The  Auto Irrigation System consists of three pieces of hardware:
  • The Moisture Puck whose job is to send moisture info to the Controller.  I covered aspects of the Moisture Puck in this post and in this post.
  • The Controller whose job is to coordinate between the Moisture Puck, Watering Puck, and Adafruit IO.
  • The Watering Puck whose job is to turn on/off the irrigation valves.  More on the Watering Puck in this post.

A Bit About the Hardware

Since I didn’t know what I was doing when I started, all hardware is prototype.  It is either too expensive, too cobbled together, or not robust enough to be “mass produced.”  However, I am happily using the system.  I like to think and evolve these type of projects.  My hope is next year I will feel inspired to improve….until one day…who knows?  Every member of my family is using this system :-).

Interaction Between

The Moisture Puck, Controller, and Watering Puck talk to one another using the RFM69 wireless protocol at 915 MHZ.  The Moisture and Watering Puck use the Adafruit Feather M0 RFM69HCW.  

The three pieces of hardware wirelessly communicate with one another using the RFM69 wireless protocol at 915 MHz.

  • When the Moisture Puck is powered on, it requests and receives the current time (i.e.: current hour, minute, second).  This gives the Moisture Puck the knowledge to know when it is 4AM.  4AM is the time I determined is best to water the plants if they need watering.
  • At 4AM every day the Moisture Puck takes a moisture reading and sends the reading along with readings for the battery level and chip temperature of the RFM69 to the Controller.  The Controller checks to see if the reading is below the threshold for determining if the soil is dry.  If it is, the Controller tells the Watering Puck to water the soil.

Interaction With The Internet

The Controller talks not only to the pucks, but also to over…DAH INTERNET….So the “heavy lifter” is the Adafruit Feather ESP8266 Huzzah.  Sitting on top of the Huzzah is the RFM69 FeatherWing.  The Huzzah yaps it up with and runs the Arduino sketch.  The FeatherWing yaps it up with the Pucks.

Keeping Private WiFi Password, SSID and AIO_USERNAME, AIO_KEY

I used the WiFiManager library to keep the WiFi stuff:

#define WLAN_SSID       “XXXXX"
#define WLAN_PASS       “XXXXX"


Then there is the private stuff:


I put these into an include file (AdafruitIOLogin.h).  I added AdafruitIOLogin.h to .gitignore when pushing the sketches to GitHub.

I created a dashboard on


and several feeds:


I ended up not using the water feed.  The water feed is fed by an IFTT channel.  The channel lets me know when sunrise and sunset occur.  I was going to base watering on these values.  However, after thinking through watering, I decided it best to water at 4AM each morning.  I like knowing how the sunset and sunrise change over the days so I leave the feed in.

The feeds I pay the most attention to are the ControlInput and Log feeds.  

Control Input Feed

The ControlInput feed accepts commands that are sent to the Controller.  The challenge with using commands through to get to the Controller is about 1/3 of the time I have to enter the commands multiple times.   To make sure a command completes, I open two web pages – one focused on the ControlInput feed and the other focused on the Log Feed.  More on the log feed in a bit.

The commands include:

  • threshold=<value>  where the default value is 215.  Notice in the above images the moisture reading was 246.  The Controller checks this reading against the threshold value to figure out if the watering puck should water.  When the threshold = 215… 246 > 215 so watering does not happen.  If I enter the command threshold=247, 246 < 247 so watering would occur.  The Controller remembers the threshold value and will use it as long as the Controller is not rebooted.
  • zones= <zone color> where zone color can be blue, green, yellow or a combination.  For example zones=yellow,green will tell the Controller to only ask the watering puck to  turn on the valves that are labeled yellow and green.  
IMG 6138

I put in three valves and color coded them.

Notice the zone=yellow in the ControlInput feed.  The command that the Controller recognizes is zones= (or ZONES = …or ZoNeS=…).  The log feed gives me feedback on whether command is correct.  In this case, I received:
  • start commands the Controller to tell the watering puck to start watering.  This command is useful when I want to force watering which was the case when I added an irrigation line to water our trees.
  • stop commands the Controller to tell the watering puck to stop watering.

Log Feed

I use the log feed to know whether a command got to the Controller and as a way of debugging.  I broke up the Controller’s activities into states.  The below logged the Moisture Puck sending data to the Controller and the Controller checking the moisture reading against the threshold.  In this case, the reading was above the threshold so no watering.


Here is a section of the log feed when the start command is entered:



To explore IFTT integration with, I explored these feeds:

NewImageNewImage  NewImage       Pasted Image 9 12 17 4 56 AM

The only one I am using to control the system is the battery level notification that goes to my cell phone.  I am having a challenge with the LiPo battery.  All of a sudden, readings went from somewhere around 4V to 3V on the next reading. The readings started waffling around 3.2V.  I think (not completely sure) the battery got damaged from being out in the garden when temperatures on the battery’s surface got around 100˚F.  If this keeps happening, I’ll look into it more.

And That Is That

The great news is everything works and I learned a lot.  Plus, there were issues with our plumbing that this project surfaced and we then fixed.  There is more I can do to make the system more robust and all that good stuff.  But for now, I am saving a lot of time not having to hand water the different areas of the house.