I think you're looking at Optional installs:
"primary": true,
"required": true
"primary": false,
"required": true
"primary": false,
"required": false
Each component in the Package Manifest would have one of those pairs. Then during install, the option menu.
In that Package I selected the "main" app to be required and primary, then a component to be required and not primary, which tells it the order to do the install. The final component (dim) is completely optional.
Interesting, I didn't know about primary before. Can you explain more about what this does?
I use required extensively. For example, I have several integrations with drivers (required) and apps (optional, with additional functionality).
What I have here is different, in that I want to have the same app be optional for two different integrations, which may be installed on the same hub. So, I want to make sure that either can add it, but neither can remove it out from under the other.
Does primary help with this? Or is there another way to do this? I thought about using bundles, because the source files get left even if the bundle is removed, but that felt like sort of a hack.
I tried this out by mocking up two packages. The both included an unrelated "required" driver and the same "optional" app with the same "id".
When I installed the packages, it installed two copies of the app. And I could remove each package and it would remove its respective copy of the app.
This helps with the concern about one pulling the rug out from another by deleting the source. But it creates a confusing situation where there are two instances of the app installed and usable, and I really want one instance of the app that can reference instances of different drivers/devices.
It looks like my solution is going to be to have the shared app as its own standalone package and to recommend it as a separate install in the readme of each driver package that it supports.
I'm getting closer to understanding your intent, but I'm not there yet.
My interpretation is that you have one App and a 'collection' (one or more) companions that fall into two targets... You have Package 1 that contains the App plus companions A, B and C, while Package 2 contains the App plus companions D, E and F
You want one Manifest that will read the users mind and install either Package 1 or Package 2. I can see it working with two manifests.. a Package 1 and Package 2, each with their own list of components and with overlap on the App, which is common.
I can see it working with a single manifest that has everything and the companions are all optional. Naming the various companions would then guide the user to picking the ones needed.
The App would be
"primary": true,
"required": true
Then all the companions would be:
"primary": false,
"required": false
"primary" defaults to false so it's redundant. "required": false means that an option menu is displayed and the user can pick one or more.
I can't think how it would hurt to install all the companions. But I know OCD can be a factor 
If the App and all the companions are added, does the App know what to do? Or is mind reading required also? You're hoping to install just the pieces that would clue the app into which form it takes?
As I said, I'm not convinced I have a grasp on your intent yet, but this is my best guess from the clues. HPM doesn't have If-Then-Else logic in the Manifests.
My mind map is the opposite of yours in terms of which is the companion to which. I'll describe it in more specific terms, and hopefully that helps:
Package A is for camera manufacturer A. It has a parent driver and some child drivers for various types of hardware. The child drivers have a command that stores snapshots in a particular format.
Package B is for camera manufacturer A. It has a parent app and a child driver for the hardware from that manufacturer. The child driver has a command that stores snapshots in the same format.
The app I'm trying to figure HPM support for knows the same snapshot format and serves it up via an HTTP endpoint (for dashboards, etc) and can also send it in a Pushover notification. In the app, you can select devices of both types (A and B), and then the app does its thing.
It's unlikely, though not impossible, that a user will have hardware A and B. So installing both all the time would be very weird. But the possibility of them both existing is the problem I am trying to solve. I have both on my system now, and it is affected by the problem I described in my previous post -- two instances of the Apps Code installed, etc.
I am seeing something odd [BUG?] with the MODIFY option. Even when unchecked in the list, HPM still tells me that it's going to uninstall the package. I am not sure if it will indeed uninstall it as I didn't continue.
On the Modify window, you should check the things that you want to have stay installed. Unchecking them indicates they should be uninstalled, sort of like having them unchecked during the initial Install step. You can also check new things during Modify if you want to add them.
Seems counterintuitive but that's probably just my warped way of thinking.
Thanks for the reply. It's much appreciated.
I banged my head against the wall a bit during the HPM install and want to add these comments as a first-time installer:
I expect that I'm going to love this, but the out-of-box experience was between "not idiot-proof" and "actually rugged" and I think a couple small changes to those instructions could make it a lot smoother.
I was just reviewing my logs and noticed these messages. I thought I would post them here for the developers. I am running 1.8.8 version of the Manager.
The BPTworld packages he moved to his own Bundles app and removed from HPM, you need to use "Unmatch" in HPM to remove them from HPM. Install his other app if you want to get updates.
For my Zooz driver, I moved the manifest a while ago, you need to unmatch then run matchup again to pair it up with the correct file.
Thanks for the response and I will follow up and make the changes you suggested.
Just completed a C-5 to C-8 migration.
This is the least of my problems so far, but I opened the Package Manager on the C-8 and got:
app:4062023-03-03 09:50:07.750errorjava.lang.NullPointerException: Cannot get property 'repositories' on null object on line 3937 (method prefSettings)
app:4062023-03-03 09:50:07.710infoSkip download of https://raw.githubusercontent.com/HubitatCommunity/hubitat-packagerepositories/master/repositories.json: java.net.UnknownHostException: raw.githubusercontent.com: Temporary failure in name resolution Please notify the package developer.
Just an FYI in case you haven't tried the new C-8 and the latest Hub software.
SK!
Sounds like a DNS issue.. "Temporary failure in name resolution"
Try... Settings:Network Setup:Network Test and ping by a name:
I used the "Override DNS Settings" and made a list of local to remote DNS resolvers and then the Package Manager was happy.
Now I'll retest all the things that are failing on my migration.
You were right on!
From a quick scan through your other thread re: migration issues, it seems it’s all related to an underlying DNS issue?
It certainly looks like that was it. And, it all made sense once identified.
Don't understand where the lost setting got lost or damaged.
I don't even recall setting any DNS entries in Hubitat and my router has no reason to treat a new local IP any different than any other local IP or block DNS.
Freaky Friday.
DNS is just one (but major) slice of the networking pie. No network connectivity at all would also throw a DNS error. It's come up 8-10 times and HPM seems to be an App people use early.. and thus I get to see this often enough to have an answer in my Parrot Memory.
Was this issue of null components being listed in HPM ever addressed? I've got one and don't want to Uninstall it without knowing what it is:
@csteele, first of all thank you to continue maintaining HPM.
I would like to ask if you think it could be possible to add a new type of file in the packageManifest that would be "libraries" in the same way that drivers and apps are added as it was proposed a while ago by @birdslikewires.
I don't know how much effort that would require or if it is even possible.
I do know that it is possible to add bundles which could include a single file like a library, but I don't like that fact that people can't see and update the code on Github since the code is burry into zip file. Althoug the source files could be added on Github. I understant that bundle is already a solutions and for some situation it is also a preferable solution, but for other situations, I believe that adding library file the same way that app and driver are added is easier.
Download the Hubitat app
