March 16, 2015 at 9:03 pm #36040
I’ve noticed that when I stop a station in the current status the next station has been set to start at a specific time, it does not move up to the current time and has to wait to run.
I’ve noticed that the current status has a list of all stations and if one is set to run and then another program initiates that same station to run before it’s last program runs, the second request is ignored.
I’ve noticed other threads where this is compared to other sprinkler controllers behavior and how other sprinkler controllers queue all requests, even duplicates.
What about creating a “current queue status”. Instead of all stations only the ones currently set to run would be listed with the amount of time they are to run (not the actual time they will start)
This new method would monitor the programming and once a zone is ready to run the system would initiate a zone to run in a queue. Not with the time to start, but with only the zone and the amount of time it will run. As zones complete or someone deletes them in the “current queue status” they get deleted off the queue.
You could even make a station option to allow duplicate station queuing or not. With the no queuing option it would operate as it currently does, and it would eliminate the wait for the next station to run if you cancel a station.
Of course i know it would also give the preview programming some challenges too.March 16, 2015 at 9:48 pm #36046
The way the current firmware works is that when a program is scheduled, it calculates the start times of all stations involved in the program. If a station is manually turned off, it doesn’t automatically move stations upwards. This behavior can certainly be changed by modifying the code, but it’s unclear to me whether the user wants to move the stations immediately upward or not. So all scheduled stations remain in their originally planned start time. We can add an option in the future, where when manually turning off a station, the user is prompted with the option of moving all other schedules upward or not.
Also, because there is no queuing structure, each station is only allowed one schedule at any given time. If the station hasn’t finished running, requests to run the station again will be ignored (unless if you manually turn off that station first, then you can schedule a new run time).
This can be solved by using a run-time queue, which should be fairly easy to implement. It’s already on my todo list.March 17, 2015 at 8:22 am #36057
I’ve only used one other sprinkler controller, a rainbird esp xxx. It had 4 different sections for programming (ABCD).
It used the queuing behavior. If you stopped a running station the next one started immediately, and it made sense to do so whenever i did it. And the same zone could be queued and was waiting if it was set up in two or more of the ABCD sections.
you could add an on/off option in the stations “allow duplicate queuing”. If yes the station could be queued again, if not and it was already in the queue it would be ignored. IMO the program should default to allow duplicate queuing.
- You must be logged in to reply to this topic.