[scottsh]

hplato – I personally calculated runoff time by watering and watching and it is on a per-zone basis. My mulch-filled raised flower beds have a different runoff limit (.1 in) than my grass (.2) and my drip-irrigated lemon trees in pots are much lower (.05in.) AND, my county extension service (local government agricultural department) has average data for this they make available.

I was able to do some web searching for the plant/grass types I have to get the average water required in my part of the world.

Shawn – When purchasing drip systems, I believe the drip heads have a l/hr or gal/hr rating. The ones I have all have ratings from .5gal/hr to 2gal/hr (GPH) drip rates. I thought the same was true in the rest of the world for l/hr (LPH) but I suppose if you were using something hand-made or drip hoses that might be less visible.

I was thinking of how to build a solution for everybody (all users of OpenSprinkler) who don’t have PWS or solar panels. That’s the good side of using Wunderground because you can likely find a PWS near you. Is there a way to estimate solar radiation based on data available from most PWS?

I think you are right about Joules not being the right unit for solar radiation. You can convert from Joules to watt/m2 but watt/m2 is probably the right unit to start with. I got J from one of the python libraries I was looking at but it was petty academic and maybe not practical.

And I know exactly what you mean about building a solution on a unit you need to work – I have the same. It can be challenging. If it messes up I either end up with dead plants or a lake.

Luckily I use an OSPi which has far more computing capability than the Arduino version so I wasn’t worried about that but I appreciate why the Unified FW uses the cloud-based approach to offloading hard work from the Arduino.

[scottsh]

A few other comments if you decide to incorporate something like this. I don’t mean to belabor the obvious, just passing along some knowledge I gained.

– Perhaps obvious, but rotary or spray heads outside the US are measured in mm/hr and not inches.
– Drip systems are measured in either gallons per hour (gal/hr) or liters per hour (l/hr) and thus you might want to support those units for entering per-zone watering rates and amount of water required.

There are a few python libraries out there for calculating PM ETO and alternatives. A google search turned up several, many of which are based on FAO’s underlying library like the one here. Here is another: http://python.hydrology-amsterdam.nl/modules/evaplib.py

The key weather data inputs appear to be:

Minimum and Maximum temperature (C)
Mean temperature (C)
Dewpoint temperature (C) or relative humidity (%)
Mean windspeed (m/s)
Atmospheric pressure (hPa)
Total solar radiation (in Jules)

[scottsh]

To do this right, I think we need to have zone-specific measurements for precip rate as well as amount of water required and run-off rates. I have 18 zones and many heads too. I thought about this a little in my plug-in to Dan’s program (see image attached.) I didn’t implement the ETO algorithm at the time because I was worried about getting all the required weather data. I’ve implemented something else but it isn’t perfect (it over-watered in the winter, for example.)

Also, it is hard to get good localized data for is solar radiation; most weather stations don’t collect that data. That doesn’t mean this isn’t worth tackling, however. It might be that getting solar radiation data from a nearby source is good enough.

Attachments:

1. 

   Screenshot-5.png
   

[scottsh]

Samer – just curious, but how goes the inclusion of this method into the main code? Is the PM-ETO method actually in the unified FW now?

Thanks!
Scott

[scottsh]

Passing this along in case it helps others – a good video on how to figure out the precipitation rate of your sprinklers.

http://www.youtube.com/watch?v=W_wn-hwLNtg

[scottsh]

Just curious, but what are you using to run mosquito repellent through your sprinklers? I want that!

[scottsh]

If it is your personal weather station or a station very close to your house, then no it probably doesn’t make sense to use both.

However, not all weather stations are created equal. My new Davis VantageVue is excellent, but my old Oregon Scientific was hit or miss. In that case I could see using both.

[scottsh]

Thanks for the note Dan – I’ll hold off until you release that update.  I pulled down the current code and started reviewing it so I could understand where the changes will be.

Scott

[scottsh]

No, I have not. The number of changes required was significant and I just honestly didn’t have the motivation to make time to do it.  But, I’m getting fired up about it again.

I’m going to pull down Dan’s latest code and see how much work it really is.

[scottsh]

This is cool news Dan and thanks for sharing. I knew you’d come back one day with an implementation :).

I can’t wait to take a look at what you’ve done.

Scott

[scottsh]

I have a few ideas, but I’m a software guy too so there could be better ways to do this. I also only have experience with Dan’s Interval Program written in python – the other programs behave differently.

First, most irrigation systems I use have normally closed valves – this way they shut off when power is lost. I think you want that here, but I see there are some professional irrigation system designs that are normally open. Check out this presentation: http://www.rainbird.com/landscape/resources/webinars/ESPLX-FlowSensing-Mar16-2012.pdf. I don’t think you need any particular product as long as it works on 24v AC.

Second, the Interval Program lets you configure a station to run any amount of time. You do have one interesting requirement in that you might suffer a power outage in the middle of an irrigation session. Currently, the Interval Program only logs when the station is done being watered. This would mean potential over-watering in your case if you lost power in the middle frequently. You’re going to need to modify the software to do something different. I recommend logging during a session on maybe a per-minute interval by creating a log entry and updating it every minute. Also, you’re going to have to modify the code to determine how much watering has been missed and automatically recover.

However, rather than water for 1 hour sessions, you might break that up into maybe 6 sessions of 10 minutes each. It is generally better to let water soak in anyway, and this would let your code use the current logging and overwater at most 10 minutes if power fails during a session.

Third, I think you could use the master valve feature to always turn on the starter before watering. You probably need to have the 24v triac that comes with the OsPi connected to a custom relay to allow it to switch the 3-phase starter on or off.

[scottsh]

That’s really interesting David – I look forward to seeing what comes from having a library like this to build on top of.

[scottsh]

