Is there any guide on how to publish a plugin? I have a couple and I can’t find any guidance on how to do it. Thanks.
I’ve put together a framework for creating basic plugins, but I never really published it and only pointed a couple of people to look at, so it’s been kind of stealth project of mine. I only recently put it on Github. I decided to build the Submasters plugin using the framework as an example and proof of concept.
Documentation is a big part of that project, as you can imagine. But I stalled that project when the eZLO announcement was made, not knowing if everything was going to change suddenly or what would happen. Now the roadmap seems more clear, and there is still time and value in finishing (even though it’s understood that big changes are likely coming nonetheless).
Would you be interested in collaborating to put the publishing section together? I could take an initial pass at writing it up, and you can edit/test and embellish?
sure, I could help. I already took a look at the code, since you posted some days ago as a suggestion to a user.
Anyway, I was referring to the steps necessary to publish it in the official store. I have more time in August, and I plan to re-write the OpenSprinkler plugin from scratch, plus publish my plugins for HTTP dimmers/lights/rgb ligths. I can’t find anywhere the procedure to access the plug-in store as a developer.
OK. I have a hastily-assembled first cut from my notes, here: https://github.com/toggledbits/PluginTools#releasing-your-plugin
It is basically here http://apps.mios.com/my-plugins.php, but it is really unnecessary overcomplicated. However publishing on an AltStore is relatively easy
See this wiki article. http://wiki.mios.com/index.php/Apps.mios_Developer's_Guide
The pre-requisite of creating an account could be satisfied with this (courtesy of support):
Patrick, were you able to get this plugin running on openLuup. I built a plugin with the framework that communicates with Home Assistant via the HA API. However, in order to get the plugin to run on OL, I had to hard path (with my actual device number) the PFB table values for each call in the lua file. Here’s an example:
D = function( msg, … ) luup.devices.environment.PFB.log( luup.devices.environment.PFB.LOGLEVEL.DEBUG1, msg, … ) end
L = function( msg, … ) luup.devices.environment.PFB.log( luup.devices.environment.PFB.LOGLEVEL.NOTICE, msg, … ) end
Everything works, it’s just the hard path means that the code won’t run outside of my particular environment. I’m using the latest development version of OL, with no other plugins loaded. I double checked the I_xml file and the function code is an exact match to the framework. Likewise, the topmost code in the Lua file is a match (in format) with only the variable values changed.
In the implementation file (I_.xml), find the line that begins
pluginSID = pluginModule.MYSID or ... and add after it:
pluginModule.PFB = PFB
The process of creating the Submasters plugin gave me a bunch of better ideas that I haven’t yet had time to get to. I didn’t expect anyone was using this framework yet. I’ll make this change in Github as well, and post some other updates, and let you know when it’s up, but this should get you rolling for now.
EDIT: For clarity, in all, it should look like this:
... pluginSID = pluginModule.MYSID or "urn:YOURDOMAIN-NAME:serviceId:PluginBasic1" pluginModule.PFB = PFB --[[ ===== D O N O T M O D I F Y A B O V E T H I S L I N E --]]
That worked! Awesome. i tried every which way to get this to run and that never occurred to me.
I’m able to follow 90% of the framework code, but I don’t understand why adding the PFB table to the pluginModule variable allows the plugin globals to be seen throughout the plugin… I see where you manually call the lua file as a module, and how the PFB table holds functions etc, but I’m at a loss as to why this new change works… it’s a couple of layers of abstraction that I don’t grok…as of yet.
On real Vera Luup, the implementation file’s code is in the same environment as that of the loaded Lua modules that the implementation loads (and which environment is used depends on how you load them, too). This does not appear to be true in openLuup. That change demonstrates how transparent these things can be to most plugins, as none of my prior plugins has ever needed any change to run directly in openLuup with respect to the environment it’s running in. But the framework is doing some special things.
What the PluginBasic framework is currently doing is expeditious, but is not a long-term solution, it was a starting point. It can do a much better job of encapsulation and carrying context, which I intend to complete. It’s just a matter of style (good style, actually) for single-instance plugins (for which PluginBasic is intended), but for any multi-instance or parent-child plugin, complete and correct encapsulation is really necessary. This also gives me the opportunity to minimize the amount of code in the implementation file, which is a pain in the Lua to deal with. That will also set the stage for better interoperability between versions.
So expect to see PluginMulti or something to that effect at some not-too-distant future date (Submasters is really a Multi, so I have changes made there to back-port). And also expect a second version of PluginBasic that will not be directly compatible with existing plugins written using the current PluginBasic, but will have a documented upgrade recipe so you can get there without too much pain. I may even give the new version a new name, like PluginSinglet, and just let PluginBasic stay as-is.
Ok I think I understand. You’re using the PFB table as a class, and then instantiating the encapsulated object with
pluginModule.PFB = PFB Lua is a bit opaque when it comes to seeing OOP structures.