OpenSprinkler based on Eto

[yellowgecko]

Please note: I created a pdf that has some graphs in here, but the forum makes it quite tedious to add images, hence the pdf has the graphics and here is only the text. The pdf is in the attachement also the script described below.

ETo based irrigation system

Hi,
I started to discuss this with a forum member [IAN- thanks for all the links to get me started], how good would it be to have the OSPI using actual Eto (Evapotranspiration data) and not relying on the current (at least not for me working) Zimmerman approach.
I started to create such a script, but the approach is currently only a monitoring one – meaning the control of the sprinkler (via api calls is not there yet). This lengthy post is merely to get some ideas/feedback if people think that the approach could also work for them.

I created a script (attached below) using R [which runs on a pi] to fill in the values of the table below:

[see pdf]

It loads available data from the Australian Bureau of Meteorology [which provides Eto for previous days] and for the days where those are not available [the most recent] and future days I use formulas to estimate Eto (those formulas Penman are using Tmax and Tmin, humidity and cloud cover to predict the Eto in the coming days. Not ideal as best is to use solar radiation and estimates tend to be too low.). I do also download daily rainfall data.
The convenient bit is that Eto is in mm (loss of water from my lawn in a day) and so is the rain data (mm added per day)
Then I grab from my OSPI the sprinkling times (I have a drip system, hence I called it driptime) and I convert those times into [mm of water added]. The rational is simply I have about 1000 drip holes in my hoses and each drip hole distributes 2 l of water per hour. Hence on a 100 square meter lawn I drip 2l * 1000 drips = 2000 l per hour, which equates to 20 liter per square meter or 20 mm.

Hence in principle I have now a complete water balance, as all my water losses and additions are in mm.

Waterlevel lawn= (rain+drip) – eto (for each day)

