Development Chat

[Rimco]

This issue should be used as main chat for active contributors. Let me know your ideas and what you want to do. First idea of teodoryantcheff was documented in https://github.com/Rimco/OSPy/wiki/API-idea. Old chat is in #22.

[Rimco]

About the new API. I know that the mobile app wants to support the arduino based version, but I don't want to let that stop us from improving the python version. The current port is largely based on the arduino code. Although this keeps stuff compatible, it is very non-Pythonic. I've already talked to @Dan-in-CA about this. Let me copy some parts of my conversation:

If I look at the program from a high level, I would expect something like the following:

• Some output class (such that it can be subclassed to support different hardware implementation). This class should provide a simple interface to set/get outputs. The software that calls these function shouldn't be bothered by the hardware differences.
• Some logger module that provides simple (standardized) logging facilities. This should take care of the underlying format for storage. Again, other parts of the software shouldn't be bothered by that. It might even support multiple log levels for debug logging and such. It should not be only for schedules but should support an arbitrary format as well.
• Schedules/programs should also be implemented in some more intelligent classes. These classes should then provide functions to change them and request the resulting schedule. Some "scheduler" class should then use all separate schedules to calculate a complete schedule. This also provides better ways to predict the schedule instead of brute-forcing over all know programs for a given period. This should also solve the "problem" that schedules are ignored if another one is still running instead of being queued. (I personally think this is a real problem.)
• By doing this re-factoring, the timing loop will be much simpler and the front end (app/webpage) should be able to just ask the scheduler what will be ran during a given period instead of calculating it again.

On the short term I think I will improve the output layer to make it more abstract and be able to use a "dummy" output that can be used during development. Currently all try catch constructions are a bit tricky. Next I want to have a look at the plug-in system. I'd like to be able to enable and disable plug-ins from the GUI and get rid of the executable bits. The executable bits now also influence the system update plugin because it has to ignore them to prevent conflicts.

[salbahra]

It is a very fair point and in the end, so long a plugin can expose the data in the method the app understands, things will work fine. So I agree, don't let the mobile app hold you back.

By the way, some of the issues you mentioned are addressed in firmware 2.1 for Arduino.

[martinpihrt]

hello,
a) I have a question it would be possible to add something like a watchdog for plugins. If for some reason the plugin crashes and shuts tried by the ospy him again after some time, run, or send an email about a fall or problem
b) happens to me quite often that after the update I set the time zone setting OSPy to -12 h and master station is turned off (other settings remain)
c) If you are upgrading ospy update using the plugin, I am redirected to the home, but for load changes must reboot the system to load changes
thanks

[teodoryantcheff]

Implementing what I've proposed in terms of API only makes sense if there
will be a client for this. So if you are not that interested in supporting
a new API, despite IMHO way better than the current one, there's not much
point in implementing it on the OSP[y|i] side.

Let's first see just how much traction my proposal gets with the community
:)

On Sat, Sep 20, 2014 at 8:01 PM, Martin Pihrt [email protected]
wrote:

hello,
a) I have a question it would be possible to add something like a watchdog
for plugins. If for some reason the plugin crashes and shuts tried by the
ospy him again after some time, run, or send an email about a fall or
problem
b) happens to me quite often that after the update I set the time zone
setting OSPy to -12 h and master station is turned off (other settings
remain)
c) If you are upgrading ospy update using the plugin, I am redirected to
the home, but for load changes must reboot the system to load changes
thanks

—
Reply to this email directly or view it on GitHub
#24 (comment).

[Rimco]

@martin:
a) This might be part of improving the plug-in system.
b) If this is a real bug that can be reproduced, you can make an issue for it:)
c) The latest System update plugin should do that for you. Although it only works if you use the OSPy service. Do you use that (service ospy start etc.)? Otherwise it might not do that for you. I could make it more robust for these kind of situations.

[martinpihrt]

I use a service ospy ... despite the fact I have to manually apply the settings tab reboot the system to load changes. I have a pure clone of https://github.com/Rimco/OSPy and update doing locally (or via sms and click update)

[Rimco]

That's weird, I also have a plain OSPy clone running and updating (using webpage) works fine. It starts updating, initiates a service ospy restart and lets the client wait for the page to come back. In less than 30 seconds I get a new plug-in page telling me the program is up-to-date. I've created a new branch in which I'll try to improve the overal structure (without impacting the api yet). I'll also include extra logging facilities to be able to debug these kind of problems more easily.

