Forum Replies Created
-
Posts
-
OK fixed – pull a fresh copy and that should resolve it – thanks again for the help in finding the bug!
Yeah that is a bug – thanks for the report.
It looks like the function I’m using to decode duration doesn’t like 60 minutes as a value. I can see why – the python library wants 60m to be 1hr instead. I’ll fix it ASAP.
Scott
Hmm, I don’t know what might be going wrong. Did you install apscheduler as root using sudo? Maybe its a permissions issue?
The implementation is complete – you can get it as part of the Auto-Program Plugin to DaninCA’s Interval program.
The instructions on how to get and use the plugin are here: viewtopic.php?f=28&t=653
Scott
Thanks for all the input – I decided to go with gallons (or liters) per hour. This was purely for ease of development – because I was already handling inches (or mm) per hour it was very easy to add a new ‘per hour’ metric.
I do have the ability to switch between English and metric, and from what I can see it works fine. What’s interesting is the algorithm doesn’t care if everything is in inches or everything is in mm – just so long as its always consistent. You don’t get to switch between them 😛
Scott
First, great points from all – it would be good if we could make it easier for folks to install from the web rather than having to manually run an installer from the shell.
It would be interesting if the Interval program could offer the ability to pull the makeself install package from a specified URL, then run it.
As a plug-in developer, I don’t know anything about makeself but a quick read makes it looks pretty straight forward. I can imagine making the complete package and placing it up on my web server for people to download pretty easily.
Scott
How do you think a wind-based delay would work? I’m thinking the code would have to be pulling live wind data frequently, but potentially only while it is actually engaged in watering. Would a single gust be enough to force a delay or only if the average gets over a certain amount?
I suspect this would only work with a personal weather station. You couldn’t pull data that frequently from WUnderground without paying for it. You could potentially pull from the NWS, but given that its not often local I’m not quite sure how useful that is?
I’m looking forward to seeing your results, Dan. I’m worried about the long-term reliability of that type of sensor, specifically around corrosion of the part that’s in the ground.
Check out the wiki for the basics – it will get you going. http://rayshobby.net/mediawiki/index.php?title=OpenSprinkler_Pi
Scott
It probably would save on watering – the ‘industry standard’ ETO method uses soil moisture as a key part of its algorithm.
How would you propose to get soil moisture data into OSPi? Would you want to have a soil sensor directly provide it over a GPIO pin? Or would you get soil moisture data from a network device? Or from a station on the internet? Would you have one sensor or multiple?
I personally backed the Edyn project in order to do just this – but obviously that device won’t arrive until 2015 (which is a crazy long time but don’t get me started.)
Scott
FYI – I just added and enabled support for drip irrigation systems. Pull a down copy if you’re interested in seeing how that works.
The “Monthly adjust” plugin and this plugin don’t work correctly together yet. It’s on my list to add though.
The amount actually watered does get adjusted by the % set but the automatic algorithm will keep trying to water up to the entered Precip rate. I need to adjust that based on the monthly adjustment settings.
Also, this is designed to work with the newly developed Weather Adjust plug-in. That plug-in needs to get forecast delay support added. This is also on my list.
I’m currently working on adding drip irrigation support. The actual code isn’t that hard, but the UI code to swap the units from in/hr to gal/hr on the radio select is proving to be challenging for me. I’m learning a lot though.
Wow – great bug find! That bug has been in there since “day one”. All fixed, if you pull or freshen your clone, it will pick it up. Thanks a lot.
To update your clone, execute the following from in the directory where you cloned the repository:
git pullThe code for determining the odd/even day watering schedule was obsolete and based on an earlier design that got refactored, but for some reason I missed handling the part when the actual watering is done. Which shows how much I tested odd/even watering lately. I’m really coming to wish I had an automated test setup.
Yes you need to add the apscheduler module which allows the app to run every day at the specific time to setup the auto-program for that day.
Use this command to install the extra module.
sudo pip install apscheduler==2.1.2UPDATE: fixed to specify the version which is now required since apscheduler updated to v3
Auto-Program is now updated to v2 support.
As always, you can sync from my github at https://github.com/scottshaffer/OSPi.git. It includes a full up to date copy of Interval v2. That said, this is making me want to think about how to to create some sort of installer so that it can be added to your existing OSPi without forcing you basically reinstall.
If you want to keep your existing settings, copy over the ~/OSPi/data directory from your existing installation to this one and you won’t have to start over with passwords/station settings.
Scott
It looks good. It is working for me, although it hasn’t actually kicked off yet – I’m hoping I’ll see it work later today when it rains.
Are you going to add the ability to delay based on a forecasted chance of rain? I think it should also look at the days forecast and if it sees a specified % chance or higher, it should delay that as well.
This way it won’t water at 3am when the forecast for rain in the evening is say greater than 80%. Thoughts?
Scott
You can configure an individual station/zone to ignore the rain sensor. Manual or Run Once works just fine for those zones.
For your use case, I’d configure that zone to ignore the rain sensor until the plants are established and your ready for it to participate.
However, in general, I can kind of see your point – that manual execution should always override the automated behavior.
Oh by the way, I have some code to pull US NWS forecast data in XML via a PHP script if needed. I have attached that. Also, I believe they also have a JSON-formatted data feed.
WU has that data also, however their information is not free. You can sign up for a developer API key for free, but it is limited on how much data you can request per hour and per day.
Scott
Thanks Ray – I checked every voltage I could and nothing was amiss, so I put in my other Pi using the same SD card from the bad one and everything worked like a champ. I was back up and running in minutes.
I hate lightning. It can cause so many strange things. Several years ago, I had lightning strike a tree outside my home (in another state) and the lightning traveled into my house via the ground line taking out several things, including hopping over to the RG6 coax line and completely vaporizing the inside of a notch filter.
Scott
I’m also thinking of adding a web-controllable power switch to my setup as well, so I could perform a hard power cycle if needed. So far though, that hasn’t proven necessary. But if you find the Pi to be unstable overall you might look into one of these solutions as a ‘belt and suspenders’ kind of approach.
This product is too expensive and doesn’t have an open API but its the kind of thing I am thinking about. https://www.quirky.com/shop/633-pivot-power-genius-power-control-from-your-smartphone
Scott
This is really a software thing – by default the software (both Arduino and Dan’s Interval program) assumes that the master valve is turned on before you use any of the other stations. I don’t use the C program (spinklers_pi) so I don’t know if it can do that or not.
However, it would be possible to code up the ability to have the master only tied to a set of specific stations. It would take modification of the base code but wouldn’t be that tough.
Hardware-wise, the system can open all the relays at once if you want, so any combination can be done.
I would think so, although you might have to do some work in the OS to get the GPIO pins mapped into use. For example, in Dan’s python-based Interval program you might need to map in a new python library to access the GPIO pins. Since the OSPi is all controlled from the GPIO pins that’s really all you need to do.
I think the OSPi can even power the HummingBoard, but I don’t know that for sure. It looked like it from the quick look I took at the hardware definition but Ray should confirm that. Otherwise, you might have to use an external power source.
Scott
