peterd

OOPS! Back to what I said about variable names, renaming these helped me see how to fix it. (To be honest, it's quite late and I'm not 100% positive this is right but I think so. Please check this & see.) // At 23:59:59 Post_Previous_Calc_Partial = Rain Today - Pre_Calc_Partial // When "Perform Irrigation Calculations" command runs Pre_Calc_Partial = Rain Today Total_Rain = Pre_Calc_Partial + Post_Previous_Calc_Partial You do raise an interesting point, though, about the consequences of irrigation calculations being performed multiple times within 24 hours. My suggestion is to prevent this within the code. I've updated this below. I've incorporated a bit of leeway (22 hours instead of 24) for times when the user might adjust the schedule a bit. I don't think running the calculations early by a bit (< 10%) will throw things off enough to matter. Daily, when the user's irrigation program issues the "Perform Irrigation Calculations" command: // Do not allow the values to be updated if the last run hasn't been at least 22 hour ago IF Time_Now - Time_of_Prev_Calc < 22:00:00 THEN return // no update at this time ELSE Time_of_Prev_Calc = Time_Now // Assign new value to Total_Rain based on whatever rain occurred between previous daily calculations and 00:00 plus Rain_Today since 00:00. Pre_Calc_Partial = Rain Today Total_Rain = Pre_Calc_Partial + Post_Previous_Calc_Partial // Calculate average for past 24 hours Daily_Evapotranspiration = Evapotranspiration_Tally / Sample_Count // ...and reset tally Sample_Count = 0 Evapotranspiration_Tally = 0 // How much water left the soil in past 24 hours? (may be negative if more rain than evapotranspiration occurred) Daily_Water_Deficit = Daily_Evapotranspiration - (Total_Rain * (Soil_Absorption_Factor / 100)) // What is the running balance of water to replace through irrigation? Irrigation_Requirement = Irrigation_Requirement + Daily_Water_Deficit // May NOT be negative (soil can't be > 100% full of water) IF Irrigation_Requirement < 0 THEN Irrigation_Requirement = 0

You've got it! Exactly!

