@dman2306, I'd be more than happy to help test and give feedback. GitHub username is the same as it is here, bptworld.
Thanks!
3 Likes
Added, didn't realize that private repos on a free account only let me add 3 people, so if a bunch are interested I'll just make it public.
Thanks! I used your packageManifest as a guide and created a new one for one of my apps to test. Very easy to do and well laid out. The only question I have is on the packageId, App Id's and Driver Id's. Do you recommend a program to create this string of digits? Will each dev get some sort of identifier so no one else can create the same set of digits? I simply changed the first set of numbers to my zip code to test.
Testing went very well. I installed a package, then modified it and then uninstalled it.
Mind blown! This is going to make things a lot easier for everyone!
I look forward to moving all of my apps/drivers to this down the road.
Also, feel free to PM me with anything you like me to do, test, etc. 
4 Likes
They're GUIDs/UUIDs (Globally/Universally Unique Identifiers). In theory, they're unique in the universe unless you purposely make a duplicate. I plan to make a tool to generate the manifests, but in the meantime https://guidgenerator.com/ works.
To try to make this even easier on end users, I just introduced the concept of a repository. That is a place where you can list out all of your packages so the user can just choose from a list. So how do people find out about your repository you might ask?
@aaron and I discussed this and came up with this.
There is a 3 tier structure:
- Master list of repositories (https://raw.githubusercontent.com/dcmeglio/hubitat-packagerepositories/master/repositories.json)
- Then each developer creates his/her own repository file (e.g. here is mine https://raw.githubusercontent.com/dcmeglio/hubitat)
- Then each packagemanifest defines the details of a particular package.
The tricky part is #1. How do you get your repository in the list? Well the best we came up with was sharing access to that github repo with a trusted set of HE community members. I really don't want to be a gatekeeper to who can release packages and who can't. This was the best we came up with for now. If anyone has any suggestions, I'm all ears!
Anyway this is the install screen now:
There is still a bunch to test and cleanup before I consider this ready for prime time (I already identified a few bugs). I've cleaned up the code enough to where I'm no longer embarassed by it, so I just made it public. You can find it here GitHub - dcmeglio/hubitat-packagemanager
Anyone who wants to look at the issues list and submit a PR, I'm certainly open to help 
5 Likes
The app is really cool... can't wait to see how it turns out.
For anyone interested in contributing their apps to use this framework, I added documentation on how to create a packageManifest, a repository, and how to get your repository added to the list. You can find this info at hubitat-packagemanager/README.md at master · dcmeglio/hubitat-packagemanager · GitHub
Hopefully people buy into this, it'll be kind useless if only 1-2 devs use it
6 Likes
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.
