- This topic has 7 replies, 5 voices, and was last updated 10 months, 2 weeks ago by
.
-
Posts
-
Hi,
I’m not sure if i fully understand how this should work – please advice how should i configure my system.I want to water my lawn every 3 days. So i have program set to run every 3 days with water adjustment enabled. I target to get ~35mm of water (sum of waterings) for my lawn per week. BUT i looked at source code of weather service and noticed that weather adjustments is calculated only using 24 hours history!
This makes me feel that “Use weather adjustment” should be used only for programs that run every day.It’s done this way for several reasons.
1) we are constrained by the range of historic data weather service providers offer. Many weather service providers will only provide more than 1 day of history if you are on a paid subscription. This is assuming the weather data comes directly from the weather service providers and it doesn’t require the firmware / controller to store the data. Obviously, one way to address this issue is to store the weather data on the firmware / controller side, which will consume flash memory space and it has not been implemented. Additionally, if you power off the controller for a few days then it will lose the history data so the controller needs to be online and have Internet most of the time.
2) It’s not entirely clear how you take into account of history data. For example, the Zimmerman algorithm uses the average temperature and humidity of the previous day, and the precipitation of the previous day. When you water every 3 days, do you take the straight average temperature and humidity of the past 3 days, or do you take a weighted average since the temperature 3 days ago probably doesn’t affect as much as the temperature of yesterday? What about precipitation? Do you use the total precipitation of the previous 3 days, or the average, or an weighted average? It’s not entirely clear what’s the right way to take into account multiple days of weather data.
3) Users often have multiple programs, and programs don’t always run on a fixed interval. For example, some programs may run on Mondays and Tuesdays, some programs may run only once a month. How do you take into account history data for these irregular type of schedules?
4) The entire project is open-source, including the firmware, and UI, and the weather code. If you have an idea how to implement it correctly, you can modify the source code in any way you want, and make a pull request so we can review and integrate your contributions to the code base.
Thank you for detailed explanation Ray.
1) Getting historic data for more than 1 day is not the biggest problem. And for sure this data should not be stored locally.
2) This is most interesting part how to correctly interpret historic data, but current method of average humidity, temperature and sum of precipitation for N days instead of 1 day could be good starting point
3) I think watering level should be calculated per program. For example I water garden and flowers with dip line every 2 days and lawn every 3 days
4) i will definitely try to experiment with source and build modified version of weather service and maybe firmware. It’s a pity that using Apple API key costs 100$ per year – i will need to find reliable weather data source for my locationp.s. I’m not an agricultural expert, but I’ve heard opinions that it’s better for plants to be watered infrequently but more abundantly than a little every day. Maybe someone has any thoughts on this?
You don’t have to use Apple API. Our latest weather code allows you to choose between many different weather service providers, most of which are free.
I am no agricultural expert either. We have a diverse group of users who use the controller in different ways. Some of them need to set programs to water several times a day. Some may only need watering once per week. There is no single ‘recommended’ way to water. It really depends on the application.
Hello,
I am currently looking into making updates to address using weather data multiple days into the past and want to circle back on options for how the data should affect watering over time.
I am starting by looking at the ETo method we use, which addresses the amount of evapotranspiration and precipitation and creates a scale based on which is greater and by how much. Looking at this metric, it is naturally cumulative so I would not think to average it, but the issue is in most areas that I have tested so far with that in mind the watering scale maxes out at 200 after just a day or two of cumulative data into the past.
When thinking about an average, you are averaging the amount of water coming in and out of the ground across days, which would not properly address multiple days of rainfall or heat, however it would at least keep scales from hitting a max within a short time span.
I am not sure which of these, or another idea, would be better so I am curious if there are any thoughts on that debate.
Thanks,
NateHello, I just wanted to add a me-too to this. I want to base my watering off of getting at least 1 inch of precipitation a week. So if I received 1.3 inches 1 day ago, then I would want the weather adjustment to set the watering level to zero for the next 6 days for any zones setup to water.
If I received .5 inches, then set to 50%
And it would be nice to also adjust based on forecasted precipitation amounts and probability. If there is a 50% chance of getting .5 inches 3 days from now, reduce the watering adjustment by some amount.
Open Meteo seems to allow showing 1 week of daily historic precipitation data, so the data seems to be there for some providers. Is the subtext that only weather adjustment methods that are supported by all of the data providers would ever be considered for inclusion? Or would it be fine to have something that is limited to only certain data providers?
It sounds like I need to run my own instance of the weather service to be able to play around with it.
Come up with a new adjustment method that looks at precip amounts over the course of a week.https://github.com/OpenSprinkler/OpenSprinkler-Weather/tree/master/routes/adjustmentMethods
Similar to the work mentioned at
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/issues/267#issuecomment-2887581934Hi, I wanted to give a +1 on this effort. Dynamic adjustment of irrigation period would be super nice.
Here are my birds-eye throughs on the problem…– It is favorable for lawn to have a decent amount of water (like 8mm) at a time, so the soil can absorb the water deep enough. This is why we are irrigating every third day or less on lower temperatures and even every day when it is hot.
– The problem is that weather is changing, so I constantly need to change the period according to the average temperature and moisture loss. But this is not straight forward as I should also calculate with the start-in n days parameter.
– ETO is a good measure which describes the daily loss of moisture = daily irrigation need.
– The algorithm should cumulate the daily ETOs as negative values and cumulate the daily precipitation as positive values. User should be able to set a threshold (like 8mm). When there is a program due and the cumulated deficit is more then the threshold, that day the program should run with the set times… So the algorithm will adjust the irrigation period to the daily evaporation and precipitation.
– It is a question what to do after the program run… The nice thing would be to be able to set the irrigation intensity (mm / hour) for every station and this way the irrigated water amount could also be added as a positive value to the cumulated ETO, so the system would be self-regulating.I know this is far from how the firmware actually wired now… But I hope this help the thinking.
BTW, I was considering to build and Openhab rule that does the calculation externally and triggering the stations over the API. This is still an option, but it would be much more elegant to have this capability in Opensprinkler as a core functionality.
There is a branch that’s being prepared which implements this feature:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/tree/multidayETo
also the corresponding weather server code:
https://github.com/OpenSprinkler/OpenSprinkler-Weather/tree/multidayETo
they will be released after internal testing.
- You must be logged in to reply to this topic.