[teodoryantcheff]

@Rimco - re logging, I'd strongly support using this. As good as they get.
And another, architectural idea, we can have one logger per plugin and one "system logger".

[Rimco]

That's indeed what I would use and my architectural idea is the same. The system should provide some global logging facility that can also be used by plug-ins. This logging facility should also be able to return the entries per group such that plug-ins can use it as feedback for the user.

[teodoryantcheff]

@Rimco @salbahra : wiki page with API proposal updated. Added programs data format.

[salbahra]

@teodoryantcheff it's almost like you are using my read_program function as the bases 👍 But really thats exactly what my function does and having the firmware do it is obviously a huge help and lowers the barriers to future development. I love what this is shaping up to be. Also, as Dan mentioned, we should get Jonathan in on this conversation since it sounds like he has already started with the development of it.

[teodoryantcheff]

@salbahra - You javascript guys really amaze me! I do understand the language itself, DOM, CSS, HTML5 and all related stuff, but still the way you manage to make it all work together seems like dark-black magic to me. High-five to that !
And haven't looked into your code, actually the whole data structure in programs I "designed" just by looking at the edit program page in the native gui of ospy latest.

[salbahra]

@teodoryantcheff Well I am learning as I go but it's a lot of fun!

I figured, I was just kidding and only meant it abstracts away a lot of the complicated stuff so the UI can focus on it's purpose. The API is essentially only used by the mobile app now and I already have a good idea if you are willing to incorporate it into your proposed API.

Right now, I only support my own plugin in the mobile app. However, if the API allowed, I would be able to manage them in the app and also interact with them (using some sort of agreed format for page formatting). Since I am using jQuery mobile, you could pass a title string and a page content string?

[teodoryantcheff]

@salbahra then you'll like the newly added /plugins/ section :) Very, very raw still, and of course this whole project is a team effort, so whatever is on your mind I want to hear and discuss.

[teodoryantcheff]

@Rimco - regarding the scheduler - this seems interesting.

[Rimco]

Although that might seem a good starting point, all schedules seem to be independent. In our case, we need to be able to combine them intelligently and also predict when they will run. During my conversation with Dan, I also told him I already started implementing such a scheduler before I discovered a Python OSPi existed. Let me copy-paste what I told him:

I've also got some designs lying around and I started coding the basics of the back-end. It contained the scheduler similar to what I described earlier. I designed the program as follows:

First you have "Schedules". Schedules are defined by specifying the active periods. Schedules can optionally repeat after a certain period (1 day, 1 week, 2 weeks, anything). The scheduler can report the time intervals it want to be active given a date/time range. It can also calculate if it would be active at a given moment in time.
In a "Program", you can assign a schedule to each output. So multiple outputs can share the same schedule or they can be completely different. The system can have an arbitrary number of programs. (The current OSPy is a specific case of this in which all outputs use the same schedule.)
Finally, there is one main "Scheduler". This scheduler maintains a list of programs and it can calculate the combined schedule (taking (weather) adjustments and enabled programs into consideration). In addition, each output should have a "usage" property. This usage property (for sprinklers this could indicate pressure drop or flow) will be used by the scheduler to make sure it will never exceed a set "maximum usage". Thereby the user can enforce sequential programs, but it can also be more intelligent by enabling outputs with low usage at the same time. The scheduler tries to execute each schedule as soon as possible without "breaking the rules". Although finding an optimal schedule is a computational hard problem, it is not necessary to find the "optimal" schedule as long as it provides decent results that the user expects. (E.g. by swapping queued schedules you might be able to combine even more outputs and decrease the total running time.)

I have working implementations of these three parts lying around which I could just copy-paste in the current implementation. My main concern is that this would change the behavior significantly making it incompatible with the arduino implementation (for the mobile app).

[Rimco]

Hi guys,

Please let me know what you think of https://github.com/Rimco/OSPy/blob/refactor/options.py and https://github.com/Rimco/OSPy/blob/refactor/stations.py.

The options instance (from options import options) provides a simple way to get and set options. The predefined options are used for the core functionality. In addition, any object can be saved by giving it to the save function. A similar load function is also available. I think I'm also going to provide some "on change" callback mechanism to notify parts that are interested in a certain property.

