When I run HPM and try to match up apps and drivers it appears to stop with this message:
Downloading package manifests
Failed to refresh https://raw.githubusercontent.com/serenewaffles/hubitat/main/repository.json
This isn't normal is it?
That repository was Quarantined back in late October.
That implies you're not running the latest HPM. It feels like you're still running Dominic's version 1.8.2
The current version is 1.8.7 and you can directly import that using this URL:
https://raw.githubusercontent.com/HubitatCommunity/hubitatpackagemanager/main/apps/Package_Manager.groovy
When you run HPM using the current code, the top section of the page looks like this:
Notice the version display on the right.
Interestingly enough I am on 1.8.7. I looked through the long repository list in HPM and I couldn't immediately spot the defunct repository in the list. I even went into the app code and in the code header it had the HPM version list, and that too was 1.8.7.
For the last 3 days I am now seeing this error at midnight when HPM checks for package updates. I did a repair on HPM and still see the error. I know we have a new developer for this driver. Is there a fix coming or something I can do to resolve this?
Bad manifest for Ring Alarm Keypad G2 Community Driver. java.lang.NullPointerException: Cannot get property 'betaLocation' on null object Please notify the package developer.
errorError downloading https://raw.githubusercontent.com/bptworld/Hubitat/master/Drivers/Ring%20Alarm%20Keypad%20G2%20Community/packageManifest.json: groovyx.net.http.HttpResponseException: status code: 404, reason phrase: Not Found
Not an HPM issue as BPTWorld pulled all of his packages in favor of his Bundle Manager. To fix, do an Unmatch on the driver.
3 Likes
I think that's the fix for both issues: "serenewaffles" and "Ring Alarm Keypad". Neither exist in HPM anymore. Both owner/authors have deleted their manifests for the Package and it exists only within your hub's HPM DB. The solution is to UnMatch those specific Packages.
To validate, you can visit this website and try and find the Package.
There's a column of Alphabetically sorted Package names and if the Package in question is found in that list, there's a possibility of a broken Manifest. IF however, the Package. doesn't exist, you know to UnMatch it.
Broken Manifests get Quarantined ("serenewaffles" for example) while I try and work with the developer to fix the typo.
The DataBase (DB) behind this site is rebuilt every 20 mins. A developer releases a new Package and adds it to their Manifest, 20 mins later it will be in the DB and shown on that site. Conversely, a developer removes their Package from their Manifest, the entry vanishes from that site in 20 mins.
Ring Alarm Keypad G2 Community Driver <-- new name (adds "driver")
Does exist and that means a migration occurred.
1 Like
I disagree. This has come up several times now (NOT just with my offerings). Anytime an author removes an app from HPM for whatever reason, it breaks HPM. That is an issue that should be fixed, in my opinion.
BTW, this item has nothing to do with BM. I'm no longer maintaining that driver and a new developer was nice enough to take over the code. So I removed my version from HPM.
2 Likes
I agree. IMO, a missing manifest should be a non-fatal error for the rest of the HPM functionally.
Happy to help with an HPM fix it that would be useful, but ultimately it is @csteele's call.
3 Likes
The code indicates it's skipped:
if (fileContents == null) {
log.warn "Error refreshing ${repoName ?: uri}"
setBackgroundStatusMessage("Failed to refresh ${repoName ?: uri}")
continue
}
The above is inside a For Loop and the Continue will cause For to move to the next. It looks like it's displaying an "Error" and then continuing.. maybe "error" is too aggressive a word?
The continue statement complements the break statement. Its use is restricted to while and for loops. When a continue statement is executed, control is immediately passed to the test condition of the nearest enclosing loop to determine whether the loop should continue. All subsequent statements in the body of the loop are ignored for that particular loop iteration.
4 Likes
I generally look at the log level for an indication; in this case it’s a warning so yes it’s an undesirable but it’s being handled.
Yes, indeed! I think the word "Error" threw me off, but it does seem innocuous given that implementation. Thanks for explaining.
I think this has split into two issues..
- What to do about message wording that can be interpreted alarmingly.
- What to do about missing/removed Packages.
For message wording, I'll suggest that the word Error be eliminated since the log category is "warn."
In fact generally I think I should 'square up' the messages. Events that are handled get Warn category and Error be used for unhandled issues.
If I look at #300 above, this screencap is a great example of this topic:
The repetitive nature indicates it's being handled, but the Red Error is too strong. Warn would be better but I'm even leaning towards Info.
1 Like
On to the more intricate issue: Missing/Removed Packages.
I believe UnMatch solves this. An "auto unmatch" is pretty scary to me.
I know when I'm updating my manifests, I don't get done in a second or two. If a random user happens to be doing a Matchup at that moment, and an Auto UnMatch occurred, I'm not seeing the benefit. For BPTWorld and his transfer of a Package example, I can see how a new verb in a Manifest could invoke an UnMatch but could be used maliciously, and that doesn't work at all for abandoned Packages.
I've thought about this more than a few times, especially when coding up UnMatch. I never got to the finish line with it so far. 
2 Likes
Agree, I would make that a manual step always.
Maybe collect a list of apps that were skipped and output a suggestive message that the user consider removal if the occurrence repeats itself?
"The following packages were skipped due to missing/unreachable manifests. If this is the first time you have seen this message, it may be an anomaly. If you continue to get these warnings, contact the developer or unmatch the package within the Package Manager App."
2 Likes
How about putting the word "Warning(s)" in yellow on the main Apps page. Like when there are updates you add a message in green that Update are Available.
Then maybe in the HPM app, you show the warnings first before options. Just my first thoughts on this.
2 Likes
I agree with this sentiment.
Error = this thing is broke
Warn = this thing isn't working as intended, but isn't necessarily broken
Info = normal operations
I would consider a broken repo being found and skipped as normal ops. If HPM was halting at that repo, then maybe that warrants an error.
2 Likes
We recently got my new repo hooked up, but HPM doesn't show the Ring Keypad Driver package using Search by Keyword (fuzzy) Ring or Keypad. The package does show up for all other methods, including Keyword (fast), Tags, and From URL.
What do I need to add/fix to make keyword (fuzzy) work ? I looked at hpm docs and browsed some other folks' repos, but I'm not seeing it. I see it's happening to some other packages too, like Iris v1 Keypad.
"Fuzzy" uses Dominic's Azure based search. When he announced the first time that he was moving to HA, I created the "Fast" replacement because I assumed he'd discontinue Azure. He didn't and even said he wouldn't, but "out of sight, out of mind" may occur and he wouldn't be checking it. Like "Fast" it automatically reads in all the manifests and builds a search DB... I know that I've set "Fast" to rebuilt every 20 mins. It's possible Azure gets "stuck" and needs a manual intervention. If so, I can't imagine he's checking often anymore.
2 Likes
I spent some time looking at each of the two issues I mentioned:
- What to do about message wording that can be interpreted alarmingly.
- What to do about missing/removed Packages.
I've gone through the code looking for Error level messages and how best to interpret them. Not surprising to me, Dominic's code is very good at ignoring/skipping them. He just chose "alarming" words I think. Looking at that #300 above, all of those are ignored. HPM just keeps on working, as I mentioned. As yet unreleased, but I've 'downgraded' them to "Info" level and reducing the intensity of the words.
These "errors" are problems that the Package Developer introduced and don't cause HPM to stop or fail. HPM just ignores them. Admittedly, the Manifest flaw can have an effect elsewhere, but for these examples from MatchUp, they have no direct effect. By that I mean: if the developer has intentionally removed the package or manifest, then HPM can no longer find updates, install, or repair those particular Packages. You should treat them as information and choose how you wish to handle it. Contact the Developer certainly and see if it's intentional.
I've also looked at how to assist with "Owner Migration" of a Package. I'm testing for unintended consequences, but I have made some progress:
info A repository was removed, [https://www.hubitatcommunity.com/hpm/communityrepo.json]
debug missingRepositories: [[name:Community Code, location:https://www.hubitatcommunity.com/hpm/communityrepo.json]]
info A new repository was added, http://192.168.7.42/communityrepo.json
info Refreshing repository list
info A new repository was added, https://www.hubitatcommunity.com/hpm/communityrepo.json
info Refreshing repository list
info Matching up packages
I created an alternate Manifest system that I can edit viciously and not affect anyone. I killed an entire manifest from the fake Master. Then put it back. Dominic's original code correctly discovers the new manifest. (bottom 3 lines)
Changing the location (URL) means it's an entirely new manifest and the original code found the new URL, but my experimental code detected the missing manifest and removed it.. effectively transferring the repo.
As I said, detecting unintended consequences is going to consume a lot of testing time. I don't want this to be ONLY a tease.. but I'm sure this won't be ready for release quickly.
10 Likes
