[Ovmsdev] Plugin Repository

Derek Caudwell d.caudwell at gmail.com
Wed Jul 15 05:04:58 HKT 2020


I had to have a few attempts to get he existing plugins working,  so a
simple repo and install system would be great.

May be worth considering the following features from the Kodi addon repo
system:
 - in the root folder there is a consistent name for initial script eg
plugin.js
 - lib folder for including other scripts (could have web folder for html
elements)
 - plugin folder tar/zipped for easy delivery and install

https://kodi.wiki/view/Add-on_structure

Cheers Derek

Date: Tue, 14 Jul 2020 13:45:55 +0200
> From: Michael Balzer <dexter at expeedo.de>
> To: ovmsdev at lists.openvehicles.com
> Subject: Re: [Ovmsdev] Plugin Repository
> Message-ID: <40cce917-3366-a6e5-1189-a28dc89578d3 at expeedo.de>
> Content-Type: text/plain; charset="utf-8"
>
> Mark,
>
> full ack, has been on my list as well. I'll handle the web UI side.
>
> I don't think we need to migrate/change the folder structure, we should
> be able to just add the meta data. I tried to define the structure to be
> usable as a public repository. Did I miss something?
>
> Btw, I used the naming "module" plugins instead of "script" plugins, as
> web plugins also consist mostly of scripts. I thought that would clear
> things for users, but I'm not sure now.
>
> Regarding the plugin structure and meta data, we should decide wether to
> split plugins into their elements or keep them bundled. You seem to opt
> for bundles ("web subdirectory"). I would second that, but we then need
> to take into account a plugin may consist of multiple module and/or web
> plugins (see Edimax plugin for an example). Normally it's just one
> module plugin, but we should not restrict the system in that way. So the
> JSON file should allow to define an array of plugin elements / options.
>
> Currently there's a version on each element, and but we could/should
> simplify this to a central overall version for the plugin.
>
> To automatically install plugins, the meta data also needs to define the
> types and default setups for web/frontend plugins.
>
> Draft: edimax.json:
>
> {
> ? name: "edimax",
> ? title: "Edimax: Smart Plug Control",
> ? description: "Smart Plug control for Edimax models SP-1101W, SP-2101W
> et al",
> ? group: "Home Automation",
> ? info: "https://docs.openvehicles.com/en/latest/plugin/edimax/README.html
> ",
> ? maintainer: "Michael Balzer <dexter at dexters-web.de>",
> ? version: "2.1",
> ? prerequisites: ["ovms>=3.2.010"],
> ? elements: [{
> ??? type: "script",
> ??? path: "edimax.js",
> ??? name: "edimax" // optional, defaults to plugin name
> ? },{
> ??? type: "webpage",
> ??? path: "edimax.htm",
> ??? page: "/usr/edimax",
> ??? label: "Edimax Smart Plug",
> ??? menu: "Config",
> ??? auth: "Cookie"
> ? },{
> ??? type: "webhook",
> ??? path: "edimax-status.htm",
> ??? page: "/status",
> ??? hook: "body.post"
> ? }]
> }
>
> A method to easily disable/enable installed plugins would also be nice,
> i.e. as subcommands "plugin disable" / "plugin enable".
>
> Regards,
> Michael
>
>
> Am 14.07.20 um 07:55 schrieb Mark Webb-Johnson:
> >
> > I feel that our plugin system offers a missed opportunity. By making
> > small extensions to available functionality, we can use this system to
> > do so much - and with a much lower complexity and barrier to entry
> > compared to C++ ESP IDF development.
> >
> > There are a couple of things I would like to now do:
> >
> >  1. Implement a mechanism for plugins to directly extend the console
> >     command language (other than the current ?script exec PLUGIN.fn?).
> >
> >  2. Implement a plugin repository, and command line tools for managing
> >     plugins. We simply need to have a store and directory of available
> >     plugins, a way of searching/listing those, and a uniform way to
> >     install/remove plugins. Once this is done, perhaps someone can
> >     handle the web UI side of this, and perhaps that can even be done
> >     as a plugin :-)
> >
> >
> > I?m already working on #1. Just an extension to the existing script
> > system to allow plugins to register commands, and to have the command
> > register/deregister done automatically on plugin load/unload.
> >
> > However, #2 is a little more tricky and I?m looking for feedback on
> > the design of this. My idea is:
> >
> >   * Store the plugins in a new
> >     github/openvehicles/Open-Vehicle-Monitoring-System-3/plugins
> >     folder. Eventually the /plugin folder will all be migrated to here.
> >
> >   * Each plugin has a unique name; the directory in /plugins.
> >
> >   * Within each plugin directory, there is a <name>.json file (JSON
> >     format) with defined tags to describe the plugin. If the plugin
> >     delivers a web extension, that is in the ?web? subdirectory. If
> >     the plugin delivered a script extension, that is in the ?script?
> >     directory. Documentation (in rst format) is in the ?docs'
> >     directory. The JSON file would need the following, at a minimum:
> >
> >       o Name: The plugin ID
> >       o Title: One line title
> >       o Group: Group for the plugin
> >       o Version: The version string of the plugin
> >       o Description: Longer textual description of the plugin
> >       o Prerequisites: Prerequisites to be checked
> >         (Each plugin installed provides name=version, the system
> >         provides system-level ones such as the version of firmware,
> >         and then the prerequisites is simple a list of
> >         <name><operator><version> as required)
> >
> >   * We can automatically build the documentation, and list, for all
> >     plugins for our docs.openvehicles.com
> >     <http://docs.openvehicles.com>?(in a similar way to how it is done
> >     for /plugin now).
> >
> >   * On a repository server, as part of a nightly build job, we can
> >     automatically build a single directory JSON file from the
> >     <name>,json descriptors. We can publish this, as well as a git
> >     export/checkout of the plugins, on a http download site.
> >
> >   * On the module, we can store a list of repository servers (allowing
> >     the user to add/remove as they require).
> >
> >   * Contributors/authors of plugins simply GitHub clone our
> >     repository, and issue pull requests as appropriate. They can also
> >     have their own private repository servers (just need to host the
> >     directory json file and associated code files) and add it to their
> >     modules.
> >
> >   * The ?plugin? command tree on the module will provide commands for:
> >
> >       o List installed repositories
> >       o Add a new repository
> >       o Remove a repository
> >       o List installed plugins
> >       o List/Search available plugins
> >       o Install a plugin
> >       o Remove a plugin
> >       o Update a plugin
> >
> >   * I would like to try to unify the web and script plugin systems a
> >     bit more closely. They are really two sides of the same coin (with
> >     some plugins providing both).
> >
> >
> > Does that make sense? Any suggestions/comments?
> >
> > Regards, Mark.
> >
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200714/87303d8f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 14 Jul 2020 20:11:41 +0200
> From: Michael Balzer <dexter at expeedo.de>
> To: ovmsdev at lists.openvehicles.com
> Subject: [Ovmsdev] PSRAM fix in esp-idf release v3.3
> Message-ID: <34a88261-2f99-478b-20d6-6bdedb769fcd at expeedo.de>
> Content-Type: text/plain; charset="utf-8"
>
> Mark,
>
> it seems the fix has finally arrived in the official release 3.3 branch:
>
> https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913
>
>
> https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bcaa1fc1b8
>
> Btw:
>
> > In the v3 silicon, the issue has been fixed, and the workaround is no
> > longer required.
> >
>
> I guess that means from some manufacturing point on we should provide
> two builds, one for the older hardware and one for the modules with v3
> chips, as the fix definitely has a performance impact.
>
> Regards,
> Michael
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200714/87809d0b/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> ------------------------------
>
> End of OvmsDev Digest, Vol 102, Issue 22
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200715/d3eab784/attachment.htm>


More information about the OvmsDev mailing list