You can also use the options instance to save any data persistently. The class makes sure that it will be available whenever the system is restarted. options.test123 = 5 will just work magically;)

Next, the stations implementation makes use of this to magically save station properties. These stations can be used as output instances directly. first_output = stations.get(0) ... first_output.activated = True will do everything for you to enable an output for example.

Let me know what you think, I'm currently trying to figure out which parts that need to be updated to let them work with these new constructions. That seems to be many.

[teodoryantcheff]

Re your first post and the scheduler - The idea that I have -- say we have a program P that states running valve 2 (station 2) for 2 hours starting 15:00 o'clock every day. So the implementation is :

• schedule a run operation for 15:00, probably also stating stations.
• at 15:00 the scheduler invokes a function that enables/starts the affected valves -- this is the on part. And then schedules an off program for 2 hours later.
• at 17:00, 2 hours later, the scheduler invokes, as previously set by the on part, a function that stops affected valves (calls the off part) and depending on what P is configured to be, sets the next on run.

You can see that this architecture is flexible enough to allow all current kinds of scheduling and some additional ones - seasonal schedules, every friday the 13th, "birthday" watering and so on :) . Also the "next" watering cycle is always known. And schedules visualization remains, just as now, an exercise for the UI. Which is where it belongs in my view.
In a way that is a view on schedule execution from the perspective of a linked list rather than the perspective of an array.
BTW, your view on scheduling as solving for minimal time and not exceeding a certain flow volume is very interesting. Especially the flow limit part. Thanks for sharing !

Finally, as long as the UI can get the same API from the controller, it does make no difference. What I was thinking about this is that the current API (current json API, urls, endpoints and so on) can be implemented as a "legacy" API on top of whatever new we decide to do in ospy.

Will be looking at the new goodies you put up for review shortly, as I have a kid on my hands that needs attention as well :)

[teodoryantcheff]

Ok, comments here since I couldn't find a way to comment code in-line.

options.py

• I'd make the init like

    def __init__(self):
        self._values = {}
        self._write_timer = None

        for info in self.OPTIONS:
            self._values[info["key"]] = info["default"]

        with open('./data/options.json', 'r') as options_file:  # A config file
            self._values.update(json.load(options_file))

• __getattr__ and __setattr__ -- since these only get called when the attribute is not found I think that all the conditionals there can be replaced by

def __getattr__(self, item):
    return self._values[item]

since all other case are implicitly taken care of already... i think.

• I'd extract the file name to file level or class level "constant"
• get_categories :

def get_categories(self):
    return sorted(list(set([o.get('category', '') for o in self.OPTIONS])))

• The Timer idea is el' genial !

stations.py

• I'd rename activated to simply active everywhere
• why do you replicate station status to BaseStations.self_state ?
• activate() and deactivate() to simpler on() and off() in BaseStations ?

[Rimco]

Your json loading seems nicer indeed, I've updated it.

The getattr should indeed only be called if it is not found, but the first self._values = {} seems to call it already. I tried to do what you say, but I found out that this way we are certain we can't get in any race condition. Furthermore, we prevent saving any internal variable by accident.

The setattr is always called, so that certainly needs this construction.

I don't know what you mean with "I'd extract the file name to file level or class level "constant"", please elaborate.

Your get_categories throws away the order and also makes a "" category. If an option has no category, it should not be displayed (automatically) on the options page. And the order specified in the options list should be returned as-is. I like one-liners, but this one seems not to achieve the goal I had in mind;)

I've renamed activated to active, but activate and deactivate seem more logical than on and off to me. I "activate" station 1, I don't "on" station 1. The BaseStation state is not a duplication, it's even the only place where the states are saved. The Station instances query the Stations "factory" what their state is. Why? Because a single station might not be responsible for the state handling. Furthermore, by delegating this question to the proper Stations instance, you could also let it query the real output state instead of some buffered state. At the moment I handle this in the BaseStations to keep the subclasses very simple, they only have to make sure that the self._state is used to set the outputs.

[teodoryantcheff]

Thanks :)
Re naming -- to put "./data/options.json" as a field or module "constant", but it's a minor thing.
setattr -- brainfart on my side....
Didn't know that order is of use, sorry for not asking first.
Thanks for the explanation of the design as well and ageed on on/off !

[Rimco]