OK, here goes. Note: All variables dealing directly with water are in units of depth (mm internally, entered/presented as mm if Metric presentation chosen in Climate config or as inches if English chosen) Variables In the Climate Module configuration: // The amount of water the user's irrigation program applies to the soil during each run. Water_Applied_per_Irrigation = (Value entered by user) // To adjust for the differing ET in inland vs coastal areas. Region_Factor = (Value based on location selection by user) // To adjust for the relative efficiency of soil absorption // Used by ISY only for absorption of rain - the user is responsible for factoring this into the irrigation run-times in their program. Soil_Absorption_Factor = (Percentage selected by user) Internal to ISY: // A single instantaneous ET calculation result Evapotranspiration_Sample // The sum of all Evapotranspiration Samples since the last Daily calculations Evapotranspiration_Tally // The number of Evapotranspiration Samples since the last Daily calculations Sample_Count // Allow WB's "Rain Today" (a midnight-to-midnight total) to be used for Daily calculations whenever the user's irrigation program requests Total_Rain Previous_Rain_Total Available to users' irrigation programs: // The average of all Evapotranspiration Samples since the last Daily calculations Daily_Evapotranspiration // The Daily_Evapotranspiration less whatever rain has been absorbed by the soil since the last Daily calculations // This is a signed float and can be a negative value in the event of lots of rain Daily_Water_Deficit // A running balance (can span multiple days) of Daily_Water_Deficit since the last time the user's program triggered a decrement or reset. Irrigation_Requirement Algorithms At each WeatherBug update: Evapotranspiration_Sample = // EXISTING INSTANTANEOUS ET CALCULATION HERE // Keep a running total (not a running average) of all samples for a 24 hour period Evapotranspiration_Tally = Evapotranspiration_Tally + Evapotranspiration_Sample Sample_Count = Sample_Count + 1 Daily at 23:59:59: Previous_Rain_Total = Rain_Today // Rain_Today is the existing WeatherBug variable Daily, when the user's irrigation program issues the "Perform Irrigation Calculations" command: // Assign new value to Total_Rain based on whatever rain occurred between previous daily calculations and 00:00 plus Rain_Today since 00:00. Total_Rain = (Previous_Rain_Total - Total_Rain) + Rain_Today // Calculate average for past 24 hours Daily_Evapotranspiration = Evapotranspiration_Tally / Sample_Count // ...and reset tally Sample_Count = 0 Evapotranspiration_Tally = 0 // How much water left the soil in past 24 hours? (may be negative if more rain than evapotranspiration occurred) Daily_Water_Deficit = Daily_Evapotranspiration - (Total_Rain * (Soil_Absorption_Factor / 100)) // What is the running balance of water to replace through irrigation? Irrigation_Requirement = Irrigation_Requirement + Daily_Water_Deficit // May NOT be negative (soil can't be > 100% full of water) IF Irrigation_Requirement < 0 THEN Irrigation_Requirement = 0 The user's irrigation programs: // Program 'Irrigation Scheduler' (Enabled) If Time is 11:00:00PM Then Trigger 'Perform Irrigation Calculations' Run Program 'Irrigate If Needed' (If) Else - No Actions - (To add one, press 'Action') // Program 'Irrigate If Needed' (Not Enabled) // The IF condition decides whether to water by comparing the Irrigation Requirement balance to a constant // The user is responsible for setting this constant equal to Water Applied per Irrigation // (and updating it if they change the value of Water Applied per Irrigation in their configuration) If Module 'Climate' Irrigation Requirement >= 0.5 Then Set 'Front Yard' On Wait 10 minutes Set 'Front Yard' Off Wait 3 seconds Set 'Back Yard' On Wait 5 minutes Set 'Back Yard' Off Trigger 'Reduce Irrigation Requirement' Else - No Actions - (To add one, press 'Action') // The final THEN action (after the irrigation zones all run) triggers ISY internal calculation of: // Irrigation_Requirement = Irrigation_Requirement - Water_Applied_per_Irrigation Please understand that in the absence of any proposed syntax for the system commands within programs I have arbitrarily written those lines of ISY code using a fictitious keyword "Trigger." I will happily edit my post as soon as Michel lets us know what the syntax of these commands should be.

Well, unlike Irrigation Requirement, Water Deficit doesn't accumulate past a single 24 hour period. I think this is the point I've been trying to make, but we'll see momentarily when I post the algorithms. Well, I think it's important to keep in mind that while WB imposes a definition (and behavior) on their Rain Today value (accumulative throughout the day, then reset after midnight), we don't have to treat our rain tally the same way. I'm not trying to force-fit anything, but I actually think there's a certain elegance to the approach. Let's look at the algorithms, and if you can please post proposed syntax for these 3 commands, we can work up some sample irrigation programs to see how straightforward (or not) it looks. Peter

Will post algorithms later today.

Mark - I want to offer the following "food for thought" on "nice to see" variables updated throughout the day: The ISY has X amount of hardware resources (CPU cycles, RAM, etc.). While each additional calculation may use a minute amount of processing power & memory, this is by far not the only functionality yet to come. In fact, we constantly give kudos to UDI for continuing to enhance the ISY software. I'd hate to see a time come when that last feature didn't fit by a couple of bytes or a couple of processor cycles because we had chosen to have an extra few variables, or because of a value updated every minute (or more) instead of once every 24 hours... Peter

Sure, but if it is being calculated at 23:59:59, it is only today's data for 1 second. Oh, I see you got that (in my best Emily Litella voice) "Never mind..." OK, but so far none of the algorithms I've written up (either in the last round or what I will post next) have minute-by-minute running averages or totals. Again, this concept only works if the 24 hour period being used is midnight to midnight. Completely agree about the current complexity. I don't agree that having a line in your program which says something like "Module 'Climate' Perform Irrigation Calculations" (using whatever syntax Michel implements - this is not meant to represent actual syntax) adds the same level of complexity.

