Mark Sanctuary

Something does not seam right, my test programs have not run because Irrigation_Requirement has not changed, so the Irrigation Complete has not been triggered.

Michel/Peter, How many days does it take to see anything in Irrigation_Requirement? I am on the third day since I installed the module and Irrigation_Requirement still says zero. And this is the first day I have seen anything in Yesterday's_Water_Deficit. I thought it should have at least two days worth of Irrigation_Requirement added up today. Thanks,

I am currently testing this to make sure everything is functioning before I switch my irrigation over to ET control. Irr Req Met 0.5 If Time is 11:00:00PM And Module 'Climate' Irrigation Requirement >= 0.50 Then Send Notification to 'Mark's Email' Wait 12 hours Run Program 'Irr Cycle Complete' (Then Path) Irr Cycle Complete If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Send Notification to 'Mark's Email' Irrigation - Cycle Complete

No docs yet. Soon.

Back from family camp! Sorry I was out right when the new irrigation module got released. I will get to testing so we can get to the Wiki docs. Thanks,

Not sure if it helps but I had a while back some SwitchLinc Timer switches that went bad which made the ISY lockup until I removed and replaced them with new regular SwitchLinc switches. I did not figure this out though until I unlinking a bunch of the switches from the ISY to systematically isolate the problem.

No worries. It's a tough subject and I have had my moments too.

Peter, I have read it many times, thinking about each thing, the hard part here is we have to all learn and discuss this over text. It's not like in a college class were we all went home studied it, then the next day got to have the teacher go over it again and then let the class discuss it. Also I would guess this topic would be broken into many parts over several days so it could be digested over several weeks. I think the time we have spent here is reasonable for what we are all trying to learn. Thanks,

So we need to do this... 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 And making this... Irrigation_Requirement = Irrigation_Requirement - (Water_Applied_per_Irrigation * (Soil_Absorption_Factor / 100)) Be this... Irrigation_Requirement = Irrigation_Requirement - (Water_Applied_per_Irrigation)

Peter, "Actual Water Applied per Irrigation Cycle" is a read only GUI widget in this screen-capture so he is just displaying data. Michel, Are you just showing us what the number without "Absorption Factor/Soil Type"? Actual_Water_Applied_per_Irrigation_Cycle = Water_Applied_per_Irrigation_Cycle * (Soil_Absorption_Factor / 100) Thanks,

Great news Michel! I am excited to see what you guys have built from all this intense deliberations we have had on this subject. I think a BIG thanks is in order for all the hard work you and team have done on this module!

Then we should call it Effective_Rain_Factor which is what it is and would take away much of the confusion.

Peter, I think all you have to do is calculate the runtime offset with an online javascript app (I plan on creating one that is just for ISY use tailored to the user's needs). Does water get absorbed any differently between rain and irrigation? It enters the soil and spreads throughout the particles. The only difference is rain has 100% spread and the dipper/sprinkler has a constrained square footage spread. So why would that entry be any different from rain vs dipper/sprinkler? Shouldn't soil type be set the same for all incoming water types? Thanks,

Peter, What I was thinking we could just adjust runtime to round off the irrigation_requirement check numbers... we can instead of applying 12 minutes for the 0.415 we can do say 14 minutes for the 0.5 application. This way the soil type that takes more to saturate with water gets more water. (this is only illustration, I did not go and actually calculate the runtime so just keep this in mind) Does that work?

Peter, If my thinking cap is on correct... Should we just use the soil factor on both sides then the user would not have to do any manual soil factoring but rather just deal with ins and outs of the water by adjusting the length of runtime per station? Water_Deficit_Yesterday = Evapotranspiration_Yesterday - (Rain_Yesterday * (Soil_Absorption_Factor / 100)) // Applied Rain water is factored by soil type and addresses if the soil is more/less porous and looses its water faster/slower Irrigation_Requirement = Irrigation_Requirement - (Water_Applied_per_Irrigation * (Soil_Absorption_Factor / 100)) // Applied Irrigation water is factored by soil type and addresses if the soil is more/less porous and looses its water faster/slower The only bummer I can think of for now would be the different soil types per station, but we are already kind of half way in this issue since we are only able to do one kind of factoring on Rain_Yesterday with our current design anyways. Thanks,

Great! I will work on it. Sorry if you have mentioned this before and I forgot. I did not mean to added posts that where unacceptable. Sometimes my memory fails me especially when I hang at the forums then get busy at work and return here six months later to hang again. Let me add these rules to the community section of the Wiki so I can reference them in the future.

Peter, If Michel confirms, just add a separate section on the bottom of your existing proposal, maybe something like this.

Thanks Peter! This basic plan looks like it will be a good starting point. Michel, The plan up here did not mention the Trigger 'Reset Irrigation_Requirement' command, is this command still planned for the first pass? I understand we are not to add anything to the Wiki that is not in the ISY ie. proposed code examples, so do you mind if we only work on the Wiki section about Evapotranspiration theory? Thanks, Mark

Thank you for being open about what your thinking. I makes it much easier for us to help you and understand the pitfalls your seeing that we may not understand from an outside perspective. Yes spaghetti code it is... because I can't think of any other ISY program commands that are limited to a window of time they can function as this trigger command idea. If the command trigger 'Perform Irrigation Calculations' part is that concerning I think we all agree you can just not do that part and sync it with the WeatherBug. In the end we just want to make the Evapotranspiration data useful. This overall design is a good idea for what we are trying to do here with splitting some functionality with the ISY side and some functionality with the user programs side, the only thing easier on the user really would be a full blown irrigation module but that option is not on the plate. Is there any other issues outside of this rain/spaghetti/trigger code issue in this design that we should discuss that is holding up it being implemented? Thanks,

No worries Michel. I will remove the links for now. Sorry about the Blaa blaa but really its only a placeholder that I was going to replace later today, at which point I was going to be pasting actual text into it. Really don't see any reason why we can't work on the explanation of Evapotranspiration since it is already a part of the tool in 3.1.3 release. As for any code examples they will not be there until the tool supports the commands.

Great! I have started with just the basic link structure in the how to guide section. How-To_Guide - Irrigation

Peter, Do you want to help with the Wiki on this topic? If so, have you gotten UDI Wiki access yet?

With this being pseudo code I guess I assumed that it would be ran every 24 hours. Peter is right it will work as expected if we just prevent execution of this part of the code too often, about every 23 hours or so. We are going to have gotchas but with safeties in place it should work great. The function of this code is looking very good and I think it is about ready for a round of alpha work. Plus after it is implemented and being tested you can put examples here of, "Guys I found this issue when I execute it, what do you think?" and we can help. Good job Peter!

I like it! It's a print! I just want to understand this further... Previous_Rain_Total = Rain_Today // at 23:59:59 Total_Rain = (Previous_Rain_Total - Total_Rain) + Rain_Today 2.0 total rain at irr trigger Friday = (3.0 End of day total timer triggered Thursday at 23:59:59 - 2.0 last total rain at irr trigger Thursday) + 1.0 current rain measurement at irr trigger Friday Does this make the stationary Rain_Today variable usable at any time of the day?

Yeah we have been working out the variables before he released the algorithm. We can move on to the next phase. Go for it Peter and submit the pseudo code.