OpenSprinkler Interval Program now available for OSPi!

[Samer]

Dan,

I think I am still experiencing this bug. I pulled the latest tarball on Github and noticed it is still marked 22/06/2013 so maybe it didn’t get updated correctly? Below is a screenshot of the June 26 copy on Github showing the same 00:01 time and nothing happening:

[attachment=0:1hdzkkf5]Screen Shot 2013-06-29 at 8.56.51 AM.png[/attachment:1hdzkkf5]

I am also noticing programs that are scheduled to run 16 zones are only flipping the first 8 on. At least, for the station status on the main page. Below are some screenshots to show what I mean for the newly discovered bug.

Thanks!

[Samer]

Okay, I think I fixed a few bugs and applied them as a patch. Most of these have been discussed here already however did not make it into the latest version on Ray’s Github.

Here is what I changed:

– Properly identify daylight’s saving time and apply it if needed (@Vaughano let me know if this works please)
– Properly set the last run time (was not applying timezones correctly, thanks @Zapp for pointing this out)
– Fix for the current time line in the program preview
– Fix for sending location information to the home page (thanks @kenbob)

I will continue to test this however attached here is the patch if you wish to try it. To apply put the patch in the same directory and run the following command:

patch < rpi.patch_.06.29.txt

Patch download: http://albahra.com/journal/wp-content/uploads/2013/06/rpi.patch_.06.29.txt

Update: I fixed the below mentioned problems by JBinkley and incorporated the fixes into the above patch.

[JBinkley]

Samer,

Thanks much for this!

I did encounter one small issue. The main web page broke because the Javascript loc value was not inside quotes.

This correction to line 361 seems to correct it.

        homepg += 'n'

Also, I notice both in the code that Dan provided and in some of what you have done, that we have some cases where time.time() is called both in an outer main loop and deeper. For instance, at the top of the main loop we have:

now = time.time()

and again in prog_match:

lt = time.localtime(time.time())

The differences are likely to be very small and I have not completely deciphered the logic, but that might on very rare occasions cause something unexpected. It might be better to either make the variable now a global and use that as the current time referent (or pass it as a variable). That seems to be what was done in the Arduino version. If I see any more hang issues after a couple of days, that’s an area I’ll look at more closely.

[Samer]

That’s a very good point! Ill be honest I have never written Python and learning as I go along.

I am not sure why the time is not a set variable either, I’ll change that and fix the location problem and update with a new patch. Sorry about the location problem, I just copy/pasted the suggested fix from the post without thinking.

Update: Fixed the problems you mentioned and updated the above patch and the attached file to reflect the mentioned changes! Hope this one works better 🙂

[Andrew]

I’ve been experiencing the hangs too. In my case it seems to be at the end of longer waterings like 30 minutes or 3 hours rather than shorter 3 minutes waterings. I’ll let you know if I still see a problem.

Also a very minor thing, but I have added a favicon to the code so I can distinguish the OSPi more easily amongst my tabs. I added the following to the urls

    '/favicon.ico', 'favicon',

'/apple-touch-icon-precomposed.png', 'appleicon',

and then this later in the script:

class favicon:

"""redirect to /static/favicon.ico"""

def GET(self):

raise web.seeother('/static/favicon.ico')

return



class appleicon:

"""redirect to /static//apple-touch-icon-precomposed.png"""

def GET(self):

raise web.seeother('/static/apple-touch-icon-precomposed.png')

return

I’ve personally used the water drop icon from http://www.favicon.cc/?action=icon&file_id=609025 which has a Creative Commons, no attribution license, but I haven’t created the apple icon yet.

[Andrew]

I forgot to mention that the program preview is correct for the waterings but it is off for which day it thinks it is. I believe it is a time zone issue that Ray corrected on the regular OpenSprinkler javascript a few months ago and was due to being a long way from GMT (GMT+10 in my case). If I set the url as gp?d=date+1 then it thinks that is today but it can’t place the red line properly.

[Samer]

@aradke I see the problem your talking about in the code and might write a fix for it soon. The problem is the time is handled a little different throughout the program and needs to be unified. This could easily be fixed by using JBinkley’s suggestion earlier of globalizing the current time. It might be a task better suited for Dan but if I can handle it I will take a look and see what I can do.

[Andrew]

I’ve been letting this roll around in the back of my mind all day and I think it probably makes most sense to use a global time value set to the equivalent of localtime() (or whatever the python version is). The timer never really needs to know it’s timezone since I very highly doubt that anyone is using one across timezones.

