Forum Replies Created
-
Posts
-
As Dan in CA said, there is a plugin for the interval program to directly turn GPIO pins on and off.
https://github.com/KanyonKris/relay_board/wiki
I have a small collection of relay boards, active high and low and they all work with the RasPi. Some are better than others, see the link for more info. I have driven a relay board with both ospi.py and sprinkler_pi.
You say you tested GPIOs with an LED, I hope you used a current limiting resistor. The RasPi GPIOs are somewhat fragile and easy to burn out. The opto-isolated relay boards I have used have all worked fine.
Like Alan, the network connect to my RasPi was just a little too flaky with WiFi adapters (I tried a few) so I switched to a powerline adapter and it has been solid. WiFi is usable, it just means you may have to resubmit webpages to make your changes. It was most annoying when I was logged in with an SSH terminal because the connection would drop and I’d have to reconnect. If you will use WiFi, do as much of the setup of your system as you can with ethernet (a network cable plugged into your RasPi) before installing it in the remote WiFi location.
Non-latching valves are much more common.
I suggest a simple test to verify your valves work. At your controller, manually connect the power supply wires to the wires for one of the valves briefly, like 1 second. If the water turns on and continues to flow even after power is disconnected, they are latching valves. Apply power again to toggle the valve off. If you get no water flow, connect the wires for a longer period and verify that water is flowing, then disconnect the power wires and verify the water stops. If this works you have non-latching valves. This test will also determine if your power supply is good (able to supply enough power to activate the valves).
The 2.5V higher 26.5V power supply should be OK.
I haven’t heard of any model of RasPi being unreliable. Mine is a few years old model B and it’s been working fine in the garage for 2 years.
When the power goes out everything will turn off, unless you have latching valves. Non-latching valves work simply by turning on when power is applied, and turning off when power is removed. Latching valves turn on, and stay on, when given say 1 second of power – then turn off by say another second of power.
A watchdog would be nice, but mine has been running without lockups for 2 years.
Dan, more good points.
So is it better to have a plugin system that can handle everything but is more complicated, or a simpler system that makes it easy to install simple plugins (Python and HTML pages)?
I believe most plugins will be just Python code and HTML pages so I favor a simple plugin manager. And there’s no reason we couldn’t also have a wiki or other system for the more involved plugins. Just throwing out ideas.
Dan, your points are valid. There’s a lot to consider when designing this plugin system. Perhaps a hybrid approach that uses Git for some things, wiki for others and functions added to the interval program to install, configure and delete plugins?
salbahra, good details about how Git can be used for plugins (I’m a Git noob).
One thing that makes these plugins tricky is the HTML pages, they have to go in the templates directory so you can’t just have one subdirectory under the plugins directory (ie plugins/autowater2000). The makeself tool can handle this with an auto-executed script, as Dan pointed out. But it’s trickier for version control systems, hence salbahra’s suggested workarounds.
Regarding this point, I suggest a naming convention for plugins so it is clear what files belong to what plugin. For example, if the plugin is SuperWater, all of its HTML files in the templates directory should use that name, ie SuperWater-config.html, SuperWater-status.html). In fact, perhaps they should be: “plugin-SuperWater-config.html” so it’s easy to know which HTML files are for the core interval program and which are for plugins. A standard naming convention would also make it easier to delete a plugin via the web interface and core interval code functions.
I had WU errors a while back and it turned out that the weather station I chose was off-line. I switched to ZIP code and no more errors.
Thinking about this some more, and discussing it with a software engineer at work, a different approach:
All plugins hosted in Github repository with interval program and downloaded during install and updated with git pulls. Instead of the interval program loading all Python files found in the plugins directory, it checks a configuration file and only loads the plugins listed in that file. Only a few critical/needed/basic plugins loaded upon new install.
Plugins web page has link to a list of all plugins where user can select new plugins to use or to disable currently active plugins.
Changes to plugins would be committed and approved by Dan, or Dan can add collaborators for plugins.
I’ll admit it seems weird to have all the plugins downloaded, but I doubt there will be that many plugins and the file sizes are small. Since the interval program is already hosted on Github, makes sense to me to use that tool for the plugins too.
My first thoughts were along the lines rederikus mentioned. Since there is a web interface, seems the user could access a list of plugins, click on one and have it installed (and also uninstalled). Having some programming experience I believe this would take a fair amount of work to implement, but I think this would be a good goal to shoot for.
In the short-term I like makeself. While it takes some manual steps I doubt many users will be going nuts installing many plugins so the occasional manual process isn’t a huge barrier – folks had to do a bunch of steps to get the RasPi setup and interval running.
Yes, the B+ has a 40 pin connector instead of the 26 pin header for B and A. The good news is the pinouts of the first 26 pins of the B+ 40 pin connector are the same as B and A. So if the OpenSprinkler board will physically plug onto the B+, it will make the correct electrical connections.
Just eye balling the B+ it looks like it might connect OK with the OpenSprinkler board, but the only way to be sure is for someone to try it, maybe Ray will.
I think it’s unlikely the B+ will fit into the OpenSprinkler enclosure, and for sure some of the connectors won’t line up with holes.
There are many relay boards that will work. I used this 4 relay board from SainSmart. It’s connected to my Raspberry Pi and running my sprinkler system for 2 years. You can buy from SainSmart, I bought one off Amazon for a $6. They also offer relay boards with more or less relays, and also small signal and solid state relays – http://www.sainsmart.com/arduino-compatibles-1/relay.html
Sounds like your 24 VAC power supply can’t output enough power for the 3 valves and Pi. Ray suggests at least 500 mA. What does your supply say it can do? It may be that you need more than 500 mA.
Here’s a simple test: unplug the 3-wire cable and instead power the Pi with an AC to USB mini adapter that can supply at least 700 mA. If the lock ups go away then you’ll need to keep powering the Pi with it’s own AC to mini USB adapter or get a bigger 24 VAC power supply.
@ray wrote:
Can you tell which version of Raspberry Pi do you have? Rev.1 (which does not have screw holes) and rev. 2 (which has screw holes) have slightly different pin names in Python, so you will need to change the pin name according.
For several versions back, the OSPi python program detected the Raspberry Pi rev and configured the pins appropriately. And in the Oct 1, 2013 version of OSPi, the code was further enhanced to use pin numbering to address this issue. So I’m not seeing how Raspberry Pi rev can be the issue, but I’m probably missing something here.
@ray wrote:
On the other hand, the ospi_selftest program, which is written in C, should work in either case. So I would suggest running that first to see if your solenoids can turn on.
Yes, do this, it will tell you if the OSPi Python program is the problem.
Also double check all connections: ribbon cable (make sure each end is oriented correctly), 24 VAC, valve wires, etc.
As I understand it, ET is trying to quantify how much water (inches or mm) will be lost from the soil (evaporation) and plants (transpiration). So conversely ET tells you how much irrigation water will need to be applied to replace that lost water. Since Hargreaves-Samani does not take precipitation into account, my assumption is that you simply subtract precipitation from ET to get how much irrigation water is needed.
For altering watering, IMO the best way is to measure water output per zone (inches or mm / minute) and then use ET (minus precipitation) to determine how many minutes to run. Measuring water applied to each zone can be done with cans placed on the lawn. A simpler alternative is to figure an average water output for all zones and then adjust them all up/down by some ratio (percent) as ET is higher or lower than this average. Another method is to look at historical ET data and figure an average (for the whole summer or maybe just July) and then use that as a baseline to compute if watering should be increased or decreased.
One of the things I like about OSPI being written in Python is how (relatively) easy it is to tinker with.
This thread discussing the use of weather data to adjust watering may be of interest to you – viewtopic.php?f=28&t=364
Somewhat related, how does sprinkler_pi handle weather adjustments when watering say every other day? Does it simply use the current day’s weather info? It would be nice if it could look back every day since the last watering and use the average of those days.
As I read into what Captn Avenger noted, it may be that it doesn’t work when run the first time but works fine thereafter. If you’d like to test this, do:
sudo python ospi.pyUse your web browser to connect and see if the Options page is there or not. Be sure to force the browser to reload pages, in Chrome, and I think most browser, do this by holding down the Shift key then click on the refresh button/icon/whatever.
If the Options page is blank, stop the sprinkler program by typing Ctrl-C which should dump you back to the command line.
Now run the sprinkler program again by using the same command as above. Tip: press the up arrow to access previous commands, then press enter when you see the one you want.
To get started I’ve written a Python program to get the 24 hour irrigation required value from the WeatherReach site and output a 100% watering adjustment. My plan is to use this Python program as a way to tinker and test various data sources and formulas for computing the weather adjusted watering amount and/or percent the current program should be adjust (up or down). Feel free to contribute, branch or start your own programs. The code is here:
https://github.com/KanyonKris/sprinkler-weather
The program uses the BeautifulSoup Python module to parse the web page into a structured tree. This makes it much easier to pick out the needed data from a web page, once you learn BeautifulSoup. I recommend using it. The documentation is good – http://www.crummy.com/software/BeautifulSoup/bs4/doc/
The best/easiest way to adjust for weather is ET data since if you know how much water your lawn (or other crop/plants) has lost you know how much you need to replace via irrigation. So next steps are to add more data sources for ET (or similar) data.
The next step down is to use weather to compute ET. I plan to work on this too, but welcome others to work on it also.
I had the same issue, but I’d made some changes to some files so I thought that was what caused the problem, guess not.
I deleted options.txt and restarted ospi.py, didn’t work.
I looked around at some other files but couldn’t see anything that might cause this problem.
Since I’ve only been experimenting with this program, I wasn’t using it to irrigate, I took the nuclear option and deleted the OSPi directory and reinstalled with:
git clone https://github.com/Dan-in-CA/OSPiRan ospi.py and everything worked perfectly.
Unfortunately the nuclear option means I don’t know what caused or fixed the problem. If someone would like to do a better investigation I suggest renaming your current OSPi directory and doing a fresh install using the git clone above. Verify the new ospi.py works fully. Then one by one copy your old data files into the new install (after renaming the new data file as a backup) and see if it breaks it. Then compare the old and new files and look for differences.
I’m fine using an AC to mini USB adapter. I had an extra one from a dead smartphone so it was free.
Perhaps someone is using a 24 VAC to 5 VDC adapter and can make some recommendations. But if not just look up the power specs for the Raspberry Pi and buy a converter that looks like it will work.
triton,
I don’t understand why you want to move the web pages to /srv/web, what’s wrong with staying with /web ?
For your relay board, go to Settings and for Output select either Direct Positive (relays are activated by Raspberry Pi output going high) or Direct Negative (my board needed this).
I haven’t heard of anyone adding garage door support yet. The source code is available, hack away.
nhorvath, I agree with Ray, you should post your board design in a new thread. It deserves more notice.
Dan, that PDF is interesting, but doesn’t it also require solar radiation data? From STEP 2:
Rns = net solar radiation over grass as a function of measured solar radiation (Rs)
As I mentioned, I couldn’t find a good data source for solar radiation so if Hargreaves-Samani doesn’t need solar radiation that’s good.
This paper shows an improvement to Hargreaves-Samani that increased accuracy – http://cagesun.nmsu.edu/~zsamani/research_material/files/Hargreaves-samani.pdf
This quote from the above paper emphasizes the need to consider solar radiation in some form:
According to Jensen (1985), at least 80 percent of ET0 can be explained by temperature and solar radiation.
According to the maker of the WeatherSet irrigation controller:
On average, 85% of ET is solar radiation and 10% is wind. When there is no wind, then solar radiation is 90-95% of ET.
(Not sure how credible this is since the website has a less than credible feel.)
The WeatherSet controller has a photo sensor of some sort to measure solar radiation. And perhaps a solar radiation sensor could be added to OpenSprinkler. However, I prefer to focus on efforts that use readily obtainable weather data unless we find it can’t be done accurately.
Dan, good work getting these equations in Python. I feel the first step is to support ET directly since there are sources of ET data available. True the coverage is spotty, but for those that live in those areas, having a daily ET value gets you almost there (just need to figure out what adjustment to make to watering). And these ET numbers should be more accurate than what we could compute based on limited weather data. Yet I can see the appeal of a method that needs only basic weather data as it would work for more people.
Dan, I’ve been looking into ET myself. I started a thread called Weather algorithms to discuss how to use weather data to water smarter.
I have found a few sources of ET data. Obviously this is extremely useful as it eliminates the need to gather all the data needed by the ET equations.
This map shows 100 or so stations where ET and other irrigation data is available:
http://access.weatherreach.com/map_stations
Click on a station and in the Irrigation Requirements box the 24 Hours value indicates how much water your lawn should need for the next day.
Knowing how much water is needed, the next issue is determining how long to water to deliver that irrigation. I see two ways to approach this:
1. Determine the amount of water deposited by the sprinkling system per minute. This can be determined by placing several gauges (or simply empty cans) on the lawn and watering for, say, 10 minutes. Once the inches of water per minute rate is know it could be entered into the watering program for each zone.
2. Determine the amount of water needed for an average day and assume that the current watering schedule delivers it. Historical weather data can be used to get Spring, Summer and Fall averages to be used in an ET calculator (like the one in the post above) to get a baseline or 100% ET which could be input to the watering program to be compared with the weather-based needed ET which will be used to adjust the current schedule of water times up or down.
OK, that’s all I have for now, take it away.
