Suggestion: weekdays/interval dependent on calender month

[Arnd]

After having opensprinkler installed – and enjoying the new controller very much – I have done some reading in order to determine the amount of water the grass needs on our specific soil and sprinkler operation duration and intervals. One interesting read was an university paper Watering Home Lawns, how much and how often. They basically say that you should always water the same amount of water but in the hot months you should water more often (see page 5).

In my view open sprinkler with its wunderground connection does make sure that the water amount is roughly the same if you consider “rain + artificial irrigation” as the water amount. What is missing is the flexibility to run the sprinkler on more or less days depending on the month of the year.
Of course it is not that complicated to have three different programs e.g. “Spring/Autumn Interval every 4 days , Summer 3 days, Hot Summer 2days” but then you would have to remember changing the program in the appropriate month. It would be nicer to just have one program where I could specify either the interval in days or the weekdays based on the calender month. This would automate everything.

Question: Do you agree with the assumption of the paper that the interval should be changed based on the month of the year? If so would it be feasible to implement this in a future release of OS?

Arnd

[Ray]

The current Zimmerman method considers the combination of temperature, humidity, and precipitation to determine the watering percentage. In a way it does take into account the time of the year, because during the summer the average temperature is higher whereas during the fall and spring the average temperature is lower.

It’s pretty easy to introduce a feature such as ‘monthly watering percentage’, but my worry is that it’s a manual setting and will introduce some confusions to users, whereas the Zimmerman method is supposed to be more automatic.

[Arnd]

Yes I can see that Zimmerman does have an effect, but only on watering duration of a run.
In this paper they stipulate that you shouldn´t increase the Irrigation Duration (as the grass roots can only soak a specific amount of water, more would be overwatering). They claim that the watering frequency should be increased inststead. Well, I am no Irrigation expert so maybe Zimmerman might already ba sufficient, anyway; on the other hand it seems quite convincing what they are saying.
What I would do: I would use the Zimmerman method and the “monthly modification factor” simultaneously (with lower Zimmerman Settings for Temp and Humidity and 100% for rain). So Zimmermann would determine the Irrigation Duration, taking into account the rain and the month correction would determine the frequency of the Irrigation (every n days).
As I said, I am not an expert at all in Irrigation, so this might be plain wrong 🙂

[Phil Maron]

I’d like to add my 2c to this discussion because I have been thinking exactly the same thing. I have been in the habit of either changing the frequency of my programs for the different seasons or creating seasonal programs and enabling/disabling as the seasons change. I’m not convinced that the Zimmerman formula by itself handles the needs of my garden all that well. In any case, I’d support the call either for programs to be automatically enabled/disabled for specified periods or for individual programs to provide the capability to set different parameters for set periods. I’m not sure which would be simpler to implement but I suspect that automating program enablement/disablement would probably be simpler.

Phil

P.S. One reason why this becomes necessary is for situations where you have plants being watered under cover. i.e. they don’t get rain! In that scenario I have ignore rain set for that particular station but I can’t set it to discount the rain component of the zimmerman formula for a single station. In reality, adding the ability to discount individual components by program would be another major bonus.

[Ray]

OK, let’s think if there is a general way to accommodate the different application scenarios. To begin, here are what’s currently supported:
– Weather algorithm, which is a global setting. Currently the supported algorithms include manual, Zimmerman, the auto rain delay. Among them, we added support to adjust the weights of the three weather factors (temp, humidity, rain) of the Zimmerman algorithm. It’s certainly possible to add another weather method called ‘seasonal adjustment’ where the user can manually set the watering percentage for each month.
– The per-program ‘use weather’ flag, which controls if the watering percentage is applied to the program or not.
– The per-station ‘ignore rain’ flag, which controls if a station observe rain delay / rain sensing or not.

From what Phil describes, there seems to be additional need for either a per-program choice, or perhaps even per-station choice of weather algorithm, meaning each program (or station) can choose which weather algorithm to follow.

There is a tradeoff between making the weather support more flexible vs. making the UI clean and less confusing. So I am trying to think of the simplest way to get the majority of the needs covered here.

[Phil Maron]

Yes I can see that the lower the level at which you provide choice the harder it would be to keep the UI clean. That said, I do think that providing these options at as low a level as possible does give greater flexibility. Maybe you could provide a way to add customised versions of the zimmerman formula where percentages are applied and allow these custom versions to be attached to stations within programs or at least to individual programs? The seasonal thing might be best dealt with by having the ability within programs to select the months when the program is active. Anyway, I’m sure my understanding of how it works is fairly simplistic and you will be much better placed to understand what will work and what won’t but thanks for taking the time to consider the options.
Cheers,

Phil

[Ray]

OK. Thanks for the suggestions. We will put it on the todo list and think about how to address it in future firmwares.

[Author]

Posts