i get an error for microlines old repository for ecowit stuff. but dont want to remove and reinstall as i have 3 locations with weather stations and at least 30 devices.
i dont see his repository in the list to see which one to uncheck so i dont get the error everytime package manager runs. i even added extra debugging to try and find it.. ie please advise
A question about versions of our package that we want to publish in HPM; apologies if this is answered somewhere up in this long thread that I couldn't find.
Am I supposed to use the main/master git branch for all of the references in all of the config files? The examples that I can find mostly use main:
To me, it seems like at least 1 and maybe also 2 should reference versions: the package manifest should reference the git-tagged version of the groovy file corresponding to the manifest version, and the repository file should reference the newest git-tagged version of each package manifest. But that's not what I've seen when I looked a bit.
Can someone please confirm what best practices are? And, if you're so inclined, explain why as well? Thank you!
EDIT: @jtp10181's post below points out why what I posted won't work. So I deleted my post to avoid any confusion.
Interesting, you don't see anything if you search under Ecowitt in HPM?
@joshr The URL to the package manifest json (2) file is read from the main repository json when the package is installed, and cached in the HPM app with no way to force it to update it. So you will want to use a link that stays always pointing to the newest file. The link in the package manifest that points to the individual files (1) is read when you go to do an update, so this could be a changing url in theory but most people just use the direct link that always points to the newest file.
I made some notes in the instructions for moving to the new copies in my repo that even when I removed Mirco's from HPM the drivers remained on the hub (See the Cleanup section).
I am wondering whether you still have the drivers listed in HPM somehow? If so, try taking a hub backup and removing them from HPM. If they hang around on the hub then you should still be able to continue using them and hopefully the error will go away from HPM.
If they are not listed as drivers in HPM, then it's one for @dman2306 I expect..... We could dig around in the code and data kept for HPM, but I feel it's better to let dman respond first.
As far as I've ever seen, nothing. Since it's just the code being updated and not removed in lieu of the update, events schedules, etc stay the same.
Is it possible to suspend HPM checking for updates?
You could always disable the app by clicking on the red “X” on the left column (needs to be turned on from the top-right of the screen)
Great, thanks
Can anyone help me. A little confused on how to submit a PR on github for a new respositories.json addition to HPM.
Do I need to fork it first, add my submission to the fork and then do a merge back to the master. Not clear on the paradigm for how this process works.
If you just go to the file on GitHub (hubitat-packagerepositories/repositories.json at master · dcmeglio/hubitat-packagerepositories · GitHub), you can click the little pencil icon to edit as if it were you're own file. GitHub will automatically make a fork of it for you...you can just make your changes there in your browser and commit it. Afterwards it will leave you on the changed file in your fork and there will be a "Create Pull Request" button you can click to submit the PR to merge that change back into the real repo.
Thank you so much for pointing that out. Not sure how long it would have fumbled around before I tried that. Would you answer a couple of other questions?
How long does it take for the new repository to be visible in HPM?
When I update my own software and then update the packageManifest. Is there any additional step(s) for those changes to be reflected in HPM?
Thanks.
Your repository should show up in HPM once the Pull Request you submit is merged...which is based on when the owners of that repo notice it and have time to verify and merge it. I don't know how long that takes, but I assume they get notifications about it and will take a look when they have time.
I'm no expert, but I believe the answer to the second question is essentially No. Once your repository is registered, if you add new things to your repo or upgrade things, they should be picked up pretty quickly and automagically by HPM (that's my understanding). Just be sure if you change things to increase the version number accordingly. HPM devs recommend semantic versioning to ensure it properly detects your new versions.
That's right, once your repo is added to the HPM list, you can add updates to your drivers / apps without any involvement from Dominic (the HPM God...
)
Yea, I should have planned ahead and made a generic Hubitat repo to add...instead I made a repo specific to the iAqualink driver I just released so now I'll have to add another if/when I write more things. I give myself a solid B- on planning there. 
That can go either way.... Certainly a single repo makes some parts of the admin easier.... But I have certainly considered splitting my repo into separate repo's for each app / driver, or some logical break-up. I can't think of all the reasons why this might be a benefit. but certainly handing it over to someone else is easier.
That's a good point. In general easier for someone else to fork for their own purposes as well. I've always felt like when you have a monorepo, separate ones always seems better...and when you have separate repos, a monorepo always seems better. Grass is always greener I suppose. 
Yeah, don't look at my setup as an example of my own suggestion.... 
I just noticed HPM said updates were available. When I ran it, it said the updates where for the light strip and the red dimmer. It tried to do the upgrade for the red dimmer and failed with this error message which is just like the one @spartysh32 posted except mine said lzw31 not lzw30 like his was;
Download the Hubitat app
