Python interval program update 8/01/13

[Samer]

It also might be easier putting the configuration in a file that is not included in the distribution. Therefore, there is no way to accidentally overwrite the configuration. The program can just check if the file exists and if not, create it.

You can then combine the above system with Github making upgrades as easy as: git pull

[Dan in CA]

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_OSPi

and 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

[kenbob]

Everything has been working great since August 5th. I have configured my system to water every 2 days for 12 minutes. It has watered every other day with no issues and it last watered yesterday August 15th, the system now shows that it is going to water again today August 16th. Is it just me or has anyone experienced this? It looks like it counted too many times on the countdown and shows 0 days, when there should be 1 day left. The Pi has been running normally and has not been rebooted.

[attachment=1:17z8d7de]sprinkler1.JPG[/attachment:17z8d7de] [attachment=0:17z8d7de]sprinkler2.JPG[/attachment:17z8d7de]

[Dan in CA]

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

[kenbob]

Thanks Dan,

I checked my schedule again and now it shows that it is not going to run until tomorrow the 17th. Weird huh? It must have past a certain time and now it is showing correctly on the preview screen.

[Dan in CA]

Hmm..

So maybe it’s a display problem. I’ll check into it.

Don’t want to give anyone false info.

Dan

[kenbob]

It looks like before 17:00 hours it shows it will run on the 16th, but after 17:00 hours it shows the 17th. Could this be something weird on my end?

[Dan in CA]

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

[kenbob]

Thanks Dan,

My schedule ran normally tonight as usual. Not sure why I didn’t notice that before, maybe I was only checking it at night. I appreciate the work you have put into this project and for your quick response. The interval program is really nice and has been working great so far.

[Vaughano]

Dan,

Once again, thanks very much for the work you have put in on this python/pi port of the interval program. Ray, yourself and Samer have provided a great platform to play with!

It might be good for us to look again at @aradke’s post at viewtopic.php?f=28&t=160&start=40#p1500 about timezones. I have removed timezone calculations myself to fix problems I was having, which I believe was a bug that has been fixed. However, my preference is still to allow the OS to keep the time, and the application to simply query the OS for it.

The only thing that I wonder is whether using the OS local time (daylight savings adjusted time) would cause any impacts when daylight saving time gets adjusted? Like a program failing to stop, potentially leaving a solenoid on?

Cheers
Vaughano

[Dan in CA]

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

[Vaughano]

Thanks Dan,

I have no solutions unfortunately, only questions!
Thanks again for your efforts.

Cheers
Vaughano

[Dan in CA]

Vaughano,

After giving this more thought, I don’t think there would be a problem since the daylight savings time is no longer automatic. You need to change the time zone setting on the options page to move to or from daylight time. You would just make the change when no program was running.

Dan

[Vaughano]

Sounds fair. I’ll grab your latest code when I get a chance and try it out.

[Author]

Posts