Mark - LOL re Adam Sandler 1. Water_Deficit can't be calculated until a rain total for the previous 24hrs is available, so in your example, it would exist only in the "Yesterday" column. 2. I question the assumption that there'll be any "Today" values to see (in my ISY, if Evapotranspiration_Average were calculated every time the WB vars were fetched, that would mean 2779 needless calculations (just in case I wanted to see a number changing in the UI) for every 1 useful calculation). When you grayed out that variable, were you indicating that it's just for display and there's no other need for it as a moving average? 3. If the only "Today" variable that's visible is the WB Rain_Today, then rather than have all the irrigation variables (which I would argue should be in the climate module, but visually set off from the WB data in the UI - since they are ISY values, not WB data) be "Yesterday", isn't it just as valid that they be "Daily"? (Which I think would be a lot less confusing if the calculation time was up to the user's program...) 4. The user will be instructed to write their program (I actually envision writing up and delivering a sample program) so that it is scheduled at the same time every day. The example was given, though, of sometimes needing to delay starting for an hour or two because of a late party. Say they did happen to run it an hour or two late, then on one side their calculations would be somewhat short (22 or 23 hours) and on the other a bit long (25 or 26 hours). That would all even out by the next cycle. If they're completely ignoring the intent and running the irrigation program at random times , that's their problem. I can see that I have to go ahead and post the algorithms I have so far which work on the assumption that the calculations could be triggered by the user's program. Unfortunately, I can't get to that for a while. Bear with me please... Peter

Mark - I know I haven't posted the algorithms yet, but as you can see from my post about the variables, there aren't any "Yesterday" & "Today" variables. Even if the calculations are fixed to 00:00, then that's when the Daily_ values are set. Here's your statement re-written accordingly: Having said that, what do you think of the idea that your irrigation program could request the calculations when it runs? Peter

Michel - Let me try to illustrate using a timeline. In this example, you've decided to irrigate whenever the amount of water loss reaches 25mm. Scenario A - calculations always happen at 00:00, your irrigation program runs at 23:00: 1. 00:00 - Irrigation Requirement is updated. Its value is now 25mm. 2. Between 00:01 and 22:59 it rains. Total effective rainfall = 20mm. Maybe it falls all at once, maybe on-and-off, maybe non-stop all day long. It doesn't matter for the example (what matters is that the rain occurred between updating Irrigation Requirement and testing its value). 3. 23:00 - The IF schedule condition in your irrigation program evaluates true. The ANDed test of "Irrigation Requirement >= 25mm" also evaluates as true. Your program runs through the zones which you've timed to dispense 25mm of water. In reality, because 20mm of rain was absorbed between the time the calculation was done and the IF in your program evaluating Irrigation Requirement you've overwatered by 20mm. Scenario B - you've scheduled your irrigation program to run at 23:00, so you set the calculations to happen at 22:59: 1. Between 00:01 and 22:59 it rains. Total effective rainfall = 20mm. 2. 22:59 - Irrigation Requirement is updated. Its value is 20mm less than what it would have been at 00:00 (before the rain). 3. 23:00 - The IF schedule condition in your irrigation program evaluates true. The ANDed test of "Irrigation Requirement >= 25mm" evaluates as false. Your program completes without watering anything. You've identified the problem (a significant delay between updating and evaluating Irrigation Requirement). As I hope the new example shows, the whole point of a configurable calculation is to close that gap for anyone who doesn't schedule their irrigation to start just after midnight. No apologies, that's certainly a valid concern. If we believe that there is value to being able to configure the calculation time (because it frees users up to schedule at any time, not just in the very early AM), then let's go from there. I do have an idea for an alternate implementation which I think may be much easier to understand: - No config variable for calculation time - Instead, a SYSTEM command to trigger calculation - At whatever time the user wants, their irrigation program asks ISY to perform the calculations - It then evaluates (the freshly calculated) Irrigation Requirement to determine whether to water yet. I think users already understand having a schedule condition in their irrigation programs. Since we're adding all these calculations to the ISY, asking them to add the trigger of calculations into their programs seems like a straightforward requirement which needs little explanation beyond "Here's how you ask ISY to perform the calculations...". What do you think of that idea? Peter

Mark - Thank you for the huge grin. Still hasn't gone away... Peter

I have one version of the algorithms written up, but will wait to post them until: 1. We get resolution on the notion of user-defined calculation time 2. I get some feedback on the variables (names, range, scope & high-level description). The algorithms may need to be changed depending on the feedback for these 2 points. OK, let's see - where's the smiley for "Throws hands up in surrender?" Michel - I started out arguing for all calculations to happen at 00:00 (actually 23:59:59), so I'm fine if we go that way. Mark pointed out that if you want to begin irrigation late in the day (say 22:00 or 23:00) your decision could be very much out of date. Here's an example: At midnight, Irrigation Requirement reached your threshold - so your program will water the plants - but it was pouring rain all day. So, if you did the calculations now (some 22 or 23 hours later) they would have your irrigation wait for another 2 or 3 days!. I realize that the user's program could try to second guess the Irrigation Requirement calculations (e.g. by looking at whether Rain Today were over some value - which would just be a best-guess) but I have a feeling it's going to get very convoluted. On the other hand, I don't think the alternative has all the drawbacks you describe: I agree that this one variable ("What time of day do you want your irrigation calculations performed?") needs to be described (oh wait, I just described it ). But I would argue that things get simpler because we completely eliminate the notion of "Today" and "Yesterday" in favor of "Daily" (meaning "For the last complete 24 hour period"). Good news - there is no optimal time! Most users would probably leave this at midnight, but changing it would be purely personal preference. The beauty of the Irrigation Requirement Balance method of irrigation scheduling is that all it cares about is that the balance is calculated/updated (once) every 24 hours. I continue to argue strongly that no matter what time the calculation is done we avoid all notions of "Today" and "Yesterday" within the irrigation subsystem. Note that in the variables I've proposed, there are no "Today" or "Yesterday" variables, only Daily_. All the user needs are Daily values. These are by definition updated only once in every 24 hour period, so any Daily value is the value as of the end of the last complete 24 hour period. (Assuming calculations @ midnight, the last complete day.) There is no "Today" value of any use because the Irrigation Requirement Balance can't be updated until the rain for the past 24 hours is known. Actually, Daily_Water_Deficit is a function of Rain Today and Daily_Evapotranspiration - but I know the point you're making is the effect of Rain Today. IFF we implement the Perform_Calculations_By setup, I already have the 2 lines of code which would allow the internal calculations to take this into account and tally the rainfall over the previous 24 hours no matter what time the user decided their daily calculations should occur. With this in mind, please think about it for a bit while I'm writing up the algorithms. If you still feel strongly that it shouldn't be done, say so & I'll update the list of variables and the algorithms back to 00:00 only. Any input as to the variables I've proposed? If we did implement the user selectable calculation time, I now think it would be better if we called it Perform_Calculations_At. Peter

Michel - I've been color-coding some text to get your attention. If you happen to be color-blind please let me know. (This may sound like a joke, but I've had this run into this with color-coding in the past...). First a note to Michel - Mark & I discussed a small but powerful change to the concept of Daily values, and haven't heard back from you. Here it is in a nutshell: The idea is that much of this revolves around "Daily" averages, tallies, etc. If Daily means once every 24 hours, there should be no reason not to allow that period to be midnight to midnight, noon to noon, 17:27 to 17:27, etc. The value of this becomes clear for users wanting to irrigate at say 11pm. If the Daily period were fixed at a midnight start, they'd have to base irrigation decisions on data that was 23 hour old. A lot (e.g. torrential rain) can happen in 23 hours to affect that decision. OTOH, if they can say "My Daily period is from 23:00 to 23:00" (ok, actually to 22:59:59) then the irrigation decision at 11pm is completely current. The beauty of this is that it simplifies out "today" and "yesterday" values - you just have the "Daily" value representing your previous daily period. Please post ASAP if this will be a problem. I'm continuing this writeup assuming it can be done. I've decided to start with a post on variable names. Having had to maintain some code with short non-descriptive variable names, I'm a big believer in making them self-documenting. Of course UDI is free to use whatever internally, but if we have a common "vocabulary" to use I think we'll avoid much of the confusion that has plagued this thread. I'll continue writing up algorithms and post as soon as I can, but meanwhile please ask any questions or make any suggestions now so I can incorporate them right away. Note 1: I've also tried for names which (w/o underscores, of course) can be directly used if the variable is presented in the UI. Note 2: All variables dealing directly with water are in units of depth (mm internally, entered/presented as mm if Metric presentation chosen in Climate config or as inches if English chosen) In the Climate Module configuration: Water_Applied_per_Irrigation = (Value entered by user) The amount of water the user's irrigation program applies to the soil during each run. Region_Factor = (Value based on location selection by user) Adjusts for the differing ET in inland vs coastal areas. Units: Decimal, range 0.0 to 1.0 Michel - Is this correct ??? Soil_Absorption_Factor = (Percentage selected by user) Adjusts for the relative efficiency of soil absorption (used by ISY only for absorption of rain - the user is responsible for factoring this into the irrigation run-times in their program). Perform_Calculations_By = (Time of day selected by user) This lets the user decide when the Daily ET average and Irrigation Requirement calculations will be done. Note 3: Actually a presentation suggestion - since this all goes well beyond WeatherBug data, perhaps an "Irrigation" box on the Climate Configuration tab? Internal to ISY: Evapotranspiration_Sample This is a single instantaneous ET calculation result. Evapotranspiration_Tally This is the sum of all Evapotranspiration Samples since the last Daily calculations. Sample_Count How many Evapotranspiration Samples since the last Daily calculations. Total_Rain Previous_Rain_Total Allow WB's "Rain Today" (a midnight-to-midnight total) to be used for Daily calculations at the time specified in Perform_Calculations_By. Available to users' irrigation programs: Daily_Evapotranspiration The average of all Evapotranspiration Samples since the last Daily calculations. Daily_Water_Deficit The Daily_Evapotranspiration less whatever rain has been absorbed by the soil since the last Daily calculations. This is a signed float and can be a negative value in the event of lots of rain. Irrigation_Requirement A running balance of Daily_Water_Deficit since the last time the user's program triggered a decrement or reset. OK. I think I got them all. At this point I'd like input on the names, scope and general understanding of the variables. I'd suggest holding usage questions for after the algorithms post. I'm out of time for now, but will post algorithms ASAP. Peter

