I am looking and transitioning the EcoWitt drivers Mirco developed across into my own list of drivers. Just wondering how it will play out.... My current plan / work I have done is to:
fork his code into a repository under my GitHub account sburke781/ecowitt
update any references to point to my ecowitt repository, including the HPM package manifest json file
update my repository json file under my sburke781/hubitat Git repo to reference the package manifest under the ecowitt repo
I have left the namespace as mircolino for now, want to do some more investigation on how best to handle that.
Does this sound like something that will work? Not sure how people will transition their drivers to the one I am now hosting? Or will it just work?
If you keep the id fields for the component entries the same in the package listing and have the package listed in a repo listing that is known to HPM, I would expect a higher version of an existing package to just upgrade. You could test to confirm.
As for changing the namespace, this template has an example of that. Though if you are just hosting the same files it seems unnecessary unless there's a technical reason to do it or if you make major modifications or additions.
Thanks, I am going to add it to my repo and believe I will have the same id's, so you are probably right.
I was loathed to change the references to Mirco in the HPM stuff, seems unfair given he has done all the dev so far. I expect will make a few tweaks from time to time, and wanted to give people an indication of who to talk to if they have any issues, certainly not to take any of the glory...
It would feel a little odd to keep the namespace, may only create confusion. But I didn't want to take that leap straight away, am focused on getting the code available once again.
Thanks for the sample code, I'll take a look when I get to looking at the namespace.
Doesn't look like the same id's was enough. I was even able to install a separate copy of the two drivers from my repo. I tried matching and doing a repair, but neither seemed to switch the drivers over to my version.
Should be a simple process for people to manually switch the drivers referenced in their devices, might test that myself.
EDIT: Not quite, can't change the driver for component devices...
Just checking, did you have the package id (at the repository.json level) the same in addition to the driver components (at the packageManifest.json level)?
There's an id at the repo level, but it's for the full repo and doesn't seem to be settable on a package by package basis. It would be interesting to see if using the existing repo level id on top of the existing packages ids allows a match to the old package, but probably not practical to continue with the old repo id if your goal is to merge this new package into your own existing repo file.
You may have to continue going down the migration instructions path. Thanks for fighting the good fight to keep this available.
Still not quite sure where you are talking about for the repository id, unless you are talking about the central list of all repos, that also does not include an id, only a name and a url.
Either way, I think I might still look at options in HPM to match them up, as I can't change the component device drivers. Even if people manually updated the component drivers in the Drivers Code section, that wouldn't allow future updates to flow through, you would have to do it each time.
Thanks for your help on this. I only recently brought some of my drivers into HPM, so still learning the ropes.
This isn’t a use case I designed for. I’m not sure there is a way to do what you want. The url of the manifest is the internal id. If that differs, then it’s a new package.
Remember, if what you’re trying to do here was possible, it would mean people could maliciously take over an existing package and potentially replace it with malware without the end user ever knowing.
Are you talking about the URL in my repositroy.json? I am assuming you are... Hmm, might have a think about it and see if there is anything I can think of... Best I can come up with at the moment would be something similar to the old/new namespace option @tomw pointed me towards. I wonder whether you could do the same thing here...
Good point.... So it would need some kind of user involvement to accept this as a change they trust. Not saying I would still suggest my last option.... need to think on it some more...
Also the namespace/name only impacts match ups. If the user already has it installed, it’s tied to the initial url. I can see situations like yours where what you’re looking for would be useful, but it’s not functionality currently implemented. Really it’s not just about the end user, it’s also about the current repo owner relinquishing control too. Even if the end user agrees, should you be able to redirect everyone who has my apps to install your version of them without my permission? Seems a little shady.
Granted, my earlier suggestion would have produced this outcome, if you implemented it as I described. What I am now thinking about would be something like I, as the developer, maintain a completely separate copy of the drivers, with different id's and other references from the existing code on HPM. Perhaps under something like the Repair or more likely Match-Up option you could choose to replace the existing drivers from one package with those from another. Thinking about it as I write this it could cause all manner of pain from a HPM development perspective, i.e. for you, if there are differences in files, etc.
I think in the end I need to come up with another approach. Just not fussed on people having to re-create their devices. But that isn't your your problem to solve...
I think that is likely to be it, but they will also need to delete their devices from what I can tell. I mistakenly chose to try and delete the wrong drivers earlier when I was playing around on my HE hub and HPM thankfully picked up that the original drivers were being used by existing devices. So I don't think they will be able to uninstall without removing the devices. I'd like to avoid it but I don't think I can...
That's funny- was basically what I was going to use as a test case for further investigation, and it occurred to me that allowing that would be bad. Thanks for stepping in to confirm.
Could your upgrade instructions detail how to install the new package, migrate existing devices via the device config page, then uninstall the old package?
