Forum Replies Created
-
Posts
-
I didn’t create a branch for these changes, I just opened the files and changed them locally. If you’d like to do the same, follow my previous post above. If you need more specific help, please let me know and I can walk you through it (it’s really simple).
Not needing a ‘suspend’ function makes things a lot easier. Ok, in ospi.py there is a call to ‘check_rain()’. That operation lives in ‘helpers.py’. Follow how that function sets the values for rain detected. I’d start by coping that function, then mapping the signal to a different GPIO pin. Then look at the ‘program_running’ if statement also in ospi.py. That shuts down the zones if rain (or in your case now) your switch is tripped. You’ll need to add a new ‘if’ path for your function when the switch is triggered so that you can start your custom zones and do <stuff>. Of course this is a high overview, but following how that rain on/off works should get you started and close to your goal.
Simple question, complicated answer. Yes, using the GPIO pins you could get the pi to know the pump is on manually. Now what to do with that signal? If you want all the zones to shut down, that’s one item you’d have to write/update in the python ospi service. If you want to ‘suspend’ the zone, then pick up from where you left off, that’s way more complicated. When a program starts, it writes the start and end times into variables. You’ll have to start a separate timer from when the pool pump started to when it’s shut off, then go through those variables, add the time, then start the service as normal again. Problems you’ll run into are what if a program hasn’t started yet, but does after pool boy is there? What if one program has started (and is now suspended), then another one is set to start before pool boy is finished? I’m sure there are other situations, but you get the point. How would you update the logging for times the zones ran vs. suspended? Yes, it can be done, but a you can start to see, it won’t be simple.
Maybe an easier solution would be to make the pool it’s own zone. I would expose a ‘Pool Fill’ button on a simple web page accessed on an internal ip (I’m assuming your pool boy has a smart phone). That button click calls the webservice to stop all programs, then starts the ‘pool’ zone in manual mode. Click the button again, and the zone is shut off. Or just give the pool boy access to your sprinkler webpage. Let him click into manual mode, stop anything that is currently running, start and stop the ‘pool’ zone manually.
Good luck!
If I understand this correctly, your bay 1 & 2 solenoids can be operated by schedule with OpenSprinkler (they are just valves or ‘zones’). Pumps A & B, no problem. There are provisions to provide pumps with power when zones are on. You have 2 pumps instead of the standard 1, but that could be worked out easy (Especially if don’t you need them to work independently). Ok – A & B Solenoid controlled by an EC Sensor – home irrigation control just doesn’t have anything like this. More info is needed. How does the EC sensor send information, and can that be mapped? My guess is yes, you’d just need the specification of values that it sends, then build the logic to open/close depending on that info. It isn’t clear if you need A&B to open fully or need to open on a range of values – I’m sure there are valves that do this, but the ones used in home irrigation are just opened or closed (or if you’re unlucky, stuck open by a grain of crap and you come home to a flooded yard).
But my guess is there is something more complicated here. If you are saying the standard system sells for 7k, and the only part of it that is complicated is that EC sensor, then what is driving the price up? Maybe liability considering we are talking commercial farms and fertilizer? Sometimes simple is better – I wish you luck!
Yes, very easy to change. However in doing so, I believe I exposed an existing bug (Which took a lot of time to find). Here’s how I did it. To change the front end, replace the code inside the ‘elif name==”mas”:’ section with the following:
output += “<select name=’omas’>\n”
output += “<option ” + (“selected ” if value==0 else “”) + “value=’0′>”+_(‘None’)+”</option>\n”
for bid in range(0,gv.sd[‘nbrd’]):
for s in range(0,8):
sid=bid*8 + s;
if gv.sd[‘show’][bid]&(1<<s):
output += “<option “+(“selected ” if value==sid+1 else “”)+ “value='”+str(sid+1) +”‘>Station “+ str(sid+1).rjust(2,’0’)+”: “+snames[sid]+”</option>\n”
output += “</select>\n”This will check to see if the option of the expansion board is present, and will only load zones marked as active. The current code handles the upper values for the master just fine, and runs it perfect. But I did find a bug in the display. So even though the master value will turn on and off, the front end web page shows it as off. To fix that, a simple change in the ospi.py file is needed. Change line 97 gv.sbits[b] |=1 << sid to gv.sbits[b] |=1 << s ‘Sid’ will grow from 1 to 16, ‘s’ will will grow from 1 to 8 twice. Since master was only on 1-8, using ‘sid’ was never an issue.
