Forum Replies Created
-
Posts
-
Hi Vaughano,
Originally the program did automatic daylight time adjustment based on the time.localtime() tm_isdst value and did not use the time zone setting from the interval program’s options page.
In response to your earlier comments, I removed the automatic daylight time calculations and included the time zone setting from the options page. That allows for manual adjustment of the time by changing the setting in options.
Looking at Andrew’s post:
“Can you see any problems with changing all references to time.time() to time.localtime() and remove all the timezone calculations?”
The problem here is that time.time() returns a time stamp from the OS such as:
1376937926.6
which is used in various calculations in the program.time.localtime() returns a tuple:
time.struct_time(tm_year=2013, tm_mon=8, tm_mday=19, tm_hour=11, tm_min=45, tm_sec=39, tm_wday=0, tm_yday=231, tm_isdst=1)
which is a whole different animal.To answer your question about when daylight saving time gets adjusted: The start and stop times for irrigation schedules are calculated starting at midnight for each day. Daylight saving time gets adjusted at midnight, and if a program is scheduled to start within the hour after midnight it might be affected.
I’d like to here what Ray might have to say in this regard.
Dan
Denny,
Check the Python GPIO info at:
http://www.raspberrypi-spy.co.uk/2012/05/install-rpi-gpio-python-library/Look under the Example Usage section at the bottom of the page to see how to set the pins for input/output.
To get the Rain sensor state to show on the OpenSprinkler home page you just need to set the var gv.sd = 1 for rain sensed, gv.sd = 0 for no rain.
EDIT: Scratch that. It needs more to make it work. I’ll let you know when I have the correct incantations.
OK. I added +’,rs=’+str(gv.sd) to one of the script lines (~426) in the class home: definition. Now if you check “Use rain sensor:” on the Options page and have gv.sd = 1 it will show “rain detected” on the home page and all stations will have a strike through. Bit it does not actually stop the stations from running – yet. I’ll work on adding that to the next update.Dan
kenbob,
It looks like the program page display is not taking into account the time zone setting from the options page (a bug). It should be easy to fix for the next update but the program should run correctly in the mean time.
Dan
Kevin,
It’s strange that the device time shown in your listing was correct but the log showed the default time.
The only thing I can think of at this point is to try ruining a test program and see if it happens again. It may have been a momentary glitch.
Dan
That date, 01 Jan 1970 00:00:00, in the log line (second to last line) indicates a default unix time.
Has the Raspberry Pi been set to the correct time zone as well as the time zone setting on the program’s options page?
More importantly, have you checked the Pi’s network connection?
Dan
Hmm..
So maybe it’s a display problem. I’ll check into it.
Don’t want to give anyone false info.
Dan
Hi kenbob,
I’ll check the algorithm but this may be a hard one to reproduce. Your description is clear and detailed enough to provide some valuable clues.
Please report back with any further insights.Thanks for reporting this.
Dan
Denny,
Just a thought, but I wonder if you could use the patch program to add your mods to ospi.py and .js files.
https://en.wikipedia.org/wiki/Patch_%28Unix%29Samer has used it to insert some bug fixes into ospi.py. I think that by using the -u switch you could add your changes to an updated program file and it might even be a way to distribute custom additions to the program.
I am looking into adding the rain sensor logic.
Also, regarding your suggestion for having the rain sensor control individual zones, that could be done by adding something like a “Sense Rain” column to the stations page next to the “Activate Master” check boxes. That looks doable.
Dan
daver,
I am looking at ways to make updates easier and appreciate your feedback. I’ll add the reboot step as you suggested.
There have not been as many bug reports lately as there were early on so the program seems to be getting fairly stable. However, some of the configuration files in the data directory have required updating, especially in the 8/01/13 revision. I’m starting to add some user requested features and that will probably result in changes to some of the files in /data. I don’t see that keeping them separate would be an advantage at this point.
I will be updating the documentation in the wiki:
http://rayshobby.net/mediawiki/index.php?title=Python_Interval_Program_for_OSPiand plan to include the README in the distribution with updated instructions.
Each update has its own set of modified files and I will try to list them in the readme and the announcement posted here on the forum.
It might be good to extract a new distribution to a temp directory and then move just the modified files into the existing installation.
I’m open to further suggestions on this.
Dan
If you are using the OSPi for irrigation scheduling it would need to be running all the time in order for the scheduling program to work unless you write your own program to activate the valves when the OSPi wakes up.
As far as power usage, I have seen an estimate on the Raspberry Pi web site of a yearly cost of something like $3.50 for running the Pi 24/7.
Dan
Hi Mickey
I haven’t seen what you describe before.
The only things In can think of that could cause a program to appear with a strike through is if the ‘stop operation’ button in the home page has been clicked. In which case the button (lower left below password) would say “start operation”. That would also cause the “en”: 1 key value pair in the sd.json file in the data directory to be “en”: 0.
The other thing would be if each program was individually disabled in the modify program window. That would cause the first element in each program in the programs.json file to be 0 instead of 1.
You describe the programs becoming struck out (disabled) when they are ready to start. Does that mean that when you view the programs by clicking the “programs” button from the home page they don’t show as disabled and only become disabled when they start to run?
Dan
Thanks Denny,
That looks really useful.
I used the rc.local method because I wanted to keep things as simple as possible for the new user. I will give your script a test run.Is it OK with you if I incorporate your script into the interval program documentation on the wiki?
Dan
Yep. It was a router setting 😳 . Something left over from some experiments a couple of years ago.
Looks like I need to revise the instructions on the wiki page.
Dan
Thanks Michael,
That’s really useful info. Especially the script for checking the network connection.
I tried the start up code just as you posted it but still no-go using 0.0.0.0. I wonder if it might be something in my router setup.
I’ll investigate further.
Dan
OK. I think I understand whats happening.
I normally interact with the interval program through its own web interface since that’s what I’ve been developing. I also use a wired network connection for my test system.
For someone using Samer’s Mobile Web App, using 0.0.0.0 as the URL for the program works great but you loose access through the underlying interface. It can be handy to be able to use both interfaces. For example, if you encounter a problem and are trying to determine if its with the web app or the Interval program.
The server used by the Interval program defaults to 0.0.0.0:8080 so if you are using Samer’s app and are willing to give up access to the interval program though its own interface you could use a simplified start up script:
cd /home/pi/OSPi/
/usr/bin/python ospi.py &If you connect to the Raspberry Pi via WiFi, you probably want to add a delay to the start of the script:
sleep 60
cd /home/pi/OSPi/
/usr/bin/python ospi.py $host:$port &I’ll wait for any additions or other comments and then add this to the wiki page.
Dan
Sounds like you’re on the right track. It needs to be fairly easy.
Some of the data used in the calculations don’t change over time such as location (Lat. and elevation). So there needs to be a one time configuration plus the ET value from the weather source.
I understand Australia has a system like the one here in CA and also I think Idaho does but that is still just part of the world.
Ray once mentioned that many of his customers are outside the U.S.
For the U.S., the NOAA has freely accessible data available:
http://www.nws.noaa.gov/view/national.phpThere may be similar resources for other parts of the world.
This is where thing really start to get interesting.
Dan
Michael,
That’s interesting. Whenever I try that it never works.
What is your setup like? Wifi, hardwared?
Dan
craigmw,
Being able to use ET data for irrigation management was actually my goal when I started this project.
Its pretty complicated. There are basically three levels of detail you can use for irrigation management.
1. Monthly adjustments based on historical weather data.
2. Daily adjustments using minimal weather data and the Hargreaves-Samani equation
3. Daily adjustment using additional weather data and the Penman-Monteith equation
All these methods take into account the type of plants and growth stage (crop factor), along with such things as soil type and efficiency of the irrigation system. You can read all about it at:
http://www.fao.org/docrep/x0490e/x0490e00.htm#ContentsHere in California we have a network of specialized weather stations specifically for the purpose of providing Evapotranspiration data. I already have Python code for accessing this data as well as code for both Hargreaves-Samani and Penman-Monteith calculations. This is as yet untested.
These techniques are mostly used in agriculture but there is development of landscape related applications. A very informative free publication can be found at:
http://www.water.ca.gov/pubs/conservation/a_guide_to_estimating_irrigation_water_needs_of_landscape_plantings_in_california__wucols/wucols00.pdf
This is focused on California landscapes but the principles can be applied anywhere.Ideally it should be possible to develop a system that can be used anywhere in the world.
Dan
ChrisFSB
I took a look and what was going on and made a couple of changes to the Interval program. The fixes will be in the next update but if you want to make the changes now, they are:
issues #1 an #2.
replace the set_station class (~line 642) with:
class set_station:
"""turn a station (valve/zone) on=1 or off=0 in manual mode."""
def GET(self, nst, t=None): # nst = station number, status, optional duration
nstlst = [int(i) for i in re.split('=|&t=', nst)]
if len(nstlst) == 2:
nstlst.append(0)
sid = int(nstlst[0])-1 # station index
b = sid/8 #board index
if nstlst[1] == 1 and gv.sd: # if status is on and manual mode is set
gv.rs[sid][0] = time.time() # set start time to current time
if nstlst[2]: # if an optional duration time is given
gv.rs[sid][2] = nstlst[2]
gv.rs[sid][1] = gv.rs[sid][0] + nstlst[2] # stop time = start time + duration
else:
gv.rs[sid][1] = float('inf') # stop time = infinity
gv.rs[sid][3] = 99 # set program index
gv.ps[sid][1] = nstlst[2]
gv.sd=1
time.sleep(1.5)
if nstlst[1] == 0 and gv.sd: # If status is off
gv.rs[sid][1] = time.time()
time.sleep(1.5)
raise web.seeother('/')
Issue #3:
Int the Get_Station class (~line 628), comment out or delete the following line:status = 'n'Modify the ine after that to change += to just =:
status = ''.join(str(x) for x in gv.srvals)The doctype line was originally added to make the program work with webkit browsers such as Chrome. I just tested this in chrome and it is working as expected.
Dan
It think the Water level % in options is what you are describing as a multiplier.
Dan
Samer, you beat me to it.
Ray and Andrew,
I have created a user page with instructions for installing the interval program. If you think it needs to be moved or otherwise changed that’s fine with me.
I have a set of screen shots to go along with the instructions but I have been trying to get them into the wiki page linked from my Skydrive with no luck. Any suggestions would be welcome. The detailed instructions are rather verbose but they are aimed at new users who may not be familiar with the Raspberry or Linux.
I also plan to add a trouble shooting section based on information from the forum.
Dan
craigmw,
There a couple of option settings that the Python interval program does not use including the port number and rain sensor related settings.
I included them to maintain compatibility with the Arduino based micro controller version of the program. They could be implemented in the future.I have been thinking about making the port number functional but it would probably require some operating system level code and that would add to the complexity of the set up.
Changing the expansion board number does cause the snames.txt file to be re-written as you discovered.
I will include that in a trouble shooting section of the documentation that I am working on for the wiki.
At this point the wiki page is located at:
http://rayshobby.net/mediawiki/index.php?title=User:Dan_in_CA
but it is not yet listed in the navigation pain for the wiki. I think Ray would need to add it there.EDIT:
The documentation for the Python interval is now located at:
http://rayshobby.net/mediawiki/index.php?title=Python_Interval_Program_for_OSPi
and can be accessed through the wiki menu under OpenSprinkler Pi.Dan
@ djagerif
I guess you could call that an accidental feature.
I think its a good one. Thanks for pointing it out.
@craigmw
Now that Ray is hosting the download for the program on rayshobby.net, installation is much more straight forward. Thanks Ray.I am currently putting the final touches on a wiki page for the Python interval program. It is intended to be a full set of documentation for the program.
It should be up in the next day or two. I will post an announcement here on the forum when it is ready.Dan
