Python Interval Program V 2.0.2 now available

[Dan in CA]

This release includes:

1. Fixed reported bugs in the Home page irrigation timeline.
2. Fixed a bug that caused a momentary power pulse to stations during a cold boot.
3. Added some error checking to the Programs page template to try and eliminate the “server error”.

Even though I’ve been unable to replicate the “internal server error” problem some users reported, I added some error checking to the Programs page template that may help. This is based on the error messages from the Python program.

If you have received this error when trying to access the Programs page in the web interface (not the mobile app), Please let me know if this helps.

For instructions on upgrading your program installation, please visit the Wiki at:
http://rayshobby.net/mediawiki/index.php?title=Python_Interval_Program_for_OSPi#Updating_the_program

As a brief “behind the scenes” peek at developments for this program I would like to mention that in addition to fixing bugs I am also working on internationalizing the code for the new UI. This will provide users who would like to contribute to the project a tool for translating the UI into other languages.

I also plan to create some usable documentation for writing plugins. It is really quite easy to create a plugin but the process has not been well documented yet. There is also the need for a simple method of installing plugins that users would like to share.

The Wiki is starting to get a bit out of date and needs some work. Anyone interested in helping document the program is welcome to join in.

If development seems a bit slow it is due to time constraints. I’m already looking forward to the winter months when I’ll have more time for things like documentation.

Dan

[Andrew]

Thanks for the update.

Unfortunately for both of my OSPis the timeline for today now doesn’t show any waterings but it did in 2.0.1. I wonder if my timezone could be a problem (UTC+10)?
Also both 2.0.1 and 2.0.2 (I didn’t run 2.0.0) don’t show waterings any recurring waterings in the timelines after the first one except for ones from the log that have run.

Andrew

[Dan in CA]

Hmm…

Sometimes fixing one bug creates another.

Could you describe the settings for the programs that are not showing up? I will try to duplicate it an see what’s going on.

Regarding the time zone; be sure the timezone setting on the Pi itself is correct. Is the time shown on the home page correct?

Dan

[Andrew]

The timezone is set correctly in the OS and also in the options. There was a similar problem about two years ago with the original OpenSprinkler where the javascript didn’t cope with timezones significantly forward of UTC-5 from memory (Rob’s local timezone). I’ve pasted a copy of my programs below and my timezone is set to UTC+10.

For ‘today’, nothing shows even programs that have run and are in the log. For ‘prev day’ everything shows as expected, and for ‘next day’ all the non-recurring waterings display correctly and recurring waterings show the first watering only. I’ve attached the screen shots that should explain more clearly.

[attachment=2:3kggq1lo]today.png[/attachment:3kggq1lo]
[attachment=1:3kggq1lo]yesterday.png[/attachment:3kggq1lo]
[attachment=0:3kggq1lo]tomorrow.png[/attachment:3kggq1lo]

On a side note: can the options choice be removed and simply have ospi.py use the localtime from the system. Having it duplicated is a bit wasteful and then the options doesn’t automatically pickup daylight saving time, etc. Also if someone doesn’t have the underlying OS configured properly it can be masked by the time display in ospi.py

Thanks,
Andrew

Program 1: Every Weekday
Run: Lawn – front
Starting: 8:30 am for 0 mins 30 secs
Recurring every 8 hrs 0 mins until 6:00 pm

Program 2: Every Weekday
Run: Verandah baskets
Starting: 6:00 am for 1 mins
Recurring every 6 hrs 0 mins until 6:30 pm

Program 3: Every Weekday
Run: Tree fern
Starting: 6:00 am for 1 mins
Recurring every 6 hrs 0 mins until 6:30 pm

Program 4: Every 2 days, starting in 1 days.
Run: Front dripper line
Starting: 8:30 am for 60 mins

Program 5: Every 2 days, starting in 1 days.
Run: Lawn – verandah
Starting: 8:00 pm for 30 mins

[Dan in CA]

Thanks for the detailed feedback. That should give me what I need to find the problem.

Regarding the Timezone settings.
The Python program is now using the system time and tz setting from the Pi. The plan is to eliminate the Options setting but I am still finding places where it is used such as in the UI and I think possibly Samer’s mobile app.

Another problem is that anyone who uses Ray’s pre-configured image file still needs to do some system set up on the Pi to set the correct time zone and possibly expand the partition size of the SD card.

Dan

[Andrew]

