[craigmw]

Actually, I don’t see a need to make the port number field within the program functional, so long as it can be set in the command line. I was just concerned that having it set to the wrong value would impair communications. Obviously it works just fine.

Thanks for the link to the Wiki. I’m still confused about how to have different station times. I know that it is possible to set it so that I can have more than one program run for certain stations to add to the times run. But, I was under the impression that this could be done by running the programs with the same start time. This does not seem to work in my hands.

[craigmw]

Samer:

I like the new theme. It would be cool to be able to have different themes (colors?) for individual OSPi/OpenSprinkler units, as this would help to identify which sprinkler system was being controlled. I now have two OSPi units, one for the front and one for the back yard. While it would be cool ultimately to be able to control both units from a single program, having some unique display for each would make it easier to control more than one setup. I like some of the other refinements as well, including the slider highlights. This is really looking quite polished.

[craigmw]

BTW, setting the number of extension boards to zero, saving and then back to 1 appears to have fixed the first issue. I’m not sure how this might have gotten corrupted, but it seems to be working fine for now.

[craigmw]

Dan:

A couple of odd things I noticed. As I described to Samer in another post, I had some weird corruption of the snames.txt file which was showing 24 stations in the web app (but not in the interval program). It seems that the webapp enumerates the stations based on the snames.txt listing, but the interval program does this using the number of extension boards field (?). In any event, I’m not sure what caused the snames.txt to become corrupted and list 24 stations when I only have a single extension board (and thus 16 stations).

A second issue is that the port field in the options page does not allow me to change from 80 to 8088. Despite this, it seems to be working fine (because I force the port to be 8088 via the python command in the rc.local file, as you so nicely detailed).

Thanks for all of your work on this!

[craigmw]

Okay, this is very strange behavior. In the interval program, I set the number of extension boards to 0, saved it and then went back and set this to 1. This seemed to solve this problem. Sorry for directing this to you, as it does not seem to be a bug in the webapp.

[craigmw]

Interesting, maybe the station names file was corrupted. BTW, the version of the webapp is 4513605 as listed under about.

On the Station Names page in the interval program (on the address you listed), 16 stations are listed. On the options page, 1 extension board is listed. However, the snames.txt does appear to show 24 stations. So, it does seem that the corruption occurred in this file. I wonder what might cause this?

[craigmw]

This looks interesting. Are you directly modifying the code in the interval program, or using the add-on approach that has been included in recent updates? I can see this being very useful for the exactly the purpose you state.

[craigmw]

Dan, thanks for the update and the detailed description about how to install it. This really helped!

[craigmw]

Dan:

Excellent program, and thanks for the updates. What is the quickest/easiest way to implement an update from the RPi? I used git clone to download the entire OpenSprinkler repository on my RPi, and then moved the OSPi folder to the /home/pi directory. But, I’m unsure of how to use git clone to pull down the updated interval program.

Thanks so much for implementing the interval program for the RPi!

[craigmw]

Samer:

Is there any way to implement updates for Dan’s interval program from your web app? This would make the process of keeping OSPi updated much easier. Thanks again for your excellent work!

[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.

[craigmw]

@PabloS wrote:

I just saw this garage door topic thread and thought I join in.

The idea of using a spare garage door transmitter to control my two garage doors seems to be the less complicated.

Since the OSPi system drives solenoids for the sprinkler valves, and the solenoids I use are less than $10 at Home Depot, how hard do you think it would be to build a mount so that a solenoid plunger could push a transmitter button? The plunger on the Hunter solenoids I use don’t have much movement and they move inward not outward. Does anyone know of any 24Vac solenoids that “push” outward and have at least a 1/4 to 3/4 inch movement?

It might be fun to build this as a project. 8^)

I think all of the solenoids designed for automated sprinkler valves pull in when powered. A better way would be to get a relay that could handle the 24VAC (on the actuator side) and wire the switched side in parallel with the pushbutton. Usually, the pushbuttons have screw terminals inside that connect to the control wire for the garage door opener. It would be simple to just add two additional wires to those terminals that connect to the contacts of the relay(s).

[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!

[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!

[craigmw]

Our garage has three doors with openers, and I was thinking about a way to use Insteon home automation to automate them. But, with an OSPi in the garage, this would potentially address this for much cheaper. The current sprinkler timer for the front yard is in the garage and only has four stations. So, a possible solution would be to use three unused outputs on the OSPi to control the doors and then use three open GPIO pins to connect to sensors (e.g. reed switches) to detect when the doors are open. To control the doors, the outputs could be wired in parallel with the manual pushbutton switches via 24V AC relays. As the output triacs could be controlled by HTTP GET commands, it would be possible to use the OSPi interval program daemon to control the doors. It would simply be necessary to provide a front end to deal with the GPIO sensors. It would also be possible to set up the program to send off an email or text message informing one that a door is open, which could be handy. It would obviously be important to not schedule those outputs in a program though. Having the garage doors open at 4:00 AM would not be a good thing. 😯

Actually, on the new OSPi board, there are four ADC inputs that could also be used for sensing. It might be interesting if Ray would consider developing an extension board with relays instead of triacs so it would be possible to control low voltage DC signals for this purpose. I agree that this could be a very handy extension of the OSPi’s functionality, especially considering that many have their sprinkler timers set up in the garage.

[craigmw]

There are several implementations out there using an RPi to check the status of the garage door, including the following which has a web server:

http://ryanfx.blogspot.com/2013/06/raspberry-pi-powered-android-controlled.html

This could likely run on the same RPi running OSPi. Of course, it would be more fun and educational to “roll your own.”

[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.

[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.

[Author]

Posts