There are some corrections to be done (e.g. a dripping system has only ~90% effectivity and actual Eto can be converted into Etkc (the need of a certain crop type, as Eto is a reference evapotranspiration) and for lawn this means that Eto is multiplied by 0.7. E.g. I found some reference that for sports fields you do not want to “replace” 100% of the water but 70% is fine. At least that is what I found in the literature. Any comments here?

So in essence
Waterlevel = (rain +drip *0.9) – (eto * 0. 7)

For those of us that are more graphical the whole thing looks like:
[check pdf]

black line: water level, red dotted line: ETO, blue bars: sprinkler, purple bar: rain
[All units are in mm.]
Today we have the 11th, hence I grabbed all the bom data from the previous 8 days (starting at the 3rd and used openweathermap api data to estimate Eto of today (BOM has unfortunately a delay and provides the Eto estimate only at 3 pm the following day) and also to check the predicted rainfall in my area.
As writing this the predicted rain of 9.26 mm just started, hence my water level will increase most likely if the predicted Eto of only 2.83 is correct. Hence I would most likely decide not to sprinkle in the next days.

Why do I write about this? Unfortunately the script is quite Australia specific, but if you are in Australia and apply for a free OpenWeathermap api the script should run fine and feel free to try it (a zipped version is attached, simply add your location and apis and sprinkler password etc. at the top).
The good news would be, that anyone basically could try to create an identical table for their local conditions using whatever method and then we could aim to develop how we would like to control our sprinkler as this becomes tricky. For example it is not too hard to edit the values by hand for someone who has not those coding abilities and then the table can be used by the opensprinkler (in the best case new firmware)
As mentioned the link between the table and how the sprinkler should be controlled is the tricky bit. In terms of coding it is simple, either use api calls to do so or at some level it would be integrated in the firmware ( as simple switch controlled by Eto table, preferable with some fail save tests/procedures.).

Here are my admittedly vague thoughts how such a system might work:
Aim: An efficient system (in terms of saving water) that sprinkles to have a healthy garden and to save as much water as possible.

For example, I am not 100% sure how should I determine my absolute water level. As currently I just look a certain number of days in the past (you can specify this number) and follow the relative change in the water level over days, but this is not the absolute level. One way to mitigate this would be to water the lawn to 100% at a certain day (e.g. I estimate my lawn to be “full/saturated’ if 20 mm of water is applied). Then I could use those changes from the reference day onwards and I would have an absolute water level.

if the water level is then predicted (or actual) to be below say 5 mm I would water my lawn (but only if no rain is predicted in the next 24 or 48 hours. So the sprinkler would be 100% controlled from the script. This is probably a bit risky all the “errors” on the water level estimates would accumulate over time. So maybe a good idea is to reset the levels to full if there has been a lot of watering/rainfall.

Another way to program the sprinkler would be to have a fixed program that serves as a baseload and guarantees the survival of the lawn. For example every 3 days 5 mm of water is added. And the script would only moderate the number minutes if there is rain predicted or the water level falls below say 0 mm. [basically a Zimmerman approach using Eto]
Any hints how the sprinkling is managed by other systems would be highly appreciated.
Surely someone has already implemented such a system.

For all Australians I attached the script that produces the table in the zip file

Any comment are most welcome.

Attachments:

1. eto_forum.pdf
2. dripper.zip

[Anonymous]

I have almost created a similar system on thingSpeak. I have a vineyard that is watered by Open Sprinkler. I currently have it completed but cannot get the command to update the watering percentage to work.

I use the calculation Irrigation (mm) = Evapotranspiration since last irrigation x Crop factor – rain.

The user then needs to simply refine the crop factor to their specific circumstance. There is information on readily available on how to do this by, observing the plants, digging hole to see how far the water and the roots go, or use soil moisture monitoring at various depths. Published crop factors vary massively for the same crop and vary over the time of the year according to the growth of the plant, so tuning this factor gives heaps of customisability. e.g. 0.25 early in the season, 0.4 to 0.7 for vines in peak growing time – so any attempt to fine tune the irrigation process needs to include some tuning by the irrigator to there specific circumstance.

There is a lot of material on irrigating using crop factor on this site if its of interest to anyone:- https://www.agric.wa.gov.au/water-management/evaporation-based-irrigation-scheduling

Providing a “base load” or feature where a fixed amount of water is provided is probably worth while as a protection against underwatering – I have some Pots where i do this on a separate timer and for shallow rooted plants it might be worthwhile.

What “language” is the script written in ?

[Anonymous]

Thanks for your kind words!

My only comment would be that the plants will get used to whatever you set, if it’s consistently high and the water stops they will suffer more.

My aim is to minimise water application so my plants don’t die, others might want them looking more lush and green.

[kdeuler]

Hi. I just found this thread. Thanks for the information.

I’m wondering: Aside from the “evapotranspirational” calculations and weather prediction approaches, are there not solutions that rely on using moisture detectors placed in various parts of a garden to determine if watering is needed or not? If you recommend this approach for some situations, and also recommend particular hardware, I’d be interested in your comments.

It seems to me that direct moisture measurement (eg via say a device calibrated to measure electrical resistance in the soil) would be quite effective in stopping or reducing sprinkler activity during the a rainy period.

Thanks in advance.

Kurt

[DoItAllDad]

Is there any post discussing (or suggesting as a feature including) a crop water requirements (crop coefficient, Kc) based on time (date) which can be assigned into the future for a particular program? Perhaps Coupe Pete is working on this feature?

That would be immensely helpful for integration into OpenSprinkler for the intermediate gardener or homesteader with a goal of set it and forget it automation for edible crops like vegetables. My example is for central Florida, where the university extension has published several papers on irrigation, including:

How to Determine Run Time and Irrigation Cycles for Drip Irrigation https://edis.ifas.ufl.edu/ae500
Principles and Practices of Irrigation Management for Vegetables https://edis.ifas.ufl.edu/cv107

First, some crops at their early stages don’t require as much water, but as they grow they need more (which Coupe Pete rightly notes). The change in crop coefficient for vegetables as they grow, for example, is considerable (ranging from 0.2 to 1.0). Including within a watering program an estimated or expected changes in crop coefficient over time would be particularly useful for more precise irrigation for certain types of plants over a multi-month schedule or growing season.

Also important to determining proper run time for an irrigation event is the water holding capacity of the soil. In some ways, I think that’s currently just fine-tuned based on initial setup by a user, and may not require changing the code to account for soil type. Thought I note a soil moisture sensor may not accurately reflect overwatering and thus leaching from the soil and wasted water. This is especially important for setups including periodic liquid fertilization to avoid leaching macronutrients into the local water supply (e.g., algal blooms). The overall goal is precise delivery of water volumetrically, based on ETo and Kc. ETo appears to be already integrated thanks in large part to contributions from ShawnHarte. But Kc is dependent on the stage/age of the plant or crop, and I don’t currently see a way to integrate that into an advanced weather based program using evapotranspiration.

So, I guess I’m wondering if we can develop a plant-based crop coefficient into a program, where a user inputs Kc values based on time? I would love to contribute with some dev/programming work, but have neither the time nor skillset to efficiently do so. If Coupe Pete is already working on (or has finished) this feature, maybe I can help get the ball across the goal line.

[Author]

Posts