ETo generated schedule

[davemiedema]

Hew user here, just learning this stuff.

I wrote my own sprinkler controller a while back using ETo data as well as how much the sprinkler had run. The approach I took was a little different and was wondering if there was interest and if so, how I could go about replicating it here.

As opposed to having a schedule that is manually configured (run all zones every 3 days for 30 minutes), it was valuable to have the system use the ETo data to know whether or not to run at all on a given day based on the ETo, how much rain has fallen and how much watering has been done.

Essentially, the ETo generates a debt (evaporation) and the rain fall and watering would generate a credit and if there was a deficit, the zones would run to offset that deficit for the next day.

In rainy or cloudy weeks, might never run at all.

I *think* in the OS model, this almost looks like a daily schedule in which the watering level can go down to 0% if there is no deficit.

Does the ETo and watering level take into account past days rain and past days watering (manual and automatic)?

Can the watering level be adjusted to 0% if there is no need to water?

Thanks!

Dave

[Roger]

I believe OpenSprinkler does exactly what you want it to.

The ETo method takes into account the previous 24 hours weather (temperature, humidity, rainfall, and solar radiation) to compute the “water level” required to replace the net deficit, if any. The resulting water level can be zero. (It’s also capped at 200%.) Note that the assumption is that the system is watering every day. OS doesn’t have to take into account the watering during the previous 24 hours because it’s always simply replacing the ETo loss, if any. Also note that the implementation expects that you have calibrated your sprinkler system so that it delivers “baseline ETo” at 100% water level.

The daily watering requirement is problematic for many of us. (Note: the Zimmerman method has essentially the same requirement.) Unfortunately, daily watering is prohibited in many parts of the western U.S. It’s also not appropriate for some types of grasses, e.g., Kentucky Bluegrass.

I’ve been working on a method to “accumulate” ETo loss, i.e., water level, and use the accumulated value to decide whether to water today and how much while staying consistent with various regulations, e.g., only water on specified days, don’t water within x days after a rain of .xx inches, etc. This is far more complex than I anticipated (catastrophic requirements creep).

I’m backing down to just my requirements: 1) accumulate the water level over multiple days (capturing the water level at the same time each day), 2) decide whether or not to run the lawn watering program (ignore all others) based on the accumulated water level (reasoning: I don’t want to water the lawn more often than every two days or less often than every four days, which is optimal for my clay ground and bluegrass), 3) force OS to use a specified water level when running the lawn program, and 4) run the lawn watering program twice on one day (if the accumulated water level would require watering more in a single session than the ground can absorb).

[The last requirement is because I live in a “high desert” area where the ETo baseline is .2 inches. If we have two “high” ETo days in a row, where the accumulated water level exceeds 150%, that much water in a single session would result in some just running off and not being absorbed, so it’s necessary to split that into two 75% sessions.]

Having a traditional green lawn in this climate is a luxury. I’d be smarter if I plowed it under, tossed out some native grass seed, and didn’t water at all 🙂

Rog

[davemiedema]

That explains a lot, I think! Thanks

But I am still confused since after my watering level at 187% this morning, and watering for 4 hours, the watering level is still at 187%. I would have expected it to go down due to the watering? I think I am still missing something about the baseline I think since it was not nearly hot enough today to warrant another 200% watering level.

I think what you are / I am looking for is a threshold watering level (don’t bother watering if level is below 90%) and then it would accumulate for a few days until over that threshold. Would keep it from running every day?

When I do a “baseline detect”, is that a baseline for my location that should not really change day to day? Or is that a computed baseline on a daily / hourly basis?

[Roger]

The watering level is the result of the weather over the previous 24 hours and has nothing to do with whether or not you watered. It’s always about the evotranspiration that occurred in the prior 24 hours, which doesn’t change just because you watered. Watering just makes up for what was lost.

The baseline detect does a lookup of your location in a huge table. The result is the average worst case day in the worst month of the year for your location. If you’re in the U.S., you can lookup the historic ETo by month for your zipcode at http://www.rainmaster.com/historicET.aspx. Once looked up by the OS weather-server, it should not change. Basically, it’s what you should calibrate your sprinkler system to deliver. More correctly, it’s what you watering program should deliver at 100%, evenly across all zones. You can use just about any other number, as long as you calibrate your sprinkler system and your default watering program to deliver that much. Using the baseline value detected means you are unlikely to ever need to run at 200%.

187% is a pretty high value. Has it been unusually hot and dry? I’m at 6300 feet outside of Denver, an area that is known as “high desert.” The baseline ETo is 0.2 inch. Those are the kinds of losses we have in July and August, when the temperature may exceed 100F, there’s no rain, the humidity is very low, there’s a fast, dry wind, and the solar radiation is off the charts. Unless you’re in a similar area, it’s blazing hot, the humidity is close to zero, there’s been no rain, and the solar radiation is intense, 187% is suspicious.

And, yes, I need, and a lot of other people need, a method that accumulates watering level and has some logic about when to water. Unfortunately, having studied the problem, I believe there are too variations in logic requirements to be practical to implement on a system that runs on a chip in a small device; the user interface would be extremely complex.

Rog 

[davemiedema]

I am in Ottawa, Canada, so not sure if the country is causing a lookup problem. My baseline is 2.82mm (0.111 inches) and has not been hot or dry here. Just barely getting into the 70s during the day and mid 40s at night.

I am a coder so if you can point me to the code I can take a peek on how it is working and may have some ideas.

Also, not sure if you are interested, but this was my previous version. Back when I wrote it, nobody published daily ET or even solar radiation so I had to compute it based on historical cloud cover and math. Maybe that has changed in the last 4 years.

https://github.com/davemiedema/envirotranspiration/blob/master/getWeather2.py

[davemiedema]

found it

https://github.com/OpenSprinkler/OpenSprinkler-Weather/blob/master/routes/adjustmentMethods/EToAdjustmentMethod.ts

[Chester Corcos]

Hey @davemiedema, did you end up getting around to this?

[Chester Corcos]

(blank message because I forgot to check email replies)

[Author]

Posts