As the title says the schedule ran at 60% … the graph is correct, but it’s almost like it did not take rain fall into account?
If I had to guess, I would say that the moisture balance was estimate to hit 0.08" (17%) and some safety factor kicked in to restore the moisture balance since no rain was forecasted…
Since the amount of water applied is fixed (will always be 0.45") it overfilled the zone.
You have a watering event scheduled for tomorrow as well?
It rained 0.35" on 6/5 & 0.18" on 6/6 (which the graph shows correctly) The schedule should run when it’s close to the allowed depletion, not at 60% full.
The red line shows depletion due to ET, which then would trigger a watering event.
Do you have days where it’s not allowed to water?
Ok, not that. Have you changed anything in this zone? (If you change something, the way I understand it, the moisture level chart will get recalculated with your new settings, so other than what you actually watered and what precip you got will all get recalculated.)
Ah, OK. I was confused when you said the rainfall was not accounted for, but the plot shows it added.
I still think it watered to prevent the level from possibly going below the threshold.
The minimum is the minimum allowed, not a trigger. I am thinking that the controller is set to water whenever it “thinks” the level falls below a certain level.
I don’t think so, but I don’t remember what happened yesterday
The ‘threshold’ is my allowed depletion. Look at the depletion trend from 6/8 to 6/10. The ET is higher than the previous days so on 6/8 the level would have been a little bit above the AD & it should water the following day. ? Unless you see something I don’t.
@ronjonp I did some research into this and my best guess is that when the simulator ran it received slightly different data than is rendered on the chart. Usually it should be close.
The recording for June 7 was:
Skipping watering because we should be ok without watering before the next possible watering date of 2016-06-07 based on the forecast. WaterEntry=WaterEntry(date=2016-06-08T13:00:00.000Z, evapotranspiration=0.24, cropEvapotranspiration=0.2, irrigationEvents=, effectiveRain=0.02, soilMoistureLevelAtStartOfDay=0.26, temperatureMin=57, temperatureMax=87, depletion=0.58, stationId=null, exposure=1.0, cropCoefficient=0.8, depthOfWater=0.54
Recording for June 8 below. Notice that at the beginning of the day according to the simulator soil moisture was at .1in, so close to being depleted.
Watering because we should based on the soil moisture deficit and because we are allowed to based on FlexScheduleRules. WaterEntry=WaterEntry(date=2016-06-09T13:00:00.000Z, evapotranspiration=0.28, cropEvapotranspiration=0.22, irrigationEvents=, effectiveRain=0.0, soilMoistureLevelAtStartOfDay=0.1, temperatureMin=57, temperatureMax=93, depletion=0.22, stationId=null, exposure=1.0, cropCoefficient=0.8, depthOfWater=0.54
If we receive different weather data at time of flex determination, than we do when rendering the moisture chart, there can be these discrepancies. Let me know if this happens again and we can look deeper.
@ronjonp One other note, if there have been any waterings through flex, and any zone characteristics are changed, previous data could look suspect since we re-render everything from the beginning of time regarding that zone in the moisture chart. Should be display only issue for the past.
That makes sense. Thanks for looking into this