Bundles are being added to HPM. There's a story there, but doesn't matter much now. Last year, I grabbed a copy of HPM "just in case". I built a Fast Search feature and made it selectable. Last year, I also got Bundles working, at least the easy part.
The first thing to do is migrate people from 1.8.2 from dmeglio repo to 1.8.3 on HubitatCommunity repo. Because of the Holiday I chose NOT to pile update on top of update and am letting the migration percolate out.
As stated above... v1.8.4 is "done, sitting on the shelf" waiting for a large number of HPM users to migrate. I'm itching to release it, but I'm trying to be kind too.
v1.8.5 will be for Bundles. Bundle Install, Bundle Repair, Bundle Uninstall, View Apps and Drivers are all tested and working. Match Up isn't, and both Update and Modify haven't been tested, because I have to build bundles that would test those features.
In other words, until this holiday weekend, Bundles were NOT going to get added to HPM. Brian chose, like I did, to invest in getting Bundles to work, but along different paths.
Oh this has been a discussion for a year now? Sounds like "Bundles" is a solution in search of a problem.
First thing I thought of when I read "bundle" was, how does it manage apps with multiple drivers in which I only need one of the drivers? Like those apps that handle color bulbs, white bulbs, switches, outlets all with a different driver. I would usually only install the specific driver I use. Bundles just sound redundant with less value to me.
That is a choice made by the author of that "package" (app/driver/etc.), not the creator or maintainer of HPM. If this is important to you, I would suggest providing feedback to the developer who made this choice. Nobody can force an author to use HPM or stop them from using a different solution.
Also, in case you aren't aware "bundles" is a new-ish platform feature that lets you upload a ZIP file to the hub to install apps, drivers, and/or libraries (also new-ish) without needing to add each individually. This is not something HPM or Bundle Manager created, though it looks like HPM will support bundles soon (yay/thanks!). Bundles are very handy for manual installs of multi-file apps/drivers (think of HubConnect, or for me, CoCoHue)--perhaps less so for automated ones like this, but I still think they'll be easier for developers to maintain since it's less HPM-specific work they'd have to do. Very much a solution to an actual problem, IMHO.
I don't know what the original use case for Bundles was BUT for HubConnect it was an answer to a huge support problem. Unfortunately, it didn't arrive in time. Many people couldn't wrap their heads around "Drivers go in Driver Code, Apps go in Apps Code" and many others would just decide that drivers were entirely optional. The product simply wouldn't work under those circumstances.
Bundles can contain Apps and Drivers. Installing them, even without HPM, yields the components landing in the right spot, at the very least.
In my opinion, Parent/Child products are better served by Bundles, because it's fewer clicks and no "parent then child? or child then parent?" install ordering question arises.
For single modules, Import is the simplest, BUT then you run into exactly what you started with.. different methods for different circumstances. HPM targeted exactly that, again, in my opinion.
Thanks for the explanation @csteele , that clears it up a lot. And yeah, I already use hubconnect so I'm aware of that list lol. I remember having to read through that lengthly install doc to get that working.
I have not looked at Bundle Manager because I've been spending all spare minutes either responding in the Community or pounding away at my Typos as I get Bundle support added to HPM.
I think Bundles are and will continue to be low usage. For a developer, they solve a specific set of issues and if you don't have one of those issues, why take the time? But my recent work, be it HubConnect, or Honeywell Thermostat, have all been multi-part and bundles help. Would I build a bundle for Aeotec MultiSensor 6 ?? no.. it would duplicate what HPM is already doing well.
Because the Dimmer child is optional. HPM installs both the Parent and one Child... leaving the 2nd child as optional.
Install the Bundle, all 3 components are added. For a lot of people, who don't want to struggle with the terminology, the bundle as a one-shot answer is ideal.
I don't want to confuse by answering in long form BUT the tradition around here is for the "owner" to use the top message in the thread to keep a running tally. Slightly to the right of these words, is "May 26" - click that and you go directly to the first message, where "v1.8.3" is identified as the current release.
Yes, I have discussed, more of a tease perhaps, the next two versions, but I expect it will be the weekend before I release the next. I'm really just trying to give the greatest number of people the opportunity to click on the migration release. Right now, both repos (old and new) are the same. But from here on, I'm only planning to release via HubitatCommunity repos. Thus stragglers would go from 1.8.2 to 1.8.3 using the old repo, which instantly switches them to the new repo, where there would be another update. The hubs don't care, it's the humans that would freak, I suspect Not everyone, but we know there would be some.
There is some oddness here. I have been running HPM 1.8.3 (as shown in the Groovy app code). Clicking Update in HPM said no updates available. Oddly, “View Apps and Drivers” showed HPM 1.8.4.
