Dealing with multiple OSPi units?

[craigmw]

I just received and set up an OSPi and I’m quite impressed with it overall. One issue for me is that I currently have two sprinkler timers, one in the garage for the front yard, and a separate one in the back yard. There are 4 zones in the front and 9 zones in the back yard (so I currently have my OSPi connected to a zone expansion board). Routing the wiring from the stations/valves in the back yard would be a challenge, as it is currently quite a long run and would require tunneling under concrete decking to route it to the garage. Instead, I plan to purchase a second OSPi so that I can run two units simultaneously. I realize that I could set up two separate IPs to connect independently to each OSPi. However, I wonder if there are others here that have more than one OSPi set up. It would seem that, given that the interval timer program can respond to HTTP GET commands, it might be possible to have other OSPis respond to a master controller via the web app. It would be convenient to have all of the stations scheduled in a single program.

[andrew]

If you’re not worried about network issues preventing the slave from receiving commands from the master, you ought to be able to set something up with a relatively small bit of hacking. Let’s call the back yard your master and the front yard the slave. Your master will consist of one RPi, one controller board, and one extension board (which is a shame since you have ports to spare on the front yard). The slave will consist of one RPi and one controller board.

The quickest thing to do would be to configure the interval program on the master RPi to have an additional extension board (two in total), but hack the code so that the data that would be sent to the controller board and its extension boards would be forwarded to the slave instead. Fortunately, this appears to be fairly easy. In the OSPi.py file, find the definition for the set_output() function (line 282 of the current version). It looks like this:

##### GPIO #####

def set_output():

disableShiftRegisterOutput()

setShiftRegister(gv.srvals)

enableShiftRegisterOutput()

Luckily, this is the only place where data is sent out to the controller board and its extension boards, so you’ll really only have to modify this area to suit your needs. We’ve configured the master to have an extra extension board, so the first thing we need to do is make sure that the data for that extra board is not actually passed to the controller:

##### GPIO #####

def set_output():

local_srvals = gv.srvals[:16]	# get the first 16 stations values

remote_srvals = gv.srvals[16:]	# get the last 8 station values

disableShiftRegisterOutput()

num_stations = 16                     # the following function uses num_stations, so we temporarily change the value

setShiftRegister(local_srvals)	# only send the local values to the master's controller

num_stations = gv.sd         # put it back to what it was.

enableShiftRegisterOutput()

Next, you’ll need to add some code to the end of that function that connects to the slave and sends the instructions for the remaining 8 values. I’ll leave that up to you, but you could implement some simple socket connections or use a web server, or whatever. On the slave side, whenever it receives data from the master, it should set its own shift registers accordingly. That’s all the slave has to do. For that, you may simply want to copy the original set_output() function (and dependent functions and variables) and simply call them. I can give you tips on the parts I’ve left out; let me know if you need further help or anything’s unclear. Also, I took some guesses wrt the bit ordering of the srvals array. it may be that the elements you want to forward to the slave are the first 8 elements instead of the last. You’ll just need to play with it.

[craigmw]

Andrew:

Wow, thanks for this! Looks like a reasonable way to hack the OSPi to get it to do what I want. I could certainly play around with the code as you describe, and this gives me a starting point for experimentation. It would certainly be nice to be able to treat all of the stations on the same program (schedule). This would prevent water pressure drops if the front sprinklers were operating at the same time as those in the back yard. It seems to be that this would be a simpler design task if the OSPi.py program were simply running as a “server” for HTTP GET commands, with all UI implemented by a web app. The web app could query scheduling databases from as many OSPis were on the net, and do the job of coordinating the schedule by a series of HTTP GET commands to open each valve independently. This might make it easier to implement individual durations per station as well. While I really like the OpenSprinkler scheduler program, it would really help to have a way to control individual station times for each program, as some zones need more water than others.

I agree, it is a shame that I can’t just do this from a single location. I have 9 zones in the back, meaning I need an zone expansion board, and then an entirely separate OSPi for the front. Aargh!

In any event, you all have done such a great job supporting a really nice way to control water usage.

[andrew]

With respect to some zones needing more water than others, you can get around that by adding an additional program that activates just the zones that need additional watering. It’s clunky, but it should serve your purpose.

[craigmw]

@andrew wrote:

With respect to some zones needing more water than others, you can get around that by adding an additional program that activates just the zones that need additional watering. It’s clunky, but it should serve your purpose.

That is what I was thinking. I will likely do that until I can find the time and energy to work on modifying the scheduling routine. I have yet to really dig into the internals in the scheduler program to see how this is being accomplished.

[Samer]

The way programs are scheduled is pretty awesome. I will just give an example since I don’t know how else to explain this:

Program 1:

M,W,F,S
2:00AM to 10:00AM
Station 1,3,5,7,9
30 minutes per station

Program 2:

M,W,F,S
2:00AM to 10:00AM
Station 2,4,6,8,10
15 minutes per station

This will run programs 1-10 in sequential mode (assuming that’s the mode you are in) and run them one after another altering between 30 mins and 15 mins based on which station it is (in this example odd vs even).

What I am trying to illustrate here is you don’t have to worry about time conflicts between programs. The way the scheduler processes program’s is by stations not locked to one program.

Hope this makes sense!

[craigmw]

Samer:

Interesting…. so you can stack up multiple programs that execute at the same time to configure different times per station? This would be indeed handy, but would make the task of programming unique times per station difficult, at least as I see it. An alternative would be to have the scheduler set up a table of events (either in an array or data file with record structure: program number, OSPi number, station, start time), each of which would be dynamically set in the scheduler page. Changes in % watering would have to access this table and modify the times for each event.

