- This topic has 6 replies, 2 voices, and was last updated 2 years, 3 months ago by
.
-
Posts
-
Experimenting with manually setting a Rain Delay for N days, I discovered that the rain delay does not reset the start date of the programs after the rain delay period ends. To me this seems illogical and makes the rain delay almost useless.
I propose that the logical implementation would be to restart all the interval programs to begin counting days from the day the rain delay ends. If I have a program that runs at a 3 day interval, I don’t want it running the day after it rains merely because that would have been the programmed watering day in the absence of a rain delay. Instead, I would want it to run on the 3rd day after the last day of rain.
For example, suppose I have a program that with a 3-day interval that last ran Sunday morning, so that the next run will be Wednesday morning in the absence of rain. Suppose rain is forecast for Tuesday, and that I manually set a rain delay that ends late Tuesday. The current implementation will run the program on Wednesday, the day immediately after the rain. Since I only want that area to be watered every 3 days, I do not want the program to run until Friday, 3 days after the Tuesday rain.
Perhaps I’m overlooking a different way to accomplish my objective.
I should add that I have another program that runs at a 2-day interval. The workaround of adding 2 or 3 to the number of rain days beyond the last day of forecasted rain cannot achieve my objective for programs having different intervals.
I am not sure if there is one correct way to implement the rain delay. The issue with your proposal is: what happens with the other programs which should run normally and that fall after the rain delay period? If we keep pushing them back and queuing them, you can quickly get into the situation where there is simply not enough time to catch up with so many queued programs. For example, let’s say a program is supposed to run every day, and there is a rain delay that happened on Monday and Tuesday. If you queue those programs to run on Wednesday (i.e. after rain delay ends), what about programs which would normally run on Wednesday? Besides, stop watering during rain delay is partly to avoid wasting water, since the rain will irrigate the lawn anyways. So delaying those programs after the rain delay ends seems to over-water the lawn still.
Using one of the weather adjustment method can partly address this issue: instead of doing manual rain delay, let the weather adjustment method to figure out the watering percentage automatically. I know the weather adjustment methods are not perfect, but my point is that no matter how you implement the algorithm, there will always be some situations where the implementation doesn’t work perfectly. So I don’t think there is one correct way to implement the rain delay.
Thanks for your detailed reply.
Ray said:
“I am not sure if there is one correct way to implement the rain delay. The issue with your proposal is: what happens with the other programs which should run normally and that fall after the rain delay period? If we keep pushing them back and queuing them, you can quickly get into the situation where there is simply not enough time to catch up with so many queued programs. For example, let’s say a program is supposed to run every day, and there is a rain delay that happened on Monday and Tuesday. If you queue those programs to run on Wednesday (i.e. after rain delay ends), what about programs which would normally run on Wednesday?”Response:
I am only addressing programs that run on intervals, not on fixed weekdays. I agree that weekday programs should not be rescheduled in response to rain delays.
In the case of interval programs, there always will be days on which all the programs run. For example, if a program has a 2-day interval and another program has a 3-day interval, both programs will run on the same day every 6 days. Therefore, someone who wants to prevent programs from running on the same day must use weekday programs, not intervals. Hence, your concern about too many programs on a single day is irrelevant to interval programs.Ray said:
“Besides, stop watering during rain delay is partly to avoid wasting water, since the rain will irrigate the lawn anyways. So delaying those programs after the rain delay ends seems to over-water the lawn still.”Response:
I guess I did not explain clearly. I certainly do not want to water the next day after rain! I want to start counting down the watering interval from the day after a rain. So if the last day of rain is Sunday, the first watering day should be Wednesday if the program interval is 3 days.Ray said:
“Using one of the weather adjustment method can partly address this issue: instead of doing manual rain delay, let the weather adjustment method to figure out the watering percentage automatically. …”Response:
Watering percentage will not work for me. I am not watering lawn. I am watering a variety of plants, including roses. When it is not raining, it is beneficial to allow the roots to dry out. Watering small amounts frequently should be avoided.PROPOSED SOLUTION:
Even if you disagree with my rationale for handling a manual rain delay, a solution would be to delete from the firmware the code that constrains the “Starting In” day to be modulo the interval, i.e., the remainder. Hopefully this would merely require deleting the modulo step rather than adding code.
I see no benefit in imposing an unnecessary constraint on the user even if you’re unconvinced by my use case.If I understand correctly, you want the start day to be a specific day (e.g. Sep 23, 2022). This change is not as trivial as you might think — just deleting the modulo operation will not work. To start, the ‘start’ day being a modulo is not my invention, on traditional sprinkler controllers, this is basically how the parameters are set. Say if you have a program that runs every 5 days, and you don’t want it to run on the day the program was created, instead you want it to start in 4 days, and then every 5 days from then. The ‘start’ day parameter will change dynamically, for example, tomorrow when you check the program, it will say start in 3 days, and the day after tomorrow it will say start in 2 days etc. The way this is implemented is to modulo today with the interval day (5) and compare it with the remainder and that tells whether today is when the program will run or not. As you can see, if the ‘start’ day is more than the interval, this comparison will not work.
What you want is for the program to record a specific day (say, Sep 23, 2022) and that you want the program to start on that day and every x days from that. This is all doable — it will need to involve both firmware changes (including changes to the program data structure because each program has to store a specific day), and also UI changes. This is nothing complicated, but what I am saying is it’s not as simple as deleting the modulo operation.
Thanks very much for explaining why the remainder is integral to how your algorithm currently works. I accept that it’s too much work for you to change if I’m the only user who wants this feature.
I think I can develop a solution for my own use in which I schedule a script to run at the end of a rain delay that resets the “starting in” date of all the programs.
(FYI, the remainder approach is not universal; the Blue Spray controller I used before Open Sprinkler does allow you to set a program to start on an arbitrary date. But it has other shortcomings that make me happy to have switched to Open Sprinkler.)
In some cases you can make use of the OpenSprinkler HTTP API:
https://openthings.freshdesk.com/support/solutions/articles/5000716363-os-api-documents
to provide customized need. For example, you can write a small script to disable a program and later re-enable it and modify its ‘start in’ parameter. This may help achieve what you want. We have an example test script:
http://raysfiles.com/os/TestOSAPI.html
which shows selected examples of the API.
- You must be logged in to reply to this topic.