[scottsh]

I turned on the watchdog function in my RPi and I did have a freeze once that was properly handled. I recommend enabling it.

Note that this is a standard RPi feature, not unique to OSPi. The wiki contains some instructions on how to set it up. http://rayshobby.net/mediawiki/index.php?title=Set_Up_RPi,_RTC,_WiFi,_Data_Log#Hardware_watchdog

Scott

[scottsh]

Awesome new Plug-in UI code! I was driving home tonight thinking that this was needed. I’m working on porting my plug-in over now.

[scottsh]

@Lamby wrote:

You could get a 24vac one, attach it to one of the solenoid relays and write some code to turn it on when it gets hot?

I love this idea – I’m not sure there are 24VAC fans but being able to control it based on temp or a schedule or whatever would make sense.

[scottsh]

I was out on vacation for a couple of weeks, but now that I’m back I’m looking forward to trying out 2.0 myself (I haven’t had time yet!) and getting the plug-in to work with it. Stay tuned!

[scottsh]

I wanted to provide a small update in that I’ve fixed a couple of minor bugs (the software didn’t handle abbreviated month names – a problem that wasn’t seen in May.)

However, all told the main algorithm is running great – it’s watering correctly based on desired in/week, correctly handling rain amounts, and overall is keeping my lawn alive with what I think is minimal water.

Next up on my list of improvements:
– Get drip irrigation support working (gal/hour instead of in/min)
– Get metric weather data from wunderground working properly
– Ability to pull point forecast data from NWS and suspend watering if forecast precipitation chance > than a specified chance over the next 24 (or 12?) hours.

However, I’m also looking at DanTripps ETO simulation to determine if that is appreciable better. I suspect it is, but I haven’t had time to prove it. I did prove out that in time of zero rain, the amount of irrigation used by both methods are the same – that’s a good “upper bound” test, but now I have to simulate rainfall and see if ETO ends up watering more efficiently.

[scottsh]

Hmm, I’ve pulled the power and reset my OSPi many, many times with no issue like this.

Is there some write caching going on perhaps that should be turned off?

[scottsh]

Just FYI, I made a small bug fix that addressed a problem with the weather history data. It was growing forever in the file instead of being trimmed to the specified number of days to watch.

[scottsh]

Is there anything obvious going on in /var/log/syslog? If the filesystem has gone read-only, the last thing in there might be some clue.

Also, the internal kernel log is still active even if it can’t write to syslog. Check that out using dmesg.

I usually see a filesystem become read-only if there is a corruption of some kind. I’m not sure what would cause that though.

[scottsh]

@mw46d wrote:

@Scott, did you try to measure which voltage your original transformator delivers? Maybe you could use that instead of the wallwart? Just an idea.

Thanks,
— Marco

I haven’t yet. It says it is 24V AC but since I had a working transformer I went ahead and used it. That’s on the list of further optimizations to do.

[scottsh]

Yes, it is. It uses an ‘inches per week’ approach that includes the amount of rainfall received, the amount of water a given zone can irrigate, and the run-off limit for each zone.

With that information, each day it determines the amount of water needed to keep the ‘inches per week’ of water at the specified level.

It works, but I’m not sure it is as optimal as the ET method DanTripp has been discussing. I have his simulation program and want to run it against the ‘inches per week’ approach to see if one is materially better than the another.

[scottsh]

Of all the data I captured, it didn’t occur to me to capture milliliters per can. I can tell you from memory that some zones had great uniformity, and some had terrible uniformity. I addressed that by taking an average of all the cans.

But it is the areas of the lawn covered by multiple zones that bother me the most. In order to get enough water on all the grass in 2 zones, I have to significantly over-water the overlap. It makes me want to hire a firm to fix this by moving the heads. Ugh.

Also, one variable that impacts rotors potentially more than spray heads is local water pressure. I notice that watering during the early morning (which is when almost everybody else is also watering) I get lower coverage than watering in mid afternoon. It got so bad my local water district asked people to voluntarily change their watering time to keep pressure up.

And determining the runoff limit is much harder than I thought. I’ve started with a suggested default value for my soil type, but it isn’t even obvious when there is runoff, necessarily. I can see it in the shrubbery with spray heads pretty easily, but not so easily with the grass.

[scottsh]

Sharing my own success story.

I’ve known I wanted an internet-controlled irrigation controller for years. But, every time I’ve looked in the past I found super-expensive commercial solutions or hobby ideas poorly executed. This spring I saw an ad for a very sexy looking device but unfortunately it only supported 8 zones. Good thing, because it caused me to renew my search and I stumbled into Ray and his very well executed design. At first I was into the Arduino OpSp, but when I saw he had an RPi version that would be easier for me to program, I knew that was the right one for me.

