Local weather-based watering system

[scottsh]

I have a local weather station at my house and I have access to that data. As a result, I know actual hard data for the amount of rainfall, temperature, and humidity. I believe I can use this information to set the watering schedule to more effectively ensure that the right level of water gets put down. According to an irrigation industry presentation I saw, this type of adjustment can reduce water use by as much as 60% over no adjustemnt at all.

I like the monthly ETo adjustment option, but I’m thinking I might be able to do better than that. I’m not positive though. I’d like to plan this out a little bit and get some feedback to ensure I haven’t missed anything.

My initial idea is that I want to ensure that a specified effective precipitation has been put down over the previous 7 day period. Every day that is specified as a day to water, the code will decide to water if needed and if so, how much (up to a specified maximum that avoids runoff.) Included in that calculation will be the amount of rainfall that has occurred during the last week, and modified based on the daily evapotranspiration as calculated based on basic plant type, daily temperature, and relative humidity.

I believe I would need to allow data to be entered that would include zone information such as the basic plant type for ETo, water needs for the plants in the zone, zone precipitation rate (might calculate this based on zone coverage, sprinkler type, and flow rate), and runoff limit.

Does that sound right as a basic algorithm?

[Dan in CA]

You are on the right track.

Take a look at this thread:
viewtopic.php?f=28&t=364

You may find some helpful information.

Dan

[scottsh]

Thanks Dan, I appreciate the information links.

It doesn’t seem like anybody developed more sophisticated code than the monthly ETo adjustments?

I don’t want to recreate the wheel here.

[Dan in CA]

If you are referring to the monthly adjustment plugin, that was mostly a demo, but hopefully a useful one, of the new plugin architecture for the Python Interval Program. I have some (untested) Python code for ET calculations you might be able to use as a starting point.
You can download it from:
http://1drv.ms/1f45m2F

You might be able to start out by simply subtracting the measured rainfall from the amount scheduled to be applied and build from there.

Some other folks here have been working on weather based stuff but i don’t know she status of their work at this point.

I am interested to see what you come up with.

Dan

[R_W]

For turf irrigation, the ability to specify zone inches of water rather than zone watering time could make for a better user experience.
Measuring inches per hour output for each zone , entering them as parameters, and subtracting rain gauge readings would be straight forward.

The not-quite-viral PhD cat food can sprinkler calibration video: http://www.youtube.com/watch?v=W_wn-hwLNtg

[scottsh]

I’ve been thinking a lot more about this and so I wanted to share where I’m at with the problem and the algorithm to implement what I think we’re all talking about.

As R_W suggests, one thing that has become obvious to me is that if you are going to compare rainfall to sprinkler-based watering, you are going to have to know how much water your sprinkler system puts out as well as how much water your plants need. The simple fact is that if you know that it rained .27in yesterday, the only way you can determine its impact on your 7-day watering schedule is if you know A) how much you put out when you turn on the zone valve, and B) how much water your plans need. Note: you also really ought to know what the maximum amount of water you can put out before it starts to run off, but that’s potentially a second order problem.

