[virtus]

Thanks for making this! I just set it up on my OSPi and got all the port forwarding, etc… set up. So I can control everything from anywhere. One question – where can I change the password for the interval program? I changed the password from “opendoor” to somehing else, but the web app stopped working. So I’ve changed it back.

[virtus]

Yeah, if you look at the interval program any of the first 8 valves can be designated as the “Master”. In the options screen you can specify the number of seconds that it opens before or after the desired valve opens (or at the same time).

[virtus]

It’s great to see more development. Can you run two programs at once with this? Some sprinkler systems are designed with a master valve that has to be opened before the other valves will work.

[virtus]

Got my OSPi yesterday and it’s already running in place of the old sprinkler controller. Next step is to pick up some reed/contact switches and connect them to the RPi and test the code. Hopefully I’ll have that hammered out in the next couple of days. These will be initally connected to the RPi’s GPIO pins for simplicity and to avoid soldering for now.

Final step will be to add the relays – I’m considering using the RPi’s GPIO pins here too instead of the OS since I’ve used up all my stations and would need to order the OS zone expansion kit (need at least two more stations for my garage doors). However, I think it would ultimately be better to to use the OS expansion board since the software already supports controlling the doors (through HTTP commands) and the connections are easier. And that should translate to more people buying expansion boards from Ray.

[virtus]

Glad I saw this thread! I just got my OSPi set up and started to wonder if something was wrong with my setup. I can confirm that you can get it to work by manually turning on the master valve at the same time the normal valve is opened, so no worries for now.

Great work on the program so far Dan. The OSPi wouldn’t be half the device it is without your contributions!

[virtus]

This is a great addition! I hope they merge it. I’d be interested in some logging as well so we can get a better picture of temperature and trends throughout the day/week.

[virtus]

@snewman wrote:

Virtus – Correct; every time a command is received it first closes all valves then opens the desired one. This prevents multiple valves from being opened at a time but presents a challenge when the original valve is ready to turn itself off. I’ll have to come up with some better logic to manage state. (but I’m trying to keep this simple and not run task queues and databases)

That’s good to know – just got my OS RPi today and will begin tinkering with it soon. I had originally planned on using one of the OS valve controllers to activate a relay and simulate a button-push for my garage door openers. It sounds like opening / closing the garage would interrupt any watering programs that might already be running. Now I might have to rethink that and move the relay to one of the Rpi’s GPIO pins and use custom python code to toggle the relay. Anyway, that’s another topic for a another thread. Maybe snewman’s program will handle it better.

[virtus]

@andrew wrote:

By the way. You mentioned that you are struggling to understand shift registers. This article offers a good explanation: http://bildr.org/2011/02/74hc595/. This will also explain why the the complete state of the controller has to been reset each time a station is opened or closed. The shift register is cleared out and 8 new bits are sent to the register (or more if you are using an expander board; the linked article also explains how shift registers are daisy chained, which is exactly how the expansion boards work — I think).

