OpenSprinkler › Forums › OpenSprinkler Unified Firmware › I'm thinking Mr. Zimmerman didn't live where I live › Reply To: I'm thinking Mr. Zimmerman didn't live where I live
Evapotranspiration(ET) is just about the only method of universally calculating watering needs. Penman-Monteith and Hargreaves are the 2 most widely accepted methods of calculating ET. There is a lot of math to calculate water lost by a plant, and it requires localized data, for the vast majority of the equation. In my experience using a site 30miles from me and my local (on my house) station yielded less than a 20% difference for the entire watering season last year. I live in CO along the front range of the Rockies (east side), and the weather here is crazy it can literally snow on one end of town and the other is 65F and sunny, so 20% seems as though it would be a good reference and a solid “universal method.” I have written the python part for the adjustment, now I need to work on how to increase the resolution of watering times on the sprinkler system, because you would essentially store a program with the number of seconds required to achieve 1mm of water coverage on your plant. Then you have to store a data set keeping the plant type (ie grass, shrubs/trees). These would then be multiplied by the calculated value, resulting in decent watering without much over/under-watering.
Forecast and actual precipitation was the hardest part to figure out, the way I did it was to assume the further out a prediction was the more incorrect it was by a factor of 2 (it is right or wrong, and each day has a greater chance to be wrong than right). It looks like this: predictedRainTotal * (1/day^2) * probabilityOfPrecipitation. Any rain forecast for the rest of the day is simply multiplied by it’s chance of rain. The Daily ET is then calculated and the 2 totals from above are subtracted. The program spit out will not water if it is currently raining, too windy, or too cold. It favors watering in the morning, to avoid mold and fungus growth in inherently damp localities, simply put it avoids putting the grass to sleep wet. The moisture in the morning cools the ground and reduces watering needs throughout the day. It will water in the afternoon on hot dry days if needed. For areas with watering restrictions you can set the time it starts the program and it will follow that.
All watering is calculated using yesterdays weather data, to allow for the greatest accuracy, and then adjusted using forecast data with less weight.
All watering methods are affected by wind, because high winds will pull moisture from the plant, watering during this time will cause the plant to literally “learn” not to conserve water. It will not close up and tighten cells near the surface of the leaf thereby releasing more water into the air. A tree that is overwatered during dry times will have a shallow root system under the same behavior. What subsurface watering does for you is conserve water through reduction of evaporation before it can be absorbed by the desired plant. While yes you don’t have to worry about the wind carrying the water away from the plant, you don’t want the plant to learn to sweat in the wind.
If you want to come up with an equation of your own the important factors to pay attention to are: Temperature(now and average daily), wind(now and average), Humidity(average), Sun Radiation reaching the ground at the site(this can be estimated pretty well), atmospheric pressure, actual and saturated vapor pressure(can be calculated well), and soil heat flux(pretty much needs to be calculated as measurement equipment is prohibitive). This will mean you can see how much water the plant has lost, then determine how much it needs.
Here is a link to the python script if you are better at working out how to get it to work with OS you are more than welcome to use it and call it your own. You will need python running locally to use it right out of the box. All the libraries used are included in the zip file, the file structure directly used by the script is setup though you may need to create a dummy file for the ET data and logs using todays epoch date(unix time/86400). You will need to edit the file to provide your own WU api key. Of course all these would exist on the OS and be transmitted to the remotely stored script during the getweather function, which would then return the info to the OS for use.
I have been fine tuning for almost 2 years in vastly different locations (AK, FL, CO, and South Korea), so hopefully it’s a good jump start to something useful. Currently I just run the script and use a cron job to edit the associated program on the OS.