BTW, great job on the web app. It is quite evident that you know what you are doing!

[Samer]

That’s the way the OpenSprinkler currently works (what I described above) and also the interval program for the OSPi.

I understand what your saying about timing individual stations but to me this fine control of what specific minute a station turns on isnt needed so long all the stations water for the correct duration inside the specified time window.

Glad your enjoying the web app!

[craigmw]

I agree that the way the program operates currently, it is possible to get close to being able to control each station to water for a distinct time. However, in my opinion, this is a difficult way to achieve this for some users. In our back yard, we have 9 zones, some in shade and some in full sun. To prevent over- or under-watering different zones, it is necessary to adjust each station timing to have each watered properly. For example, some zones need 15 minutes and some only 3 in the summer. This changes over the year as the weather gets colder. In addition, when it is dry here, I often have a second program run to water some zones in the afternoons. Of the nine zones, I need at least three run times per program (and preferably more). So, that would be three separate programs, and then additional ones for the afternoon programs. For some of the larger installations, this could get even more complex.

I think the OSPi is perfectly functional as it is, but adding greater flexibility to the scheduler would be great. As for the exact time a station is activated, I agree that this is less important.

BTW, I don’t see an option for controlling sequential mode in the OSPi. Is that feature only available in the Arduino based OpenSprinkler?

Thanks again!

[Samer]

Ah okay I get why you want more control now.

By the way as of right now the OSPi is only sequential however the feature for sequential on/off is being added to the OSPi and will hopefully be available soon.

[Ray]

Let me explain the rationale behind having each program use the same water time for the selected stations. Since this is different from how a lot of other sprinkler controllers work, I understand it can be confusing. The main reason is that OpenSprinkler is designed to support potentially a large number of stations. The highest number I’ve seen is that one user bought one main controller plug four expansion boards, for a total of 40 stations. If each program allows a different water time for each station, this will potentially require a large amount of space to store the program data. While it won’t be an issue for OSPi (since there is plenty of space on the SD card), but on the microcontroller-based OpenSprinkler, the program data are stored in EEPROM, which has limited space. This is while most other controllers are limited to only 3 or 4 programs in total. I believe it’s due to the storage constraint.

In practice, there are seldom cases where you can’t consolidate the water time into a small number of uniform groups. For example, you can probably split all your stations into 2 or 3 groups, where each group uses the same amount of water time. As the user manual clearly explains, if you set each program to have the same start/ending and interval settings (while different water times), it will work as if it was one single program. This is overall a more efficient way to use storage.

Certainly you can change it to the other way by modifying the source code. The downside is that you will have significantly less number of programs. Hope this explains the design decision.

[craigmw]

Ray…

Thanks for the clarification on memory usage. I fully understand the limited memory on the Arduino platform, so I can see how this could be an issue. I agree that the way that the scheduler deals with overlapping programs is clever. However, this will be confusing to many users, though the program view window helps to make it easier to understand. I wonder if it might be possible to hide some of this complexity while still maintaining efficient memory use through the scheduling window subroutines? For example, it could automatically generate additional program entries when different times were needed for different stations. Let’s consider that a setup with six stations:

1. 3 minutes
2. 6 minutes
3. 9 minutes
4. 6 minutes
5. 3 minutes
6. 9 minutes

So:

Program 1: 3 minutes, all stations respond
Program 2: 3 minutes, 2, 3, 4 and 6 respond
Program 3: 3 minutes, 3 and 6 respond

This could be handled in the logic of the scheduler.

An alternative, considering memory constraints, would be to have a single start time per program, and then simple byte values for each station duration (representing 0 to 255 minutes). Setting a station number limitation for the original OpenSprinkler of say 4 extension boards, plus the 8 on the OpenSprinkler itself gives 40 stations. So, each program would require only 40 bytes plus the additional bytes for the start time variable. No stop time would be required. This may require variable length records (number of stations*number of programs) to maximize the number of programs on a typical setup. Users with a large number of stations and separate programs should be encouraged to implement an OSPi to take advantage of the essentially unlimited memory.

These are just thoughts about how to enhance the user interface and flexibility. I think that the OpenSprinkler is very nice, and you, Dan and Samer have done a great job to enhance the concept.

[Ray]

First of all, in the example you gave can be implemented with 3 programs:
program 1: 3 minutes, stations 1, 5
program 2: 6 minutes, stations 2, 4
program 3: 9 minutes, stations 3, 6
this is logically easier (and matches what I mean by consolidating the stations according to equal water time), but if you want to optimize, you can implemented it with just 2 programs:
program 1: 6 minutes, stations 2, 3, 4, 6
program 2: 3 minutes, stations 1, 3, 5, 6

As I said, in most case the water time can be consolidated into a small number of groups. The more stations you have, the more likely you can consolidate. I know this is different from other sprinkler timers, but there are cases where you can argue this programming pattern is easier to set and modify than having to set one water time for each individual station.

The storage size is actually more than you thought: the start / end time and interval time each take 2 bytes (granularity of minutes), and water time takes 2 bytes (granularity of seconds). OpenSprinkler 2 supports up to 48 stations, so including the other necessary bytes each program would take a total of 105 bytes. This is quite a bit more than what the current program data structure takes, which is 17 bytes per program.

That being said, Samer and I have talked about how to have a front end that can handle different water time per program, and back end to compress it to more efficient storage. So I will think about this option.

[Author]

Posts