I’m going to refer to the amount of water placed by the sprinklers in inches per hour as Precipitation Rate or Pr. To determine your Pr, you have to measure your actual water output using the method R_W links to in that video. You can use a kit (like this http://www.agrilifebookstore.org/product-p/sp-424.htm) or set out empty cat food tins or frankly anything else that will work. We need this data for every zone. I can’t state enough how important this is.

You also need to know how much water your plants (grass, flowers, vegetables, or whatever) need. From what I can find, most information available refers to the amount needed in inches of water per week or every 7 days. I’ve seen estimates for some grasses in my area of 2in of water needed per week, and some need as little as .5in per week. This value is referred to as evapotranspiration and abbreviated ET. Note: a commonly used term in the literature is ETo, which is the amount needed by a particular referent plant.

With this in mind, I believe the right thing to implement for OSPi is an advanced watering model that, on a per zone basis, determines the amount to water on a given day by factoring the amount of rainfall and amount of irrigation for the previous 6 days along with the amount of water that zone needs. The model I have in mind looks like this:

– ( + ) = water needed

or
– for a zone that contains grass that requires 1.5in/week
– and contains a sprinkler system that can put out .5in/hour
– that has been used for 90 minutes in the past 6 days
– and has had rainfall of .25in in the previous 6 days

1.5in – (.25in + (.5 * 1.5)) = .5in water needed

Once this is determined for a given zone for that day, the controller can then decide how much to water this particular day. In the case of our example, .5in of water is needed so 1 hour of watering is required for this day. If we know in advance that the maximum amount of water that can be put down before runoff occurs is .5in, then we’re fine – we can water for the full hour and everything is great. If we know that runoff occurs at .4in, then the system should activate the zone for 48 minutes and wait for tomorrow.

Does this seem right? Am I missing something?

If you had a UI that allowed you put in data per zone for the information on amount of water needed ET (in/week) and the amount of irrigation throughput Pr (in/hour) would that be acceptable?

Thanks!
Scott

[michaeli]

This looks like you are on the right track and something i would really like to get in to as well…one question though, in my yard, all of my zones overlap each other, any thought on how to address this?

[Dan in CA]

scottsh,

Just wanted to say that I think it is really cool that you are working on a plugin for this even though I have not posted any real documentation of the plugin system.

You may have discovered that if you start the program manually from the OSPi directory:

sudo python ospi.py

That you will get any error messages that are generated when your plugin is being loaded. This should help in debugging.

If you have any questions, please post them here.

Dan

[951calguy]

Im interested on this as well, I work with different commercial controllers and I can give you my input, I can also tell you that the water savings come from adjusting the run time every 24 hrs. according to ET That’s what weathertrak, rainmaster and most use.

[951calguy]

I have not had time to check the watering schedule for open sprinkler but the easiest way to avoid run off is by having lets say 3 or 4 different programs with up to 8 start times. Program a, b, c for different plant types. Let’s say program a (turf) runs 3 times x week with 3 -4 min cycles, starts at 7 pm. Program b runs 1 times per week (shrubs) with 5- 5 min cycles and it runs on the program a day off. We need to figure out soak times, and all the run times need to be adjusted by getting a daily ET update, we need a et reference value that get adjusted according to daily ET provided by a local weather station, there are some free ones on the net.

[R_W]

@scottsh,
Normalizing on inches (or millimeters) of water makes a lot more sense to me than using uncalibrated time units for irrigation.
The not-to-exceed watering time to prevent runoff is a great idea.
Defining zones as overhead irrigation such as lawn sprinklers (rated in inches per hour) vs drip tape (rated in gallons per hour) for crop and vegetable irrigation would be a useful addition.

Long term for your next plug-in 🙂 , Fertigation valves in series with the irrigation valves that know the crop type and nutrient requirements over the growth cycle of the plant once the planting date has been specified would be awesome.

[scottsh]

Great ideas – I included zone type (rotor, spray, drip) and allow input of in/hr for rotor/spray, or gallons/hr for drip.

I have a little drip irrigation myself and its rated at 2 or 3 GPM – how common is that compared to GPH?

[R_W]

I think most drip systems publish GPM and GPH.

One more thought on what is certainly a corner use case scenario: A few years ago I set up a flood and drain hydroponic system with an AVR controlling a fountain pump for the fill cycle. It was very crude compared to OpenSprinkler. As well as being amazed at the accelerated growth rate possible with hydroponics, I found myself constantly having to increase the fill frequency and duration by small increments almost daily. I could literally watch the plants start to wilt and revive as the pump cycled. A simple slider for fine tuning zone time/water amount would have saved me a lot of repetitive hand coding.
Ultimately the hydroponic system had a catastrophic failure (for the plants) due to a missed watering day. There is absolutely no room for error in that type of system. Growing in soil may be slower, but it is much more forgiving.

[scottsh]

I made it look like this – does this work to your thinking?

[attachment=0:214214qq]example.png[/attachment:214214qq]

[R_W]

Looks good!
Since the calibration values are measured for each zone, and Rotor and Spray have the same unit of measure, I don’t see why both are necessary. Would Sprinkler and Drip be enough?
Showing the user the calibration value and calculated watering duration would be good for debugging and system operation confidence at a glance.

[scottsh]

Regarding Rotor/Spray being the same – they are from a calculation standpoint, but I think it will be helpful from a UI standpoint to identify this in some way. From my experience, rotors have a much lower Pr than sprayers. As a result, it was helpful when I was doing manual programming to be able to know which was which – the rotors run for 30m per run while the sprayers only run for 5m.

Of course, once you go fully automated I suppose this isn’t as important.

And once I have the calculated plan information I plan on making that visible in several places. It’s slowly coming along. I think I have all the data I need so I’m ready to start creating the automated programming system. Hopefully I will have something working this weekend.

[DanTripp]

I’ve been doing a lot of reading about weather-based irrigation over the last few weeks. There’s a lot written about the “water balance” or checkbook approach, and it seems to be commonly used by professional irrigation managers and systems. See my brief description here: http://rayshobby.net/phpBB3/viewtopic.php?f=28&t=364&start=15. I created a simulation to use as proof of concept for this approach. My code and the papers on which it’s based can be found here: http://1drv.ms/1jDASLj. It would be great if others who are interested would try the code, experiment with it, and comment on your findings.

This approach to scheduling is very different than the one traditionally used for home irrigation, but it’s used quite a bit in agricultural and commercial contexts. It requires a sophisticated controller with daily or hourly access to weather data. With OpenSprinkler we have this capability. In traditional scheduling, you define programs with start day/times and run times for each sprinkler zone. With the checkbook approach, this is done automatically. Instead, you specify constraints when watering can take place, such as time windows, days of week, or odd/even days.

The first thing you must do is specify the characteristics of your zones. At a minimum, this includes soil type, plant type, and sprinkler type. The Rain Bird schedule calculator (http://www.rainbird.com/rbts/tutorials/RunTimeCalculator/) illustrates how this can work. It would be great to have a nice UI like this in OSPi at some point. The software calculates a number of zone attributes using the supplied information, defaults, and values looked up from tables of data from research. The values calculated include soil water capacity, maximum allowed depletion, sprinkler run time (broken into water/soak cycles, if necessary), and many more. You can provide additional zone characteristics like slope, sun/shade, plant density, sprinkler coverage efficiency, etc. to refine the calculated values.

Once the zone values are known, the irrigation schedule can be determined based on the weather. The ET0 and rain values are obtained from a weather source, either daily or hourly. (If there is no source, a schedule can be generated based on historical averages, but obviously that won’t account for current conditions.) Each zone has a landscape coefficient which is multiplied by ET0 to estimate the amount of water lost. This is subtracted from a per-zone water balance and any rainfall is added. When the water amount falls below a depletion threshold, irrigation takes place and the amount watered is added to the balance.

The weather-based calculation generates a list of zones that need watering each day. The final step is to generate the watering schedule for the zones. The scheduler must look at the user-specified constraints and the maximum run times and minimum soak times for the zones needing irrigation.

The simulation I’ve written does all the above using weather data from WeatherReach. I’ve created a database with daily weather data from January 2013 to May 2014 for a station near where I live, near Seattle. If you try the simulation, you can use this data or follow the instructions to download data for a station near you. Replace the zones with your own and run the simulation to see what watering schedule results.

I’m not sure the best way to integrate this into OSPi, since the model is so different than the current one. Ideas?

[scottsh]

I looked hard at this approach myself, because as you say it is the one most commonly used by commercial irrigation solutions.

What stopped me was the difficulty in getting accurate ET data. According to the Texas A&M site and papers, they stated that you had to have a soil moisture reader and solar radiation sensor to generate accurate ET values. This stopped me because neither are commonly returned values from Wunderground and aren’t common on most home weather stations. But, there is a Texas A&M official ET station about 35mi from my house that could be leveraged. I figured once I had the more traditional system done I would return to this ET-based idea and see what I could do.

I like your simulation and it makes me want to run the numbers and compare that to the more simplistic system I have come up with with in order to determine how much water would actually be used with each. I’m going to see how difficult that would be to add.

As for adding it to OSPi – I think I can see a way. You would have to collect the zone-specific data similar to what I have done that includes irrigation capacity, water needs, run-off limit, etc. Then you would have to model the individual zone needs, adjusting for the weather data. When it is time to water you program the OSPi model directly by setting gv.rs[zone] for a given amount of time respecting any filters (such as limited days, limited hours, run-off limits, soak time, etc.) Soak time is an interesting filter, by the way, one that fits relatively well within the current model.

I’d probably do something like wake up a thread every hour and run through all the checks/filters for each zone, and water if needed/allowed.

[DanTripp]

You can calculate ET0 from the following weather data: temperature, humidity, wind speed, and solar radiation. Solar radiation is the tricky one since it’s generally not present in Weather Underground data. I use the solar radiation reading from a nearby WeatherReach station and calculate ET0 using the other weather data from my own weather station (via Weather Underground). I find the ET0 I calculate is close to the one at Weather Reach. I suspect I’d be fine using their value instead of my own. There are so many variables used in water balance scheduling that a little inaccuracy in ET0 should not be big deal.

Dan in CA previously posted links to a paper containing equations for calculating ET0 step-by-step, and to code implementing the calculation. I wrote code as well before discovering Dan’s, and you’re free to try it. I added it and the equations paper to an ET directory with my other code.

Dan in WA

[scottsh]

I thought I would share a little data based on my experience in my lawn. My overall lot is 1 acre, however only approximately half of that (say 22ksqft) needs irrigation.

Here are my actual values from my lawn based on measuring Pr using the method of putting collection cups in the zones and running them for 15m. I spent about 4 hours in the lawn, putting down a set of shallow plastic containers with straight sides, flat bottoms, with a heavy rock in each one to keep them from blowing away or moving around. What I found was eye-opening.

zone#: type – Pr – comment
1-4: spray heads – 1.5in/hr – spray head coverage for me was extremely uniform, with +/- 10%
5: 5x rotors – 0.56in/hr – well designed zone, with excellent overlapping, heads laid out in a triangle formation right out of the literature!
6: combination zone, with 3 rotors and 5 spray heads – terrible zone to manage, rotors got .35in/hr coverage, spray heads were 1.47in/hr
7: 4x rotors – 0.41in/hr, partially overlaps zone 6 (!!!)
8: 6x rotors – 0.5in/hr
9: 5x rotors – 0.275in/hr – almost no overlap between rotors in the zone
10: 4x rotors – 0.53in/hr
11: 3x rotors – 0.4in/hr – where there was coverage, there was a portion of this zone without any coverage at all (0!) due to a driveway extension by a previous homeowner taking out a head (or 2?)
12: 5x rotors – 0.475in/hr
13: 5x rotors – 0.25in/hr – very sparsely covered zone, with almost no overlap between rotors
14: 4x rotors – 0.45in/hr
15: spray heads+drip – 1.53in/hr for sprayers, drip heads are 2gpm put into 2 tall decorative pots with lemon trees
16: 4x rotors – 0.35in/hr – 16 overlaps the half of 17s coverage area, unclear why that was done
17: 4x rotors – 0.475in/hr – fully overlapped by 16 & 18 coverage, 2 heads were relocated during a rear patio expansion which caused the overlap with 18
18: 4x rotors – 0.375in/hr – overlaps the other half of 17s coverage area

All this got me to believe that I couldn’t calculate coverage based on types of heads in software. Given what I see in my area, most lawn sprinkler setups are similar, with very poor overall design and impacts being made by landscape or hardscape changes.

Here in Texas, my water costs run about $50/month during the winter when I’m not running my sprinklers, but during the summer, there have been $300/month bills multiple times in the last few years. All this leads me to have a strong financial incentive to be more optimal in my water use on top of my overall desire simply not to waste water.

[DanTripp]

Interesting data, thanks for sharing. It’s nice to see that the few spray heads you have are exactly on the manufacturer’s spec of 1.5 in/hr, which is the default used in the simulator. For rotors, the default is .75 in/hr, and your values vary quite a bit but are all well below this. There are so many variables at play here that I always try to keep in mind that the precision of the calculated results is not the same as accuracy – everything is just a ballpark number and needs to be looked at skeptically. Also, the research was done for crop irrigation. Managing acres of soybeans or a baseball field is a lot different than a home landscape. In my case, I have a few areas in beds that get little or no water because spray heads are blocked by shrubs. No amount of calculated watering will fix this. I could add or relocate sprinkler heads, but it’s easier just to hand water these areas.

There are several numbers that are good to measure for your zones, and the measured values used instead of defaults. The first is the precipitation rate, as you’ve done. You might also want to calculate the distribution uniformity – DU(LQ). It’s described in the Landscape Water Management Training Manual (in the References directory). If you have individual catch can values from your tests you might not even need to retest. Basically, the uniformity is the ratio of the average water volume of the lower quarter (hence LQ) of catch cans to that of all the cans. In the simulation it’s the field called “Efficiency”. Here’s a web site that calculates efficiency from catch can measurements:
http://wateringschedule.com/get-started/

Another thing that’s easy to measure is the maximum water cycle time. I found that in several of my zones, runoff starts in 5 or 6 minutes, which is less than the calculated value (which is based on soil type, slope and sprinkler type). So I set MaxCycleTime.

[scottsh]

Of all the data I captured, it didn’t occur to me to capture milliliters per can. I can tell you from memory that some zones had great uniformity, and some had terrible uniformity. I addressed that by taking an average of all the cans.

But it is the areas of the lawn covered by multiple zones that bother me the most. In order to get enough water on all the grass in 2 zones, I have to significantly over-water the overlap. It makes me want to hire a firm to fix this by moving the heads. Ugh.

Also, one variable that impacts rotors potentially more than spray heads is local water pressure. I notice that watering during the early morning (which is when almost everybody else is also watering) I get lower coverage than watering in mid afternoon. It got so bad my local water district asked people to voluntarily change their watering time to keep pressure up.

And determining the runoff limit is much harder than I thought. I’ve started with a suggested default value for my soil type, but it isn’t even obvious when there is runoff, necessarily. I can see it in the shrubbery with spray heads pretty easily, but not so easily with the grass.

[ssurowiec]

Wow! I definitely found the forum for me!
Sounds like you guys have hit the ground running!

I recently went through a sprinkler audit provided by the city of Fort Collins (here in Colorado) The lead auditor told me that once your nozzles and system is running efficiently the next step is to move toward a smart controller.

Like many of you I am interested in an even smarter controller. One that will ultimately be proactive, predictive and auto-magical!

I know that here in colorado wind plays a big role in how effective the irrigation system can put water where you want it. It would be nice to see a wind sensor input whereby if windspeed exceeds a certain value averaged for a certain period of time … then Delay or Pause the watering schedule and resume at a later time.

… Its amazing how watering plants has gotten so complicated!

Keep up the good work … I hope to be the proud owner of an OpenSprinker controller soon!

[ssurowiec]

@DanTripp wrote:

I’ve been doing a lot of reading about weather-based irrigation over the last few weeks. There’s a lot written about the “water balance” or checkbook approach …I’m not sure the best way to integrate this into OSPi, since the model is so different than the current one. Ideas?

From a UI perspective perhaps the user is presented with a choice for a simple or advanced mode. Choosing advanced would engage the checkbook approach and dump (or archive) the settings from the simple mode (and visa versa).

Bringing advanced industrial grade irrigation control and methodologies to a residential application is why I am so excited about this project!

[scottsh]

How do you think a wind-based delay would work? I’m thinking the code would have to be pulling live wind data frequently, but potentially only while it is actually engaged in watering. Would a single gust be enough to force a delay or only if the average gets over a certain amount?

I suspect this would only work with a personal weather station. You couldn’t pull data that frequently from WUnderground without paying for it. You could potentially pull from the NWS, but given that its not often local I’m not quite sure how useful that is?

[Author]

Posts