Forum Replies Created
-
Posts
-
Vlad,
If you can measure soil moisture content directly, you can bypass the ET calculations completely since they are used to estimate soil moisture. The core of the algorithm is the “checkbook” balance calculation. Instead of calculating the balance each day based on rainfall, irrigation and evaporation (ET), you can just measure the balance directly. The various zone calculations using factors like soil type, plant types and root depth would still be useful to determine how long to water. These calculations do not involve ET or any weather data. Good luck, and let us know how it goes.
Dan
I’ve been using the ET checkbook water balance algorithm all summer and am happy with the results. My implementation is based on the same code as the stand-alone simulation found here: http://1drv.ms/1jDASLj.
The code is not tightly integrated with the OSPI program; it’s mainly stand-alone Python programs that run as cron jobs. I have a database containing tables for weather data, sprinkler zone configuration, the irrigation checkbook, and the watering schedule. I modified the sprinklers_pi program to load its schedule from the database every day. (I used sprinklers_pi instead of Interval because I was familiar with its code and because its schedule model was an exact match to my data: a schedule is a simple list of watering events consisting of a start time, zone number and duration.) I configure zones by editing a text file (a nice UI would be great, but not worth the effort to me so far). I get an email every day telling me what watering took place the previous day and giving me a ten day weather forecast with the projected watering schedule for each day. Most of the experimenting I’ve done this summer has been in tweaking the projected schedule. The tricky part is forecasting future ET values.
Here in Seattle the summer is mostly dry for long stretches with an occasional rainy day. Last night we got a lot of rain. There was no watering yesterday because there was rain in the forecast. Now that the rain has fallen the ground is saturated and the projection is for no watering for three days. At that point watering will resume first with my lawn zone and zones with shallow roots. A day or two later irrigation will resume for zones that have larger capacity to store water. My lawn in shallow clay soil gets watered every two to three days during dry stretches. Other zones containing shrubs in deeper loamy soil get watered less often. I found I had to tweak some of the shrub zone parameters because we planted flowers that need more frequent watering. My biggest irrigation issues are mixed plant types in zones and incomplete coverage by sprinkler head placement (e.g. water flow to some flower areas is partially blocked by shrubs). Therefore I do some additional hand watering during dry stretches. It would be much easier if I had big fields of soy beans instead of home landscaping!
The ET approach to irrigation is nice because it’s so dynamic. When the weather is hot and dry, watering happens more often. Windy days mean more watering; overcast days mean less. If it rains (or if rain is in the immediate forecast), watering is suspended. When watering resumes depends on how much rain falls and how hot/dry/windy the following days are.
If anyone is interested in trying this approach themselves, I’m happy to share my experience and code. Start by checking the link above. The primary reference I’ve used is this document from Irrisoft, which describes this approach and is pretty easy to read:
http://irrisoft.net/downloads/manuals/Landscape%20Water%20Management%20Training%20Manual.pdfHi,
Take a look at my first posting in the other thread where I include a link to my code. There’s a stand-alone simulation that shows the approach I’m taking. I adjust the frequencies of the waterings, not their durations.
The WeatherReach station map is here: http://access.weatherreach.com/map_stations. I see they have a station in Buffalo, NY. Perhaps this would be close enough to you? The key piece of data is the solar radiation, so if you can get that from WeatherReach or some other source, you can calculate ET from other weather data that is widely available (temps, humidity, wind). The solar radiation value on the ExactET site might be correct even if the rain measurement isn’t. Also, Weather Underground can store solar radiation, but most home weather stations don’t report this info. Still, might be worth checking WU stations near you to see if any do. Cloud cover has a big effect on solar radiation, so the main consideration would be whether the sky conditions at the station usually match those at your location.
Davis sells a solar radiation sensor for their weather stations for around $150. I wonder if it would be possible to put together a low cost sensor for the Pi that would generate “good enough” estimates for solar radiation, for cases where budget matters more than total accuracy. Even a simple solar cell might do the trick when combined with formulas that estimate the clear sky radiation value based on location and date.
I just found another Python program to calculate ET, via Wikipedia:
http://test.oncrete.gr/static/progs/eto-2007-10-13.tgzAn aside: Not to get too pedantic, but I just realized that in the various papers the subscript following ET is the letter O, not the number zero. I had assumed it was a zero since it’s a reference value, and other values like ETc – the crop ET – are calculated from it. Anyone know what gives?
Hi,
See the additional discussion in this thread: viewtopic.php?f=28&t=564&start=10#p4134
I have a prototype that uses the water balance method and looks ahead one day for rain. Every midnight it generates a watering schedule for the day by looking at the running water balance (where ET is subtracted and rain and irrigation are added). When the balance is negative, irrigation is needed. However, if the forecast for the day calls for enough rain to make up the water deficit, the irrigation is not scheduled that day. The next midnight, the calculation repeats. If the forecast rain fell, then all is well and the watering delay was justified. If the rain didn’t come, the water balance will be even lower and watering will be scheduled unless an even larger rainfall is forecast for that day. The case not currently handled is if there is a large amount of rain forecast more than a day in the future. It would be easy to check for this; the concern is the uncertainty of the forecast the farther it is in the future, and the possible stress on plants while waiting for the rain. Also, looking more than one day out the check should include water depletion via ET, but I don’t know of a source that forecasts ET. I’m doing some experiments to predict ET, but it’s too soon to tell how accurate this might be.
Dan T.
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.
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
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?
Hi folks,
I’m new here. I got my OSPi a few months ago and have been experimenting with the software. This thread has provided a lot of useful information. The approach I’m pursuing now is to calculate a daily ET value using the solar radiation reading from a Weather Reach station about 10 miles from my house. I use other data (rain, wind, humidity) from my neighborhood (via Weather Underground) to calculate a more localized ET. Calculations using historical data yield ET values very close to those at Weather Reach, so using their values directly would be a reasonable simplification.
I came across this very informative document which covers a lot of relevant information and is easy to read:
http://irrisoft.net/downloads/manuals/Landscape%20Water%20Management%20Training%20Manual.pdfIt recommends a soil moisture balance or “checkbook” method for calculating an irrigation schedule. This technique keeps a running daily balance of moisture required that is increased by the day’s ET (water lost) and decreased by the day’s rainfall. When the depletion exceeds a particular threshold, irrigation takes place and the balance is decreased by the amount of water applied. This approach waters the same amount each time, but skips days when no irrigation is necessary. The idea is that when irrigation takes place the amount needs to be enough to penetrate deeply into the soil. I ran a simulation of this approach using historical data from last year and the schedule seemed pretty reasonable. During the rainy season there was no irrigation and during the driest part of the year watering happened every two to three days. I’m thinking I might use a base schedule based on this approach augmented by shorter but more frequent watering in zones containing shallow-rooted plants. I’m curious to hear what people think of this approach.
One of my pet peeves is having my sprinklers come on when there’s significant rain imminent or, worse, when it’s actually raining. To prevent this I plan to use forecast data to reduce watering when rain is likely. Currently I’m using the Weather Underground QPF (Quantitative Precipitation Forecast) value to adjust my watering times. I look out a couple of days and scale today’s QPF value at 100% and later days at lower values. I’m wondering if there might be an alternative approach where future ET values are estimated based on forecast conditions and the result integrated into the irrigation scheduling calculation. What approaches are other people taking to adjusting watering based on forecasted rain?
At this point I’m just simulating watering. Here in the Seattle area it’s common knowledge that the rainy season ends on July 5 (or later), so I’ve still got plenty of time to experiment.
Dan in WA