My suggestion is re-title the thread "Proposed Evapotranspiration data in 3.1.4 Beta" (as that's where most of the discussion has been) and move to Product Requests. Once implemented we can do a How To thread and if need be have links to the few relevant posts in this thread. Just sitting down to write up more. Stand by...

Sorry, something's come up. Looks like I'll have to pick this up tomorrow. Peter

Michel - I've stepped back to try to see how we can simplify things, and how this can be explained by a former apartment dweller (boy I miss those days!) to a current one. Please bear with me if some of this is stating the obvious, because I think there are points here which are getting overlooked... Let's start conceptually. 1. ET is just an approximation of the amount of water leaving the soil via a combination of evaporation and transpiration (a fancy word for plants drinking it up). 2. The goal of an ET-aware irrigation system is to approximately (despite all the appearance of precision, we have to remember this) replace this water. 3. It does this by tracking the water used/lost from the soil until a threshold is reached (where the plants would starve for water if much more left without replacement). 4. In most climates, this will result in watering every few days. 5. Rain may offset some of the water use/loss, resulting in less frequent watering. 6. Calculations performed once every 24 hours are sufficient for this tracking. I'm again incorporating the diagram & table from earlier in the thread so we have them right here for reference. I would ask that you take just 5 minutes to absorb them before moving on. First the diagram: The 3 key concepts here are: 1. There's some amount of allowed depletion (based on the plant types, root lengths, etc.). 2. This depletion will not typically happen in a single day. 3. What is varied is when to water, not how much. Just thinking about this we can see why all of this is an attempt to approximate. As soon as I have more than one type of plant in my landscaping, I have different water depletion tolerances. We could envision a very sophisticated system with differing calculations for every plant in our garden, but the reality is that we'll come up with a compromise depletion depth which allows the majority of plants to thrive (and doesn't kill any). Now for the table: This shows how: 1. A running balance is used to decide when to irrigate. 2. It's not necessary to exactly replace all the water which has left the soil (i.e. zero-out the balance). OK, at this point I have to take a break and eat some dinner. When I return I'll answer any questions up to this point, then go over what I hope can be a final cut at naming, describing & calculating values for the necessary variables. Peter

