[scottsh]

Oops, bug in initializing an empty settings file. I fixed it and pushed the changes.

Also, if you notice I had to make small modifications to ospi.py and gpio_pins.py. The ospi.py change is twofold – first I modified added the station # to the log file. This allowed me to scan the log for watering history without having to string-match the station names. Second – and it involves the change to gpio_pins.py as well – is the addition of the simulation capability. I added a gv.simulate flag (initialized in ospi.py) that prevents the writing to the registers. The idea was to let the software run completely and exercise it without actually triggering solenoids.

These 2 changes are obviously not aligned to a plug-in strategy. I’m hoping to convince you of the need for the log change :). The simulation capability is probably only useful for developers, so that is really just for me.

Scott

[scottsh]

I think I have an alpha version that works, I think. If anybody is interested they can clone it from https://github.com/scottshaffer/OSPi.git

To use the new plugin(s), browse to http://ospi:8080/auto. It does require that you setup the Zone information and Weather settings before working.

I’ve added the ability to simulate operation. It does everything as normal except it prevents OSPi.py from writing to the GPIO pins. This will prevent your OSPi from working at all, not just the automation.

UPDATE: Drip irrigation support is not working yet – it will dramatically over-water those zones if used.

Scott

[scottsh]

Thanks Dan – that helps – I somehow missed that section of ospi defining gv.

salbahra, I don’t think gv.rs is the rain sense bit. I think its the run schedule.

gv.rs = [] #run schedule
for i in range(gv.sd):
gv.rs.append([0,0,0,0]) #scheduled start time, scheduled stop time, duration, program index

I was thinking I might be able to create a program that had a unique duration for each zone by setting gv.rs[station_id] with start, stop, and duration times, set program index to maybe 98 (to indicate an auto-program) then set bsy=1 and let the controller go.

This way, I avoid messing with the user-created programs (which might be confusing to users).

From what I can see, gv.ps is the ‘program schedule’ and isn’t used in the OSPi? It looks like it was just for the display of the Arduino version?
UPDATE: Whoops, I was wrong – gv.ps is used by the web UI – so it is needed.

scott

[scottsh]

Thanks Dan, this helps a bunch – I appreciate the pointers. I get why the stored attributes (nbrd, bsy, etc.) had short names to work with the Arduino code.

Is there any real limit to the number of programs? I was thinking about making all the automated programs have pid beyond the current max (32) to avoid conflicts. Again, thinking about the maximum number I could see the need for 56 programs to handle all the various zones that might be in use.

Is all of gv documented somewhere? In particular I’m looking to understand what gv.rs and gv.ps are.

Thanks, Scott

[scottsh]

Thanks Dan, these are good thoughts. Right now I can switch from inches to mm with nothing but a UI change. It’s not complete yet, but the algorithms remain the same. So far, I’ve been able to avoid any code that required me to use inches as anything other than just a unit of measure. In other words, I don’t have to divide by 12 or calculate area or something like that with it.

I had the same thought that you did to allow for the weather history data to be a module people can change. I’ve designed the code and UI to allow this but haven’t implemented it yet because I’m so weak with Python. But it will happen.

One question – I’m at the point where I have to create a schedule program automatically. However, the code is very hard to decipher. Do you have any thoughts on the best way to have my plug-in create a program or set of station schedules?

My first thought was to create a new set of programs, but that’s looking like I might have to create a new program for every zone because it is likely that each zone will have its own unique precipitation rate (at least this is true in most of my zones) and potentially a unique evapotranspiration value too. This means each day, each zone will need watering on a unique duration. My next thought was to create a single program with each station having a unique duration value. Does that sound right? I was thinking of copying the code out of timing_loop, settings up the station values and calling schedule_station. Does that make sense?

[scottsh]

I found it – in case anybody else has the same issue, the file is:

/var/spool/cron/crontabs/www-data

I never knew that cron jobs could end up in that directory – you learn something new every day!

Scott

[scottsh]

Great points – I’m still thinking about the best way to do this. The information I need is the amount of watering done over the previous week (or whatever specified time interval – as you state you have some 2 week cycles.)

