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 notifications@github.com
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.