Mark - When I sit down to write up more this evening I hope we'll wind up simplified yet more powerful... Thanks for hanging in 'til then.

Yes, if this is what we've been calling "Water Applied per Irrigation" (a more descriptive name since most of the variables involve depths). Yes. Michel - I think we can simplify this greatly. There are some mistaken assumptions about Irrigation Requirement which cascade into way more complexity in today vs. yesterday, etc. But rather than try to go point by point from your post I'd like to try another forward pass through it. I won't be able to complete this (needs some thought to make the writing as straightforward as possible) for 6 - 8 more hours. In the meantime, let me ask: Do you have any problem adding one more config variable (a time of day) and making the time of calculation based off of this? Thanks, Peter

mark - Not enough time to continue re ET right now, but a quick story I think you'll like as we have the same vocabulary policy. One day my daughter's Kindergarten teacher tells us that our daughter reported another girl had used "the F word." When the teacher asked (very wisely) "What word was that?"... You guessed it!

Mark - Just had a brainstorm. We leave all as is. No mention of Today or Yesterday, Daily means what it says (a 24 hour period). The reason for 23:59 is because WB resets Rain Today at 00:00. So, we ask Michel for a configuration value of what time of day the once daily calculations happen. This plus one more internal variable tracking Rain Today will allow the calculation to be done at the same time every day, whenever you want. What do you think? Peter OK, Now I'm really offline...

