peterd

Unfortunately not possible since Rain Today is a WeatherBug supplied value which resets at midnight. Using our example of 0.5" deficit being the point at which you'd irrigate, if you find that your runtimes to deliver that 1/2 inch of water are too long (run too far into the morning), but you're typically reaching that deficit say every 3 - 5 days, you might want to cut both your runtimes and the trigger point you set by 1/2 or 1/3 and just let the system water more often but for shorter times (shorter cycles seems to be where the current thinking is going anyway). Me neither! I think Allowed Depletion is actually how we'd figure out at what point (how much of a water deficit) we'd irrigate. I've been using 0.5" (since I had nice diagrams & tables for that value) as an example, but as each of us figures out the allowed depletion for our situation we'll know the absolute maximum deficit we can accumulate before watering. I think the presence of various plants and soil types within our landscapes means we'll have to come up with a number which satisfies the least drought tolerant plant (in the most porous soil) which we have. (As an aside, don't forget that lots of the ET research is done with an eye towards irrigation a single crop!) Maybe I should have named this "Soil Absorption Factor" or "Relative Soil Absorption." (But don't really want to as it gets wordy. Maybe just "Soil Factor"?) We're not actually specifying this as for instance "inches absorbed per foot of rain" (an absolute absoption value for a particular type of soil). Rather, this is an adjustment based on the absorption ability of various types of soil relative to sand. Peter

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

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

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 - 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

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 - 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

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 - 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

Mark - Glad you're "liking" my post. Hope Michel does, too. By "doing the math for Irrigation inches now" I assume you mean having UDI implement the value I am calling "Daily Irrigation Inches." That's sufficient for one of the 2 approaches to irrigation (fixed frequency - e.g. daily - with varying duration). For the other (fixed duration with varying frequency) the "Running Total Irrigation Inches" is the equivalent. Note that this requires some way to reset (or decrement) the running total in the program once irrigation completes. I do agree that in the absence of floating point variables the value of the ET data increases by an order of magnitude if UDI implements the ET minus Effective Rain calculations. I also would strongly urge the implementation of running totals, as this is also extremely difficult to do in ISY programs today (w/o floating point variables), and covers the other major school of irrigation thought. Peter

Just as a P.S. to my earlier post, if the ISY implemented an Absorption Factor based on soil type. Assuming Sand as having the highest absorption (i.e. 100%), the factors for the major soil types (based on their relative absorption rates in inches/hr) would be: Clay 0.17 Silty Clay 0.25 Clay Loam 0.33 Loam 0.58 Sandy Loam 0.67 Loamy Sand 0.83 Sand 1 Peter