I've made the filepath a constant:) The order was something I didn't think about either in the first place, no problem;)

@salbahra Do you mean to push OSPy to OSPi or to push the refactor branch to master?

[salbahra]

I actually deleted the comment since its technically not development topic but to OSPi since that's the repo people are using.

[Rimco]

General ideas are also welcome here;) We should check if the OSPi branch has some functionality we need to port. I think Dan kept it fairly in sync. If possible, we might ask Dan to update OSPi with our contents. Currently he is referring developers to this version.

[teodoryantcheff]

Speaking of users -- any idea how big is the userbase of OSPi/y and the arduino variant ?
Also what are you guys watering with ospy/i ? I personally have a lawn (3 sets of sprinklers), some vegetables, some thuia trees and some flowers. Overall ~10 "stations" in ospi lingo.

[teodoryantcheff]

Oh, and @Rimco 's changes are quite significant and affecting all of the source. I'd be doing logging otherwise or new API. Now I will have to wait :)

[Rimco]

That's why I'm making my changes in a separate branch. You can use the master branch to make your changes;) Although I may change a lot of things, I'm trying to make it as simple as possible. In the end I could get your parts from master and make them work in the refactor branch.

[martinpihrt]

Hello everyone,
I have a problem with the shift outputs in ospy refactor.
a) if I upload ospy from git (Rimco - master not refactor) everything works - outputs (shift register) ok. if program set station to on - station is set to on. all is ok.
b) if I upload ospy from git (Rimco - refactor) not function any output from shift register

No function any output from shift register. In debug is print:
2014-12-08 12:42:54,650 [START Run] Program 0 - Station 1: From 2014-12-08 12:42:54 to 2014-12-08 12:50:00
2014-12-08 12:42:54,654 [START Run] Program 0 - Station 2: From 2014-12-08 12:42:54 to 2014-12-08 12:50:00
2014-12-08 12:50:01,146 [FINISH Run] Program 0 - Station 1: From 2014-12-08 12:42:54 to 2014-12-08 12:50:01
2014-12-08 12:50:01,150 [DEBUG Event] stations.py:185: Deactivated output 1
2014-12-08 12:50:01,157 [FINISH Run] Program 0 - Station 2: From 2014-12-08 12:42:54 to 2014-12-08 12:50:01
2014-12-08 12:50:01,160 [DEBUG Event] stations.py:185: Deactivated output 2

in debug is all ok, but shift register not function. I have a raspberry pi.
Is it a mistake? or to other boys OSPy works with shift register?

LCD plugin is really now OK, thanks Rimco

[Rimco]

Seems to be an issue, I think it didn't recognize the RPi properly. Please
create an issue on github such that I won't forget to look at it;)

[Rimco]

Finally found some time to look at the issues...

Done:
Fixed all reported issues.
System info plug-in: Cleaned-up, working, ready.

TODO:
Mobile app plug-in: Martin started, but I'm not sure if we'll be ever able to be compatible with the current mobile app. We are now at a point where we have much more functionality and in a completely different format. We might need to consider dropping its support for now.
Pressure sensor plug-in: Martin started, needs some more clean-up (to make it platform independent).
SMS plug-in: Martin started, needs some more clean-up.
UPS plug-in: Martin started, needs some more clean-up.
Weather based rain delay plug-in: Martin started, needs some more clean-up.

In addition, I'd like to have some opinions on the plug-ins. I see we are getting a many plug-ins, which is nice. But, I also see a lot of plug-ins that are completely unrelated to the irrigation system. In addition, many require hardware that is very rare. For example:

SSH client: Has nothing to do with OSPy, Webmin could also provide this.
UPS plug-in: Same holds for this one.
A/D plug-in: Could be used to get temperature readings, but other than that I'm unsure.
Webcam: Might be used to look at the irrigation, but is completely useless for OSPy itself.

I can understand that the current plug-in system is very nice and easy to develop code, but I don't think OSpy is the proper location. Should we keep these plug-ins in the repository under the assumption that others won't enable them anyway, or should we consider (re)moving them? Please let me know what you guys think.

[teodoryantcheff]

My 2 cents :

• plugins that are not core should be moved.. e.g. to a separate repo or shipped in the code but not enabled by default
• same thinking as you about the mobile app integration -- as long as the systems remain incompatible, support for the current mobile app should be dropped. Hopefully some day @salbahra will decide to include support for what ospy has to offer :)

