peterd

I think the confusion has been that I've been calling "Daily" the value I would use today (i.e. the value calculated at 23:59:59). While technically calculated yesterday (just), this is still the most recent (complete) Daily value we have access to. If the label Daily_ is too misleading, then let's come up with a better convention (Daily_Water_Deficit becomes Water_Deficit_Yesterday and Daily_Evapotranspiration becomes Evapotranspiration_Yesterday) and not show any "today" values.

I don't think this variable exists. I think Michel suggested this because he did not understand that the decision as to whether irrigation is needed yet is simply looking at whether Irrigation Requirement has met or exceeded Water Applied per Irrigation. If you want to know whether to adjust your irrigation times, then add an email to yourself of Irrigation Requirement after running the System command which subtracts Water Applied per Irrigation - at that point it will be the remainder. (As an aside, going back to that example Irrigation Requirement Balance table I posted, having some remainder should not be a problem. Only if it were consistently high would adjustment be needed (maybe longer times, maybe shorter...) But are these in fact running totals? If you did these calculations repeatedly throughout the day (and at the moment they are specified as happening only once @ 23:59(:59)), would the results be useful? As an average, Daily ET could swing up or down as more samples were collected depending on the instantaneous ET samples. Daily Water Deficit could rise at first, then fall if it rained later in the day. I think the real value in these is as a record of how what happened yesterday (sun, wind, rain...) affects whether irrigation is needed today.

One question for you, Michel - how are you thinking of handling the user's entry of Soil_Absorption_Factor in the configuration? Peter

Can you reflect these storage variables too in this writeup? At 00:00 daily: Yesterday_Evapotranspiration = Daily_Evapotranspiration # At 00:00, ISY copies today's average ET to yesterday's average ET and clears today's Yesterday_Water_Deficit = Daily_Water_Deficit # At 00:00, ISY copies today's deficit to yesterday's deficit and clears today's I will get back to you on the land location thing after I read a bit in that pdf... I can certainly add those, but in that case Daily_Evapotranspiration and Daily_Water_Deficit will only be non-zero for 60 seconds. Is that what we want? (Is there confusion arising because the day in "Daily" is in fact yesterday? Do we need to rename the "Daily_" variables?)

Mark - Please check this, then I'll mark it as final. (In particular, do you think I've gotten the whole location thing right?) In the Climate Module configuration: Water_Applied_per_Irrigation = (Value entered by user) # Units: Depth (mm internally, entered/presented as mm if Metric presentation chosen in Climate config or as inches if English chosen) # This is the amount of water the user's irrigation program applies to the soil during each run Land_Location_Factor = (Value based on location selection by user) # Units: Decimal, range 0.0 to 1.0 ??? # Internal variable not available to the user (of course they can see or change their location selection) Soil_Absorption_Factor = (Value entered by user) # Units: Percentage # Adjusts for the relative efficiency of soil absorption # (Example values: sand 100%, loam sand 83%, sandy loam 67%, loam 58%, clay loam 33%, silty clay 25%, clay 17%) Michel - I suggest that Soil_Absorption_Factor be either: - a value directly entered by the user or - a soil-type pulldown list with a Custom choice allowing a value to be directly entered by the user (so that they could derive this by measurement, by using the example values directly, or by interpolating from the example values). Throughout the day at each WeatherBug update: Evapotranspiration_Tally = Evapotranspiration_Tally + Evapotranspiration_Sample # Units: Depth (mm) # These are internal variables not available to the user Sample_Count = Sample_Count + 1 # Internal variable not available to the user At 23:59 daily: Daily_Evapotranspiration = Evapotranspiration_Tally / Sample_Count # This variable is an average of all samples in the previous day. # Units: Depth (mm internally, presented as mm if Metric presentation chosen in Climate config or as inches if English chosen) # Available for use in programs in case advanced users want to program some custom irrigation strategy. Daily_Water_Deficit = Daily_Evapotranspiration - (Rain_Today * (Soil_Absorption_Factor / 100)) # Daily Water Deficit is the amount of water that needs to be replenished for the day. # Units: Depth (mm internally, presented as mm if Metric presentation chosen in Climate config or as inches if English chosen) # This is a signed float and can be a negative value in the event of lots of (absorbed) rain. # Available for use in programs in case advanced users want to program some custom irrigation strategy. Irrigation_Requirement = Irrigation_Requirement + Daily_Water_Deficit # This is the amount of irrigation that is required to replenish water lost since the previous irrigation run. # Units: Depth (mm internally, presented as mm if Metric presentation chosen in Climate config or as inches if English chosen) # This is an unsigned float and cannot be below zero. # It is incremental so it can collect for days if necessary. # Available for use in programs - the most straightforward way to use ET data within ISY. Within the user's irrigation program: # The IF condition should be able to be written as: IF Irrigation Requirement >= Water Applied per Irrigation THEN ... # The final THEN action (after the irrigation zones all run) would trigger ISY internal calculation of: Irrigation_Requirement = Irrigation_Requirement - Water_Applied_per_Irrigation Peter

