You shouldn't need to. Doing a repair then update should fix the double issue for now. You won't lose any config options. Those aren't touched.
1 Like
@csteele with the issues above just want to share some anecdotal information that might be relevant.
I had has issues with random debugs in my log for ages in HPM long before your changes but just ignored them. With your changes and knowing I had migrated I went nuclear to give a clear out.
I uninstalled HPM and then looked at the code and clicked the import button in the app code page. What I then spotted was the code jumped from 1.8.4 to 1.8.3.
I copied the URL from the code and pasted it in the import and then tried again and it grabbed the latest.
I then installed, matched up and logs are clean and updates are smooth.
So I was thinking, my understanding of HPM is basically it goes out and clicks that import button? So maybe this is why some are having issues because that button is not taking the change in the "import URL" in the code. Then it's going backwards then the update pulls it forward and so on.
It's not the first time I have seen that button string not get updated.
I don't think it's exactly an Import. HPM reads in the code from a repo and then asks the Hub to save it. It looks more like a Paste of the code into the code window followed by a Save click, to my eyes.
2 Likes
I'm just about to dive into some driver updates again but was wondering... does HPM have the ability to install Libraries Code right now? Reading back I saw @dman2306 mentioning it with the same caveat on time I usually flag up!
I can't see anything in the documentation about it, but before I go nailing some JSON together I thought it was worth a quick ask here.
As mentioned in another post, I have tried to not touch any of the code related to Apps and Drivers for Install, Update, Modify, Repair, Uninstall, and so on. Libraries are found at {Your IP}/library/list and similar: /library/editor
The word "library" does not appear in the code. If I remember right, he said Libraries would be a better fit than Bundles.
On the other hand /fileManager/ does appear.
1 Like
Thank you, yes, I've just had a search too and it looks as though the time was never found. I know that feeling. Maybe I could try "bundling" only the library in the first instance... ignore me, thinking out loud now.
Ta.
Yes, that was my thought too... a Bundle, containing Libraries, alone or in concert, would work.
2 Likes
Okay, it sort of works but there's a chicken-and-egg thing going on.
I've created a library.zip bundle and added it to all my packageManifest.json files as a required component. However, when upgrading or repairing, the updates to the drivers occur first, meaning I get a weird "Be sure the package is not in use with devices." error when it comes to the only driver currently using the library:
This is because the library isn't present yet, so HE sees the driver as faulty.
The only workaround which immediately comes to mind is to version bump everything to trigger anybody using my drivers to update, but not have the library referenced in any code, only as an installation requirement. This should cause the bundle to be installed once the clean update for the drivers completes, ready for future updates. However, anybody who skips the bump will land themselves with this error
Could HPM's behaviour be updated to handle bundle installations first and then install the individual apps and drivers? Or can anybody see a better solution?
1 Like
Like this??:
app:689 2022-06-08 09:08:16.961 am info Installing Virtual Switchable Presence
app:689 2022-06-08 09:08:13.854 am info Installing Splurge Driver
app:689 2022-06-08 09:08:13.322 am info Installing library
app:689 2022-06-08 09:08:13.101 am info Downloading Virtual Switchable Presence
app:689 2022-06-08 09:08:12.853 am info Downloading Splurge Driver
app:689 2022-06-08 09:08:12.606 am debug Install beginning
app:689 2022-06-08 09:08:12.603 am debug prefInstall
Library installed THEN driver
Uninstall is the reverse??
app:689 2022-06-08 09:11:38.446 am info Uninstalling library
app:689 2022-06-08 09:11:37.357 am info Uninstalling Virtual Switchable Presence
app:689 2022-06-08 09:11:36.295 am info Uninstalling Splurge Driver
app:689 2022-06-08 09:11:36.114 am debug Performing uninstall
I think Repair would have to change too.. Bundles first.
I thought bundles allow setting order for both install and for update (where they may be different).
It seems for HPM, there would be specification for
- new install order vs. update order, that the developer would set.
If you're going to that trouble it might be easier to add a couple of JSON elements to each, i.e.
installOrder: 2,
uninstallOrder: 1
Order within a "type": you can set the order of Apps, you can set the order of Drivers, you can set the order of Libraries... but not between types.
In the New Bundle screen on your hub, you can see that.. You can order vertically, not horizontally.
ok, I don't use them yet.
My issue is for my parent child apps
- For install
- have to install the top parent app first
- you can then install whatever
For updates
- I have order I need -> in my case I want:
- drivers
- apps (except main parent)
- then main parent last
This allows me to coordinate state changes across everything that is running.
I'm sure others have other needs, hence developer should have a way to say this.
HPM has had an install order all along of App then Driver ... I simplistically added Bundles at the end. My point being, Apps then Drivers has worked a very long time, adding JSON elements could be the best thing since.. or it could be nightmare. Dominic announced that the Manifest JSON was "locked" more than a year ago.. I broke that by allowing ONE additional word: bundles.
1 Like
You're staying within a "Column" and there's ordering for Apps. What is being pointed out is that the HUB does not offer any ordering between Apps and Drivers; Apps and Libraries; Drivers and Libraries; etc. If your Bundle contains, like HubConnect does, both Apps and Drivers, you currently have no control on the order of Drivers first or Apps first. There must be an ACTUAL order.. what the hub actually does, but we can't alter that, and certainly HPM can't
1 Like
Would solve @csteele if you are open to this enhancement request, I did a little testing of this idea and its a very simple change within the prefPkgVerifyUpdates() function. Change:
updatesToInstall += "<textarea rows=6 class='mdl-textfield' readonly='true'>${updateDetails[pkg].releaseNotes}</textarea>"
to:
updatesToInstall += "<div>${updateDetails[pkg].releaseNotes}</div>"
I added HTML tags to the release notes of my Google Calendar Search and here is an example of this enhancement working with another update for the Hub Information Device that doesn't have HTML within it:
They are always "a very simple change" -- it's all the stuff that gets broken as a result that is hard. hahahaha 
What happens if there's dangerous html? Could you change your html to be the URL of the groovy file.. in other words a simple brain fart / typo where the link points to the code not the .md
1 Like
They do, but the way I'm using bundles is to circumvent the lack of library code installation support in HPM, as @dman2306 couldn't find the time to add it. There's nothing in my bundle except for a single library file, all of my drivers are handled in the traditional manner to give users the option of which to install (and keeps the versioning much easier to handle IMHO).
What currently happens if the user is upgrading is that the drivers are installed, then the bundles. But because the bundle is providing the library code the driver relies upon HE sees an error in the driver code (hey, there's no library code in that namespace!) and borks, causing the cryptic error message from HPM.
In my mind an install flow of Bundles -> Drivers -> Apps makes most sense, as Apps may rely upon Drivers and Drivers may rely upon the content of Bundles. Just my 2p though, I'm not familiar with HPM's code or how difficult it may be to adjust this.
Developers obviously have to be mindful of the changes to their manifests and need to test their code. Not sure I see how this could be dangerous because its just making the release notes value render HTML inserted in the value from the manifest. Each developer is responsible for their manifest file that HPM reads. Another idea is to put an additional flag in the in the manifest to specify you want an HTML release note as an extra step to ensure the developer knows what they are doing.
