- This topic is empty.
June 9, 2013 at 3:14 pm #22468
The title says it all 🙂 Please check this blog post for details:
http://rayshobby.net/?p=6339June 17, 2013 at 3:48 pm #24405
Cross-posting my findings here in order to bring the interval program closer to the HTTP GET API documentation of the normal OpenSprinkler I made the changes documented here: http://rayshobby.net/phpBB3/viewtopic.php?f=2&t=154&start=40#p781
These allow my webapp to work almost 100% with the interval program. The patch file is designed for the latest version of the OSPi posted on Ray’s Github (Commit #5f1042f9ad68d679ac1eacdb38762894c46614a3). I am hoping these changes can be incorporated into the live version of OSPi interval program.
Couple of other notes: I do not find a sequential option in the program (which causes problem’s if that setting is checked in my web app). Is this something that is planned to be incorporated? Also, I noticed the last run information is not updated on the OSPi, is this something I am doing wrong or just not working yet.
Thanks!June 17, 2013 at 6:16 pm #24406
Easy for this noob to download and install. Ran right out of the “box”, so to speak.
A couple of issues and questions.
1. The options doesn’t seem to accept any port number I set. It uses 8080 only.
2. When reviewing the program preview, the MASTER only shows up for the first seven zones. (I’ve not completed my wiring, so no way for me to tell if the MASTER is really on for zones on the expansion cards. )
3. Also in the program preview, the red “NOW” line stays at about the 12:45am mark.
4. And the question – how difficult would it be to add the functionality of a manual mode into this!
So far, all I can say is WOW! As a noob, I look forward to learning more!
Thanks!June 18, 2013 at 6:50 pm #24407
With the awesome mobile app described at: http://rayshobby.net/?p=6409
there is a need to keep ospi.py in sync with the Samer’s expectations. For example, his patch file didn’t work on the “older” (original?) version. Updating to the latest in Github worked fine. But I’m not clear what other files need to be updated.
What is the best practice for keeping the version running on the OSPi current?
TimJune 18, 2013 at 6:59 pm #24408
Fortunately, this will become a thing of the past (consider this growing pains). Dan has reviewed my patch and plans to incorporate it into the main OSPi code. He’s also working on a fix for the last run code and maybe the sequential code as well. So, starting with the next OSPi interval program update there should be no reason to patch/modify the code and should work out of the box with my mobile web app.
Thanks!June 19, 2013 at 11:04 am #24409
I have noticed a bug that is now confirmed by another user. While a program is running the OSPi will not update the status of the stations using sn0. The status is only updated during manual mode or run-once mode. However, the program does correctly show a station running on the home screen. Basically, it’s properly updating the ps variable on the home page to reflect station status during program mode but it’s not updating the HTTP GET API, /sn0, during a program running.
Thanks!June 19, 2013 at 12:10 pm #24410
Another bug I have found is to do with daylight saving. In my setup I was getting daylight saving corrections, even though it is winter here in Australia.
Looking at the ospi.py code, I see
gv.lrun = now-(time.timezone-(time.daylight*3600))
homepg += 'n'
I am no python programmer, so I looked up the time functions. It seems that time.daylight will return 1 in timezones that have daylight saving regardless of whether it is currently applied, so the above code segments will incorrectly adjust for daylight saving all year. More discussion on this gotcha at http://stackoverflow.com/questions/2881025/python-daylight-savings-time.June 19, 2013 at 3:43 pm #24411
Thanks for the bug reports. I will see what I can do.
Regarding the daylight time situation, I thought that might be a problem. Maybe the best thing would be to remove it. Even in locations that use daylight time there is really no reason for an irrigation schedule to change. It can just stay on standard time.
DanJune 19, 2013 at 10:40 pm #24412
No worries Dan, thanks for your efforts!
I agree that removal is as good as making the daylight saving work, that’s what I did on my local version. If I manage a fix I will provide a patch, or push a branch back (after I learn how to use git…).
VaughanoJune 22, 2013 at 1:22 pm #24413
I installed the interval program on my Raspberry Pi and seems to be working for the most part. I noticed a few bug I thought I would just call out. None of my programs are running automatically, the manual and run once programs work great though. Also I when I look at the program preview window the current time line is always between 0 and 1 in the morning but never makes it past that. I am also seeing no logging, I have enabled it. I see this when I go to the log page: “Total number of records: -1” Any help would be appreciated.
Thanks!June 22, 2013 at 6:54 pm #24414
Hi all, I’ve been lurking around here for a couple of weeks now, getting very excited about the possibilities of a Pi-powered sprinkler system. Well, I got my Pi as a Father’s Day gift and have started to set it up, trouble-shooting issues with SD cards, power supplies and monitors. Finally I have a stable Pi so I proceeded to setting up OSPi but I immediately ran in to an issue.
I downloaded the latest OSPi from github (the instructions refer to ospi.tar.gz that doesn’t exist so I downloaded the latest version (OSPi-jun19-13.zip) and unzipped it (unzip OSPi-jun19-13.zip). I checked the directory structure under /home/pi/OSPi and everything looked to be correct. Permissions were rw-r–r– for ospi.py so I made it executable rwx-r-xr-x but that didn’t fix my problem….
Running ‘sudo python ospi.py’ worked and i was able to access the web page on port 8080. However….selecting the options page and trying to save changes just displayed ‘unauthorized’
The app spat out a couple of errors. I suspect the first is the one thats causing the issue.
192.168.0.7:62687 - - [22/Jun/2013 12:30:41] "HTTP/1.1 GET /co" - 401 Unauthorized
192.168.0.7:62687 - - [22/Jun/2013 12:30:42] "HTTP/1.1 GET /favicon.ico" - 404 Not Found
192.168.0.7:62688 - - [22/Jun/2013 12:30:42] "HTTP/1.1 GET /apple-touch-icon-precomposed.png" - 404 Not Found
Did I do something wrong or miss a pre-requisite step?
Thanks to everyone here – this looks to be a great product and well-supported!June 23, 2013 at 2:24 am #24415
The -1 in the number of log records indicates that the log file has a problem. Click the “Delete All” button to clear the file.
If you start the interval program manually and then log out of the pi, the program will stop running. See the last instruction in the readme on GhtHub:
Once you have the interval program setup to start automatically and run as root, your irrigation programs should run as expected.
The “Unaurthorized” message indicates that you did not enter the password (opendoor) before clicking the Submit Changes” button.
DanJune 23, 2013 at 4:49 pm #24416
@PabloS/@cmwahlqu I found a fix for the red bar not moving in program preview and submitted it to Dan. In the meantime your welcome to test this fix if your comfortable editing some code.
Inside ospi.py you will find the following line (#796 in the latest code 6/22/2013):
graphpg += 'n'
And the fix is to change it to the following:
graphpg += 'n'June 23, 2013 at 10:58 pm #24417
Also this will fix the Program Preview to show the correct time…
ospi.py [File to Edit]
devmin=’+str(lt.tm_min)+’ [Old Value]
devmin=’+str(lt.tm_hour * 60 + lt.tm_min)+’ [New Value]June 23, 2013 at 11:01 pm #24418
@kenbob I believe that is the same fix I posted above right?
Edit: I just replaced the whole line to make finding/changing it easier.June 23, 2013 at 11:04 pm #24419
Oops sorry, you are right. Nothing like duplicating. 😳
I thought it was a fix for adding the bar.June 23, 2013 at 11:06 pm #24420
The good news is, we reached the exact same fix! Also, Dan got back to me and said he has incorporated the fix into the development version and should hopefully get pushed out soon as part of the official package. The OSPi software has really come a long way and very impressed with Dan’s work.
Absolutely loving the community around OpenSprinkler!June 23, 2013 at 11:13 pm #24421
I also noticed that the location (loc) string does not work, but here is the fix for the location in case you want to add the weather button back, which I have done on my system.
ospi.py [File to Edit]
loc=”” [Old Value]
loc=’+str(sd)+’ [New Value]June 24, 2013 at 12:10 am #24422
This one is just plain nit-picky but you have a debug on line #594 that can be safely removed:
print nstlstJune 24, 2013 at 12:40 am #24423
I have already taken out the “print nstlst” line.
I was using it to help figure out how to implement the last run log for manual mode operations with an optional timer value. I think I have that working now even if you start more that one station.
I’m also testing a fix for a bug that does not clear the station status on the main page after running several irrigation programs. I won’t be sure how that works until tomorrow morning. Every time I test it manually it works as it should.
DanJune 27, 2013 at 4:19 pm #24424
I wonder if anyone else has encountered a problem with the interval program getting “stuck”. I have 5 different schedules. What seems to happen is rather randomly, one of the stations will come on, run, and, apparently, turn-off at the right time. But the interval program seems to be a little confused and shows a status with 1 second remaining. Then, apparently none of the other stations come on.
I’ve not had a chance yet to review the code, but expect to later today, unless someone else has already discovered what could be causing this.
/joeJune 27, 2013 at 5:35 pm #24425
I have also experienced this bug. For me, it happened if I hit stop all stations right after I start a program and requires me to switch enable on/off for it to fully reset back to normal.
I have no clue what would be causing it but that might be an easy way to replicate the issue.June 27, 2013 at 7:41 pm #24426
I have also had this issue. I have included a screenshot of the problem. This was after running my normal scheduled program.June 28, 2013 at 4:41 am #24427
Just to tack on one more bug, sorry. If I set a master station and then tell all stations to trigger it, only the first 8 stations show up using the master in the preview. I have found the masop variable is only changing for the first board (main board) and not any of the extensions. However, it does have a placeholder for the number of extension boards in place. If I need to clarify let me know, thanks!June 28, 2013 at 3:39 pm #24428
The latest update on GitHub should have the hang bug fixed.
- You must be logged in to reply to this topic.