The simplest path is to open HPM, click Repair, find HPM in the list and click Next.
The latest code is downloaded into the Apps Code area. Since HPM is running at that moment, there's a rare chance that swapping the code out can cause a fault with the display of the "success" message. Imagine the code is at Line XX and then the code gets swapped. Instead of running line XX+1, it's running YY. It doesn't damage anything, it just gives a log message and sometimes, appears to hang. (No "Success" message.)
Click on Apps in the Left Menu and start HPM again.. check the running version shown in the upper left corner:
An Update from 1.8.3 to 1.8.7 often has another cosmetic issue where two instances are shown. v1.8.7 has a new feature called UnMatch that, along with its other uses, also clears the two instances display.
Is there a plan to add in a Package Explorer type feature, or possibly take over the original?
Package explorer has been throwing errors(I assume since his other apps transitioned to Bundle Manager?). Although, maybe I'm just missing something. Is there a better way to search through HPM?
My history with HPM is mostly one of practicing the fine art of procrastination. The packages I was involved with at the time didn't fit HPM well. I have to admit even less demand to understand Package Explorer. Even today, I'm not sure what it did... I do know two things, it's mothballed and it was built to solve a problem that doesn't exist any more. @thebearmay points out that HPM gained external search features long ago and I enhanced (fast search) those when I chose to provide support.
I too am a semi high functioning PRO-crastinator, so I fully get it.
I liked it because search was a little faster(at the time?) and I could compare app summaries. I just re-ran a few searches in HPM to see if I was missing something, and my original question seems to have stemmed from the perfect lineup of results with terrible descriptions. It just seemed like there was no info before having to commit to an install.
One thing I do like about the explorer results is that they include the community and github threads. It makes it easy to compare what is available in HPM before opening up the search to the general community.
From what I have gathered, it appears you took over maintaining HPM, for this I am appreciated. I have also looked (not to deeply) to see if a feature has every been requested before for what I am about to see if it is possible.
TL;DR
So I was on HPM today and wanted to see what packages were available to install. I went with the use of tags to check out different packages. I found one I like about a 3rd down the list, clicked to install it and all went well as usual. But the problem now is, I couldn't go back to the packages I had originally clicked (which was several at a time) without having to re-click all the boxes I did before.
What I am looking to see is if there is a way to either click to download multiple packages at one time (kind of like we do when we update packages) or at the very least, allow for us to go back to the list of packages we were looking over to continue where we left off. Maybe even something like a cart feature, where we can add packages to a "cart" and then go to this "cart" when we are done looking and download all of them in the cart or remove the ones we decided not to use.
On a side note to this as well, wish there was a way to ready the full description and maybe see more in detail what the package does before we download it?
Again, thank you for taking over and thank you for what you have done. Because of this community, I have made my "Smart Home" the way I want it to be and not just what an echo system setup tells me I can do.
I'm not sure your feature is possible, given the limits of Hubitat's GUI. (We don't invent our own Interface for Apps...) The Update Package list is limited by not being able to include free format text.
The words under each Package name on the Install screen is fully controlled by the manifest a developer creates.
I've typed in short and long descriptions along the way, often dictated by how poorly I can describe a package that I otherwise know everything about
This 'level' of the manifests contains a Description field (which is what is displayed under the Package name,) while it doesn't exist in the PackageManifest level, yet that is where the URL to any documentation does exist.
One of my main goals in 'taking over' was: do NOT create a breaking change.
Dominic drew a line when he said that the Manifest structure was complete. He received good support for that because it meant that Developers were able to "create once, use forever" manifests. Altering that would be larger than I'm contemplating, since it would also alter 'hpm -- the tool for creating manifests'
A small little tool called Hubitat Package Manager Tools has been provided which assists in the creation of these files. On Windows simply run
hpm.exe --help
and on MacOS and Linux run
./hpm --help
Underlying all of the above is the fact that I like the idea(s) -- mostly due to it being of benefit to new users. HPM does have a 'one-at-a-time' orientation and that comes from its history when discovery of a package was via the Community alone. Then you'd find the package in HPM and install it. The use of HPM as a discovery tool is somewhat new.. and useful too.
Hi @csteele thanks for all of your work on HPM, it is a tool the platform badly needs for discoverability. I listed some driver in HPM a while back and everything worked as expected. Just a few days ago I released my first app and as it's dependent on the use of said drivers I thought I would put it in the same package.
I used the HPM tool to add the App: section and details and everything seemed to go fine and the JSON checked out. However when I go into HPM I never see the newly added app. I've tried an un-match and re-match but no success.
The repository in question is here and the new app is listed at the top.
I did find your documentation and read it but did not get the aha moment. Would you mind taking a look and letting me know what I'm doing wrong.
I’ll second the thanks to @csteele for keeping HPM going after Dominick decided to switch to another home automation platform.
But I would also add that the platform has a pretty simple interface for installing built-in drivers and apps. The ability to add custom code written by community developers is a really great bonus feature.
But based on public statements they’ve made, the staff have concluded they do not intend to get into the business of supporting/featuring/selling/[insert verb here] community-developed code, for a variety of reasons.
So while HPM is really useful for users that choose to install groovy code on their hubs that isn’t baked into the hub firmware, it’s, IMHO, a stretch to say it’s “badly needed.”
Let's not get carried away on the thanks to ME.. it's still almost entirely Dominic's skill and determination. I've added just 'a brush stroke or two'.
I appreciate that it's a relief that someone (anyone) is keeping it going, I suspect that more than a few are still on 1.8.2 (Dominic's last version.) There's roughly 100 unique visitors to the repo and that really does back up your
HPM makes it easy ONCE you cross over into Community offered code...
Sorry to have wasted your time. My severe refrigerator blindness has now spread to the computer. I just kept looking at the wrong place as that was where I was used to looking for all my prior updates.
Is there a way to have the driver versions report correctly. I saw your comment about not mixing and matching the version usage but it's very helpful in just mentally tracking what is in a package, even if the versioning (at the component level) is not actually used in any computations for versioning control.