Other than that -- great work, all !

[salbahra]

Just to chime in regarding the mobile app, I would be open to adding support for OSPy fork of OSPi as long as it's being used (by request). Right now, it's too much time to spend on something that's still in an early stage.

I absolutely agree though this looks awesome and love the improvements!

[martinpihrt]

Hi, all
SSH client is currently non-functional and can be removed. Yes web cam is used to check irrigation from SMS plugin (send email with photo attachment). I have an Internet connection via a mobile Vodafone LTE. My provider does not allow me a public IP (DynDNS also does not work) because I wanted to have a plugin for SSH connections of raspberry 1 to raspberry 2 (which is the public IP in my home ...)

AD plug used for measuring the temperature in the greenhouse:-)

a) please remove plugins for the move to a temporary folder:
SSH, mobile.

b) I think that plugins do not take up much space and should be delivered in a whole folder OSPy. It is up to the user whether the plugin in settings starts, or let him off.

Yes plugins installation support would also be appropriate (in the future it would be easier for the average user to install a plugin to add to OSPy - installation in the folder plugins and plugins template).

Also, I think it would be appropriate to introduce some help (all plugins) as well as connect hw and how they work.

Thank you all for a great job, I'm excited for the system to "refactor" to start in the spring watering my gardens. MP

[martinpihrt]

PS: Je jednodušší spravovat všechny funkce z jednoho místa v rámci integrace (pluginů sms, e-mail, webové kamery plugin plugin, pluginy tlak, Vodní plugin ....
než běží někde v Linuxu na přistýlce webových stránkách ....

Dívám se na OSPy jako malý operační systém:-)
MP

[martinpihrt]

sorry:
PS: It is easier to manage all functions from one location within the integration (plugin sms, email plugin, webcam plugin, plugin pressure, watter plugin ....
than running somewhere in Linux on extra website ....

I look at OSPy as a small operating system:-)
MP

[martinpihrt]

997f3ca
latest commit
TODO:
Arrange plug-in installation (from zip file?).
for me yes
Add support for plug-ins that want to install packages (properly).
for me yes
Support ospy.service file in setup.py?
for me yes
Thank you for new version...
Martin

[Rimco]

Hi Martin, could you tell me what kind of operating system you are running?
For mine (Raspbian), the ospy.sh works fine. I've read some operating systems use the new style .service file, but I'd need to detect this somehow.

[martinpihrt]

Hi,
a) I have raspberry Pi b (512mb) clear installation (Raspbian os) update and upgrade.
b) I clone from: git clone -b refactor https://github.com/Rimco/OSPy
c) open home/pi/OSPy and type: python setup.py install
and first error is web

[Rimco]

That should be fixed now, see #60. My question was regarding:

"Support ospy.service file in setup.py?
for me yes"

Did you use the ospy.service file yet?

[martinpihrt]

Hi, I run installation now and find error
gfm not available, do you want to install it? [y/yes/n/no]
y
Cloning into 'tmp'...
remote: Counting objects: 128, done.
remote: Total 128 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (128/128), 23.17 KiB, done.
Resolving deltas: 100% (64/64), done.
Traceback (most recent call last):
File "setup.py", line 1, in
from setuptools import setup, find_packages
ImportError: No module named setuptools
Failed to use git: Command '['/usr/bin/python', 'setup.py', 'install']' returned non-zero exit status 1
Traceback (most recent call last):
File "setup.py", line 1, in
from setuptools import setup, find_packages
ImportError: No module named setuptools
Failed to use zip file: Command '['/usr/bin/python', 'setup.py', 'install']' returned non-zero exit status 1
Failed to install gfm.

and error2
Do you want to install OSPy as a service? [y/yes/n/no]
y
update-rc.d: using dependency based boot sequencing
insserv: script ospy: service ospy already provided!
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
Traceback (most recent call last):
File "setup.py", line 185, in
install_service()
File "setup.py", line 104, in install_service
subprocess.check_call(['update-rc.d', 'ospy', 'defaults'])
File "/usr/lib/python2.7/subprocess.py", line 511, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['update-rc.d', 'ospy', 'defaults']' returned non-zero exit status 1
root@opensprinkler:/home/pi/OSPy#

[martinpihrt]