Here is what I consider to be the worst case scenario. I see in another post that somebody has 6 expansion boards. That’s 56 zones. If every zone was activated 3x per day every day, you’d end up with over 1000 entries per week. I did say ‘worst case’ ;). In my real-world case, I have 24 zones that are activated 3x per day 3x per week. That’s only 200 entries. I’m worried about consume too much memory, but maybe I’m over-thinking it. Currently my Pi (128MB version) has 23MB of free RAM, so there does appear to be plenty of memory even for 1000 entries.

[scottsh]

Dan (or anybody familiar with the Interval program) – what are your thoughts on the best way to determine the historical watering data? I suppose I could use the log if you think that’s best? If so, I’m going to want it to be able to hold 7 days worth of log data (rather than number of entries.)

Or, is there a need for a database of some kind that would hold historical watering data?

Scott

[scottsh]

Regarding Rotor/Spray being the same – they are from a calculation standpoint, but I think it will be helpful from a UI standpoint to identify this in some way. From my experience, rotors have a much lower Pr than sprayers. As a result, it was helpful when I was doing manual programming to be able to know which was which – the rotors run for 30m per run while the sprayers only run for 5m.

Of course, once you go fully automated I suppose this isn’t as important.

And once I have the calculated plan information I plan on making that visible in several places. It’s slowly coming along. I think I have all the data I need so I’m ready to start creating the automated programming system. Hopefully I will have something working this weekend.

[scottsh]

I made it look like this – does this work to your thinking?

[attachment=0:214214qq]example.png[/attachment:214214qq]

[scottsh]

Great ideas – I included zone type (rotor, spray, drip) and allow input of in/hr for rotor/spray, or gallons/hr for drip.

I have a little drip irrigation myself and its rated at 2 or 3 GPM – how common is that compared to GPH?

[scottsh]

I will – I didn’t know this wiki existed, thanks for pointing me to it.

Update: Done. I modified the previous add-on section with what I think is now accurate information.

[scottsh]

UPDATE: Either you fixed it or I had an older version of the code – in the latest pull this is fixed. Thanks!

Dan,I’m noticing that gv.snames isn’t being updated when the station names are updated through the UI. The ospi code uses data(‘snames’) in most places itself, so this isn’t apparent.

I’m thinking somewhere around line 704 gv.snames should be updated?

gv.snames=data('snames')

[scottsh]

I wasn’t arguing the bug fix, but the overall concept of having blank station names. I’m thinking it might mess up some UI to have blank names, or make it hard to read. If there is a case for blank names, I was thinking the UIs should do something to handle that (like use a light gray color ‘none’ for the name maybe.)

One thing I noticed was that station names can’t contain commas (because the names are written out as a CSV and any commas aren’t quoted.) If you do, certain UI things like the log display don’t handle that right. Do we want to modify the code to allow commas in the names or should we prevent commas during input validation? Right now I’m assuming no commas in my plugin but I can change that.

[scottsh]

What do we all think about empty zone/station names? I get that they are just an attribute but given the ways we want to present data it seems odd to allow for empty names?

Also – the current code is highly optimized (which I appreciate) and assumes that zone/station limits are on the boundary of how many expansion boards you have. That seems odd – especially if you have 18 real zones, but have to see 24 in the UI. I’ve taken to using the name ‘Unused’ for unused zones, for example.

Is it worth investing in specifying a zone limit value and then restricting the display to that? I was thinking of changing the options page to input the # of zones, deriving the # of expansion boards from that, and letting the core code keep using number of boards but changing the UI pages to restrict to a specific # of zones.

[scottsh]

@Dan in CA wrote:

@scottsh,
The reason the plugins are not loading is that they now need to be set as executable.

Yeah I figured that out after a bit of debugging. I like that change by the way, it keeps the code from trying to load a file that isn’t ready or isn’t a plugin.

Scott

[scottsh]

Dan, just FYI – I pulled this version and it looks like my plugins quit working. At least it seems that way – I am trying to add a plug-in so I might have caused it. I removed my plug-in and the other ones still won’t load (ma or mobile_app.)

I can’t quite figure out how to debug a plug-in yet so I’m not exactly sure what is going on.

[scottsh]

I’ve been thinking a lot more about this and so I wanted to share where I’m at with the problem and the algorithm to implement what I think we’re all talking about.

As R_W suggests, one thing that has become obvious to me is that if you are going to compare rainfall to sprinkler-based watering, you are going to have to know how much water your sprinkler system puts out as well as how much water your plants need. The simple fact is that if you know that it rained .27in yesterday, the only way you can determine its impact on your 7-day watering schedule is if you know A) how much you put out when you turn on the zone valve, and B) how much water your plans need. Note: you also really ought to know what the maximum amount of water you can put out before it starts to run off, but that’s potentially a second order problem.

