Hello @richK
It’s weird because the config file is there but is not getting recognized as soon as I tried to upload it!
Can you please try with this one? prefix is: ezlo1
ezlo_wol.tar.gz (3.4 KB)
It doesn’t work. I tried it even though the ezlo1 prefix is not in my list (I cannot add the ezlo1 prefix). Same error. I then edited the config.json file and replaced the ezlo1 prefix with my own and tried again. Still the same error.
Hello rick,
Can you please share the error message you receive when attempting to upload the plugin?
You can find it when you try to inspect the page.
- Under the Network tab
- Try to upload the plugin
- At the third request, select it and then open the Preview.
bdbb-11eb-8fb5-1b358695a13b", status: “error”, … }
uuid “5a9515e0-f400-11ec-b8d1-0dcd8285db9b”
location_uuid “b0274630-bdbb-11eb-8fb5-1b358695a13b”
status “error”
status_details “{"errors":[{"text":"config.json file not exists"}]}”
timestamp “1656104290”
We are still checking this case, and we’ll report new findings as soon as possible, we are sorry for the inconvenience.
@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!
1 Like
Hi @Lee
Thanks for your valuable feedback which has lots of details and improvement suggestions.
Let me recap them at once :
- The user would expect clear documentation of the concept and principles of “prefix”.
- The user would expect all error information persistently, prominently displayed and copyable until cleared by the user.
- The errors which exists only in logs should be reflected to users.
- The user would expect all practical validation to occur during upload.
- User would expect complete interface.json documentation at Quick Start Guide - developer.mios.com **. Specifically, the “contents” section is undocumented.
We will be working on improvements on our side, feel free to add any suggestions anytime.
Thanks for the summary, Osman!
There are some irregularities around having to relogin, too. My first interactions of the day with the app are a little rough.
Let me add a little more. My company has partitioned our devices into more than one account (just for example, separating client premises devices from those used for development). Your concept of prefix appears to bind a prefix to a single account. This would seem to mean we have to build once version of the plugin for each account, with a different prefix for each. This means changing every Lua file in the code project that includes another Lua project. It’s really unworkable!
Hello @Lee
I believe you can do it through the Marketplace. You can upload a plugin to the Marketplace, then download it to a private Marketplace (My private plugins) on each account. Did I get the use case you described right?
I’m not actually familiar with the operation of the Marketplace. Our plug-in is private; I have presumed the last place we would want it is on the public Marketplace. Have I been missing out?
I have not seen any improvement in these issues.
Today, I’m trying to deploy our plugin to a remote Ezlo controller that reports as being online. (I know it was offline a couple days ago.) From the Edge Plugins; Private Plugins screen, I select “Manage Plugins” for the most recent version of the plugin and observe the controller in question has an “Install” button, so I press it. The red box, “An error occurred while installing” appears. But it includes no information about the nature of the error! Were this my local controller I develop with, I’d just log in and read the logs.
Fortunately, uninstalling the plugin on my development system and reinstalling it DID result in an error!
2022-10-07 15:29:23.523868 ERROR: Failed to execute an update plan for custom plugins, gateway data error: script: HUB:[snip!] plugin Id doesn't match
It would really help if this kind of error showed up in the web UI.
I’ll address the introduction of errors in new software version in a separate issue.
ETA: An observer of this controller reports that our plugin’s heartbeat messages were still being transmitted, even though ezlogic showed the plugin not installed. Possibilities include that ezlogic was just out of sync.