I run ospy python run.py (without service error) and in options select lcd and update plugin....
root@opensprinkler:/home/pi/OSPy# python run.py
Started the System Update plug-in.
Started the LCD Display plug-in.
LCD display plug-in:
Traceback (most recent call last):
File "/home/pi/OSPy/plugins/lcd_display/init.py", line 76, in run
update_lcd(line1, line2)
File "/home/pi/OSPy/plugins/lcd_display/init.py", line 225, in update_lcd
import pylcd2 # Library for LCD 16x2 PCF8574
ImportError: No module named pylcd2

result: update plugin in web not found
lcd plugin error import pylcd2

2015-02-19 05:05:45,924 [INFO Event] init.py:200: Failed to load the pressure_monitor plug-in:
Traceback (most recent call last):
File "/home/pi/OSPy/plugins/init.py", line 188, in start_enabled_plugins
plugin = getattr(import(import_name), module)
File "/home/pi/OSPy/plugins/pressure_monitor/init.py", line 20, in
from email_notifications import email

2015-02-19 05:06:59,173 [INFO Event] init.py:200: Failed to load the ups_adj plug-in:
Traceback (most recent call last):
File "/home/pi/OSPy/plugins/init.py", line 188, in start_enabled_plugins
plugin = getattr(import(import_name), module)
File "/home/pi/OSPy/plugins/ups_adj/init.py", line 12, in
from email_notifications import email
ImportError: No module named email_notifications

ImportError: No module named email_notifications

When I press plugin in menu do not see any page for plugin:

and test run
root@opensprinkler:/home/pi/OSPy# /etc/init.d/ospy.sh start
root@opensprinkler:/home/pi/OSPy# start-stop-daemon: unable to chdir() to {{OSPY_DIR}} (No such file or directory)

[Rimco]

I tried to fix all your issues, please let me know if it works:)

[martinpihrt]

Hi,
all ok. Only:
Do you want to install OSPy as a service? [y/yes/n/no]
y
Removing (old) service first:
start-stop-daemon: warning: failed to kill 6417: No such process
Killed

root@opensprinkler:/home/pi/OSPy#

I delete old ospy.sh in etc and check installation...
root@opensprinkler:/home/pi/OSPy# python setup.py install
Checking web
web is available
Checking gfm
gfm is available
Checking pygments
pygments is available
Do you want to install OSPy as a service? [y/yes/n/no]
y
Removing (old) service first:
OSPy was not running.
update-rc.d: using dependency based boot sequencing
Service not found
update-rc.d: using dependency based boot sequencing
Done installing service.
You are still using the default password, you should change it! Do you want to change it now? [y/yes/n/no]
n
Do you want to start OSPy now? [y/yes/n/no]
y
Done
root@opensprinkler:/home/pi/OSPy#

Error is in Removing (old) service first:

Web page on the web for plugin is not function...
root@opensprinkler:/home/pi/OSPy# python run.py
2015-02-20 06:09:07,117 [INFO Event] init.py:192: Started the Email Notifications plug-in.
2015-02-20 06:09:07,137 [DEBUG Event] server.py:44: 192.168.4.12:56385 "HTTP/1.1 POST /options" - 303 See Other
2015-02-20 06:09:10,396 [DEBUG Event] server.py:44: 192.168.4.12:56385 "HTTP/1.1 GET /" - 200 OK
2015-02-20 06:09:10,653 [DEBUG Event] server.py:44: 192.168.4.12:56406 "HTTP/1.1 GET /status.json" - 200 OK
2015-02-20 06:09:10,661 [DEBUG Event] server.py:44: 192.168.4.12:56385 "HTTP/1.1 GET /log.json" - 200 OK
2015-02-20 06:09:10,788 [DEBUG Event] server.py:44: 192.168.4.12:56385 "HTTP/1.1 GET /log.json" - 200 OK
2015-02-20 06:09:16,769 [DEBUG Event] server.py:44: 192.168.4.12:56385 "HTTP/1.1 GET /plugins/email_notifications/settings" - 303 See Other
2015-02-20 06:09:19,961 [DEBUG Event] server.py:44: 192.168.4.12:56385 "HTTP/1.1 GET /" - 200 OK
2015-02-20 06:09:20,427 [DEBUG Event] server.py:44: 192.168.4.12:56406 "HTTP/1.1 GET /status.json" - 200 OK
2015-02-20 06:09:20,449 [DEBUG Event] server.py:44: 192.168.4.12:56385 "HTTP/1.1 GET /log.json" - 200 OK
2015-02-20 06:09:20,564 [DEBUG Event] server.py:44: 192.168.4.12:56385 "HTTP/1.1 GET /log.json" - 200 OK

