- This topic has 3 replies, 2 voices, and was last updated 1 year, 12 months ago by
.
-
Posts
-
For a program defined by interval days instead of weekdays, the web client will not allow me to enter a “Starting In” value greater than the interval. (I would like to do that to delay the next start until after the next predicted rain. I do not want to rely on an online weather service or rain sensors.)
Is this a limitation of the firmware or of the web client? Specifically, if I send a json “change program” command that sets days0 to a “starting in” number greater than the interval, will the firmware correctly delay the program start for that number of days?
Alternatively, the firmware spec defines a controller variable “rdst”, rain delay start time, that is not accessible via the web client. If I send a json command to change this variable, will it actually delay all the program start times, or is this an unimplemented feature? Will it automatically reset “rd” after the delay expires? Is “rdst” defined as an absolute epoch time or an interval in minutes or seconds from the current time?
Lastly, when all the programs are delayed, either manually as above or in response to weather, do all programs have their first start date on the day after the delay period, or does the delay stagger the next start date according to what the “Starting In” value was before the delay event/action?
SOLVED. I apologize that I overlooked the “Change Rain Delay” menu item in the web client because I was originally focussed on changing the program “starting in” date.
(I tried to delete my previous post entirely, but the Edit button doesn’t seem to do anything.)
The ‘starting in’ days is always a remainder of the interval days, for that reason cannot be larger than (interval-1). Basically this is not used to delay the program by some arbitrary number of days, instead, it’s used to set when the programs should start within a cycle of interval days.
- You must be logged in to reply to this topic.