Let me know if you need anything more or would like to test anything. One of the OSPis is spare for a few more days so I can break things on it without plants dying.

For the timezone, maybe the system timezone could be returned when queried by the mobile app, etc.
I am glad to hear the options setting is being fazed out, as a sysadmin it’s bugged me from the start as being a possible place of conflicting and poorer quality data… 😉

And lastly, maybe a bug report could be filed with the maintainers of raspi-config to have a record of it having been run and what has or has not been set would be very useful. Then you could query as to whether the timezone and locale have been set and if not show a set of instructions on how to fix it. The same would probably apply to other projects for appropriate settings like the camera, GPU memory split, etc.

[Dan in CA]

Andrew,

Looks like your program #1 caused the a hiccup in the simulator routine that generates the data for the timeline. The duration of < 1min (30sec.) was not expected.

I added a couple of Math.ceil() functions to round up to 1 min. increments and it seems to be working properly now.

You can get the update from GitHub. Let me know how it goes.

Dan

[Andrew]

Hi Dan,

That has fixed the preview for today and the recurring waterings but brought another rather unusual one in.

When first accessing the front page it jumps to tomorrows preview until you click on the ‘today’ or ‘prev day’ buttons.
Also tomorrow’s waterings show as empty and everything after tomorrow is shifted back a day. I.e. program 4 in my example is every 2 days, today (Monday), Wednesday, Friday, etc, but the next watering shows as on Thursday, Saturday, etc. I also just noticed that program 5 which will run tonight at 8pm (4pm here now) doesn’t show on today, but it is shifted in the future like program 4.

If any of that doesn’t make any sense let me know. I’m also happy to email you more screen shots, etc if that helps rather than posting lots more to the forum until it’s all sorted if you prefer.

Thanks,
Andrew

[Samer]

I noticed a small bug with v 2.0.2 in regard to the options page for the mobile app. This caused two issues: options cannot be saved (due to an opw check) and use rain sensor wasn’t being checked correctly. I sent two pull requests for these bugs.

Also, I am getting a lot of the pickeling errors all of a sudden (especially on v2.0.2) and can’t put my finger on it (posted exact error on Github issue). Any idea what’s causing this? The mobile app only loads the home page for OSPi (for me) about 20% of the time (huge failure rate).

Thanks!

[Dan in CA]

@ Andrew,

Your description should be enough to locate the problem, I’ll let you know by private message if I need anything else.
Thanks.

@ Samer,

I have seen the same error during routine testing. It happens pretty randomly but I will see if I can find the cause or at least handle the error. When I have seen it, It did not crash the program.

Dan

[Samer]

Dan, you are absolutely correct that the program doesn’t crash. However from the mobile app’s perspective it is crashing (since no real way to recover other than to keep trying the request until works).

Thanks for looking into it!

[Andrew]

Hi Dan,

Hold off on looking to deep for the last problem I reported with the preview code. I just checked my timers again today and it seems okay. It goes to today correctly on opening the front page and tomorrow shows correctly now.

Before I reported the bug with “tomorrow’s” page being empty I force reloaded my browser and even tried a different browser with the same bad results. So there may be a bug in there somewhere but if there is I’m betting it is only when looking at the 2.0.3 page after it’s been running with earlier versions and the programs I had that triggered the original bug.

Thanks,
Andrew

P.S. I might have a play with some CSS at some point to make the web pages display properly on iPhones and iPads correctly again without needing any apps. It is very pretty now on a big screen but overflows horribly even on an iPad. Should be easily fixed I think.

[Andrew]

Hi Dan,

Sorry to say I am still seeing the problem sometimes. Let me see if I can lock down what is causing it further and I’ll get back to you with the details. I’ll also send you a private message with a bit of extra CSS for improved rendering on small displays.

Andrew

[Andrew]

Hi Dan,

I believe the problem with the preview is time based. It appears to be fine until around 2pm localtime (UTC+10) after which it display the problem I’ve mentioned before of showing the date as tomorrow with no waterings. Clicking on today returns to today but all future waterings show as a day later than they really are (including ones later today).

As before, let me know if you need any further info and I can provide it by private message if it helps to reduce the chatter on the main forum.

Thanks,
Andrew

[Dan in CA]

Hi Andrew,

That sounds like the system is not using the correct timezone.
I am in the process of doing a side-by-side comparison of the Python code that actually runs the stations and the javaScript simulation code that creates the timeline’s preview display. I’ll look for tz problems.

Dan

[Author]

Posts