peterd

Michel - I would have pulled out all my hair had I not found this thread! The behavior of the "3-way" checkbox is definitely reversed. I conducted "black box" testing (observing behavior only - no reference to API docs, ISY logs, etc.) using a Micro On-Off module and a switch. All I had to go on was the Smarthome product documentation http://www.insteon.com/pdf/2443-x22.pdf describing how the 3-way mode is expected to work. I would ask that you please hook up a Micro module (On-Off or Dimmer) to a toggle switch and test it against the Owner's Manual. Adherence to the API docs is moot if checking the box does the opposite of what the user expects based on the user documentation. Thanks in advance, Peter

Thanks, Michel -I find that the program as I've written it If Status 'Filter Pressure Switch' is On And $Filter_Clogged_Msg_Sent_Today is $FALSE centralizes both conditions in one place and is completely self documenting, so thank you again for variables! Peter

I have a program which alerts me of a condition. I only want 1 message per day, so the program tests the value of a flag variable (reset @ midnight by another program). Would enabling/disabling the main program be significantly more efficient than using the flag? Thanks, Peter EDIT: I should mention that the condition I'm checking (back-pressure indicating that a filter needs changing) should only occur once every 12 - 18 months. When it does there may be a period of several days (to several weeks if I were out-of-town) before the filter is changed, During this time, the pressure switch would close & re-open every 5 - 10 minutes when the pump cycles. All the rest of the time the main conditional test (Insteon status = ON) in the program would be false. Do I understand correctly that until the ON event occurs, the program never actually runs?

Tim -Don't feel bad - so much has evolved. Your original view of things was correct... halfway back in the thread. I had to stop & think a moment before my reply. Peter

Tim - What you're seeing is correct behavior. You should set Allowable Depletion to a value representing how much water your plants can tolerate leaving the soil. Then set up your program to run whenever Irrigation Requirement >= Allowable Depletion (you can't actually write the program this way - you have to copy the Allowable Depletion value into your program). Finally, using the Water Applied per cycle value which ISY calculated for you, you have to calculate how long to run your valves so that depth of water is applied (and put the appropriate WAIT statements in your program). One way of doing this (for sprinklers - not drip) is using a "catch can" test. Another is using a PC program which helps you do these calculations. (See my post early in the thread for a link to a website with info on both of these.) Cheers, Peter

I think for most people, this is going to be a last resort. If, for example, you had en extended outage (ISY down, broadband down, etc.) which meant that you could no longer count on the Irrigation Requirement value to accurately reflect the balance of water depletion from the soil then you might want to reset everything and make a clean start. That said, Mark did come up with at least one creative way to use this if for some reason you wanted to irrigate for 2 different durations (rather than my trying to explain it you could look back through the thread if interested in the specifics of his approach). Cheers, Peter

Hi all - As I've already told Michel, I've had an initial look at the irrigation module and am pleased with what I see. At the moment, we're in the midst of a major home renovation project - which as a side effect had our entire irrigation system apart until this week. As a matter of fact I was testing the irrigation valves just today. Things are very busy for me over the next week, but I hope to be able to sit down soon (may not be until week after next) and do my flow rate & runtime calculations for all 20 zones. Once that happens I'll be configuring the irrigation module and will report back via the forum. When I do, I'll try to walk through what I've done and learned which hopefully can be used to enhance the Wiki entry. Cheers, Peter

Michel - Cool! Peter

Michel - I agree that Allowable Depletion is not as intuitive as Water Applied per Irrigation. But I'm not suggesting we eliminate Water Applied per Irrigation, only "Actual Water Applied per Irrigation". I think "Actual Water Applied..." will confuse matters more (because it isn't describing the water applied - it's describing the effect of the water applied). Allowable Depletion (explained as "How much water will I allow to leave (be depleted from) the soil before I irrigate?") and Water Applied per Irrigation ("How much water must I apply - given my soil absorption - to make up for the Allowable Depletion?") complement each other conceptually. I think it's easier to understand the irrigation strategy if you're able to think of (even if we can't today actually write) the program condition as: IF Irrigation Requirement >= Allowable Depletion (because that is logically what the user will be writing when they select a constant equal to Allowable Depletion for this comparison). Unfortunately, ET is not simple. But I am certainly willing to try to come up with simple explanations like those above to help people start to use and learn about ET-based irrigation. And, if that simple explanation isn't enough to understand Allowable Depletion, at least by our using a standard term for it they should be able to read that PDF (or others) to help learn more. So to sum up, I propose that: 1. The user should enter "Allowable Depletion", and be shown "Water Applied per Irrigation Cycle" ((100/Soil_Absorption_Factor)*Allowable_Depletion). 2, When the "Irrigation Cycle Complete" action occurs, the ISY decrements the "Irrigation Requirement" balance by "Allowable Depletion". Example: - Target H2O in soil is 30mm. (Not entered/shown in ISY, this is a decision the user must make based on the types of plants they have.) - Soil type is Sandy Loam (83%). - Allowable Depletion entered as 15mm. - Water Applied per Irrigation Cycle calculates to (and displays) 18.0725mm - IF Irrigation Requirement >= 15mm THEN irrigate (apply 18.0725mm so 15mm will be absorbed) - Irrigation Cycle Complete: Irrigation Requirement = Irrigation Requirement - Allowable Depletion (15mm is the loss we made up for when we added 18.0725mm). Thanks, Peter

Mark - Sorry. My frustrations with many things got the better of me there. I know everyone's been making their best efforts (myself included) to learn about this stuff. Back to the point of the discussion, I think a 1st release would have been better with the ISY performing the absolute minimum of calculations, but it looks like we'll have soil absorption factored into our irrigation for us. I think that complicates matters, but if we're headed down that path I hope we'll at least have the appropriate configuration variables to work with... Cheers, Peter

