Sorry Bryan but that seems a backwards step for the community. We'll end up with multiple package managers and new users will just get confused. Your contributions are always appreciated and it's your choice to make in the end.
11 Likes
I somewhat don't agree. I have an Android phone and have 3 app stores (Google, Amazon, Samsung), and if I am not mistaken, Apple is going to allow other app stores as well.
We have multiple device vendors with different features and steps to get connected. I could say it would be better for all users if we only had 1 vendor with the same way of doing things. I don't think any of us want that. Competition is necessary in getting better features.
Plus, I don't see home automation in its current state as a plug and play environment. It takes time with learning to get your stuff working.
Even better is that both developers are known for helping and sharing so I see this as the best of "both" worlds.
3 Likes
As I worked through Bundle support, there is a sliver of a mismatch between what bundles really are on the Hub, vs what HPM has been doing all along.
Bundles are handed to the Hub as a ZIP and the hub instantly unzips and plants the code where ever they are supposed to go. Apps to Apps Code, Drivers to Driver Code, Libraries to Libraries Code. A few seconds later, the Bundle ceases to exist from more than a placeholder role. If you delete the bundle, nothing happens to the code that was unzipped.
HPM has to work in the same way... A bundle is added, the contents are planted and done. The bundle object exists in the HPM cache, and can be deleted. But all that gets deleted is the Bundle, not the contents. As a result, a Match Up in HPM will probably find a match to the individual code components and not to the Bundle.
Since this is the way the Hub works, I'm planning on leaving HPM to follow along.
Here's the visual story:
I've installed the Auto_Off Bundle and it appears in the View list and the components appear in Apps Code:
If I were to do a Match Up, then HPM will find the matching Apps:
Accepting the match up will result in both showing in View:
Uninstall is as you'd expect, can delete the Apps or delete the Bundle, or both:
They are independent at this point, their relationship is known only to us.
2 Likes
2 Likes
I agree. While developers are free to choose to use HPM or not, it has helped so many users to be able to find and manage things all in one place.
I am very grateful that csteele has taken over this project.
9 Likes
For those still using 1.8.2 (before migration) an Update will only show v1.8.4
Doing the upgrade will also flip the master manifest and will then offer v1.8.5 as a 2nd upgrade.
7 Likes
That's alright, I'd point out that HE is not a phone, and your talking about official supported app stores on mobile, whilst we're talking about disparate community content and making it easier to find. If some apps are available on one but not on the other, then new users to HE and home automation which has enough challenges as is will get confused about why they can't find what they're looking for. I wouldn't point to the mess on mobiles as a model to follow anyway, I just don't think it's a good idea for community apps to be hidden away in separate places. Anyway, I don't want to derail here, or create any further tension. My view is simple, keep it as easy for people as possible, and any added complication will only make things worse not better imo.
Edit: I'd also like to add that Bryan is an amazing developer and member of the community, so his hard work is always appreciated and shouldn't be taken for granted either. Same goes to csteele. We're just so blessed to have folks like them in our community to elevate our homes even higher.
12 Likes
Having a bit of an issue. A few days ago I got a notice I had updates available on all of my hubs. When looking at the apps page a update was indicated on each hub. When I ran the update, however, it said all my apps were up to date and nothing was available. Just figured it was part of the move over process and didn't worry about it, otherwise all seemed ok.
This morning I got the notice again and same thing, all hubs showed an update available but on each no updates were available.
So I tried a repair of HPM on my rules hub and I got the error shown below and the process would not complete.
java.lang.NoClassDefFoundError: user_app_dcm_hpm_Hubitat_Package_Manager_118$_copyInstalledItemsToNewManifest_closure87 on line 3573 (method performRepair)
On this hub under view apps and drivers I see HPM is 1.8.3, however on the main page there is small text saying it is 1.8.5.
My other three hubs show they are at 1.8.5 but they do not have that small text on the screen. I have not ran a repair on them.
Not sure what to do next. Should I reload HPM manually?
2 Likes
No... I haven't found a situation where a reload / reinstall is needed. For me, Repair gets the latest code, which is 90% of the goal. I'll look into why View isn't matching.
As I said a few messages ago, Apps and drivers aren't required to contain a version and those that do, implement it in a variety of ways. Adding a visible version to HPM was one of my ToDos. It makes it easy to know you're using the intended version. View however displays the version from the Manifest, and is what HPM uses for it's comparisons.
2 Likes
I have seen this too. I'll run a repair and see if it happens again.
I'm seeing a weird issue where now I have TWO HPM apps listed within HPM. You can see it in the screen shot below. I can't figure out how this happened, but any insight into how to fix this, would be awesome. One is 1.8.4 and the other is 1.8.5.
I ran repairs of all apps in HPM including HPM, ran update, 1.8.5 showed up and updated. Hopefully settled now.
I got this too.
Being the impatient type I just deleted HPM from Apps and its code from Apps Code, reinstalled the code using the link and added HPM back to the Apps list. A quick "Match Up" and it's as good as new.
Just did the same, all good now. Current version v1.8.5
It's strictly a cosmetic thing. I understand using "the big hammer" to fix it, but nothing but a display got fixed 
But yes, that big hammer does the trick 
Be careful, and don't hit your thumb.
Remember, HPM can only get HPM code from the single repository. There aren't two copies.
3 Likes
Always with the big hammer here. 
Sorry for the dumb question, but for some time I've quite liked the idea of using the Libraries code feature to reduce duplication (and maintenance!) in my drivers, but I've always assumed distributing those would require a bundle. Is this right?
If so, do I need to go through this manual process of creating a .zip? That seems like it would be a pretty laborious process, moreso than just copy-pasta-ing the "library" block at the end of each driver and updating the repo directly via GitHub.
If not, how do I use HPM to install both driver and library code? Could I simply make the library code mandatory using the existing "required" tag in packageManifest.json under a libraries block, something like this:
"libraries": [
{
"id": "blah",
"name": "Some MegaLibrary",
"namespace": "BirdsLikeWires",
"location": "https://raw.githubusercontent.com/birdslikewires/hubitat/master/libraries/megalibrary.groovy",
"required": true,
"version": "1.01"
}
?
1 Like
NO.. NO... NO... LOL
You build a Bundle right on the Hub.
Click Bundles:New Bundle and get that screen. Just select the pieces. Give it a name, give it a namespace and click Save and export. Bingo. You're all done.
Like so:
Or like this if you have a mix of components:
https://hubitatpackagemanager.hubitatcommunity.com/bundles.html
Mmmm, that was what I feared. I have a bunch of drivers split by manufacturer and don't necessarily want to force the end user into installing all of them when they may only have one device from that brand. Looking at this I would need to clickety-click through this process for each driver and its associated library to keep that granularity.
Would adding the library as a requirement in the manifest not work? I haven't checked if this is a supported thing to do, but I figured apps and drivers land in the right place with HPM anyway, so perhaps the same would be true of libraries..?