In the event someone is managing multiple timers that could be in different timezones I believe they probably are going to need to keep track of which timezone each timer is in anyway so as not to run into problems dealing with any local support staff that are likely in this scenario.

Since the underlying operating system is taking care of the system clock I doubt there is value in running on UTC time and adjusting for the timezone as there is on the OpenSprinkler that has to keep track of the RTC and NTP.

[PabloS]

salbahra wrote:

@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):

Looks Good. 😀 THANKS FOR ALL THE GREAT WORK!

[ITDawg]

+1 for the fix to the Program Preview current time line. Changing the devtime variable to “devmin=’+str(lt.tm_hour * 60 + lt.tm_min)…” corrected the issue for me as well.

Also, the favicon mod would be a very nice addition too.

Hope both of these find their way in the core distribution soon…

[Samer]

It turns out Dan has been posting updates on his own Github. This version does indeed fix all the problems and is properly dated June 26. The user @maddox discovered this earlier today, thanks!

Github: https://github.com/Dan-in-CA/opensprinkler/tree/master/OpenSprinkler%20Pi/software/demos/interval_program
Forum post: http://rayshobby.net/phpBB3/viewtopic.php?f=2&t=154&start=290#p1207

[Dan in CA]

Hi all,

I’ve been offline for a few days. Traveled to Arizona and got to observe some dry farming methods that use little or no irrigation at all. When we arrived in AZ the temperature was predicted to be 120 deg.F (48.9 deg. C) but it didn’t reach that and there were thunder showers.

I am looking through the posts from the last week or so and will try to fix any open bugs. I will also be working on adding the sequential option that is in version 1.8.3 of the OS firmware.

The next update will also include aradke’s suggestion for adding the faveicon. All that required was is to download the icon file and place it in the icons directory under OSPi/static/images then add the following line to the “home” class in ospi.py.

homepg += 'n'

The last update was supposed to get posted to Ray’s Github account. I am just learning to use Github and things should work better going forward.

Thanks to salbahra for all the help with bugs.

Dan

[Samer]

Awesome on the update! By the way I extracted Ray’s new logo from the PDF he provided and created a favicon using it available here: https://github.com/salbahra/OpenSprinkler-Controller/blob/master/img/favicon.ico?raw=true

[Ray]

Hi All,

I just re-updated the Jun 24 version of Dan’s interval_program. I thought I updated it correctly, but there may have been a glitch due to an earlier conflict. Anyways, hopefully the version currently on Rayshobby Github:
https://github.com/rayshobby/opensprinkler/tree/master/OpenSprinkler%20Pi/software/demos/interval_program
is the same as the version on Dan’s Github:
https://github.com/Dan-in-CA/opensprinkler/tree/master/OpenSprinkler%20Pi/software/demos/interval_program

-Ray

[JBinkley]

Dan – I just updated to your latest. Thanks for putting that together.

