[Dan in CA]

Thanks.

I’ll check it out. That should be an easy one to fix.

Dan

[Dan in CA]

Hi rkovvur ,

What you are referring to as the “main valve” is know as the master valve in OpenSprinkler terminology.

You can hook up the master valve to any of the first 8 stations on the OS. Then go into options and select that station as the master.

You will also need to go to the Stations page. When a master has been selected, you will see a column of check boxes next to each station for activating the master.

On the options page you can also set an optional delay for the master.

Dan

[Dan in CA]

Archades,

Sorry to hear about the problems you are having.

One thing you can do to get more information about the problem is to start the program manually from the OSPi directory.
From the Pi home directory, issue the command to stop the program:

sudo /etc/init.d/ospi stop

Then cd to the OSPi directory and run the program with:

sudo python ospi.py

When the program is run this way it will show you more information about what is happening. If you see some error messages, post them here and we will try to figure out how to solve the problem.

Dan

[Dan in CA]

Hi inahas,

Is the problem occurring when your are using the mobile app or the native UI or both?
I have tested with the native UI and don’t see what you describe. The code for manual mode in the main program has not changed in quite a while and as far as I know there have not been any problems.

Dan

[Dan in CA]

@ atatistcheff,

Thanks for your bug repports.

I will be working on fixing things this weekend.

@ virtus,

Great news that you have the garage door plugin working!
I knew the question about adding buttons to existing pages from plugins would come up. I think there should be a way to do it but I don’t have a good answer yet.

EDIT: Got an idea.
We could add a “plugins” button to the home page (or all pages) that opens a drop down menu that could be populated from a global dictionary with links to any number of plugin pages.

What do you think?

Dan

[Dan in CA]

A new version of the program has just been posted to GitHub. The green pages with the tabbed interface are now the default.

A “git pull” will cause problems if you try to update from the version you have now. See the announcement for the new version for details and instructions.
viewtopic.php?f=28&t=686

Let us know how it goes.

Dan

[Dan in CA]

alfiomantineo,

I have been able to replicate the bug you reported. I will post here as soon as I am able to fix it.

For now, setting the correct time zone on the options page and on the raspi seems to eliminate the problem.

Dan

[Dan in CA]

The code update was about May 15.

Also, be sure the Raspi has the correct time zone setting. The software now uses the Raspi’s local time and not the time zone setting on the program’s Options page.

I will keep checking on this end also.

Dan

[Dan in CA]

alfiomantineo,

I have been trying to replicate what you describe but so far it has been working correctly. There were some resent changes to the code that calculates the days remaining.

Try updating the program as described on the wiki:
http://rayshobby.net/mediawiki/index.php?title=Python_Interval_Program_for_OSPi#Updating_the_program

and let me know if you still see the problem.

Dan

[Dan in CA]

You will find some useful information in the following post:
viewtopic.php?f=28&t=242

Dan

[Dan in CA]

Hi Martin,

I was going to suggest that if you are running the newest version of ospi.py you could put your code into a plugin as a separate file in the plugins directory. It looks like you already figured out how to make it work.

Great job!

Your English is good. No need to apologize.

Dan

[Dan in CA]

Craig,

The most likely file that could be corrupted is sd.json in the data directory. It holds the actual settings for the program. Try renaming it, the program will make a new one when you reboot the Pi but it will revert to all default settings.

The file options.txt in the same directory holds the labels and tool tips for the options. It should be updated during a git pull. I tried renaming this file on my system but didn’t get what you describe.

Dan

[Dan in CA]

Yup. I forgot about that.

I guess the answer is that it is best to make a separate options page for your plugin. That will also help avoid conflicts as more plugins are developed.

Dan

[Dan in CA]

OK. I deleted the OSPi directory and re-cloned. Now it works fine.

Looking really good, especially for such a short development time using what had been an undocumented plugin system.

