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