Michel - First, a big thanks for implementing this. When we were discussing finding a public domain source for the algorithm, I really didn't anticipate this would make it to beta w/in such a short timeframe. I'm also happy to see from the discussion here that you're looking for input to change/refine this during the beta. I'll begin by saying that I'm no expert on ET (still learning along with many of us), so please accept this as my humble opinion based on what I think I've learned so far. I know this is a long post, but hope it will help all of us refine our understanding of this subject. For all the complexity in implementing this, the concept is simple. Quoting the PDF I mention below, "An ET-based control system manages the irrigation system by calculating water lost from the landscape, measured in inches and then replaces lost water using the irrigation system." Here are the resources I've found most helpful: The best single info source I've found is the Irrisoft website http://www.irrisoft.net/wr/insite.cfm. They have a download-able "Landscape Water Management Manual" PDF which explains ET and irrigation very well. They also have a program "InSite Irrigation Scheduling" which is free to use with historical ET data (they make their money on subscriptions to live ET data). This diagram from the Irrisoft PDF shows very succinctly how a daily ET reading can be used to determine how often to water and how much water to deliver. (Of course we have to figure out how to translate "how much" into "how long" to run the irrigation, but I'll get to that in a minute.) So, based on this it seems that the instantaneous value doesn't help directly. When I track this value w/in the ISY, I see great variations over a short time (as sun and wind conditions change). And, according to the Irrisoft manual, the ASCE formula you've implemented requires hourly readings, and the daily number seems most useful in calculating irrigation frequency and system run-time. The diagram mentioned above does simplify out one factor. As Mark points out, the daily rainfall total should be subtracted from the daily ET value to give a final daily number representing the water loss for the day. However, since rainfall rates and soil types have a huge effect on rainfall absorption, maybe this should be done in user code. (For example, the same daily rainfall total can mean something far different in terms of its impact on daily irrigation requirements depending on not only soil (e.g. clay vs. sandy), but also how fast the rain has fallen. The entire daily total falling on clay soil within an hours time could have a negligible effect on irrigation needs, while the same amount falling on sandy soil spread over 24hrs could result in a surplus delaying irrigation for one or more days.) Ideally, once we have floating point variables, this will be no problem. (BTW, with only integer variables currently, I understand Mark's request for this calculation w/in the ISY, so it may be worth including. And that alone might be sufficient for some folks, but doesn't take into account irrigation less frequently than daily.) Here's what I think would be most useful to have w/in ISY: A daily ET value (averaged out from at least hourly readings), calculated at a time of day just before the Weatherbug daily rainfall total resets (so both daily values can be examined at once) - just as Mark suggests in his pseudocode. And, a running total of daily ET readings, with a way to programmatically reset the total. (I used to believe in daily irrigation, but the more I learn about the subject the more I think it should be only once every several days, thus the running total...) For those of us who live in areas (such as my location in the SF Bay area) where 99% of rain is confined to a rainy season (and no irrigation happens during that time), the running total would be enough. For those who live in areas where it rains on and off throughout the year, the daily number can be used along with the daily rainfall total to implement a set of programs to account for rainfall rates, totals, and soil absorption ("Effective Rain"). Or, per Mark's suggestion, a built-in rain subtraction used instead. What would make that approach really slick would be a place in the configuration where a user could input a soil Absorption Factor (value 0 to 1, defaulted to 1) so that the irrigation inches total presented would take into account Effective Rain. If going down that path, you could have 4 values in the climate module: Daily ET, Running Total ET, Daily Irrigation Inches (Daily ET - (Rain Today * Absorption Factor)), Running Total Irrigation Inches. I think with those 4, it would be easy for anyone to implement as simple or comprehensive an irrigation strategy as they want, either daily or less frequently. How I would use this is as follows. First, I'll use the InSite program to figure out the baseline for irrigation (how much water does each zone deliver per minute, how does soil absorption affect this, what are the differences in water requirements based on different types of grass/plants/trees in each zone, etc.). Once I have a baseline for the driest month of the year (and the historical ET value this is based on), I'll create my irrigation timer program(s) for the ISY, with the times calculated to deliver a specific amount of water (in inches) to the landscape. Finally, I'll create the trigger program(s) which will look at the running total ET (or Running Total Irrigation Inches) to determine when to irrigate (and reset the running total). I think figuring out how often to water will be enough, but if it turns out I need to adjust the run-times for the various zones based on different ET & rain rates I'll use the daily ET (or Irrigation Inches) values to set a "scaling factor" as a multiplier to use within the timer program(s). Hope this helps. Peter

Michel - I'm working on an in-depth post, but first a question: Which of the calculations from the paper you reference have you implemented - ETh (as described in Step 4), ETos (as described in Step 5) or ETrs (as described in Step 6)? ETos would be the obvious choice as it is calculated for grass (lawn). (As an aside, I find their labeling of these confusing as it seems that after Step 3 it should be 4a, 4b or 4c - since these are 3 different calculations.) Cheers, Peter

Mark - Yes. Your post appeared just as I was editing mine for clarity. See revised post. Peter

Mark - Exactly. But if the ISY is keeping the tally, I wouldn't subtract the rain before presenting the ET total because of the differing soil absorption rates. Peter

What more can one ask for! Thanks, Michel. Peter

Michel - Since Spring is in the air, now's the time for implementing irrigation systems. Any chance this will make it into a 3.1.x beta? Thanks, Peter

Michel - This is great news! Glad I could help. I really do believe that having a sophisticated yet user-friendly irrigation capability which leverages the ISY's existing capabilities (location awareness, climate module, etc.) can be a significant differentiator against competing HA controllers. I'm building out my HA system now in stages, and will be tying in the irrigation over the coming weeks before spring arrives. I look forward to beta testing this functionality. Peter

Michel - It took some digging, but here's what I've been able to find. On this UN FAO page: http://www.fao.org/nr/water/eto.html is a public domain program for calculating ET. Among the program's downloads is the reference manual. This manual (which has no copyright notices that I could find) reiterates that the software is public domain. One of the chapters in this manual lays out all the formulas used in the program including the FAO Penman-Monteith equation. It would seem to me that if the software is public domain and the accompanying (non-copyrighted) documentation spells out the algorithms used, then those algorithms must themselves be unencumbered so reimplementing them elsewhere should be completely legal. Have a look and see what you think... Peter

Michel - First, thanks for the prompt reply. While I can understand where the various papers published which cite the algorithm would be copyrighted, I can't comprehend why the Food and Agriculture Organization of the United Nations would adopt and recommend an algorithm which would not be freely available. Are we certain that the algorithm itself is copyrighted under a "closed source" license? Peter

Michel - I'm considering using my ISY-99i to control irrigation. Before I purchase EZFloras... Has this calculation ever been implemented? Where would one see it w/in the admin console? I haven't purchased the WeatherBug module yet. Will I need to have this installed to see the ET calculation results? Thanks, Peter PS - Love my ISY. Way to go UDI!