That's alright, I'd point out that HE is not a phone, and your talking about official supported app stores on mobile, whilst we're talking about disparate community content and making it easier to find. If some apps are available on one but not on the other, then new users to HE and home automation which has enough challenges as is will get confused about why they can't find what they're looking for. I wouldn't point to the mess on mobiles as a model to follow anyway, I just don't think it's a good idea for community apps to be hidden away in separate places. Anyway, I don't want to derail here, or create any further tension. My view is simple, keep it as easy for people as possible, and any added complication will only make things worse not better imo.
Edit: I'd also like to add that Bryan is an amazing developer and member of the community, so his hard work is always appreciated and shouldn't be taken for granted either. Same goes to csteele. We're just so blessed to have folks like them in our community to elevate our homes even higher.
Having a bit of an issue. A few days ago I got a notice I had updates available on all of my hubs. When looking at the apps page a update was indicated on each hub. When I ran the update, however, it said all my apps were up to date and nothing was available. Just figured it was part of the move over process and didn't worry about it, otherwise all seemed ok.
This morning I got the notice again and same thing, all hubs showed an update available but on each no updates were available.
So I tried a repair of HPM on my rules hub and I got the error shown below and the process would not complete.
java.lang.NoClassDefFoundError: user_app_dcm_hpm_Hubitat_Package_Manager_118$_copyInstalledItemsToNewManifest_closure87 on line 3573 (method performRepair)
On this hub under view apps and drivers I see HPM is 1.8.3, however on the main page there is small text saying it is 1.8.5.
No... I haven't found a situation where a reload / reinstall is needed. For me, Repair gets the latest code, which is 90% of the goal. I'll look into why View isn't matching.
As I said a few messages ago, Apps and drivers aren't required to contain a version and those that do, implement it in a variety of ways. Adding a visible version to HPM was one of my ToDos. It makes it easy to know you're using the intended version. View however displays the version from the Manifest, and is what HPM uses for it's comparisons.
I'm seeing a weird issue where now I have TWO HPM apps listed within HPM. You can see it in the screen shot below. I can't figure out how this happened, but any insight into how to fix this, would be awesome. One is 1.8.4 and the other is 1.8.5.
Being the impatient type I just deleted HPM from Apps and its code from Apps Code, reinstalled the code using the link and added HPM back to the Apps list. A quick "Match Up" and it's as good as new.
It's strictly a cosmetic thing. I understand using "the big hammer" to fix it, but nothing but a display got fixed But yes, that big hammer does the trick
Be careful, and don't hit your thumb.
Remember, HPM can only get HPM code from the single repository. There aren't two copies.
Sorry for the dumb question, but for some time I've quite liked the idea of using the Libraries code feature to reduce duplication (and maintenance!) in my drivers, but I've always assumed distributing those would require a bundle. Is this right?
If so, do I need to go through this manual process of creating a .zip? That seems like it would be a pretty laborious process, moreso than just copy-pasta-ing the "library" block at the end of each driver and updating the repo directly via GitHub.
If not, how do I use HPM to install both driver and library code? Could I simply make the library code mandatory using the existing "required" tag in packageManifest.json under a libraries block, something like this:
Click Bundles:New Bundle and get that screen. Just select the pieces. Give it a name, give it a namespace and click Save and export. Bingo. You're all done.
Mmmm, that was what I feared. I have a bunch of drivers split by manufacturer and don't necessarily want to force the end user into installing all of them when they may only have one device from that brand. Looking at this I would need to clickety-click through this process for each driver and its associated library to keep that granularity.
Would adding the library as a requirement in the manifest not work? I haven't checked if this is a supported thing to do, but I figured apps and drivers land in the right place with HPM anyway, so perhaps the same would be true of libraries..?
The final item I have on my HPM wish list is what others have called "Un Match" -- it's a mechanism for allowing a package to be "rediscovered" during the Match Up process. In other words, you'd Un-Match a package, then do a Match Up to cache the latest Package Manifest. I think this would be used when a Developer relocates or restructures their Manifests.
This is a tease of what I have built:
Let's start with a slightly familiar instance, I need to clear out the existing cached Manifests...
I begin here:
I select the Package Manifests that need to be cleared from cache:
I'm seeing similar. For a few days I was getting prompts to say there were updates available but then when I ran the update it says everything is up to date.
I ran a repair and it installed 1.8.5. However this morning the banner is there again 'updates available'. When I've ran the update, it's telling me that the latest version is 1.8.5 and that 1.8.3 is currently installed? The image below shows this and the screen also indicates that the current version is 1.8.5 already. I've checked and there is only one instance of HPM installed:
Looks like I have all my hubs up to date on HPM. On each hub I repaired which added the banner saying it was at 1.8.5 but generated an error and rolled the code back to 1.8.3. I then did an update and the code was back to 1.8.5 and had the banner.
Except for my last C7 hub it did not generate an error during the repair but it still rolled the version back to 1.8.3. Doing an update then brought it up to the current revision as well.
As long as it's only displaying 2 HPMs and not actually running 2 HPMs, I'm okay to leave it like that until that display issue is resolved. I'm not a big fan of uninstalling / reinstalling if I can avoid it. I feel like i'll lose all my configurations if I did so.