It's back! I've had several requests for this, so I've added it to Bundle Manager. 
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.
Nice, good timing (or maybe I should have just waited a couple more days) for my question.
Just transferred it over to Bundle Manager.
Hello @csteele,
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.
Stephen
2 Likes
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.
4 Likes
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.
Thanks.
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.”
1 Like
You're welcome and thanks for that...
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...
4 Likes
I'm not detecting anything wrong...
I search for and find the Package.... select it for install...
And get offered a choice of one App and a lot of drivers.
What did I do wrong? I might suggest that calling it a package of drivers is now a misnomer but it doesn't change what's in it
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.
While I have your attention though this is how HPM looks.
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.
Mine looks different....
..
..
..
Even where our packages overlap...
But help me understand.. is MY screen cap what you're asking for or did I focus on the wrong difference?
UPDATE: I added some of your code to my development hub and get these lines:
That looks right to me. I specifically selected the Eight Relay because it's not v1.0.1
Interesting, I have two hubs and on the other one it looks like this with correct versioning.
I suspect that those apps that show v0.0 were added with an older version of HPM and have not been updated since HPM was upgraded.
I'll run a match and upgrade on everything and see if it all clears up.
There are currently 38 apps built into the platform and these all update automatically when the platform gets updated and I don't think anyone argues that is a bad thing. When it comes to updating all of the third party software on your phone, most people just receive updates automatically as no-one wants to do it on an app by app basis. Why is this considered an integral aspect of a smartphone but considered un-needed in a similar type of device that also uses apps?
I look at HPM as an "app store" for Hubitat. One place to go to search for, install and get all your app updates. It's somewhat disappointing to me that Hubitat wants to distance itself from the rich variety of community developed apps. This is the exact opposite of the approach taken by Apple, Google or Microsoft who know that making their platform sticky requires a richness of apps that can only be generated by engaging with 3rd party developers.
Requiring users to go out to github and grab code on a regular basis is one sure way of keeping Hubitat as purely a platform for hobbyists.
HPM is probably the closest thing we’ll get to an app store for Hubitat. Staff have said in no uncertain terms that’s not a business they want to be in.
I think they would argue that they don’t expect users to install custom code unless they want to. No one is required to do anything on GitHub.
I use the App Store on my iOS device, like everyone else. And on a couple android tablets I use the google play store.
But Apple and Google are much bigger companies, with lots of staff and other resources dedicated to running their respective app stores.
I think they are looking at community solutions as a liability and not an asset. Even Apple, the original "walled garden" has given up on that approach.
HPM removes the need to know anything about GitHub or the location of anything, which is why I said it's badly needed. That, and the ease with which I can update all my apps in just a few minutes.
It’s not an either or. It could be both an asset and a liability. It’s definitely a lot of work.
I love HPM, and the Apple App Store. But I don’t hold my breath re: the Hubitat app store because I don’t think that’s the one thing, or even an important thing, needed to move the hub further into the mainstream or improve overall user satisfaction.
IMO the UI would be a much higher yield area to work on to achieve either of those goals, for example.
I 'walk with one foot on each side of the line' I think. There's certainly some code available that's well into the liability side of the line, in the sense that it would create a lot of support hours for very little increase in the number of hubs sold per month. At the same time, it's hard not to notice that the platform has chipped away at the add-on value of quite a few Community offerings. Most Hubitat offerings are well on the "good enough" side of the line.
Don't forget that all those app stores do require that the developers jumps through hoops and that the app gets approved before getting posted, one wrong step and your out. This takes a lot of human resources and all, the code is hidden from site of the end user and protected. Reason why it's difficult for end users to install non approved apps on many of these platforms.
As for HE, Hubitat is a small company with limited resources, developers don't have to jump through loops to get the app on your device, it's the end users and community that will keep the apps in check and make sure code is not malefic because the code is public, but that makes it that the code can be reused by anybody and can be adapted for your specific needs.
3 Likes
They take a very authoritarian approach which is necessary for their scale. Hubitat does not need to adopt that model.
If Hubitat had a list of the 20 most commonly used community developed apps and 20 most commonly used community drivers in their "app store" does that really change anything other than A) make the software easier to find, B) make it easier to install and C) Doubling the number of "built-in" apps.
I would wager that many Hubitat users would find one or more of these community apps interesting\useful if only we knew they existed.
I agree 100% that many people don't even know about drivers and apps built by the community.
This is where it causes me a problem, which ones, how would the Hubitat managers decide on what to include and what is popular, this can't be done without causing a lot more problems, that is why this would never work and never will. If I were in charge at Hubitat, I would not go down the slippery road of deciding which community apps/drivers are "good enough" to make the list so I understand there position and actually support it.
If they decided to have HPM included in the built in apps with a statement when installed about the risk and that they are not liable and what not, so that the basic user would never have to actually copy paste anything to get access to many community apps and drivers, that would be great and would actually love that! It's actually the first thing I install when getting a new hub or helping someone else with his/her new hub. But again I don't see this happening in the near future either.
2 Likes