Mark - There is no running total as currently written up. What you're proposing is that the ISY perform the entire calculation (everything currently in the "At 23:59 daily" section except Irrigation Requirement) on every WB update. (Irrigation Requirement can't be calculated every time because it would then add the ever increasing (in the absence of rain) Water Deficit multiple times.) Because there may be other things users are looking for (e.g. I care about the light values from WB) which demand responsiveness from the home automation, this may be very high (e.g. 2880 times daily with a :30 update interval). Maybe that matters, maybe not... I understand about the water pressure issue. May I suggest looking for some historical daily ET values for your area (or a similar climate) and plugging them into a spreadsheet (as IndyMike is doing with the ISY's current instantaneous ET values). I'd like to know if watering according to a true Irrigation Requirement Balance model will result in watering more than once a day. If not, there's no reason you couldn't use the value calculated at (moments before) midnight to schedule irrigation 23 hours later. The balance will simply carry over. Unless the actual soil loss limit for your plants is less than one day's ET this would work. I have to be offline for the day. I'm going to ask you to ponder this for a while before responding, and we can continue the conversation this evening. Michel is asking us to stabilize the description. I just want to be sure before changing the calculation strategy and introducing more variables. Peter

I'm glad we have a couple of climate extremes represented. If we can get IndyMike to weigh in here, all the better... Excellent! (I knew you would.) I think we're in agreement that for maximum flexibility we will need the ability to do arbitrary math with these values (e.g. decrement Irrigation Requirement by different amounts directly in code). But, that's down the road after we get floating point variables. Meantime, you've found a very reasonable solution to the limitation of having only a single Water Applied per Irrigation value with which to decrement Irrigation Requirement. Michel - Mark just proved conclusively the need for the ability to reset Irrigation Requirement from a program. Peter

Michel -Agreed as to consistency, but to be fair after reflection I do suggest we revise a couple of variable names just to avoid confusion among users (see my recent post re "Daily_" vs "_Yesterday" naming convention). The base names stay the same, but for clarity I suggest: Water_Deficit_Yesterday instead of Daily_Water_Deficit Evapotranspiration_Yesterday instead of Daily_Evapotranspiration If you agree, I can update my algorithms post accordingly. If by "automatically" you mean "when the user's program triggers it" then yes. This is what Mark is seeking. I think most users will simply let any non-zero remainder ride. (And I think Mark can do what he wants to without our adding another variable.) Here's an example which may help: - My ET values for the day are typically 3 to 5 mm. - I've decided that I'll allow about 12mm water loss from the soil before watering, so I write my program to test Irrigation Requirement >= 12mm. - I aim to replenish 12mm on each watering, so I set 12mm for Water Applied per Irrigation in my Climate Module configuration. - New installation so we start with Irrigation Requirement at zero. - Three days pass with ET values of 3mm, 4mm and 3mm. Not yet 12mm so no irrigation yet. - The fourth day has an ET of 5mm. Now Irrigation Requirement reaches 15mm. - My program applies 12mm, triggers the decrement by 12mm and Irrigation Requirement is now 3mm. So is the 3mm a problem? I don't think so. If a similar ET pattern continued I'd simply water again in 3 days instead of 4... I believe Mark's concern is if somehow on occasion a single day's ET was so high as to leave a very large balance (say 6, 8 or 10mm in our example). He'd like to water again to try to replenish that remaining water loss. I'm not saying that's not a valid approach, but I think most users would let this ride since it may simply mean that their next full cycle will run the next day instead of 3 or 4 days out. If a large Irrigation Requirement balance was happening to me often, I'd adjust my Water Applied per Irrigation value (and my program's IF comparison) to better match the ET pattern. I think this is our best guess here. Irrigation Requirement is cumulative water loss from the soil, and how much loss to allow between waterings is ultimately based on the root length of the plants (short for grass, long for trees, etc...). The examples I've seen all deal with daily ET values below one inch (so several days before an inch is lost from the soil), and I wouldn't imagine that you'd get higher than a single digit (in inches) Irrigation Requirement before watering. If Irrigation Requirement is persisted (once a day @ 23:59:59), then I wouldn't reset if I rebooted. In the Irrigation Requirement Balance model of ET use (there may be another model, but I haven't found one in my research), you'd most often have a non-zero Irrigation Requirement. The only reason I could see for wanting to reset would be an extended outage (ISY down for days, so Irrigation Requirement balance is now completely invalid). If Irrigation Requirement is persisted as soon as it is calculated, you'd probably never be more than a day's ET off (in the case where the ISY reboots (off for < 24hrs) and comes back to life between say 23:58 and 00:01). More likely just part of a day's ET. I can't see persisting the tally and sample count on every increment (too many flash writes), but I suppose you could choose hourly (or even a back-off algorithm where the more uptime the less frequent the snapshot). It would be good to persist the tally and sample count before an intentional reboot (e.g. firmware upgrade). Excellent, thanks!!! While I did see an academic paper with over 2000 soil types I think this list is most useful: Sand 100% Loam sand 83% Sandy loam 67% Loam 58% Clay loam 33% Silty clay 25% Clay 17% Hope this helps! Peter

Your program makes the decision whether to irrigate based on checking how much water has left the soil vs how much you expect to replenish. You can add your own test of what time of day you want to start, disable the program, etc. Peter

Mark - Re having a remainder variable: While I used the example of "email me", couldn't you just retest Irrigation_Requirement after the main irrigation run (and after the decrement) and if over X then enable a "Top Up" program to give some additional water? Personally, I think this ET stuff is very hard to understand (I know I need to think hard about it). My perspective is to make it simple to do the 99% solution, possible to do the 1% "extra mile" and hard to get confused & off-track about the whole thing. That's why I'd look for ways to accomplish that 1% with a minimum of extra variables, commands, etc... Peter