- This topic is empty.
August 31, 2013 at 7:39 pm #22626
The August 30 update to the Python Interval Program is now available.
There have actually been a couple of “silent” updates in the past few days.
I am new to GitHub and made a couple of small blunders in getting to know the system but there is no going back.
The kinks are getting worked out and this update should be pretty smooth.
If you have not updated the program in a while (before Aug. 25), follow the instructions on the wiki for updating from an installation that was not done using git:
If you updated the program on or after Aug 25 using the new GitHub repository you just need to log into the OSPi sirectory on your Pi and run the command:
Depending on when you actually updated your program there could be a couple of different results:
1. The program will be updated and your done. EDIT: forgot to mention that you will need to restart the program (reboot) to enable the changes.
This is the expected result and should be how things work from now on. Your settings and programs should remain intact.
2. The program is updated and shows a bunch of *.pyc (compiled python) files being deleted.
There is nothing to worry about. The .pyc files are automatically compiled by Python when it runs a program and these files will be re-generated. Git will ignore them from now on.
This was one of the blunders I made as a git noob. I shouldn’t have included them in the repository.
3. The update aborts with a message about overwriting files and either commiting or “stashing” your changes.
this is not as bad as it looks and there are a couple of options:
You could re-install from GitHub following the directions on the wiki at
or you could follow the on screen instructions for adding an email address and user name to git. Then run:
and the update should work.
Let me know how it goes.
Now for the good stuff:
1 This updates includes a change to the program that uses only the time zone setting from the Options page. Previously, parts of the program relied on the tz setting from the Pi. This has caused problems if the two tz settings were out of sync.
2. The CPU tempreature display is clickable and toggles between C and F temperature units. This is for our international friends.
3. A file named ospi.sh has been added to the OSPi directory. It is a copy of Denny Fox’s init.d start-up script. you just need to move it to /etc/init.d and rename it to ospi like so:
from the OSPi directory
sudo mv ospi.sh /etc/init.d/ospi
Then follow the instructions on the wiki to get it working:
This version of the script assumes that the OSPi directory is in the default location as a sub-directory of the /home/pi/ and you will be using port 8080.
If you have moved your OSPi directory to a different location or want to use a different port such as 80, you will need to edit the file accordingly.
The port setting is on line 34.
The location setting is on line 38.
Not a whole lot this time but I wanted to use this as a test of the new update method.
Files that were changed or added in this update:
DanAugust 31, 2013 at 10:18 pm #25487
Traceback (most recent call last):
File “/home/pi/OSPi/web/wsgiserver/__init__.py”, line 1245, in communicate
File “/home/pi/OSPi/web/wsgiserver/__init__.py”, line 775, in respond
File “/home/pi/OSPi/web/wsgiserver/__init__.py”, line 2018, in respond
response = self.req.server.wsgi_app(self.env, self.start_response)
File “/home/pi/OSPi/web/httpserver.py”, line 306, in __call__
return self.app(environ, xstart_response)
File “/home/pi/OSPi/web/httpserver.py”, line 274, in __call__
return self.app(environ, start_response)
File “/home/pi/OSPi/web/application.py”, line 279, in wsgi
result = self.handle_with_processors()
File “/home/pi/OSPi/web/application.py”, line 249, in handle_with_processors
File “/home/pi/OSPi/web/application.py”, line 246, in process
File “/home/pi/OSPi/web/application.py”, line 473, in internalerror
parent = self.get_parent_app()
File “/home/pi/OSPi/web/application.py”, line 458, in get_parent_app
if self in web.ctx.app_stack:
AttributeError: ‘ThreadedDict’ object has no attribute ‘app_stack’August 31, 2013 at 11:09 pm #25488
Looks like there is a problem with web.py,
Could you provide some information about what occurred before the error messages?
Was this a new install or an update from a recent version?
The easiest fix would probably to just re-install:
I have tested the update and a new install and they both worked.
DanSeptember 1, 2013 at 4:01 pm #25489
I am still having the same issue where it is off by 7 hours. If I set the watering schedule for 16:15 it will water that day on time. If I set it for 17:15 it will not water that day. Some how there is an issue with the localtime and gmtime. I suspect it is reading the gmtime, but it is showing the localtime on the interface. I wish I could be more help, but my programming skills are very limited.
My main watering device is Ray’s Opensprinkler V1.2U, so I run this one virtually just for testing. I like the work you are doing and hopefully I have been of some help. In the future I may switch to the Pi because of the Wifi and flexibility. 😀September 3, 2013 at 5:27 am #25490
I think I found the problem. It looks like an issue with devday in ospy.py, I manually subtracted the 7 hours with 25200 seconds and it looks like it works. I made a change to the graph_programs and the prog_match. It just needs to calculate the selected time zone in order to fix the issue. Hopefully this helps.
def prog_match(now, prog):
devday = int((now -25200)/86400)September 3, 2013 at 9:28 pm #25491
OK here is my fix so that it will calculate your local timezone in ospy.py. It will add or subtract the time depending on where you live.
devday=’+str(int((t – time.timezone)/86400))+
def prog_match(now, prog):
devday = int((now – time.timezone)/86400)September 3, 2013 at 9:44 pm #25492
I did some further digging and found 2 places in the code that were still using the timezone data from the Pi.
those have been changed to use the tz setting from the options page.
I just pushed an update to GitHub,
If you don’t mind, could you try the update and see if that fixes the problem?
I really appreciate your help with this and it looks like we are getting close to a fix. If you are still seeing the same problem after the update I will investigate your suggested changes but there may be a more basic place in the code that needs to be changed.
DanSeptember 3, 2013 at 10:52 pm #25493
I am still having the issue after 17:00 hours. The issue seems to be at… devday = int(now/86400) # Check day match it is not compensating for the time difference and gets stuck at if (devday %prog) != (prog – 128): return 0. Also the program schedule devday=’+str(int(t/86400))+ needs to pull from the local time as well. Thanks. I was playing around learning something new, but it has been fun. 😀September 5, 2013 at 2:04 am #25494
OK, I did a thorough overhaul of the way current time is handled throughout the program.
I think what was causing the timing problem you have been seeing was due to the main_loop using UTC time without adjusting for the time zone setting from Options.
Once that was fixed, it broke a lot of other parts of the program so I made the “now” at the start of the main loop an attribute of the gv module (now is now gv.now and includes the tz adjustment) and used it throughout the program. That fixed the broken parts and simplified the code quite a bit.
I just pushed an update to GitHub. Please check it out and let me know how it goes.
Thanks for “bugging” me about this, I want the program to work flawlessly.
DanSeptember 5, 2013 at 3:04 am #25495
My install was a fresh install (I moved the old directory out, git cloned, put the data files back in, and rebooted)September 5, 2013 at 4:52 am #25496
Thanks Dan. I will check it out and let you know if anything comes up.
Everything looks great! I ran some tests and it is working with no issues so far. I set a program at 00:00 hours and another at 23:00 hours. It is showing the correct program preview all day and has been running the schedule on time. Thank you for the fix.September 11, 2013 at 10:24 pm #25497
Did an update today.
Now i get this result when trying to start.
[email protected]:/OpenSprinklerPi/interval_program/OSPi# python ospi.py 0.0.0.0:8080
Starting main loop
Traceback (most recent call last):
File “ospi.py”, line 1008, in
File “ospi.py”, line 1003, in run
return web.httpserver.runsimple(func, (‘0.0.0.0’, port))
File “/OpenSprinklerPi/interval_program/OSPi/web/httpserver.py”, line 157, in runsimple
File “/OpenSprinklerPi/interval_program/OSPi/web/wsgiserver/__init__.py”, line 1753, in start
socket.error: No socket could be created
Sent from my Nexus 7 using Tapatalk 4September 11, 2013 at 10:31 pm #25498
Nerver mind. Found solution in other thread.
Sent from my Nexus 7 using Tapatalk 4September 12, 2013 at 7:17 pm #25499
I did the update today but after doing so, I’m seeing this error in the output log:
[email protected] ~ $ tail -f error.log
File "ospi.py", line 644
for i in range(incr):
IndentationError: unexpected indent
Line 644 in ospi.py (with context) looks like this:
def update_scount(self, qdict):
"""Increase or decrease the number of stations shown when expansion boards are added in options."""
if int(qdict)+1 > gv.sd: # Lengthen lists
incr = int(qdict) - (gv.sd-1)
for i in range(incr):
for i in range(incr): <
snames = data('snames')
nlst = re.findall('['"].*?['"]', snames)
ln = len(nlst)
That line seems to have TABs instead of spaces on it, but trying to reset that to spaces didn’t fix this error for me.
This is a straight pull from the git repo you recently setup (thanks for doing that! Love the simpler updates now!).September 12, 2013 at 8:54 pm #25500
I thought this was going to be an easy one.
Anyway i just pushed another update.
There were some other lines that needed the tabs changed to spaces. I just tested an update from GhiHub and things finally seem to be working right.
- You must be logged in to reply to this topic.