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.
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.
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;
As many might have noticed by now, Dominic has decided to leave the Hubitat Community and has marked himself as no longer active. One of the first questions that brought up is what happens to HPM.
I forked his repo, as he suggested, many months ago when the handwriting was on the wall. I also took some time to augment the Search feature he built in that relies on him maintaining an Azure site. I've had that functional for quite a few months, where I added a switch to pick the search method. "Fuzzy" using Azure, or "Fast" using the search I built.
The purpose is to provide stability. If Dominic closes the Azure service, this fork will continue to work using "Fast".
Thanks for your efforts @csteele . What happens with the config file that controls the published repos now? It is also hosted in Dominic's GitHub here to which we also wouldn't have control?
We should also update the README accordingly for your fork. Are the controller/owner of that HubitatCommunity on GitHub I assume?
I know the answer is very unlikely to be yes, given previous expressed views, but I really think that the HE team should consider building this into the platform, even if it has GIANT warnings on it about unsupported user code/no guarantees, I think HPM adds so much value to the community side it would be a shame to see this fall down. @bobbyD@bravenel@gopher.ny@bcopeland .
Please consider having this as part of the platform. Pretty please.
)
