What’s the community consensus on assuming management of an app and/or driver in HPM that the “registered” appears to have abandoned.”?
Is it just easier to fork and create a new HPM package possibly confusing users on what app or driver they want to install for a device or is there a way/council for assuming control or just removing the obsolete package?
Im trying to decide what’s the best way to ship to the wider Hubitat audience updates to an likely abandoned app and driver set (Community Bond Integration) I am fixing on for my own use.
That's the path when the Developer has left the Community and is unreachable. (Otherwise you'd just handshake with them to get access to their Repo. This is the path taken for HPM itself.)
You would fork and adjust the package name to include something identifiable, for example adding 2024 to the end. Then, in the Topic you create to announce the new release, make heavy use of the new name. Really, the HPM part is easy, it's getting the word out that is all the work, in my experience.
You would likely need to think about and provide some guidance for people on moving to your new version as well. This is not always a straight forward exercise.
@gatewoodgreen - Ideally you'll want guidance for users of the community Bond app you're taking over, but also for folks coming from the HE built-in Bond app, since it's not uncommon for an updated/actively supported community app to be more popular than some built-in apps.
Also, be prepared to be bombarded w/requests for help w/intial configuration, specific/esoteric fan setup, and dumb questions from people who can't follow the simplest instructions, and don't listen to you when you answer.
And all that above is just me.
Good on you though, will be nice for this integration to have an active owner!
Not sure I understand what you meant by "adjust the driver" HE built-in drivers can't be modified, they don't make the code available. I'm sure you know that, so I must be completely missing your question.
The HE built-in Bond app is Hubitat proprietary code, and as far as I am aware not open to direct community modification. That's not to say they (HE) can't ingest the model of this work.
My starting goal was to fix issues I had with the community integration, especially since the 2.3.9.192 Google Home update. The original community (DMan's) code is an incomplete implementation of some core Hubitat device models (eg fans) which is what tripped up the latest Google Home integration app.
Also the community Bond driver(s) model is children of an app that implements common management code and also teases out grandchildren devices.
Yeah, my post wasn't clear, I was only talking about selecting a different driver, but had forgotten about the potential for a parent app relationship.
I wasn't connecting the dots.. Dominic is still reachable. Although it can take a week or more. But check that he has a License for the work. He has, in at least one case I followed, added a License when there wasn't one already, allowing the work to be re-used.
If you keep the same driver names and namespace, it would be as simple as Unmatch in HPM, then matchup and select the new package. Then run a Repair to force download all current code from new repo.
If you change the name or namespace, then I would suggest adding one extra step after UnMatch, which would be to manually update the code for each item. Then run the Matchup and it should match to the new package only.
Either of these would keep an existing app/devices installed and working, the code would be updated behind the scenes. Least disruptive to users.
Of course lots of people WONT follow the instructions and install new from HPM, create a huge mess and be confused.... as we still find to this day with the HPM transition to a new repo.
My only edit:
