I seem to be stuck on HPM 1.9.6
When I try to update or repair it hangs on Please Wait...
I've waited several hours.
What should I do next?
You could try updating the code manuallly. Feom github
If you are not sure how to manually update the code directly, I think if you just install the bundle it should update it.
HPM Documentation
Recommended:
For Hubitat Package Manager, it's recommended you use the Bundle feature because the code itself is large. Copy this URL: https://bit.ly/3VfykH9 then paste into the Import Zip: Download from URL and click Import again.
Docs for how to install a bundle: Bundles | Hubitat Documentation
1 Like
Thanks - I installed HPM using the bundle.
It worked, HPM now shows 1.9.7.
Thanks!
Oops, the bundle has not been updated yet, but you should pick up the 1.9.8 update shortly. When you update it might seem like it hangs for a few minutes, just go back to the apps menu and go back tp HPM and it should be updated.
Bundle Updated
1 Like
got the 1.9.8 bundle - thanks
I had a mess. Somehow HPM didn't update itself properly on one of my hubs.
I deleted it, reinstalled it (note: I had to expand the bit.ly link and paste the full "*.zip" URL to get the Import button to activate). I rematched everything, etc.
Then, trying to set the settings, I got an error saying I needed to fill out all the required fields.
It REQUIRES at least ONE Beta package to be selected. And, I really do not want one selected.
Thoughts?
Thanks!
Did you turn off this toggle?
Mine was apparently on by default. But I did not have to pick any beta's either
4 Likes
You should only get that message if you have the option to install betas turned in but none selected to install.
If you dont want any betas, turn it off and that message should go away.
That changes was made in 1.9.8. It was to allow better control over what beta packages are installed. Before, once you turned in the beta switch, everything if enanled, would inatall the beta packages. That could be a problem if several of the softeare packages you used had beta options but you only wanted one.
2 Likes
D'oh!
I totally missed that. Thanks!
2 Likes
HPM Development Continues
I rewrote the fast search external tool to approximate Azure's fuzzy result. Fast Search will simply offer more options, just like Fuzzy search has all this time. The next version of HPM will drop the Azure / Fuzzy option.
In order to produce search results, I've always had to crawl the "Repo Tree". It's been running for a couple years, 24x7x365x every 20 min. Obviously then, if I have all the repos in one DB (externally) I wondered what else I can do with the DB.
I thought it would be amazing if I could 'shortcut' the burdensom task the hub has on each Match Up. The 'Repo Tree' is over 800 URLs that need to be read each time.
You can see it with each Match Up.. a long list of "refreshing <every repo>" followed by lengthy delays for "Downloading Package Manifests", "Retrieving List of Installed Apps", etc. I created another external tool to provide the shortcut.
Every time the HPM goes into Matchup, it sends a list of the apps and drivers already on the hub to the external tool and gets a response of all the packages that are 'candidates'. If the attempt to send externally fails, it automatically falls back to using Local. Match Up must work every time.
The logs below show that the time to do the matchup is roughly a second. Clearly the effort to reduce the time was highly successful.
Fast-Track method:
0.92s
12:41:33.490 PM debug HPM: UI List contains 2 valid objects.
12:41:33.387 PM info HPM: Fast-Track matched 2 packages.
12:41:32.860 PM info HPM: Sending metadata to Fast-Track server...
12:41:32.570 PM debug HPM: Collecting metadata using native getAppList/getDriverList
12:41:32.470 PM debug Performing Package Matching
Current method:
16:51s
08:51:27.807 AM info Matching up packages
08:51:11.297 AM debug Performing Package Matching
Superb, right? 
But there are two things fighting in my head about releasing this:
-
The actual need for speed: Match Up isn't run every hour or every day, heck it might get run once a year. Saving 16 seconds doesn't seem so great on a more realistic time scale.
-
Privacy: Your hub's list of installed apps and drivers are sent to the Fast-Track server to build a list that applies to your hub only. If there are 816 packages in HPM's Repo Tree, and your hub only has 40 apps and drivers, you only need a list displaying which of your 40 apps could be managed by HPM. Obviously Match Up does this independent of where the CPU resource is located.
The resolution for me was to make Fast Matchup optional, it defaults to fast and will not if you choose.
It's taken 50+ hours for me to get this working, and of course, I'm dazzled by it. However, I'm at the point where I can discard it, if it turns out, "the juice ain't worth the squeeze".
Is there a consensus?
7 Likes
Funny you post this now, cuz I'd been thinking on the same "problem" much of the past week, and was on the brink of suggesting similar refinements. As usual, you beat me to the punch, and I think that takes HPM in a positive direction. Thanks for your efforts!
2 Likes
It doesn't alter anything at, the 20,000 ft level.
Still get Fuzzy, still get Match Up. Funny how 'complete' HPM was when Dominic finished it (v1.8.2) Un-Match is my only claim to fame (v1.8.6).
4 Likes
@csteele, my professional experience tells me that, every improvement based on the developer's "gut feeling" should be developed and released (specially since you did it already!) - you'll only know if it's useful or not for the users/consumers if you release it into the "wild".
In my "old" days, I did It a lot with mixed results. However, there was a thing that never, never failed: the satisfaction in doing it.
So, go for it!
5 Likes
OK...
Update released:
v1.9.9
- UpgradeApp() moved to the Top to remediate HPM crashing during Upgrade of itself due to the methods moving post-upgrade.
- Replaced "Fast Search" algorithm to also use fuzzy, thus eliminating the need for two choices. Delete Azure query.
- Created an external Fast-Track Match Up tool. Default on but Optional.
9 Likes
error trying to update : v1.9.9 Just Hung.
java.lang.NoClassDefFoundError: user_app_dcm_hpm_Hubitat_Package_Manager_128$_copyInstalledItemsToNewManifest_closure100 on line 4214 (method performUpdates)
Upgrading Hubitat Package Manager
However after I moved away it shows this .. Updating HPM version to 1.9.9 from previous upgrade
That's the classic "random code where the old code used to be" issue. v1.9.9 has one of the most likely methods moved to the top, so it doesn't move version to version. Future changes are likely to be in the 4500 lines of code AFTER the relocated method. Most likely
We'll have to see with the next version of HPM when the two methods will be in the same place.
For the 5 hubs I upgraded, 2 'hung' -- but since I know that symptom, I clicked on the Home icon in the left menu and went back into HPM. Everything was fine.
2 Likes
Thats what I did ..
I certainly love that HPM continues to get the love it deserves.... And happy that something so important as HPM is in good hands.
And I hate to be that (ill-informed)... guy.... But.... (and I'm likely too late in making this assessment / request)
As much as I Iove to see self-contained solutions that don't rely on external systems or processes... Personally I would expect most people would be finding their apps or drivers here on the Community rather than happening upon them after searching within HPM. It feels like if dev's could have an easy way to direct new users to find their creation through some simple instructions on a post here on the Community, that should be all we need. This would remove the need for complex search functions that need to be maintained in HPM, plus it would provide a more targeted outcome people could rely on. TNH, I thought this was already being handled by the current search functionality, but I have likely not being following the discussion here closely enough.
I know, I'm likely pouring water on a re-ignition of work in an area of HPM.... so feel free to say boo to my suggestion and press on, I won't take it personally.
