Proposed Evapotranspiration Algorithm in 3.1.4 Beta

[Mark Sanctuary]

I was thinking daily runs if the "Irrigation inches" are above a determined threshold, then using a "every other day" schedule for the lower rate Evapotranspiration.

 

Lower Irrigation inches rate (ie. 0.05 to 0.25)

Sun Tue Thu Sat

1hr 1hr 1hr 1rh

 

Higher Irrigation inches rate (ie. 0.25 or greater)

Sun Mon Tue Wed Thu Fri Sat

1hr 1hr 1hr 1hr 1hr 1hr 1hr

 

Really if we want to get serious then we would need Michel to design the complete Irrigation module that all someone would have to do is point the module to the INSTEON EZFlora, set the crop types (ie. grass/plants/trees) and soil types (clay/loam/sand) settings for each zone/station and the ISY would do the rest.

[Mark Sanctuary]

You know really we are going to need the ability to do math and inject variables into the wait/repeat loops in ISY programs in order to do any major magic with this stuff otherwise its going to be ugly. Lots of separate programs to bracket the many different levels of irrigation runs.

[peterd]

[...] otherwise its going to be ugly. [...]

Mark -

 

I agree. We're all eagerly awaiting floating point variables and the ability to read system values (whether climate, dimmer levels, analog I/O from something like an EZIO8SA, or something we haven't even envisioned yet) into variables so we can calculate, delimit loops, etc.

 

Meanwhile, I think if UDI can implement the 4 variables we've proposed, we can relatively easily accomplish most of what one would want for a home landscape irrigation system.

 

For example, the way I plan to address the irrigation would be fairly simple if I had the Running Total Irrigation Inches. First, I figure out the drop in soil water level at which I'll irrigate (for simplicity, I'll use the 0.5" amount from the diagram). Then, figure out the run-time to deliver that amount of water (say 1 hour). My trigger for my zone timer program(s) will then be when the Running Total Irrigation Inches >= 0.5". Whether that results in watering daily, weekly or every 2nd or 3rd day (and I expect that the frequency of watering will change throughout the year depending on seasonal weather conditions) won't matter to me as long as I bring the water level in the soil back to where it was before the drop (at which point I reset the running total).

 

As long as when the daily totals are updated I'm hitting close to my target (e.g. 0.5"), I'll leave it alone. If I found out that (for example) the running total was typically getting to 0.45" one day and 0.6" the next, I'd just change my trigger to either >= 0.45" or >= 0.6" and adjust my run-time down or up accordingly. I figure after one or two such adjustments I'll find a balance where the drop in soil water level and the amount I'm watering are close enough (after all, what did we have before the ET calculations...).

 

Cheers,

Peter

[Michel Kohanim]

peterd/Mark,

 

Thanks so very much for the most thorough explanation and suggestions.

 

I can see there are going to be some confusion (especially on our part) as to what means what such as running total, average, subtracting rain today from ET (they might not have the same unit: rain today = inches, ET = inches per day). Since we are no experts in this field, the best way to get your suggestions implemented is:

1. Observe ET values, Rain today, Rain rate values from ISY for a week using an interval that you think is good (you can have them emailed to you)

2. Use your recommended calculations against the values in 1 and make sure they jive with some baseline ET calculator

3. Add soil type to the variables and make sure the values make sense

4. Provide us with an algorithm using these variables

 

Please note that we can store or take sample as frequently as WB's polling interval or as infrequently as 100 years at a time. The choice is yours. Please do not send a description of algorithm for everything will get lost in translation. Also, please do make sure you take into consideration conversion between different units of measures. It would be best if everything is calculated in metric system so that we have the same point of reference.

 

I am hoping that we can all agree on one algorithm and this would not turn out to be yet another Scene Status issue!

 

Thanks again and with kind regards,

Michel

[peterd]

Michel -

 