Michel - I will post this within the hour. Peter

This is a very interesting idea. But it cannot be specific to an EZFlora (I use 3 EZIO8Ts). Basically, you would be saying "Decrement IR whenever you see a Fast Off of this Insteon node." So it would work no matter what Insteon device someone used to control their valves.

Yes Again, I strongly urge that for now this be a % of soil absorption rather than a list of types. Allows user to:- Handle mixed type ("split the difference") - Determine absorption empirically Yes If you mean literally "decrement" then no. What if you can't water at the time? If ISY decrements this first, then the continuing Irrigation Requirement balance will be too low. If what you mean is test that WAI - IR >= 0, that's different. It's ok if you want to present the user with a boolean (Water or not) based on testing whether the value of IR - WAI >= 0, but there still has to be a way for the user's irrigation program(s) to say "I succeeded in watering completely, so go ahead and decrement IR by WAI." Remember, Irrigation Requirement is not "Irrigation Required?", is is actually Irrigation Requirement Balance. Peter

Yes - in the sense that to change it the user has to go into configuration and update it. Why would you say yes? A constant is something that is defined and never changed... "hardcoded". This is not constant because the user may want to adjust it based on runtime length. Mark - He didn't ask if the implementation was as a constant (e.g. that it's permanently compiled into code), he asked if the value is constant. When Michel said he clearly understood that if the user defines it (in the config page, which can be revisited...) it's not a constant in the literal sense. I believe he meant "Does anything change this at runtime?" Perhaps if he'd asked "Other than the user setting a value in the Climate Module configuration, is this value read-only?" Cheers, Peter

Correct. That user-defined value is what Mark was referring to. I suggest it be called Water Applied per Irrigation. Yes - in the sense that to change it the user has to go into configuration and update it. Yes No. That would amount to the irrigation system removing water from the soil. It would also be great if the user's program could use Water Applied per Irrigation to compare against ("IF Irrigation Requirement >= Water Applied per Irrigation THEN ..."). That would prevent having the same value have to be specified in configuration and also hard-coded in the irrigation program (and potentially get out of sync). Peter

Mark - Re land location. Got it. Thanks. Post edited. Peter