I like the fact you included drip systems. My entire place is on drip, no lawn, no “sprinklers”.

Your change to the log output can stay. I will add it to my dev. version.

Dan

[Dan in CA]

Hmm..

Pulled the update, still getting the same error.

Dan

[Dan in CA]

The home page loads fine but when I try */auto there is a server error in the browser and on the command line:

File “templates/auto_program.html”, line 125, in __template__
KeyError: ‘simulate’

Can’t wait to see what you’ve done.

Dan

[Dan in CA]

Lamby,

If your plugin is something you would like to share with the community, I would suggest keeping it as self contained as possible and not modifying the existing UI. However there is already an unused location field on the option page that could hold lat-lon data (gv.sd).

It sounds like you are planning to calculate sunset time from geographic location rather require a light sensor. That would be really cool.

Dan

[Dan in CA]

There was a glitch with the plugin that is required for the app to run. 😳
you can fix it by either doing another git pull or from your pi directory:

chmod +x ./OSPi/plugins/mobile_app.py

Dan

[Dan in CA]

All of gv is not yet documented but a good part if it, the gv.sd (settings dictionary), is described in the file sd_refertnce.txt in the OSPi directory.

Also, if you look in ospi.py starting at line ~378. The Global vars section is where the all the gv (global vars) attributes are defined. There are some comments describing what they are.

I am planning to add the rest of the gv info to the sd_reference.txt file and probably rename it to gv_reference.txt. I’ll post here when it is ready.

EDIT: Forgot to answer your question about the 32 program limit. That was the case on the micro-controller version of OpenSprinkler. I left the JavaScript files that produce the UI pretty much as they were. So, short answer: disregard the 32 program limit.

EDIT: Here are the rest of the gv attributes:
gv.ver firmware rev number (int, based on firmware version this program was ported from)
gv.rev release number of this program (int)
gv.revdate date of release (string)
gv.now current time, updated once per second at top of timing loop
gv.srvals shift register values, used to turn zones on or off (list of one byte per station, 1 = turn on, 0 = turn off)
gv.rovals run once values – list of duration times in seconds for a run once program (list, length = number of statons)
gv.pd program data – loaded from file at startup (list of lists)
gv.ps program schedule used for UI display (list of 2 element lists i.e. [program number, duration])
gv.pon program on (Holds program number of currently running program)
gv.sbits station bits, used to display stations that are on in UI (list of bytes, one byte per board)
gv.rs run schedule (list [scheduled start time, scheduled stop time, duration, program index])
gv.lrun last run, used to display log line on home page (list [station index, program number, duration, end time])
gv.scount station count (not used — dead code ????)
gv.snames station names, loaded from ‘snames.txt’ file (string)

Dan

[Dan in CA]

Dave,

You should be able to just do a “git pull”. It will not change any of your programs or other settings.
If you want to be extra cautious you can copy the contents of the data directory to another location outside of /OSPi to preserve your current settings in case the unthinkable happens.

Dan

[Dan in CA]

Scottsh,

Creating a program for each zone using the existing UI and then modifying the durations for each program on a daily basis would be a good approach

The program data is held in memory as the list of lists gv.pd (program data) and as the file programs.json in the data directory.
The format was ported from Ray’s micro controller code where every bit had to count because of limited memory.

Here is a breakdown of program data that I took straight from Ray’s C code with added notes:
pd[0]=[
v[0] = 1, //Program enable flag (byte/boolean)
v[1] = 1, //days byte (includes a flag for odd – even restriction) Mon. = 1, high bit: 0 = no restriction and no interval, 1 = odd/even parity or interval enabled.
//When used for interval: high bit = interval on, rest of byte used for days countdown set as “starting in” = days remaining in cycle.
v[2] = 0, //Interval days: if 2 -> 255 = interval enabled (most sig bit set), — if value is 1 (least sig bit set) = odd restriction, if value is 0 = even restriction. This field shows 3 by default in the UI when no interval is selected.
v[3] = 360, //Start time in minutes (from 0 at midnight)
v[4] = 1080, //End time in minutes (from 0 at midnight)
v[5] = 240, //Repeat (cycle) interval in minutes
v[6] = 900, //Duration in seconds for each active zone in this program
v[7] = 1]; //Zones bytes – indicates which zones are active (selected) in this program).