I am observing one interesting little bug on the program preview. I am in California and I noticed that with some of the modifications mentioned in this thread that I don’t see the red line on the program preview for the current day when it is rather late in the day. A little while ago (at 11:20 PM PT Monday), I noticed that the red line is showing up on the Tuesday page at 11:20 PM. (http://:8080/gp?d=9&m=7&y=2013) I also noticed that the page referred to itself as the “Program Preview of Today”. So, I think there might be some confusion on the time zones in the preview page.

Edit: Opps… I should have read back a few posts. I think this is exactly what aradke mentioned. By the way, my post earlier about a single time was not really related to time zones as someone later implied. I was really talking about the potential for an intermittent problems when, during the same pass through the main loop, the time reference might be different by a millisecond or two.

[Samer]

Dan,

I am using your latest 7-10-13 copy and having issues doing a run-once program. I see it appear in the queue then it just disappears. Not sure what is going on, is it just me?

Thanks!

[kenbob]

@salbahra wrote:

Dan,

I am using your latest 7-10-13 copy and having issues doing a run-once program. I see it appear in the queue then it just disappears. Not sure what is going on, is it just me?

Thanks!

I am also having the same issue. It looks like all the station count down at the same time, but only one station is running. When it is done, the Log of the last station shows some crazy time that it ran.

[attachment=1:ieerwj7u]Capture 1.JPG[/attachment:ieerwj7u]

[Dan in CA]

Hi,

I’m currently working on the Run once program code to add some missing master (station/valve/zone) functionality. I’ll look at this issue also.

Thanks for reporting it.

I must say that Ray has managed to cram a lot of features into a small amount of micro controller code. You don’t really appreciate it until you try to replicate it.

Dan

[Andrew]

Hi Dan,

I’ve updated to the 10/July/2013 code and the program preview is wrong for our timezone (GMT+10). It believes that the today is tomorrow for the red line and the header at the top says “Program Preview of Tue Jul 16 2013” which is correct but using the url for /gp?d=17 (ie tomorrow) gives “Program Preview of Today” and shows the red line on it. There was the same issue some time ago on the regular OpenSprinkler that Ray corrected in the javascript. Not a big problem to live with though.

But I do still have a concern with trying to deal with timezones and time calculations in the code. The OS already knows the timezone and calculates the localtime accordingly. It handles daylight savings where appropriate and changes when local governments change these. Trying to duplicate all of that in the python code is fraught with problems as we’ve seen. And if you happen to miss the configuration setting in the options screen, as I did between one of the updates recently, you get very weird results of some things running generally as you would expect but then somethings run on the wrong days if the timezone settings line up badly, etc.

Can you see any problems with changing all references to time.time() to time.localtime() and remove all the timezone calculations?

I notice code like this:

dse = int((time.time()-time.timezone)/86400) # days since epoch

which doesn’t take DST into account which should become more accurate too.

There may be some places where time.time() needs to be outputted to the web to maintain compatibility with the standard OpenSprinkler javascript but I haven’t looked at how it handles the times to be sure.

Andrew
P.S. I hope I haven’t sounded to rude here. I am extremely impressed with the work you have done.

[Zapp]

A-z and 0-9?

Is that all?

I’d kindly like to be able to use all the characters in the alphabet. Just now I got an snamnes.txt without any contents in it but trying to use some of the Swedish characters (åäöÅÄÖ) in the station names.

Just to verify I also got the same result when trying with the character é …

Can we please get this functionality in the code?

/Jonas…

[Zapp]

favicon.ico

I don’t know it it’s intentional or not but the favicon only shows up on the main page. The Stations and Programs page does not have it for sure.

/Jonas…

[Andrew]

The favicon will be because it has been added to the html of the first page and has been missed on the others.

Personally I’d prefer to use a redirect in to the static file whenever it is requested. A couple of reasons:

• It’s done once and works everywhere (avoiding this potentially).
• The returned html is smaller and faster. (not a big deal but does help people connecting over the Internet or a VPN)
• The favicon query is only processed and sent on the rarer occasions that the browser asks for it.
• The favicon is not requested by any of the new frontends being created.

None of this is a big deal, just optimisation. It applies to the apple-touch-icon-precomposed.png too if you want one of these to make a bookmark on an iPhone/iPad.

Dan may have some reasons against this approach though and I’m not a real Python programmer so take that into account with my approach. I do live and work around bandwidth constrained environments though where sometimes little things like this can make a difference.

If you want to have it everywhere either copy the favicon line from the html on the first page to each of the other html generation code or add the following to the urls (near the top of ospi.py):

    '/favicon.ico', 'favicon',

'/apple-touch-icon-precomposed.png', 'appleicon',

and then this to the bottom of the script:

class favicon:

"""redirect to /static/images/icons/favicon.ico"""

def GET(self):

raise web.seeother('/static/images/icons/favicon.ico')

return



class appleicon:

"""redirect to /static/images/icons/apple-touch-icon-precomposed.png"""

def GET(self):

raise web.seeother('/static/images/icons/apple-touch-icon-precomposed.png')

return

[djMax]

I believe this program to be unsafe as is. It has bugs which can activate a large number of valves and cause electrical problems, in theory including fire.

[Andrew]

@djMax wrote:

I believe this program to be unsafe as is. It has bugs which can activate a large number of valves and cause electrical problems, in theory including fire.

Hi djMax,

Could you elaborate on this. Where do you think the bugs are that could allow this?
Also Ray has done some great work on the electronics on both the standard OpenSprinkler and the OpenSprinkler Pi. Is there something on these that has been missed that would cause a fire if you did try to open too many valves at once?

Making a claim like that as a single comment without any further info will likely get a lot of people quite defensive too (myself included, but of course I want to know about it if you have found a problem).

[djMax]

I entered a run once program and saw multiple valves activate. And then the transformer blew.

[Author]

Posts