I ordered it up, plus one of the new 16-zone expansion boards and waited impatiently. 😀 I wasn’t comfortable trusting the mini-Wifi adapter in the RPi because I had heard of so many problems with it. Like others, I elected to use an out of service wireless router converted to a wireless bridge thanks to DD-WRT. I’ve used these things all over my house in the past, so this was done in a couple of hours.

When the OSPi finally arrived, I pulled the old Rain Bird unit out of service by removing the control panel + the circuit board behind it. I was honestly surprised at how easy it was to wire up the OSPi to the existing wiring. No stripping or rework was required, and I was able to remove a zone and connect it to the provided connection blocks very easily without forgetting which wire was which zone. When I was done, I excitedly stood in the garage, powered it all up, then used my phone to connect and manually turn on a zone. I was grinning from ear to ear when those sprinklers came on without a hitch.

https://flic.kr/p/nGR7V2

Here is a photo of my setup. It’s nice that I can just close the door on that wiring mess. But, eventually I would like to add a small display to show status plus a button that will execute either ‘Stop All Stations’ or maybe a ‘Pause’ function. Having a button that the lawn guy can use might be helpful.

[scottsh]

I thought I would share a little data based on my experience in my lawn. My overall lot is 1 acre, however only approximately half of that (say 22ksqft) needs irrigation.

Here are my actual values from my lawn based on measuring Pr using the method of putting collection cups in the zones and running them for 15m. I spent about 4 hours in the lawn, putting down a set of shallow plastic containers with straight sides, flat bottoms, with a heavy rock in each one to keep them from blowing away or moving around. What I found was eye-opening.

zone#: type – Pr – comment
1-4: spray heads – 1.5in/hr – spray head coverage for me was extremely uniform, with +/- 10%
5: 5x rotors – 0.56in/hr – well designed zone, with excellent overlapping, heads laid out in a triangle formation right out of the literature!
6: combination zone, with 3 rotors and 5 spray heads – terrible zone to manage, rotors got .35in/hr coverage, spray heads were 1.47in/hr
7: 4x rotors – 0.41in/hr, partially overlaps zone 6 (!!!)
8: 6x rotors – 0.5in/hr
9: 5x rotors – 0.275in/hr – almost no overlap between rotors in the zone
10: 4x rotors – 0.53in/hr
11: 3x rotors – 0.4in/hr – where there was coverage, there was a portion of this zone without any coverage at all (0!) due to a driveway extension by a previous homeowner taking out a head (or 2?)
12: 5x rotors – 0.475in/hr
13: 5x rotors – 0.25in/hr – very sparsely covered zone, with almost no overlap between rotors
14: 4x rotors – 0.45in/hr
15: spray heads+drip – 1.53in/hr for sprayers, drip heads are 2gpm put into 2 tall decorative pots with lemon trees
16: 4x rotors – 0.35in/hr – 16 overlaps the half of 17s coverage area, unclear why that was done
17: 4x rotors – 0.475in/hr – fully overlapped by 16 & 18 coverage, 2 heads were relocated during a rear patio expansion which caused the overlap with 18
18: 4x rotors – 0.375in/hr – overlaps the other half of 17s coverage area

All this got me to believe that I couldn’t calculate coverage based on types of heads in software. Given what I see in my area, most lawn sprinkler setups are similar, with very poor overall design and impacts being made by landscape or hardscape changes.

Here in Texas, my water costs run about $50/month during the winter when I’m not running my sprinklers, but during the summer, there have been $300/month bills multiple times in the last few years. All this leads me to have a strong financial incentive to be more optimal in my water use on top of my overall desire simply not to waste water.

[scottsh]

I looked hard at this approach myself, because as you say it is the one most commonly used by commercial irrigation solutions.

What stopped me was the difficulty in getting accurate ET data. According to the Texas A&M site and papers, they stated that you had to have a soil moisture reader and solar radiation sensor to generate accurate ET values. This stopped me because neither are commonly returned values from Wunderground and aren’t common on most home weather stations. But, there is a Texas A&M official ET station about 35mi from my house that could be leveraged. I figured once I had the more traditional system done I would return to this ET-based idea and see what I could do.

I like your simulation and it makes me want to run the numbers and compare that to the more simplistic system I have come up with with in order to determine how much water would actually be used with each. I’m going to see how difficult that would be to add.

As for adding it to OSPi – I think I can see a way. You would have to collect the zone-specific data similar to what I have done that includes irrigation capacity, water needs, run-off limit, etc. Then you would have to model the individual zone needs, adjusting for the weather data. When it is time to water you program the OSPi model directly by setting gv.rs[zone] for a given amount of time respecting any filters (such as limited days, limited hours, run-off limits, soak time, etc.) Soak time is an interesting filter, by the way, one that fits relatively well within the current model.

