Yes, un match, exactly what I said to do….
2 Likes
Try a repair instead.
Same issue using repair
Manually update HPM to 1.9.1 using the import link in the first post.
Unable to duplicate.
The message you posted:
Is usually accurate. HPM gets the code then transfers it, to Apps or Drivers as appropriate, and clicks "save". It's at that point Hubitat will fail with the error message shown, which HPM just parrots.
For packages that create child devices, that then might get used in other automations "in use" means that it's in use.
I installed the YoLink package and tried an update, but since I don't have that product, I can't get a UAC to give the App. That means the child devices aren't created for me. Which means an update goes quite smoothly:
It does this for all apps I have updates for. Not just yolink
Is there a way to uninstall package manager and reinstall it without screwing things up?
There's nothing for HPM to screw up 
You can delete it easily by clicking the gear icon, top right. Then scroll to the bottom and click the red Remove button.
After that, you can go to Apps and Add user app again. You will have to go through the mandatory Match UP, but in just a few moments, you'll be able to try again.
2 Likes
Just wanted to confirm something...there are times when a dev has released a new version of their app and I want to grab the update. Since I do a nightly package update I know that all of my packages are up to date except for the one that was just announced. Rather than starting an "Update" and waiting for HPM to cycle through all the packages, I have started doing a Repair as I can just select the app/driver and apply the update quickly.
Just wanted to confirm I'm not going to hose anything up w/my apps/drivers by doing this...as far as I can tell doing Repairs like this doesn't cause any issues.
HPM is a lot of paths to the same thing... get a file, get it into the hub, update the manifests.
You can be north looking south, south looking north, east looking west or west looking east, everyone is facing rather similar/common code. It's mostly just picking a view point. Install is picking from the master manifest, repair is picking from the local manifest. Update is picking by comparing master manifest to local manifest. The result is the file loaded into the hub. Remove is another that is picking from the local manifest but... removing files(s) then updating the manifest.
1 Like
So you don't know either? 
1 Like
HPM can't cause harm, if that's the question. It can be out of sync from the reality of a Hub. People can just delete code... I know I have, completely forgetting I added it in via HPM. So HPM can have a mismatch in it's manifests. It's certainly one of the big factors that drove me to add UnMatch.
8 Likes
Can't remember if I did an update or a repair (I think it was the latter) but I ended up with two of everything.
Is that because the original versions were (probably) not installed with HPM?
Just go through and delete them.. the ones that are in use cannot be deleted Check the ones that survived for up-to-date.
If the survivors are up-to-date, then you can then do an UnMatch, followed by a MatchUp and it should find them. Select the up-to-date option and HPM will manage the Package.
If the survivors are not up-to-date, then you can choose to manually update or UnMatch and Matchup and not select the up-to-date option. Then do an Update in HPM and it will do what HPM does.. put the latest code onto your hub.
I guess the final scenario is that none survive, and that's easy too... UnMatch then do an Install
2 Likes
Make sure HPM is updated as well, one of the HE updates broke the old version of HPM and could cause duplicated drivers to get installed.
3 Likes
I'm not sure this is the right place, but just in case... I use the "Weather Canada (OWM-EC)" app, but it is outdated, and it seems like the original repository is no longer supported by its owner. I forked it and made corrections to it:
What might be the proper way to propagate this to HPM ?
To HPM, without access to the original repository, you have a new Package. 
You'll have to create a new set of JSON files and get yourself added to the Master Repository.
Although you have forked the original, obviously the Intermediate and Package Manifest is still pointing to the original as well. You'll need to edit all three of these too:
"location": "https://raw.githubusercontent.com/dmike3/Hubitat/master/hpm/xbox-smartglass/packageManifest.json",
as well as:
"location": "https://raw.githubusercontent.com/dmike3/Hubitat/master/Drivers/Xbox-Smartglass/Xbox-One-Smartglass-Driver.groovy",
anything pointing at the "dmike3" repos.
1 Like
Ok, thanks. I'll try to see to add a new package... Is there a vetting process, or a process to get packages marked as unsupported/deprecated ?
How do people using the current Package find out that there's a shift in developer? And what to do when that discovery is made?
Yes, there's a quarantine process for a Master Repository entry but HPM tends not to be the dominant issue. Because the Index/Key to a Package is the Locations, removing the location simply means the location is never again checked... for anything.
There's nothing in HPM to facilitate migrating Developers in one step. UnMatch has to be a step in the total process, You can scroll all the way back in this topic to see the difficulty in migrating HPM itself, when I had access to the original repository.
3 Likes
Thanks, in advance.. i search for "how long" in this thread but didnt find anything..
as a developer i just added the new tesla tessie integration to my manifest.. how long before package manager picks it ups so i can announce it is now available via package manager..
Is it only nightly.. thanks again.
