One pattern I’ve seen for the repository list it to use github tags and the GitHub api. It wouldn’t really work without a source in the middle... but maybe it could be used to make a script to update the master list.
Hmm that is a possibility (though I'm not familiar with github's API at all), however I was hoping to not have to box people into using github. I know there are some members of the community here who provide their apps on their website, for example. The only thing I don't intend to support is apps that are locked behind a username/password type system. First, it'd be incredibly difficult to support since people are using their own login systems, not something standard like OIDC , and second, I'm not really a big fan of that model...
3 Likes
I love the idea of not boxing into Github! Great point.
Any thoughts on how to use the apps we already have installed? Would be a hard sell to tell everyone that they have to reinstall all of their 3rd party apps.
Maybe a one time, 'is this that app' type of thing and then it could assign the ID to it?
Just thinking out loud here... 
Edit: just noticed your open issues on GitHub. This is already on the list. 
Hah yeah... this is the biggest thing I haven't yet figured out. I have a thought let me know what you guys think.
1.) Add a new property to the manifest called "namespace"
2.) If both the name (this is the name of the App Code, not the label of the installed app), type (driver/app), and namespace all match, marry them up.
3.) Maybe also some manual process as a plan B?
2 Likes
Wondering what everyone thinks about being able to see the 'Choose a category' and ' Choose a package' on the same screen. Makes browsing MUCH easier, can just click around on both at will.
2 Likes
With a bit of brainpower from @aaron and some code from @gavincampbell I've gotten to the point of making it so the package manager can detect and install updates for itself using the exact same Update process that would be used for other apps .
Gavin's code will help with being able to match up based on name/namespace as well!
5 Likes
I agree, that would likely make life a lot easier! I think it's a pretty easy change too, should just be moving some code around for the most part.
Just downloaded the latest to make the adjustments and the new app has an error when installing...
2020-04-08 02:10:01.013 pm errorjava.lang.NullPointerException: Cannot get property 'https://raw.githubusercontent.com/dcmeglio/hubitat-packagemanager/master/packageManifest.json' on null object on line 1673 (prefSettings)
Ugh that's what I get for not testing a fresh install. It should be fixed now, could you grab the latest code and try again?
1 Like
I have been playing with this. I like it alot. I used to use Community installer in Smartthings to keep this up to date and get notified. I think this is great! With apps like Bond, Ecobee, and other where you need to install a lot of Master, child apps and drivers this can be a full time job. 
Keep this up it's great!!! I like this direction.
Made some real progress on matching up existing apps and drivers. There is no way this is ever going to be 100% perfect. For example, if the app name doesn't match what a user has installed, really the only option is going to be to reinstall. That being said, I added a few more of my apps to the list for testing this and it matched up things correctly. In the () are the apps and drivers I already have installed that match the ones in the package:
The one caveat, you need to include the namespace in your manifest file. So for example:
{
"id" : "214069ec-3791-45cd-baf2-4053fe41bc4f",
"name": "Presence Monitor",
"namespace": "dcm.presence",
"location": "https://raw.githubusercontent.com/dcmeglio/hubitat-presencemonitor/master/apps/Presence_Monitor.groovy",
"required": true
},
2 Likes
I added some initial work on a "Match Up" feature which matches installed apps/drivers to packages so you don't need to reinstall. This requires the addition of the "namespace" entry to each packageManifest (sorry to anyone who already created one!)
2 Likes
So, this is needs to be done on the GITHub side by the developer? I have tried this with Echo Speak and Ecobee Manager but they failed.
I'm not following... what manifest json file did you use for those two? Someone has to create it, most likely the developer of the app but theoretically anyone can.
Yea, sorry. I just user the Packager App to import Habitat-bond. I used packageManifest.json to do this within the Packer App. Worked great. I attempted the something (import url) Ecobee Manager Suite and Echo Speaks. I get a failure on both of those. Is there a special manifest.json that is needed. Does the developer create this on their site (GITHub). Or is this something we can create to get the app installed and updated as updates come out. Let me know if that helps. Thank you for the quick reply.
Other developers need to create their manifests. Since this is still Alpha only myself, @dman2306 and @bptworld have created manifests to test with.
Thank you! This is great! I really like this. It makes it so much easier to maintain.
This is on my to-do list. I'm working on newer versions of a couple of my apps (Dimmer Button Controller, CoCoHue) and plan to try this out when I'm not as embarrassed about their current development state. 
This looks like a great idea to me!
2 Likes
I'm following this as it seems like a fantastic idea.
I always tend to turn up late to the party so that others can find the bugs first. 
Is there going to be a formal beta release for this great app or should I just keep following this thread and jump in in the future.
Just wondering.
Thanks.
2 Likes