If click on email plugin page redirects to home page
Martin

[Rimco]

Just wanted to update you guys on the current developments:
I'm cleaning-up all templates to put as much code as possible in the static files. This will reduce the amount of data that needs to be processed by the template renderer. At the same time I found the root-cause of the slow loading times. Templates are cached by web.py, but in our case we were creating a new render instance for every request. This would circumvent the caching completely.
I've solved this problem and in combination with the reduced size of the templates, the average loading time has been reduced to 100ms or an actual RPi system:)

[martinpihrt]

Thank you, I reported my errors. I do not mean any harm :-)

[Rimco]

I don't mind reported errors, they are my fault anyway;) Issue #72 should be fixed, can you confirm?

[teodoryantcheff]

@Rimco - well, damn ! I should have paid proper attention and found this :) Not just leave for "later" investigation.... Stupid me.
Anyway -- thumbs up times a hundred for the amazing work !!!
@martinpihrt - Many thumbs up to you too, buddy !

[martinpihrt]

@Rimco - Please add support for i2c tools and SMBus to the installer? (python-SMBus, i2c-tools)
and if checked i2c in instalator proccess add:
etc/modules (i2c-bcm2708, i2c-dev)
/etc/modprobe.d/raspi-blacklist.conf (#blacklist spi-bcm2708, #blacklist i2c-bcm2708)
Thanky you
Martin

[martinpihrt]

Hi Rimco,
a) I thought we could in to OSPy also embed the ability to export settings and in another OSPy import settings? (export / import) and for setting plugins.
b) Please watching and fix isue deleting the settings to the default settings after power on power supply for all plugins?
Thank you Martin

[Rimco]

Hi all,

Plug-ins have now been moved to external repositories. I will only maintain the core plug-ins located at https://github.com/Rimco/OSPy-plugins-core.

Please have a look at https://github.com/Rimco/OSPy-plugins-temp for the plug-ins that I don't consider to be a core part. If you "own" one of these plug-ins, move them to a repository of your own and submit a pull-request to add your repository to the list of repositories (in plugins/init.py).

@martinpihrt I'll try to have a look at some way to let a plug-in specify what it needs in some way. Problem is that the installation of packages might need user input, so I think it should not happen silently.
Exporting settings is not a priority for me right now, but it should be possible. In any case, the options.db file contains all settings, including the plug-in settings. If you back-up that file, you are fine:) If you want something special, please submit a feature request. I cannot keep track of requests in this thread and might forget about them...

Rimco

[martinpihrt]

Hi Rimco,
thank you for the great plugin manager.
Bug with saving settings plugins is really ok (right here tried with one plugin, tomorrow I'll try all plugins).
Export settings would ask user friendly in tab "options" such as export and import button "File options.db" - I have more sprinklers and me this job easier (for web and from web no ssh connection.)
Yes in the plugins in order to give the opportunity to install a package missing
Thank you
Martin

[martinpihrt]

Hi Rimco,
It would still be resolved in some way to update information about the plugins. Plugin that was published a new version (or update). In OSPy it does not figure out only on git hub according to date and it is not my good way to maintain the current version of the user. Or in to plugins manager plugins that update the plugin (button OPEN, DELETE and UPDATE new?)
Thank you Martin

[Rimco]

Hi, I'm planning to extend the update manager to contain this information, but I wanted to start with a basic version. I already implemented this a while ago and wanted to push at least something. I think it is possible to extend the plug-in manager to show this information and to (automatically) update. Rimco

[martinpihrt]

Ok,
great, I am not noticed that you have already started working on it
thank you
Martin

[Rimco]

I did not push it until I was finished;)

[martinpihrt]

I understand, thank you
PS: all plugins work (so far I have not found error) SMS plugin does not work, but I'm not sure I have all the modules in the system (gammu, etc ...) I have to look at it.
thank you
Martin

[martinpihrt]

Hi Rimco,
it is possible to connect in some way?
Thank you in advance
[email protected]