Michel - Thanks! By user side, I think you mean that these are Climate Module configuration values input by the user - correct? 1. For soil type I think we envision just a soil absorption % the user can enter so that situations such as multiple soil types can be approximated by the user. The other reason to have this be a value rather than a pick-list is that there's a technique for measuring the rate at which soil absorbs water which will give a more precise idea than the approximation of soil type. 2. ok. 3. Defining the decrement for Irrigation_Requirement as a config value is fine, but recognize that there still would need to be a way to trigger this programmatically. The decrement only happens after you've successfully irrigated. Ideally: - This value would appear in the configuration as Water Applied per Irrigation and is in depth (mm/in) units (as are all the values we're discussing - except the soil absorption %). - In the user's program the IF condition would be able to be written as Irrigation Requirement >= Water Applied per Irrigation - The final THEN action (after the irrigation zones all run) would trigger ISY to decrement Irrigation Requirement by Water Applied per Irrigation 1 - 5 look fine, although I'm not sure what value there is to Today's ET being a constantly changing average (couldn't it just be calculated once @ end of day). Personally, i think that the instantaeous ET and Today's ET should only be used internally (not visible to the user), as these don't have any direct utility and will probably be a source of confusion. 6. after step 5, then set Irrigation_Requirement = Irrigation_Requirement + Daily_Water_Deficit This is the depth of water the irrigation system needs to supply to replenish loss. It is a running total of Daily_Water_Deficit. Once the user irrigates, their program says "it's time to decrement Irrigation_Requirement by Water_Applied_per_Irrigation." Note that Daily_Water_Deficit could be negative (a surplus of water today), but there can never be a negative Irrigation_Requirement (which would mean literally "the irrigation system must remove water from the soil"). So the most decrementing by Water_Applied_per_Irrigation can do is take this value to zero. Hope this helps. Peter edited 06/09 07:45 to further explain the benefits of "Soil Absorption Factor" entry vs "Soil Type" choice selection

Mark - First, let me see if I understand what you mean by "callback" (because I didn't think the ISY supported them). As I understand the term, support for callbacks would allow me to write a piece of code completely external to the ISY programming environment (for instance a 'C' function or a Java method). Then, I could specify this piece of code to be executed at some point within an ISY program. The ISY program would call my code, which presumably would be passed pointers or references to ISY variable(s) on which it could act. After this code completed the ISY program would continue executing at the next statement, unaware that something "external" to it had changed anything. In that case, yes - I see how we could write that code today, in a way which would support the floating point math, outside the ISY Admin UI environment. If I've overlooked the ISY's support for this extremely powerful capability, then I stand corrected. If that's not what you meant then please help me understand what you have in mind. I do understand your point about purity of design. I think there may be a difference in our perspectives (neither being right/wrong or better/worse) about how far to take the design. Assuming that what we have now is a version 0.1 beta implementation, I'm just trying to design a version 1.0 (ok, maybe 0.9 - it is still beta after all ) which can go to beta soon, be in people's hands to gain experience and does not lock out a future implementation. Maybe I'm anticipating a non-issue, but (even 'though it may initially seem straightforward to implement) my concern is that UDI wouldn't want to "back into" floating point variables by introducing limited support in one specific place. For instance, this implies that floating point values would be available in the program editor pulldown for that variable (and that variable only). What's the precision? (We currently have instantaneous ET to 4 decimal places...) We've been using .5 as an example, but what if I want 0.273; 1.005; 2.8241? Think of how many values that pulldown would have. So, should it be 2 lists (left & right of the decimal point)? More? (I understand why UDI has created the program editor as their IDE for ISY, but for those of us unafraid to open source code in a text editor it would sure make things like this easier...) That said, I'm happy to ask Michel which way he can do this now (as a variable which can be the target of an assignment involving floating point arithmetic or one which can only be read and reset to zero). We do both agree that the ultimate design (whether in the next release or down the road) is to have the Irrigation_Requirement be able to be incremented or decremented (by floating point values) within user programs. Peter

Hey, I'd love to go for that implementation right away, but we'll need floating point math on it. If UDI can enable math on a single floating point variable w/o having their entire floating point variable support ready to go, then YES, YES, YES! On the other hand, if this would mean skipping one or more betas (and assuming that a zero-ing out implementation wouldn't) then I, personally, would vote for the "close enough" re-init approach. I specifically haven't mentioned this before because I wanted to help get in place something that would be as useful to as many people as soon as possible, but... Due to major home renovations I've had to re-do my entire irrigation system. I've had 2 temporary setups up till now. I have nothing running right now. I'd really rather get an ET-based setup going than have to yet again do something temporary. But, hey, that's just me... Peter

Welcome aboard, Mike! Based on what I saw of your analysis of the scope traces with the CFLs & Insteon dimmers I'd say you deserve a higher rank than Private. Since this is all water related, I guess we should be looking at naval ranks. What's equivalent - Ensign? Peter

I think you just answered your own question. ET is water loss. Your original question: is valid, though. ISY applies it to rain because it's doing that calculation. We apply it (offline) to irrigation when we determine how long we water to achieve a certain replenishment amount. So in your case, with 2 different soil types, you can determine different runtimes for the zones to take this into account. Then, what I'd do if I were you is split the difference between soil types when inputting my Soil Absorption Factor. That way, in the absence of any rain you'll be watering just the right amount for each soil. If there is some rain you'll have a reasonable approximation of what it has replenished, and your own program will still be applying irrigation to the different zones in proportion to their soil type. Peter

Doh! Sometimes we get so deep into things that the obvious escapes us (especially late at night)! So while Daily_Water_Deficit can go negative, Irrigation_Requirement cannot go below zero. Makes sense. So we keep everything in one place, I'll update my earlier post to indicate this. Peter

True! I don't think this could ever happen, since Rain_Today will have already been subtracted from Irrigation_Requirement (happens when Daily_Water_Deficit is calculated). What this does point out is that either (or both) Daily_Water_Deficit and Irrigation_Requirement could want to go negative. I'm sure that's valid for Daily_Water_Deficit (indicating a surplus of water for the day). This is the case shown for 4/15 in the Irrigation Requirement Balance example table. Suppose Irrigation_Requirement were at 0.25", and today's Daily_Evapotranspiration is 0.25". But, Rain_Today is 0.30" (and to simplify this example we'll specify pure sand - so soil absorption's not a factor). So now when the Daily_Water_Deficit is calculated it will be -0.05" (a surplus of water), and Irrigation_Requirement will drop to 0.20" (meaning the plants will be able to wait just that much longer before we need to water them). I'm not sure what it means to have a negative Irrigation_Requirement. Is it any different than the case of a negative Daily_Water_Deficit? Also (and I'm going to edit my earlier post so this thought doesn't get lost), resetting the Irrigation_Requirement to zero is a compromise. The reality is that we'll probably not hit the exact target. I.e. - we want to irrigate 0.5" worth whenever Irrigation_Requirement >= 0.5". After some tuning we find we're typically irrigating when Irrigation_Requirement is between say 0.52" and 0.56" (and maybe we've extended our irrigation time a bit to try to apply 0.54" each time). Once we have floating point math, what we really want is to leave the irrigation time at 0.5" worth, and subtract 0.5" from Irrigation_Requirement every time we irrigate. (This is exactly the approach shown in the table - carrying an Irrigation Requirement balance.) Peter

Yep, Alameda. So I'm guessing that you as well, in Sac'to, probably have no irrigation in the rainy season and no rain in the irrigation season? Only thing about trying to test with a calculator is that we can't get all the actual values out of the ISY. Sounds like we need to find someone (*cough* guinea pig *cough*) back east who's interested in using ET with the ISY and willing to do some data capture (& maybe calculations)...

Mark - I also apologize if I took things too literally. Happens to me sometimes. I was thinking the same thing about the limitations of text vs. in-person. Overall, though, I think this has been a good collaboration so far! Maybe we should put back concrete, if only to see if anyone picks up on it! I agree about spreadsheet testing, but I'm not in a good position to do so right now (both because it will be another 6 months before I see a non-zero rain value in my climate module and because of time limitations). It also occurs to me that we don't know how much debugging UDI's initial v3.1.3 implementation of the instantaneous ET calculation may need. I guess if we can find a daily ET calculator we could input the base weather values to check against the ISY ET value... Peter

Here's my proposed (slightly revised) psuedocode: In the Climate Module configuration: Soil_Absorption_Factor (Example values: sand 100%, loam sand 83%, sandy loam 67%, loam 58%, clay loam 33%, silty clay 25%, clay 17%) The Soil Absorption Factor configuration variable is a factor of soil type to adjust for the relative efficiency of soil absorption. User intervention required. I suggest that this be a value directly entered by the user (as opposed to, say, a soil-type pulldown list) so that they could derive this by measurement or by using the example values. Throughout the day at each WeatherBug update: Evapotranspiration_Tally = Evapotranspiration_Tally + Evapotranspiration_Sample Sample_Count = Sample_Count + 1 # These are internal variables not available to the user At 23:59 daily: Daily_Evapotranspiration = Evapotranspiration_Tally / Sample_Count # This variable is an average of all samples in the previous day. Daily_Water_Deficit = Daily_Evapotranspiration - (Rain_Today * (Soil_Absorption_Factor / 100)) # Daily Water Deficit is the amount of water that needs to be replenished for the day. # This is a signed float and can be a negative value in the event of lots of (absorbed) rain. Irrigation_Requirement = Irrigation_Requirement + Daily_Water_Deficit # This is the amount of irrigation that is required to replenish water lost since the previous irrigation run. # This is an unsigned float and cannot be below zero. # It is incremental so it can collect for days if necessary. # ISY programs need a way to reset this variable. My proposal to allow resetting this is to have 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.) Note that resetting Irrigation_Requirement to zero is a compromise until we have floating point math. What should really be done each time we irrigate is to subtract the amount of water applied from Irrigation_Requirement. (Thereby carrying an Irrigation Requirement balance.) Daily Evapotranspiration, Daily Water Deficit and Irrigation Requirement are all available for use in programs. It is envisioned that Irrigation Requirement would facilitate the most straightforward use of ET data within ISY. Irrigation would be deferred by skipping days until the Irrigation Requirement met the irrigation output threshold. The threshold is established within the user's program by setting an IF condition against the value of Irrigation Requirement. Daily Evapotranspiration and Daily Water Deficit are provided in case advanced users want to program some other irrigation strategy. Except for removing specifics (the sample frequency, the TCL-ism) which might be taken literally and revising the example absorption factors to account for the division by 100 in the Daily_Water_Deficit calculation, I haven't really changed anything. Tried to clarify comments somewhat, but if I failed let me know. Peter edited 6/8 00:30 to clarify the future requirement for user programs to be able to set Irrigation_Requirement to a non-zero value edited 6/8 08:11 to clarify that Daily_Water_Deficit can be negative, but Irrigation_Requirement cannot

Re: sample frequency - I felt Michel was asking for very specific input, so didn't want this taken literally... Re: append list - ok, so again not literal (i.e. store every sample) but just a way to say add this to a running total... Re: concrete - oops, I mistook the sample frequency for it!

Mark - My thoughts: Not sure why 5 minutes. My Climate module update, for instance, is set to 60 seconds. So, I would expect to wind up with 1440 samples (more samples = higher resolution average). Well, I suppose the sample count could be derived from the day divided by the rate, but that might not take into account what might happen if there were lost samples (suppose my DSL hiccups). I think incrementing an actual counter is simplest and most accurate. This one kind of loses me since I think of an array, linked list or other container of multiple values when I hear "list". Isn't this just an accumulator? Here again, not sure why 288 samples? Since I think the ET could be sampled on every WeatherBug update (and the user configures how often (& therefore how many times daily) this happens). I'd say instead "This variable is a 24 hour snapshot of all the samples in the day and is averaged." I'm now proposing that this be expressed in the UI as a percentage (sand 100%, loam sand 83%, sandy loam 67%, loam 58%, clay loam 33%, silty clay 25%, clay 17%). (The concrete was tongue-in-cheek. ) That's why it's now divided by 100 in calculating the Daily Water Deficit. I'll post a suggested revised psuedocode shortly. Peter

Michel - I think the monthly average is used as historical data in many ET calculators to predict irrigation requirements. The daily average tells us specifically how much water has been removed from the soil (whether by evaporating or by being used by the plants) within the past 24 hours. Tracking this tells us when to water to replenish this. Mark - Maybe you can ask your friend from Johnson Controls to weigh in in this... Peter

Mark - I think you're right. Shorter cycles for spray, longer for drip. (And even 'though I'm migrating more to drip (even about to re-sod with drip for my lawn), I must have been thinking spray at that moment. ) Peter