Mark - I understand. My point is that if we're going to enter one value & see another derived value, the value we need to be able to enter directly is Allowed Deficit ("Actual Water Applied per Irrigation Cycle"). Working backwards from how much water the soil can hold and how much we need to replace, we wind up with the number representing Allowed Deficit (i.e. 50% loss of 30mm total = 15mm). We were thinking of that number as "Water Applied per Irrigation Cycle" which is no longer correct if ISY is doing the Soil Absorption math on our irrigation. The user now needs to calculate out that ISY calculation in order to determine when they've applied enough water. In that example it's not helpful that ISY shows 12.45mm when they enter 15mm, because they need to figure out what to enter so that that "Actual" field displays the Water Deficit of 15mm (18.0725mm Water Applied per Irrigation Cycle = 15mm Water Deficit). I tried to explain that there were implications to changing the algorithms I proposed, but wasn't successful. This is one of those implications. I also really wish everyone involved had invested an hour to read over and understand at least the first couple of chapters of that PDF I linked to early in the thread because I feel we've spent far more time than that trying to explain/understand concepts, terminology and techniques which are well established among irrigation professionals who use ET. This is not to say that I'm not very grateful to Michel & co. for soliciting our input (and to you for your participation) and for implementing ET at all, just that I don't think we're quite there yet on this one point. Cheers, Peter

Michel - Thanks for the preview. It's exciting! One clarification (maybe for beta 3.1.5 ): - If you're going to apply the Soil Absorption Factor to irrigation water, then the label "Actual Water Applied per Irrigation Cycle" should be changed to "Allowable Depletion." - The user should enter "Allowable Depletion", and be shown "Water Applied per Irrigation Cycle" (So in the UI, the calculation (100/Soil_Absorption_Factor)*Allowable_Depletion would be performed). Here's why: "Allowable Depletion" is the proper term for the amount of water loss from the soil before irrigating. (We've been referring to "Water Applied per Irrigation Cycle" as though it is synonymous with "Allowable Depletion" (which it was until the Soil Absorption Factor started being applied).) Using the industry standard soil moisture balance method of irrigation management, the depth of plant roots is used to determine the ideal water depth. Some percentage of depletion (usually 50%) is allowed before watering to make up the difference. So, the Irrigation Requirement is tracked, and once the irrigation requirement reaches the allowed moisture depletion level it is time to irrigate. So, as a concrete example, if our ideal water depth is 30mm and we want to water when half of that has been depleted by evapotranspiration, our Allowable Depletion is 15mm. That is also the amount of water we want absorbed by the soil. So if our Soil Absorption Factor were 83%, we'd need to apply 18.0725mm to result in 15mm absorbed. But, our ISY program will read: IF Module 'Climate' Irrigation Requirement >= 15mm As you've shown it, the user will either have to calculate the inverse of 83% and apply that to 15mm to determine that (s)he must enter 18.0725mm or sit there trying values until they get 15mm for the Actual Water Applied per Irrigation Cycle (Allowable Depletion). And, when the "Irrigation Cycle Complete" action occurs, the ISY must decrement Irrigation Balance by Allowable Depletion (in this case 15mm) since that's what we've replaced with our irrigation cycle. Cheers, Peter

Works for me. Michel - Have you been following this part of the discussion? The proposal on the table is to rename "Soil Absorption Factor" as "Effective Rain Factor" and use it only in the rainfall side of the calculation. That way we make it clearer what we are calculating, and leave as many options as possible for enhancement going forward... Peter

Mark - The issue is not that irrigation water is absorbed differently. It's what we're measuring. I simplified out some of the explanation to help move things along, but there is a concept called "Effective Rain." That's what we're calculating when we factor soil absorption into rainfall. On the other hand, we haven't been dealing with "Effective" irrigation. Water Applied per Irrigation is not Water Absorbed per Irrigation. Hindsight being 20/20, if this variable had been named something like "Decrement from Irrigation Requirement Balance per Irrigation Run," perhaps it would have made the intent clearer. As for soil type being entered differently - because we're trying for a basic initial implementation we're specifying a single value to approximate Effective Rain. You yourself indicated that you have multiple soil types. When you must compromise (ISY's internal calculations), that's one thing. But why would you want this being calculated for you when you can do this yourself (as part of the initial calculation of run-times which you must do anyway) exactly as needed for your situation? Then there's the lack of clarity introduced by incorporating it into the behind the scenes calculations. If it were possible, the most logical, intuitive and understandable way to write the irrigation program would be: IF Irrigation Requirement >= Water Applied per Irrigation but that isn't possible. Therefore, we take one step away from the intuitive by having to specify the value of Water Applied per Irrigation in the program. Having this constant be different than the value of Water Applied per Irrigation just makes it even harder to understand... Peter

Maybe, but I think you're actually making my point for me. Until we have either a full-featured module or all the tools (e.g. floating point vars & calcs) to do this all in user code, why not keep things as simple as possible? I only included the soil factor because otherwise there'd be no way to take it into account for rainfall. OTOH, we can adjust the runtime - not to round off the Irrigation_Requirement check numbers, but to directly account for the soil absorption (and do that zone-by-zone). If the user figures out the effect of soil absorption on runtime (e.g. "running this zone for 14 minutes will result in 0.5 inch being absorbed") as part of their one-time setup calculations outside of the ISY, then the comparison on a day-to-day basis remains easy to understand ("When Irrigation Requirement >= Water Applied per Irrigation, then I apply Water Applied per Irrigation"). Peter