I’d probably do something like wake up a thread every hour and run through all the checks/filters for each zone, and water if needed/allowed.

[scottsh]

@Lamby wrote:

Hi,

I am not sure what I am missing. I can’t seem to get a page to render. All I get is a blank page with the word “None”.

I think at the end of your Get method you need to include a return that causes page to render.

return self.render.sunset()

[scottsh]

@salbahra wrote:

Yes I did, sorry for the confusion. I test the software on my Mac (easier/quicker) and also I don’t have a Raspberry Pi :P.

My intention is to test against my mobile app (make sure everything works).

Thanks!

I use your mobile app as well – all the time in fact. It’s excellent and it works great alongside my plugin.

One feature I’d like to see would be the ability to display the history log. I’m not sure if this is feasible or not.

By the way, if this drives you to want to change the logging away from a CSV file to something else, I think Dan is open to it and I’d be willing to contribute to that as well. I have the CSV working for me, but it does feel a little unwieldy.

[scottsh]

@ray wrote:

@Scott: I have been trying to get my hands on the RPi compute module and re-design OSPi using the compute module. If this is feasible, it will allow LCD to be added to OSPi just like the Arduino-based OpenSprinkler. I am quite excited about this and hope it will happen soon!

I thought the same thing when I saw the compute module. It should allow for a much cleaner OSPi, although I thought it might increase your costs slightly. You have to include that SODIMM connector plus the USB/Ethernet ports on your board now.

Scott

[scottsh]

Oops fixed a problem when the settings file didn’t exist (which it would on first-time startup.) I keep forgetting to test a fresh install.

It should be fixed now – thanks!

I don’t understand the ‘No GPIO module was loaded…’ message though? Did you expect that?

Also, like Dan’s monthly program, I also need the apscheduler python module.

Scott

[scottsh]

Oh I see – you want OSPi to work with this DC solenoid instead of the standard 24V AC solenoids? That’s Ray’s department, not mine. I’m not sure what it would take to get that to work.

[scottsh]

I’m not suggesting you change an existing board, I’m suggesting you just use a transistor. When working with low voltage DC you can use components directly without the need for fancy boards. It know it might be scary to work with solder but if I can do it – and I’m a CS grad, not EE – then you can too :). There are lots of examples on the web on how to use it to switch DC. And from a cost standpoint, you can’t beat it – I see you can buy one of those 2N2222 for 10 cents ($0.10).

And besides, if you fry something it probably won’t hurt anybody. It’s when you start messing around with AC 120v 15A that things get … challenging. That’s when buying a board is a good idea – somebody else has already worked to make that safe.

You can pull a lot of mA out of a 9V battery; but that’s not the issue – the issue is the load, so you’ll have to look at the solenoid and see what it draws.

What are you trying to do?

[scottsh]

If you’re working entirely with DC then a transistor would work just as well and be a lot cheaper. Something like a 2N2222 would work, depending on how much current your solenoid pulls.

I see some 9v solenoids that only need 240mA so an 800mA transistor would work.

Scott

[scottsh]

Thanks for sharing! I really like seeing what other people have done with their OSPi setups.

I like that LCD display. I’ve been thinking of adding something like that as well for the same reason (display of some basic status info.)

I’m also thinking of adding some kind of ‘All Stop’ button to the system somehow so that somebody other than me can shut things off if needed.

Scott

[scottsh]

Another set of updates if you are following along at home:

Bugs
– Fixed minor UI save/load issues with the weather settings page

Features
– Added back-end code to allow switching between metric and imperial units for the UI display. The zone settings page is now displaying properly.

Known issues
– Disabled the Drip irrigation option for now to prevent selection until the back-end code is working
– Despite unit setting to metric, the pull from wunderground is still in inches.

[scottsh]

Just FYI – I pushed several updates to the auto-program plug-in.

Bugs
– Fixed algorithm errors that resulted in incorrect durations.
– Fixed small issues with data validation
– Fixed issue with invalid WU URLs (bad dates!)
– Fixed a major bug that prevented automatic operation (!!!)

Features
– Added ability to check WU for any rain today, and if so, to set the ‘rs’ or Rain Sensor active bit. Note this is only used if there is not a Rain Sensor configured.
– Added UI to configure between english or imperial units; back-end code is not implemented yet

Known issues
– Unit settings are not used, saved or reloaded properly
– Drip irrigation zone data is not calculated properly by the algorithms (gal/hr incorrectly treated as in/hour.)

[scottsh]

You might have to rm the wx_settings.json file in data and make it create a good one.

I just did a fresh clone and it loaded OK.

[Author]

Posts