I’m going to refer to the amount of water placed by the sprinklers in inches per hour as Precipitation Rate or Pr. To determine your Pr, you have to measure your actual water output using the method R_W links to in that video. You can use a kit (like this http://www.agrilifebookstore.org/product-p/sp-424.htm) or set out empty cat food tins or frankly anything else that will work. We need this data for every zone. I can’t state enough how important this is.

You also need to know how much water your plants (grass, flowers, vegetables, or whatever) need. From what I can find, most information available refers to the amount needed in inches of water per week or every 7 days. I’ve seen estimates for some grasses in my area of 2in of water needed per week, and some need as little as .5in per week. This value is referred to as evapotranspiration and abbreviated ET. Note: a commonly used term in the literature is ETo, which is the amount needed by a particular referent plant.

With this in mind, I believe the right thing to implement for OSPi is an advanced watering model that, on a per zone basis, determines the amount to water on a given day by factoring the amount of rainfall and amount of irrigation for the previous 6 days along with the amount of water that zone needs. The model I have in mind looks like this:

– ( + ) = water needed

or
– for a zone that contains grass that requires 1.5in/week
– and contains a sprinkler system that can put out .5in/hour
– that has been used for 90 minutes in the past 6 days
– and has had rainfall of .25in in the previous 6 days

1.5in – (.25in + (.5 * 1.5)) = .5in water needed

Once this is determined for a given zone for that day, the controller can then decide how much to water this particular day. In the case of our example, .5in of water is needed so 1 hour of watering is required for this day. If we know in advance that the maximum amount of water that can be put down before runoff occurs is .5in, then we’re fine – we can water for the full hour and everything is great. If we know that runoff occurs at .4in, then the system should activate the zone for 48 minutes and wait for tomorrow.

Does this seem right? Am I missing something?

If you had a UI that allowed you put in data per zone for the information on amount of water needed ET (in/week) and the amount of irrigation throughput Pr (in/hour) would that be acceptable?

Thanks!
Scott

[scottsh]

@DanTripp – I’m looking at something similar, which is great – I’d like somebody to collaborate with.

One thing I saw was that Texas A&M claims that you can’t get an accurate ETo without having solar radiation values in addition to local soil temperature and moisture readings. I can’t get all that from wunderground. Have you done some simulation that suggests that isn’t that critical? I’ve messed around with some calculations and it looks like even being way off on some calculations has only moderate impact on the amount of watering.

However, I’m not sure how important ETo really is? I haven’t modeled it, but I should. Instead, I was going to start with a simpler version that adjusted the pattern based on the amount of watering+rainfall over the last 7 day period. I’m going to post my algorithm in the other thread I created for this discussion.

In the meantime, here is a python routine to get yesterday’s rainfall total from the wunderground api. I’m thinking that certain configuration items like the decision to use wunderground or your local rain gauge should be something set globally, so I created a settings module and put a couple global variables in there (that’s what settings.useWunderground, settings.pwd and settings.keyWunderground are from.)

#

# getYesterdayRain

#  - returns a floating point value that represents the total rainfall from yesterday

#

def getYesterdayRain():



rainfall = 0.0



if settings.useWunderground:

# if we are using wunderground.com as a data source, then pull from their api using the configured key

url = r'http://api.wunderground.com/api/' + settings.keyWunderground + r'/yesterday/q/pws:' + settings.pws + r'.json'

json_data = wget(url)

if (json_data):

data = json.load(json_data)

else: return -1

#			print 'hour:', hr, 'date:', data[hr], 'data:', data[hr]

rainfall=float(data[23])



return rainfall

[scottsh]

Interesting – no I didn’t. I just trusted the 26.5VAC output it listed and ran with it.

[scottsh]

I picked this one up at my local Home Depot and it has been working just fine with OSPi and my valves.

http://www.amazon.com/Rain-Bird-UT1-Sprinkler-Transformer/dp/B000DCN8LS

[scottsh]

Thanks Dan, I appreciate the information links.

It doesn’t seem like anybody developed more sophisticated code than the monthly ETo adjustments?

I don’t want to recreate the wheel here.

[Author]

Posts