@Leonardo_Soto Thanks for your follow-up on this issue.
I work with RichK and am temporarily picking up this issue. I did not reproduce the problem Rich reported. For the time being, much as we’d like to see the issues below addressed, they are not our priority. I’ll poke you on one or two other issues, which are. We’ll re-raise this one if Rich reduplicates the problem.
I’ve succeeded now in remotely deploying a repaired version of the example Wake-on-Lan plugin, and in deploying and running our own plugin. We’ll have to see whether in some other context Rich’s issue remains; for now we can move on.
I ran into a fair number of barriers in getting this to work. I document them here in the hope that you will be able to drive some improvement in your systems.
I began on Thurs 23 June 2022. Part way through I encountered errors possibly related to your update 1.29.1 which I saw Mon 27 June. See Can't delete a plugin All the issues reported here happened before that update.
Prefix rules murky
To enable testing, I attempted to add the prefix “ezlo1” on the Plugin Settings screen. This results in an error message: “An error occurred while setting the prefix” in a temporary red popup window, not captured by Firefox “Take a screenshot”. Same result with our corporate abbreviation, “epyu”. Adding the prefix “randomname” was successful. I eventually settled on “epyu_lee” as a temporary prefix. This will be completely unsatisfactory for a production version of our plugin. See Better Lua require package.path
The error says nothing about its cause. Inspecting network traffic shows a JSON response message with addition detail:
{“status”:0,“complete”:1,“data”:{“error_code”:20200,“error_message”:“Name already used”}}
This is an unsatisfactory means of conveying error information to developers. The majority of our workflow is generating errors. Once we aren’t generating errors, we’re done. Errors are our product, and what we want most from you! Placing meaningful error messages in diverse and less accessible locations decreases our velocity, sometimes to rates approximating zero.
The user would expect all error information persistently, prominently displayed and copyable until cleared by the user.
I’m still in the dark as to the vision behind these prefixes. In none of the documents I’ve read is the vision or purpose behind the new “prefix” explained. Our lack of control over our corporate abbreviation, “epyu” is unsatisfactory. It’s possible it’s registered by another account under our control, but this is not particularly traceable at present.
The user would expect clear documentation of the concept and principles of “prefix”.
UI installation errors
Uploading ezlo_wol.tar.gz provided by Leonardo_Soto at Unable to Upload or Install a plugin - #21 by Leonardo_Soto was successful. On the UI it shows as “Wake_on_lan”.
Attempting to install on my Ezlo Plus reported “An error occurred while installing”. No additional information was provided in the UI. (Note that clicking on the button did not provide any immediate response, leading me to wonder whether my click was seen, until I got the error message.) As before, this error message didn’t show in a screenshot and shortly vanished.
Looking in the developer tools network panel and repeating the operation, I see only one message,
The request was {call: “dashboard_deploy_package”, [omitting a couple GUIDs because I don’t know the security implications.]}
The response was a 200, {“status”:1,“complete”:1,“data”:{}}
That’s it. That’s all there was. It’s not clear how a user should proceed with such sparse diagnostic information. If we’re going to rely on consulting the Developer Tools Network panel, it’s not so hot when what’s visible there is success.
My solution was to log onto my controller’s root account and inspect the log files at /var/log/firmware.
I repeated the attempt to install the ezlo_wol.tar.gz file provided by Leonardo_Soto. After the expected failure, I inspected the controller’s ha-update_manager.log:
2022-06-24 14:29:41.737024 ERROR: Failed to execute an update plan for custom plugins, invalid metadata for ezlo1.ezlo_wol plugin, details: /“config.json”/“meta”/“prefix”: field of type ‘string’ is expected
Inspecting the config.json file I see:
{
"id": "ezlo1.ezlo_wol",
"version": "1.0.5",
"meta": {
"name": {
"text": "Wake_on_lan"
},
"prefix": {
"text": "ezlo_wol" [<-- observe prefix is a map, not the expected string. Note also the two conflicting uses of the term "prefix": here referring to the name of the plugin, elsewhere referring to an extra bit of name dotted onto the front!
Note also that this prefix element is absent entirely on the example shown at https://ezlogic.mios.com/#/ezlo/plugins/settings ! –Lee]
},
[ sections omitted –Lee ]
"executionPolicy": "restoreLastScriptState",
"startup": "scripts/startup",
"teardown": "scripts/teardown",
"gateway": {
"name": "ezlo_wol",
"label": "ezlo_wol_plugin",
"setItemValueCommand": "HUB:ezlo_wol/scripts/set_item_value", [<-- observe the absence of the required prefix here. –Lee]
"setSettingValueCommand": "HUB:ezlo_wol/scripts/set_setting_value",
"forceRemoveDeviceCommand": "HUB:ezlo_wol/scripts/delete_device"
}
}
I edited the plugin by reducing the “prefix” member to a simple text field. I used a new prefix, “epyu_lee” for clarity and changed the description of the plugin to “Lee’s Wake on lan”. The upload succeeded. The immediately following installation attempt failed silently. Eventually I reloaded the page and was required to log in again.
The user would expect to be notified if relogin is required.
The user would expect relogin requirements to apply uniformly to operations providing access to private resources, for deployment, upload, download, and so on.
Repeating the install attempt after relogin failed with the same previously reported brief popup message and a minimal JSON as before showing success.
Inspecting ha-update_manager.log showed:
2022-06-24 15:05:44.513947 ERROR: Failed to execute an update plan for custom plugins, internal error for epyu_lee.ezlo_wol plugin, details: Failed to deploy custom plugin!
This seems like a chance for more strict validation of the sort demonstrated above.
I again edited the config.json, entirely deleting the “prefix” member. This conforms with the example at Quick Start Guide - developer.mios.com .
The user would expect the term “prefix” to have a unique meaning. Should a developer identifying prefix on plugin names be an ongoing requirement, another term should replace “prefix”, or ideally both usages of the term should be replaced. Elimination of JSON members named “prefix” is a good first step; complete replacement of the term in all contexts should follow.
I deleted the old version and uploaded the new. Uploading succeeded. After installing I was offered options for “Uninstall” and “Configure”. Inspecting the controller’s /home/data/custom_plugins, I see a directory “epyu_lee.ezlo_wol”.
@Leonardo_Soto I speculate that your example was out of date. Perhaps the design here is a moving target?
I hadn’t read documentation explaining the operation of WoL plugin at this point, so I didn’t have a practical test to run to confirm its operation beyond the claims of the UI.
UI Installation success isn’t real success!
I moved on to work on deploying our actual plugin and ran into more problems.
On deployment, the Web UI reported success. However, the plugin does not appear to be receiving the messages it’s supposed to have registered for: no log entries; no error messages.
ha-extensions_manager.log:
2022-06-27 14:19:57.288998 ERROR: Error during loading gateway config from json
2022-06-27 14:19:57.289260 ERROR: Plugin: fail to get a gateway part of the plugin’s config
Cause: needed to specify missing required parameters. In the config.json gateway section we had only name and label.
The user would expect all practical validation to occur during upload. The failure may happen in a later part of your processing. But if the config file is doomed from the start, it would be nicer to fail faster with a real clear error message.
My solution to this was to specify a noop.lua that does nothing. Our plugin doesn’t create a device and doesn’t have parameters. We need to learn more about what force remove is supposed to do.
Next failure; specified command files were checked for existence.
ha-update_manager.log:
2022-06-27 17:17:34.324083 ERROR: Failed to execute an update plan for custom plugins, invalid metadata for epyu_lee.epyu_forward_events plugin, details: /“configuration”/“script”: script: HUB:epyu_forward_events/scripts/noop Does not exist
another chance for earlier validation.
At some point I also got dinged for not having an interface json. Again, we’re not (at least so far) exposing any controls; it’s just not our purpose. I adapted the example by gutting it. That was chancy because the documentation is incomplete.
User would expect complete interface.json documentation at Quick Start Guide - developer.mios.com . Specifically, the “contents” section is undocumented.
My final step to success was correcting the require and other calls in Lua code referencing files that now have changed locations. Some of this code ran as a result of running the startup script, some errors only happened later. I don’t have a specific request for better error visibility here, but a better Lua package.path would be really nice! Better Lua require package.path
Thanks for digging through all this!