November 21, 2019 at 2:58 am #63336
I’d like to set up watering so that a watering cycle only proceeds when it meets a minimum threshold, with the remainder being held over for the next execution of the program. My intended use case is to water with a consistent amount of water, but instead alter the interval between waterings according to the weather. With a threshold set to say 500%, it would on average only water once every 5 days, but increase the watering frequency it hot weather.
I’m thinking this could be implemented by adding by adding two int16s to ProgramStruct, one to hold the threshold, and another to hold the current percentage that has been held over for this program. Then when an event is scheduled, the new watering duration is added to the current deficit.
With the addition of a rain constant, rainfall could be subtracted off the water deficit, delaying the next watering based on the amount of rainfall.
If I were to implement something like this, is it something that could be included in the main distribution. Are there any particular guidelines on the storage of these parameters and current state?December 31, 2019 at 1:21 pm #63847
I’m working on something similar to what you are requesting. I run HomeSeer, which has a plugin module that can communicate with OpenSprinkler. HomeSeer also has an extensive scripting language. However, I also operate my own weather server (that feeds the data from my personal weather station); I’ll explain why that’s important after a few sentences. I built a test script to see if I could accomplish what you wanted, and it’s not very complex. Note that OpenSprinkler updates the water level every two hours. which turns out to be important.
I wrote a small node.js application that intercepts the call from OS to the weather server, and I push the desired water level to that (but at 9 p.m. every night that application resets itself so it no longer interferes with the delivery of the data from the weather server, allowing time for the latest water level to be pushed to OS, so my script can fetch it just after midnight.)
My test script runs at 12:01 a.m. and retrieves the latest water level from OpenSprinkler and adds it to an accumulator.
Then, if the accumulated water level is less than 50%, the script sets the water level in OS to 0 and also pushes that to the intercept application.
If the accumulated water level exceeds 50%, and is less than or equal to 200%, I push that to OS and to my application that intercepts the weather data call, and I zero the accumulator. If the accumulated water level is greater than 200%, I push 200% to OS and the intercept application and subtract 200% from the accumulator.
[I understand this is what is technically known as a kludge, but I’m sort of prototyping a solution to a more complex issue, which is how to make ETo work when you can’t water every day.]
Seems to work in test mode. (It’s the dead of winter here. The low this morning was close to zero F and the high won’t make it much past 40F, so my sprinkler system is off, but I can still run OS and review the logs.)
This was a good exercise for me to understand what I will have to do to make ETo work when daily watering is impractical or inefficient. Eventually I would like to move this logic into the intercept application. However, for ETo, I may have to run the sprinkler programs multiple times in a single day to get sufficient water without runoff, so the problem is a little more complex. I think I may have a way around this which was triggered by your suggestion of a minimum threshold.
- You must be logged in to reply to this topic.