Repair re-reads the code from the repository without checking versions. Just a reminder, versions are an HPM construct. Hubitat does not need or require code versioning. In fact, most Community code does not have a version recorded in the groovy code.
Repair just re-imports whatever code is at the developer’s repository. This can mean that HPM has a db entry of v1.1.0 on your hub, while the repository is distributing v1.1.6 HPM will run it’s query for updates (nightly) and should discover that the code needs updating. It will then suggest you update to v1.1.6 (again).
Repair is ideal when you’ve manually removed some code.. perhaps a package has 2 apps and 5 drivers and you decide you don’t need one of the drivers and manually delete it. Since HPM still believes it’s supposed to be managing the Package you can recover from that by simply doing a Repair, bringing in that one missing driver (along with a refresh of the rest of the package) and HPM will have a match of what it thinks it is managing and the code on the hub.
I’ve found that an UnMatch of a Package, followed by a Matchup, does a more complete job of getting the HPM DB to match what’s on the hub. In other words, there’s a couple of edge cases where Repair alone “makes things better” for today only.
I’ve made Matchup significantly faster so that the UnMatch & Matchup cycle isn’t as time consuming.
I have documented in several places this bit of timing.. that the ‘tree crawl’ runs every 20 mins and takes 2+ minutes to complete. I recently enhanced the crawl code to use concurrent HTTP fetches via curl_multi, resulting in a reduction of the extract from 2+ minutes to 12 seconds.
It’s been running live for more than a week and I thought it would be good to make a record of when I made this change. I can’t imagine anyone needing to know… or anyone thinking that “2+ minutes” needed to be “fixed:“
@csteele I have a question. I recently released an updated version of an app that the original developer is no longer maintaining. We talked a little bit and he removed his version from HPM and mine is now added. Is there a way for users to easily switch? Or will they just need to uninstall the current package and download the new package?
Unfortunately HPM indexes the Package with the Location/URL. IF that changes, and of course it will when a new person takes over a Package, then it’s effectively an completely new Package with a colliding name. Uninstalling the OLD solves the issue, followed by a new Install.
UnMatch would strip the abandoned code from HPM management.. aka the DB, but the code would remain on the Hub. It just became manually managed. Would the result be two copies of the code? With the same name?
I think the match process tries to match based on the driver, app name. If the old code and new code use the exact same name it may match up if the nre repo manifest uses the same names as well. Just make sure when you do the match that you don’t tell HPM it is running the latest code. Then they would need to perform a update to get your code.
I think it may also be possible to do something with the Guid in the manifest file, but would need some testing to validate. That would likely require some coordination with the original developer though.
No, just do not install the new package first. Unmatch then match to new package, and then do an update/repair. That would in effect migrate it to the new package. This assumes the new package keeps the same name. Even if the name changed slightly you can specify alternate names in the maniest so that a match would pick up the old name.
EDIT: One other thought, I think it also matches on the namespace, so you may need to keep the namespace the same for this to work. You might be able to specify the alternate name AND namespace in the manifest though as I suggested above.
You may remember that I’ve been down this path when I took support of HPM, when Dominic left. Transferring from HIS github repo to “MY” github is pretty much what the question revolves around.
Well, the good news is the existing app will likely continue working for anyone using it, which I have no idea how many that actually is.
It’s for Trane thermostats. It seems like they changed how the backend works for newer models, but left things alone for older models. So my version of the app is basically if (oldTstat) use old code, else use my code. So I was mostly just curious what would happen, like would HPM tell them there is an update. But I guess not.
I just had to do this for WyzeHub yesterday, where the package was taken over by a new person years ago. That just means the repositories.json had the old location removed and the new one added -- but that change doesn't update the local installed state on my hub. My WyzeHub install was a few versions out of date when I went to make a change to it and realized the error.
Anyway, doing the Un-Match made HPM forget about the installed package (without removing it) and then doing a Match-Up made HPM match the existing installed files to the package. Then an Update brought all the code up-to-date.
What I learned is that you need to do this dance if a package changes ownership.
I'll note that the Match-Up goes by file names. I remember doing this in the past for files from the Ambient Weather Station, which has file names that match 3 different packages. HPM offered me all three (but I knew which one to select).
Testing to see if it was that specific package, I then tried a repair of HPM itself and got the same error. Also noticed a null point exception for another one of the packages
It will then suggest you update to v1.1.6 (again).
