Master station start before

[wifi75]

hello to all,
it is possible run before, 10 seconds master station (punp) before start zone irrigation?
Question is why Opensprinkler delays the start of the pump?

[Ray]

This is due to the way the scheduler is implemented, which only activates the master if a non-master zone is activated. Since it currently doesn’t look into the future to see what zone would be activated, say, in the next xx seconds, it can’t start the master before the zone starts.

That said, there is a work-around to achieve the effect of this by using a dummy zone. Specifically, you can use the first non-master zone (for example, zone 1 or zone 2 depending on which one is your master zone) as a dummy zone. You can schedule the dummy zone in a program. The reason it needs to be the first non-master zone is that that’s the zone that runs the first in a program. Let’s say you want the master to open 10 seconds before any other zone starts, you just schedule the dummy zone for 10 seconds, it will start first and activate master along with it (the dummy zone itself doesn’t operate any physical valve), then it goes to the next zone (which is a physical zone). That achieve the effect of opening master 10 seconds before a zone.

[wifi75]

Yes I understand the workarround, but why the application it is without this features?

[Ray]

“but why the application it is without this features?” — I don’t understand this sentence.

[spanno]

(sorry if posting duplicate, am struggling with forum software:()

Hi Ray,

I too, am thinking of a solution for advanced master start (if that’s what you’d call it). And yes, I think the solution with a dummy zone is effective. However, It does come at the cost of a physical station. (whereas the delay at the end of a program can be assigned to an non existing station, for example #9).

I was wondering if it would be possible in a future firmware release to either:

1) change the order of (sequential) stations in a program? (for example place station 10 before station 3, when 1 and 2 are master stations)
2) add manual override mapping of stations (so default software station 3 maps to hardware station 3 on the GPIO, but with advanced setting, user can map software station 3 to hardware station 10 on GPIO – or any other if desirable)

As far as I can see any of these solutions would allow for (one or two) master station(s) to start before irrigation stations are opened, without the cost of one/any (hardware) station.

What are your thoughts? would this work, and also be workable/programmable?

My situation is that I need one master station to start the pump at a depth of about 200 feet, and after about two minutes (when water starts flowing) second master station to close one NO ball valve and simultaneously open a second NC valve diverting water flow from the cistern to the irrigation manifold. And only then open solenoid irrigation valves.

Hope I made some sense. These things are harder to explain then to think up;)

[Ray]

We can make the dummy zone a virtual zone (for example, zone 0) so that it doesn’t occupy any physical zone.

Regarding your two suggestions:
1) yes, the ability to change the order of zones in a program is a possibility. In fact, the firmware for OpenSprinkler Bee (OSBee) has a new, more flexible program type where you can set zones in any arbitrary order, including multiple zones at the same time, and duplicate zones. Specifically, each program contains a number of ‘entries’, and each entry is a set of zones and associated run time. It’s feasible for OSBee because it supports only 3 zones, so the program editing interface is not too complicated. For OpenSprinkler though, due to the possibly large number of zones (up to 72), this more flexible program type would be a lot harder to display and visualize in the app. For that reason, it has not been implemented.

2) manual overriding of zone mapping has been proposed by some users before. I personally do not favor this approach because it can be confusing for the user to remember the mapping (like logical zone 1 maps to physical zone 7 etc.) And option 1) above seems a more flexible approach anyways.

There is a good reason why the master zone is implemented as it currently is: we need to guarantee that whenever an associated zone turns on, the master zone turns on as well, regardless of whether the zone is scheduled to turn on in a program, or manually turned on. So currently, the firmware decides whether the master should be on or not by dynamically checking all other zones. There is no scheduled turn on or turn off time for master, instead, its status is determined on the fly by other zones. It’s harder to make such guarantee with other ways like the two suggested above.

Speaking of that, you should be aware that you can always get rid of master zone settings, and instead manually schedule them with other zones using multiple programs. This may be able to achieve what you need. Specifically, go to Edit Options, remove the Master Station configuration. Then let’s say zone 1 is physically the master zone, you set it’s ‘sequential’ flag off (i.e. it’s in parallel mode). In parallel mode it’s allowed to run with other zones. You set one program to turn on zone 1 at some given time, and duration as long as how much you need to water all other zones. Then you set another program for the other zones, with a start time some time after the first program. This way zone 1 turns on first, then after some time, program 2 starts running, and because zone 1 is parallel, it runs in parallel with the other zones. This should achieve the effect of turning on master earlier than the other zones. The downside is that you have to use multiple programs to do so, but since the firmware supports up to 35 programs, it should give you plenty of room for multiple programs.

[spanno]

@Ray: Thanks for the explanation. I agree that zone re-ordering is preferable over re-mapping. I had not considered the complexities of 72 zones reordering. I was just imagining a way to change the order by drag and drop or repeatedly pushing an up- or down button in each zone-bar.

One way to simplify might be to change the program interface from a full list of all available zones to an ‘add zone to program’ option where you start with an empty program and add zones as you need them en then place them in de desired order.

And by the way. I was confused about the GPIO option in the advanced tab. I now realize it is only applicable in/on OSPI and the GPIO does NOT refer to the physical zone connectors on Open Sprinkler. My mistake.

Anyway, (FYI) I came to a work around using two programs and two dummy zones (nr 9 and 10). Zone 9 results in an advanced master start and zone 10 in delayed master stop.
Program one contains only zone 9 (activating Master 1 – the well pump via relay)
Program two starts 2 minutes after program one (activating master 1 again and also master 2 -the two NO/NC valves redirecting flow from the cistern to the irrigation system)

Program one runs for 3 minutes so there is an overlap of one minute in activating master 1 – because I noticed that the well pump relay will shut down momentarily when the programs are sequential- causing a power interruption to the pump for about one second (not desirable for a pump)

Program two will end with dummy zone 10 allowing for the irrigation solenoids to close under pressure and advanced shut down for master 2 to redirect flow from the irrigation system to the open cistern to avoid irrigation water entering the well as water flows back once the pump stops under pressure of about 200 feet of water column.

The advantage of this solution is twofold:
1) does not cost a physical zone (like zone nr 3 acting as a dummy when only one program is used)
2) still allows for automatic changes to the duration of program 2 (the irrigation program) because of weather forecasts or sensor input

Disadvantage is:
1) start times of the two programs must be coordinated and in tune with each other. So a change in start time for one program must be manually matched with a change of the other program’s start time. This becomes more of a challenge in more elaborate and complicated programming schemes

It is a workaround that takes a little thinking through and requires some user-alertness. Would improve a lot with zone re-ordering, making that a nice-to-have feature, not a need-to-have.

Thanks for elaborate reply, I hope my work-around may benefit other OS users or challenge someone to come up with (even;) better approaches. and btw: I am available for betatesting or brainstorming about zone re-ordering anytime.

[spanno]

oh! and as an afterthought: user definable dummy zones might also be a solution – allow users to define one or more dummy/virtual zones and assign them a zone number either smaller than 1 (starting with 0 and then -1, -2 etc) or larger than 72 to place them at beginning or end of a program ( or even a decimal to place between real zones? i.e. dummy zone 2.5 to run between real zones 2 and 3).

Might be useful to research the user base for advanced and delayed master start/stop and zone re-ordering. Any way to figure out how many users on a well pump for instance? Because if only a handful of users would benefit too advanced a solution would only needlessly complicate UI for most (regular) users.

[Author]

Posts