So if the interval program is in the middle of a program (let’s say valve #1 is open), and you manually tell it to open valve #3 using the http command, does it automatically close all the valves first, then open valve #3?

[virtus]

It should be a fairly simple fix, but in the meantime you can also use google like this: “search term site:rayshobby.net/phpbb3”. So if you want to search for the word sensor, enter this in google (or your address bar):

sensor site:rayshobby.net/phpbb3

[virtus]

I’ve been posting a lot in the other garage door thread. I’m glad to see more discussion about it and a different approach. I’m not familiar with the 1.2 board, but I’m going to try to use the GPIO pins on the raspberry pi itself for my garage door sensors since they are fairly well documented and I believe they already have pullup / pulldown resistors.

[virtus]

@ray wrote:

@virtus wrote:

The RF route is extreme overkill for most applications.

I understand, but personally I hate running long wires. I think RF is a more elegant solution, plus one transmitter can be programmed to talk to multiple devices. On the other hand, hard-wired solutions are more robust for sure.

I agree about the wires – we just moved into a new home and the previous owners put the sprinker control unit in the back yard right next to the control valves. I guess they hated long wires too! I’m going to buy some longer wires and move it into the garage where it’s more secure and has better protection from the elements. I’m not too excited about leaving a wlan-connected device sitting out in the open.

Wireless makes sense if the unit isn’t in the garage. But I prefer the simplicity, security, and cost effectiveness of hardwiring it since my unit will be in the garage. For a simpleton like me the hardwiring is easier and quicker than sniffing out the RF codes.

Also, since this mod deals with a potential security issue (garage door access to a home), I’m trying to limit the complexity and number of wireless connections – so the OSpi will be connected via ethernet and all the garage door connections will be wired. So the main vulnerabilities will be the garage door opener itself and any internet weaknesses. Still not perfect, but it’s a start.

[virtus]

another update… Garage status code

This is all air code since I don’t have the OSpi yet, but I had a few minutes to kill this morning – so here goes. Since RPi.GPIO is being used by the interval program anyway, I should be able to connect a reed sensor directly to the RPi’s GPIO pins. If so, could I use the recently added ospi_addon.py functionality to get the status of the reed switch? Here’s an example (python is pretty far from my native programming language!):

#!/usr/bin/python

import ospi



#### Add any new page urls here ####

ospi.urls.extend([

'/gds', 'get_door_status',

])



class get_door_status:

"""Return a page containing the status of garage door sensor"""

def GET(self):

custpg = 'n'

door1_pin = 23

if GPIO.input(door1_pin):

custpg += 'TRUE'

else:

custpg += 'FALSE'



return custpg

I just want to be able to use an HTTP command to find out if the door is open or closed. This would need to be expanded to handle multiple door sensors.

[virtus]

So I see four parts to this:

Wiring / connection to the garage door opener buttons. We just need to find a suitable 24VAC NO relay – should be easy
Open / close software control . This is basically done already since we’re just using an existing station – so it’s already built into the software.
(Optional) Garage door sensor – It would be easy to add a contact sensor to a garage door for someone who is a little handy. Connecting it to the OpenSprinkler might be a different story (not sure what’s available on the board). Also we’d likely need room for at least two sensors since many people have 2 or more garage doors.
(Optional) Software update to allow us to query the status of the door – Again, should be doable if the OS board can be connected to a sensor – but this definately isn’t my area of expertise.

I haven’t even received my OS Pi yet (should be here this week), so I won’t be able to tinker with any of this for a while. I’m considering handling the door-status sensing with my alarm system, but it would be so much easier if the OS could just handle everything via HTTP commands.

[virtus]

Here’s a quick thought and a question – it looks like this can be done by connecting one of the OpenSprinkler stations to a simple 24vac NO relay placed on the line that goes to the button inside the garage. Some garage openers are more complicated, but some are so basic that they use a doorbell to close the circuit.

Anyway if that’s the case could I use the following HTTP commands to open / close the door?

http://x.x.x.x/cv?pw=password&mm=1 ‘switch to manual mode (required to manually turn on a station)
http://x.x.x.x/sn1=1&t=2 ‘activate the relay for 2 seconds
http://x.x.x.x/cv?pw=password&mm=0 ‘switch back to program mode

Also, what effect does changing to manual mode have if the system is currently in the middle of a program? Does the program stop?

[virtus]

Hi Ray – I just wanted to chime in and say that this would be a great addition that should be easily added to Opensprinkler.

The RF route is extreme overkill for most applications. You probably already know this but most home automation people simply add a relay to the line that runs to the button that opens/closes the garage from inside the garage. There are several examples of people doing this (and remotely controlling the relay with something like a z-wave controlled outlet) – here’s one I found on youtube: http://www.youtube.com/watch?v=W8RtzUgupDI

I’m not an electrical engineer, but it seems like Opensprinkler already has most of what is needed to make this work and this would really get the attention of the home automation market.

Determining whether the door is open or closed could be tricky (or added later) but I think it could be as simple as adding an open/closed loop sensor that you typically find in security systems for < $10. So a little guidance and code could really expand your market.

[Author]

Posts