Thanks – that’s a great resource.

I like these 2 as well: http://www.agf.gov.bc.ca/resmgmt/publist/500Series/577100-3.pdf and http://www.agf.gov.bc.ca/resmgmt/publist/600Series/619000-1.pdf

I’m starting to look at this more directly. I’ll probably start a new thread to capture some requirements and to kick around some ideas on what data people would need to input (for example, does anybody know their soil water storage capacity?)

Are there any consumer-oriented solutions that implement the ETo model of irrigation? I’ve found plenty of commercial solutions, but those aren’t so friendly to consumers.

[scottsh]

According to another forum post on this topic, if you use the original version of the Interval Program that matches the Arduino version, there is a Vera plug-in that supports it. I know nothing about that, however.

See here: viewtopic.php?f=28&t=825

[scottsh]

This is just my opinion but…

In terms of development and future proofing, the OSPi is clearly advantaged. Active development is ongoing on different applications and plug-ins as you can see in this forum. Also, if you are capable you can contribute to the solution easily. One of the apps is developed in python, the other in C++. It is just easier to write code for than the Arduino (and I have done both.)

In terms of reliability, the advantage goes to the Arduino version. Nothing against the Pi, but a microcontroller solution is just more reliable in my experience. The OSPi has some unique issues with storage (you need a high quality SD card to handle lots of writes) and networking (that WiFi dongle is notoriously challenging.) If you want a rock-solid controller that you can set and forget, this is the solution for you.

The Arduino version draws less power. The Pi draws about 5W while the Arduino uses about 1.5W. I wouldn’t choose the Arduino because of this though. It feels like a minor consideration.

The type of intelligent watering you mention is being developed in the OSPi version. I don’t see this being worked on for the Arduino variant but I don’t follow that as closely.

Scott

[scottsh]

Great-looking installs! Mine looks like a hacked-up bunch of spaghetti compared to yours.

[scottsh]

In case you don’t follow the code on github like I do, you’ll probably want to know that Dan modified the main program to allow for practically an unlimited number of programs. Pull a fresh copy to get that fix.

[scottsh]

I did a quick test and created 34 programs and it worked fine (took a while but it worked.) I also manually executed program #34 and it worked OK as well.

[scottsh]

32 its just an arbitrary limit that matches what the Arduino can do. I haven’t tested this but I think you can expand it yourself if you want.

Look in ospi.py for the setup of gv.sd around line 405. You want to change the value of the mnp variable.

Current line:

gv.sd = ({u"en": 1, u"seq": 1, u"mnp": 32, u"ir": [0], u"rsn": 0, u"htp": 8080, u"nst": 8,

Change to:

gv.sd = ({u"en": 1, u"seq": 1, u"mnp": 64, u"ir": [0], u"rsn": 0, u"htp": 8080, u"nst": 8,

I haven’t tested this myself but I don’t see anything in the code that wouldn’t work with >32 programs. I create a program #97 and the code works with it.

[scottsh]

Yeah those are my settings, if you copy over the data file from your previous install it will copy your old data if you have it.

My .json file shouldn’t really be in the repo, I’ll figure out a way to use his (initial, blank) copy.

[scottsh]

I can’t see why not – my OpenSprinkler connects via Ethernet to a Buffalo WiFi router setup as a client bridge and it works just great.

[scottsh]

I realized this morning in the shower how to fix the implementation of the Monthly Adjust to Auto-Program that was previously bogus. It is fixed now – pull a new copy if you want these two plug-ins to work properly together.

For those who want to know what was up: the previous implementation modified the duration of the watering schedule by the monthly adjustment similar to how the manual program mode works. However, Auto-Program is “smarter” than manual mode, and as a result would automatically compensate back the other way, removing the adjustment! Why? Because Auto-Program recalculates the amount needed every day based on the actual watering time + any rainfall. This allows the code to include any manual mode watering, regular programs that you still want to run, etc. in the calculations for the next watering cycle. Subtle, I know, but it shows the power of this method of automation.

But enough about all of that, its fixed now so all is good.

Scott

[scottsh]

Oh wow thanks – obviously that bug is caused by interaction between the other plug-in that I haven’t touched in a while. I kept having a problem where the Monthly Adjust plug-in was resetting itself so I quit using it. I didn’t get back to it post 2.0.

Obviously there is a type problem there with float/int. All part of the fun with weakly-typed languages :).

Fixed and committed.

Thanks a lot for helping get to the bottom of this!

Scott

[scottsh]

Thanks for the screenshots – they certainly looks right. Any chance the rain sensor detect is set to enabled somehow? That would cause this.

However, for further debugging I would recommend the following. SSH into the OSPi board and do:

cd ~/OSPi
sudo service ospi stop
sudo python ospi.py

This will run ospi.py on the console and show you all the debug output.

Then go to the Auto Program page and select Run Now and watch what happens on the console. What should happen is that all the zones should be scheduled and the system should start watering immediately. You won’t see anything on the Program page though – these aren’t real programs, just immediate zone scheduling. You should see that on the home page.

To return to normal operation, press Ctrl-C on the console and execute:

sudo service ospi start

Scott

[scottsh]

Here are a few things to check, we’ll get this figured out!

– First, on the Zone Settings page, do you have the zones enabled for automation that you want automated?
– Second, on the Auto Settings page (the main page) is the auto programming enabled? Are there valid days selected? Is the start time set for a valid time?

One way to test then to see if its able to auto-program is to click the ‘Run Auto-Program Now’ and see what gets scheduled.

You should see ‘Program 97’ running against any zone that needs water.

Oh one last thing – the system will never water less than 1 minute, so even if the ‘duration next run’ says it will run 0.43 minutes know that it won’t actually run.

Scott

[Author]

Posts