While I'd be happy to validate the values as you suggest in steps 1 - 3, it won't rain again where I live for another 6 months. Tomorrow I will sit down & write up what I would propose as algorithm, along with a bit of explanation/citations (I'll work to keep it brief) as to why I believe they're valid. Someone else will have to validate them observationally.

 

Cheers,

Peter

[Mark Sanctuary]

Peter,

Lets hash out the details here in this same thread then when we agree on the solution then send them over to Michel. Pseudo code, variable names, reference links, length of tracking, etc.

 

Michel,

No not the "Scene Status issue" again!

[Mark Sanctuary]

Also I was talking with my friend Mark from Johnson Controls about what we are working on and he mentioned he could give us some help on these formulas since this is what he is experienced in and does it all the time.

[peterd]

Lets hash out the details here [...]

 

Mark -

Agreed. Happy to have your friend look at this before we submit something to UDI. I suggest that once we've gotten things to where we're ready to put in front of Michel we can start a new thread along the lines of "Proposal for ET irrigation implementation" in the Product Requests forum.

 

 

Michel -

No need to try to parse anything else in this thread until we've hashed things out.

 

 

Cheers,

Peter

[Mark Sanctuary]

I suggest that once we've gotten things to where we're ready to put in front of Michel we can start a new thread along the lines of "Proposal for ET irrigation implementation" in the Product Requests forum.

 

Perfect!

[peterd]

Mark -

 

Have to step away from this for the next 6-8 hours, but this evening I'll try to post a 1st draft of what I think we're suggesting.

 

Peter

[Mark Sanctuary]

Here is an example I came up with for the WeatherBug GUI tab...

 

[Mark Sanctuary]

I have done some updates to the GUI idea above...

[Mark Sanctuary]

The more I read the more I wonder if we really need Plant Type in this setup because the ET is already figuring an average for this so soil type may be enough.

[peterd]

Mark -

 

Wow. That certainly looks like a fairly complete GUI for an irrigation controller. I'd love to have that implemented in ISY someday!

 

But - before we go too far down that path - I think we need to consider UDI's desire & resources for building a full blown irrigation sub-system. I'm concerned that asking for this as a complete package may push the priority of implementation very far down on their todo list. Also, to get to that level of completeness requires a lot of decisions before anyone gets to try things out and provide feedback.

 

On the other hand, I think we can get the ET data averaged rather than instantaneous, another variable or two factoring in rainfall and soil absorption and an accumulator or two - and have these in the next beta. (And - having these won't preclude a later implementation of a built-in scheduler such as what you've designed.)

 

I can already envision how I could use one or two more values (including at least one accumulator) to do 100% of what I would need without resorting to "ugly" programming. I do recognize, though, that my approach (fixed watering duration, variable frequency) and needs (rainfall is basically not a factor since we don't irrigate during the rainy season and it doesn't rain during the irrigation season) are different from what others want/need. That's why I suggested that UDI implement the math to factor in rainfall and soil absorption.

 

By the way, last season I used the more common (variable watering duration, fixed frequency) irrigation approach. It's only after reading up on ET that I now believe that watering for fixed time cycles only when the soil has reached a certain dryness is the way to go. But, if I understand correctly, you're planning to implement a more fixed frequency approach. Also, I'm not sure, but I think you're in an area where rainfall during the irrigation season is a factor. So, I'm looking to you to represent those things in the basic requirements for what data & calculations UDI would need to supply.

 

My question to you is: What's the minimum you think you'd need in terms of data (e.g. Daily ET; Daily ET - Rain Today; etc.) to enable you to write some reasonable (i.e. not particularly "ugly") programs to implement that approach?

 

Thanks,

Peter

[IndyMike]

Peter and Mark,

 

In a word - damn! You guys are all over this. I took a little time to read up on ETo and you guys filled two pages!

 

Now that I'm a little more educated on the subject (i.e. dangerous) I'd like to cast my vote for the Daily Eto as well (averaged as Paul put it). Most of the calculations available support this directly. It's difficult to find calculations to support hourly observations that don't require solar radiation measurements (we don't have this through weatherbug). The approximation that Michel provided previously does not appear appropriate for instantaneous measurements. It requires min/max temperature readings that are applied over the available sunlight hours.

 

I would think that most users would be concerned about the water loss "yesterday", rather than on an hourly basis. I might adjust my watering today if it were raining at the time. This is detectable through weatherbug. Beyond that, I would base my watering schedule on the previous day's ETo.

 

I do live in an area where rain and watering schedules are mixed. Due to the sandy/mix soil, I can get an Inch of water on Monday an require watering on Wed. My fixed schedules typically over water which produces a green "unhealthy" lawn with short root penetration. This is the situation that I'm trying to rectify.

[Mark Sanctuary]

Here is what I was thinking that you and I hammer out the conception of this module, the math, the algorithms, and all the sourcing to the documentation, then we might be able to get Michel to buy into doing it. I can tell you from my experience in the software field that implementing a preplanned design is much faster than doing it from scratch. Personally I don't want a hack for this since it will save my money with less water and it will be more reliable too. With a preplanned design coding the algorithms would take a few days, GUI work would take a few days, and debug plus testing is done buy us users. Michel what do you think? We will do all the heavy lifting and you implement the design?

[Michel Kohanim]

Hi All,

 

Thanks so very much for all the feedback. As I mentioned before, if you can all agree on a verifiable algorithm, then it shall be implemented.

 

Mark, this is an excellent UI but, unfortunately so, we cannot sign up for UI development especially something so elaborate. Just unit testing it is going to take weeks.

 

With kind regards,

Michel

[peterd]

Michel -

 

Thanks for weighing in on what's the scope of work you can undertake.

 

 

Mike -

 

I agree that "yesterday's" ETo is most significant. It looks like we're thinking along the same lines. PS, thanks for the LED/CFL + Insteon scope trace info over @ CocoonTech.

 

 

Mark -

 

I don't want a hack, either. However, I don't see the notion I envision for a next iteration of this beta as being a hack. Let me explain:

 

I'd start with a new Climate Module configuration variable, Soil Absorption. This is a percentage representing the relative absorption rates of various soils (sand = 100%, cement = 0 ). While I understand that this could vary from one irrigation zone to another, I think that will be rare and for most users a global value will suffice (at least for a 1st version). Note that for ease of understanding/use I've evolved from the notion of a 0 to 1 value to a percentage.

 

I think we all agree on turning the (currently instantaneous) ET value into a daily average: Daily Evapotranspiration. This can be tallied internally throughout the day (@ every WeatherBug update interval: ET_tally += instantaneous_ET; samples++). The daily average is calculated (Daily Evapotranspiration = ET_tally / samples) just before midnight (when the WB Rain Today value is at its daily max). All of the following values are calculated immediately after the Daily Evapotranspiration value as well.

 

Next, the ISY calculates the Daily Water Deficit (BTW, note that I'm avoiding naming anything using a specific unit of measure since I envision all of these values will be calculated internally in mm then presented in the user's choice of English or Metric). The formula is: Daily Water Deficit = Daily Evapotranspiration - (Rain Today * (Soil Absorption/100)).

 

Finally, we have Irrigation Requirement. This is simply a running total of water loss from the soil: Irrigation Requirement += Daily Water Deficit. Note that the one new notion that an accumulator adds to the ISY programming model is a way to re-init the value back to zero in one's program. My proposal here is simple. Have Irrigation Requirement (Irrigation_Requirement ? ) appear as a predefined choice within the Variable pulldown of the Actions in Program Details. The only allowable selection would be Init To and the only allowable value selection would be zero. (Of course I defer to UDI if they have a preferred way to handle this.)

 

Now, what's left for the user. Well, as is done today, write a program to step through the zones for a given amount of time on each irrigation valve. It's true that (at least in this initial version) the time calculation would have to be done (once) by the user outside of the ISY environment - no different than today.

 

The time is calculated to deliver a set amount of water to the soil. For this example let's say 1/2". Make the IF condition for this program be Irrigation Requirement >= 0.50, and add a final action which resets the Irrigation Requirement to zero. (This assumes that starting to irrigate at about midnight is OK. If not, then the IF can be moved out to another program which simply enables/disables the timer program, and the timer program itself would have a time-of-day test as its IF condition.)

 

This assumes that the irrigation strategy is a pure water replenishment strategy. From everything I've read this is the preferred way to use ET data. I've attached a table which shows how this strategy would play out in this example, and urge everyone to have a look at the Landscape Water Management Manual PDF (http://www.irrisoft.net/downloads/manuals/Landscape%20Water%20Management%20Training%20Manual.pdf) where it appears.

 

As I said earlier, I think this would be a great start for everyone to begin to get some experience with ET based irrigation. It's an easy migration path for anyone who already has an irrigation program running in their ISY. And, it's very likely to get implemented right away. Since UDI is not ready to implement a full-blown sub-system such as your (excellent) proposed design, please think about something like this as the next iteration implementation.

 

Peter

[Mark Sanctuary]

Mark, this is an excellent UI but, unfortunately so, we cannot sign up for UI development especially something so elaborate. Just unit testing it is going to take weeks.

Thank you Michel! I thought it wouldn't hurt to ask. At least the idea is out there now and maybe someday in the future it may be viable for UDI to build. I think it would even work as a separate module you could sell for $50 to customers, I certainly would buy it. After all to get this type of functionality from any of the separate irrigation boxes out there that do this cost over $300.

 

Peter,

I will answer your post in a bit, I have to help get the family out the door and want a bit more time to understand and read it over.

[peterd]

Mark -

 

I love the idea of the basic ET values being part of the climate module, and an optional Irrigation Module for a fully featured interface. This parallels the A10/X10 module nicely.

 

Peter

[Mark Sanctuary]

I'd start with a new Climate Module configuration variable, Soil Absorption. This is a percentage representing the relative absorption rates of various soils (sand = 100%, cement = 0 ). While I understand that this could vary from one irrigation zone to another, I think that will be rare and for most users a global value will suffice (at least for a 1st version). Note that for ease of understanding/use I've evolved from the notion of a 0 to 1 value to a percentage.

I agree lets go with a single variable for now for this. But as an example... my front yard must have been dirt that was brought in at some point to raise the front yard because its the most beautiful Sandy Loam. The backyard however is a beach, heavy in the sand department, and then 1 to 2 feet down its hard pan. When I run the front yard drip all the soil is nicely damp, however the backyard will have areas that are very dry. For now I can adjust run times in the programs and I am switching all the emitters over to 1 GPH to address the poor capillary of sandy soil.

 

I think we all agree on turning the (currently instantaneous) ET value into a daily average: Daily Evapotranspiration. This can be tallied internally throughout the day (@ every WeatherBug update interval: ET_tally += instantaneous_ET; samples++). The daily average is calculated (Daily Evapotranspiration = ET_tally / samples) just before midnight (when the WB Rain Today value is at its daily max). All of the following values are calculated immediately after the Daily Evapotranspiration value as well.

This is a must have. I would love both rain and ET to be a rolling 24 hour snapshot, I start my irrigation at 11pm because of how early we have to get up the next day. With a rolling snapshot of these variables midnight start times would not be required, but this may not be possible with rain being already accumulated for us.

 

Next, the ISY calculates the Daily Water Deficit (BTW, note that I'm avoiding naming anything using a specific unit of measure since I envision all of these values will be calculated internally in mm then presented in the user's choice of English or Metric). The formula is: Daily Water Deficit = Daily Evapotranspiration - (Rain Today * (Soil Absorption/100)).

I am not an expert in this, actually learning as we go... but I am not sure if this is how Soil Absorption fits into this formula. Should this be Allowed Depletion which is calculated from the Soil Type Factor and the Depletion Depth?

Allowed Depletion = (Root Depth x Soil Type Factor) / Wilting Point

Daily Water Deficit = Daily Evapotranspiration - (Rain Today * (Allowed Depletion / 100))

 

Finally, we have Irrigation Requirement. This is simply a running total of water loss from the soil: Irrigation Requirement += Daily Water Deficit. Note that the one new notion that an accumulator adds to the ISY programming model is a way to re-init the value back to zero in one's program. My proposal here is simple. Have Irrigation Requirement (Irrigation_Requirement ? ) appear as a predefined choice within the Variable pulldown of the Actions in Program Details. The only allowable selection would be Init To and the only allowable value selection would be zero. (Of course I defer to UDI if they have a preferred way to handle this.)

Looks good. Agree. Yes.

 

Now, what's left for the user. Well, as is done today, write a program to step through the zones for a given amount of time on each irrigation valve. It's true that (at least in this initial version) the time calculation would have to be done (once) by the user outside of the ISY environment - no different than today.

 

The time is calculated to deliver a set amount of water to the soil. For this example let's say 1/2". Make the IF condition for this program be Irrigation Requirement >= 0.50, and add a final action which resets the Irrigation Requirement to zero. (This assumes that starting to irrigate at about midnight is OK. If not, then the IF can be moved out to another program which simply enables/disables the timer program, and the timer program itself would have a time-of-day test as its IF condition.)

The length of each station run time is the part I see all this improving on with using ET. I would like to see this automated in the case of if Irrigation Requirement is low then the valve run time would be lowered too. I have an idea of how this would look but it does require several programs per station to do it. I will put together the programs I am thinking of and post them next so we can discuss them.

 

This assumes that the irrigation strategy is a pure water replenishment strategy. From everything I've read this is the preferred way to use ET data. I've attached a table which shows how this strategy would play out in this example, and urge everyone to have a look at the Landscape Water Management Manual PDF (http://www.irrisoft.net/downloads/manuals/Landscape%20Water%20Management%20Training%20Manual.pdf) where it appears.

Agree. The user should not have to be concerned by how many days, the frequency of those days, and how long the run time should be, because this can all be taken care of by using ET.

[Mark Sanctuary]

Next, the ISY calculates the Daily Water Deficit (BTW, note that I'm avoiding naming anything using a specific unit of measure since I envision all of these values will be calculated internally in mm then presented in the user's choice of English or Metric). The formula is: Daily Water Deficit = Daily Evapotranspiration - (Rain Today * (Soil Absorption/100)).

I am not an expert in this, actually learning as we go... but I am not sure if this is how Soil Absorption fits into this formula. Should this be Allowed Depletion which is calculated from the Soil Type Factor and the Depletion Depth?

Allowed Depletion = (Root Depth x Soil Type Factor) / Wilting Point

Daily Water Deficit = Daily Evapotranspiration - (Rain Today * (Allowed Depletion / 100))

Humph. Wait Soil Absorption has to do with how much of the rain was absorbed. Where is the formula for Soil Absorption based on rainfall? Looking...

[Michel Kohanim]

Peter/Mark,

 

Thanks so very much. This is all excellent information and we do not mind at all implementing the irrigation module. My only concern is that I still to do not know what to do with daily values: say, for the past 30 days. Are they averaged out?

 

With kind regards,

Michel

[Mark Sanctuary]

Lets discuss ET over time...

 

ET when collected at a weatherbug sampling is the picture of what is coming out of the plant and soil at that exact moment in time. Several samples are several moments in time. So which would give us an idea of what has left the plant and soil for a day?

 

ET average would give us an average of what has come out of the plan at a single moment in time.

ET average = (s1 + s2 + s3 + s4 + s5) / 5

 

ET sum would give us a total of all the slices in time which would be an idea of what has left the soil and plant for the day.

ET sum = s1 + s2 + s3 + s4 + s5

 

ET peak would be the highest point in the day.

ET peak = s1 > s2 ... etc

 

I think the formulas that we are looking at are using ET from a single moment in time so average seems like the correct choice.

 

I think we want to know what has happened for ET over the last 24 hours because we are thinking each day we are going to evaluate the water deficit each day and run accordingly. Maybe this could be an option for the user to adjust?

Sample length = 1440 minutes

 

Peter, does this agree with what your thinking?

[peterd]

Michel -

 

Re ET over time. I think Mark's right that when you have access to realtime data the daily average is the significant number. The reason you see monthly averages is that if all you have to go on is historical data you're relying on an approximation and want to smooth the outlier values. On the other hand, out irrigation systems want to know that, for instance, today's been an especially hot day so we've had a higher daily ET than a historical average and will be watering sooner.

 

As to the idea of allowing the user to determine the timespan for the average, unfortunately this breaks using the Rain Today value which is supplied by Weatherbug and resets every 24hrs.

 

Mark -

 

I'll post more shortly re your earlier post.

 

Peter