As you can see the duration (in seconds) for a program is stored in element 6 of the program data list. You should be able to modify the duration of any existing program from your plugin.

Here is an example of a program from Python’s gv.pd list:
1, 21, 0, 360, 1080, 240, 900, 21

And the corrisponding program creation page:
[attachment=0:3qj05420]Prog page.jpg[/attachment:3qj05420]

EDIT: Here is a web site I found extremely useful for visualizing bit patterns and figuring out what the values in the program data represent
http://calc.50x.eu/

Their Timestamp page is also very helpful
http://unixtimestamp.50x.eu/

This whole project has been a huge learning experience for me. I think you will gain some valuable knowledge from developing your plugin

Dan

[Dan in CA]

Sounds like you’re planning ahead. That’s always a good thing.

If memory won’t be a problem, keeping the data in a list or something would probably be good. Database programs tend to write to disk a lot and this can be hard on the SD card unless the data is stored somewhere else.

I have a couple more thoughts. Of course its your plugin so feel free to ignore my suggestions.

1. OpenSprinkler is used all over the world but here in the U.S. we are still using imperial measurements. Calculations are easier with SI (metric) units and most of the weather data sources I have seen offer both SI and imperial units. You might consider using SI units internally in your program and offer the user the option of using imperial units in the UI. I think you would only need to convert inches -> mm, Gallons -> liters and possibly sq ft -> sq m.

2. What ever source of weather data you decide to use it might be a good idea to keep the data acquisition code in a separate (importable?) module. That way you or someone else can add support for other data sources as needed.

Dan

[Dan in CA]

scottsh,

I have tired to keep things a simple as possible. That’s why data is stored in json/text files rather that a db. If you only need 7 days of data, a db might be overkill.
That said, the number of records that will cover 7 days depends on the number of schedule programs, if zones run several intervals in a day and the number of active zones. Keeping things in json files makes it easy to load data into Python lists and dictionaries.

Of course it depends on the requirements of your plugin.

EDIT: One thing to keep in mind is how easy it will be for users to install and setup your plugin. That is one of the reasons I stayed away from using a DB.

Just as a matter of interest; I have some fruit trees that get watered once every 14 days. There may be other cases where schedules span more that 7 days.

I think the current log is probably not in the most efficient format. If you would find it useful to have the records hold different data or in a different order or something it is certainly possible to reconfigure it.

Dan

[Dan in CA]

@scottsh,
I misread your post about commas in station names.
The reason for storing the log data in a csv file is to allow for easy download and import into a spreadsheet for analysis and long term record keeping as documented on the wiki.
http://rayshobby.net/mediawiki/index.php?title=Python_Interval_Program_for_OSPi#Archiving_log_data:

@mstormo,
I didn’t intend to imply that the bug you found was obscure, only that even obscure bugs are worth fixing.

Regarding the matter of hiding unused zones in the UI, I think that is definitely a useful feature. In fact Johathan Marsh already implemented it in an early version of his improved UI.
[attachment=0:m1xyl1gb]Zone-connected.jpg[/attachment:m1xyl1gb]

However I don’t see in his latest rev which is now in beta as described in this post:
viewtopic.php?f=28&t=499

I’m a little hesitant to make any major changes to the current UI until we see how his UI develops. That’s why I have been concentrating on the plugin system and bug fixes in the core program.

Dan

[Dan in CA]

I am thinking about changing the snames.txt file to json format. That should allow more free form names.

It’s just a matter of having the time.

Dan

[Author]

Posts