Issues with updates

[Shivy011]

I'm trying to update Predbat to any later version, and I keep getting in log

71283 | 2026-08-31 16:41:19.757028: Warn: GitHub returned status 403 for https://api.github.com/repos/springfall2008/batpred/releases - will retry next cycle -- | -- 71227 | 2026-08-31 16:40:46.736716: Warn: Predbat update failed to download Predbat version v8.54.2 Critical Octopus bug fixes 71190 | 2026-08-31 16:40:41.357206: Warn: Predbat update failed to download Predbat version v8.54.2 71097 | 2026-08-31 16:40:00.906852: Warn: GitHub returned status 403 for https://api.github.com/repos/springfall2008/batpred/releases - will retry next cycle 70990 | 2026-08-31 16:35:00.210767: Warn: GitHub returned status 403 for https://api.github.com/repos/springfall2008/batpred/releases - will retry next cycle

predbat_debug.yaml.txt

I've attached the debug too
Predbat version
8.53.4

[springfall2008]

Automated first-pass triage (a maintainer will review before any action is taken).

Classification: bug
Priority: priority_low

What I investigated

The two warnings come from two different code paths that share one cause:

• Warn: GitHub returned status 403 for https://api.github.com/repos/springfall2008/batpred/releases — the release check in apps/predbat/github.py:96 issues a completely unauthenticated requests.get(url, ...) every 5-minute plan cycle (2-hour success cache, but a 403 is deliberately never cached, so it retries next cycle).
• Warn: Predbat update failed to download Predbat version v8.54.2 — the self-update in apps/predbat/download.py:79 needs the same unauthenticated API (/contents/apps/predbat?ref=<tag>) to fetch the file listing before it can download anything; the listing request is also rate-limited, so the update aborts. (The per-file error text for this goes via print() to the addon stdout log rather than the HA system log, which is why the HA log only shows the two warnings above.)

GitHub returns 403 on the REST API when the unauthenticated quota is exhausted — 60 requests/hour per source IP. Predbat sends no Authorization header anywhere (it's an explicit empty header dict in both call sites) and there is no config option to supply a token, so an install behind shared egress — CGNAT, VPN, corporate proxy, or anything else on the same public IP making GitHub API calls — can have the pooled quota spent by traffic Predbat never generated. Nothing in Predbat itself is high-volume here: normal steady state is one release check per 2 hours plus a couple of API calls per manual update attempt; but the two do contribute, and neither path reads X-RateLimit-Reset/Retry-After or backs off, so under rate limit the log carries the warning every cycle and stays pinned at the limit.

Confirmed against current main (v8.54.2-19-gf3ddb4c5): both call sites are still unauthenticated with no backoff. The zip-archive bulk download used since v8.47.6 (codeload.github.com) is not API-rate-limited, so only the release check and the initial directory listing need quota.

What this means for the reporter

This is environment-side, not a broken release: the release exists and the updater's files are fine. The quota window is rolling — wait roughly an hour without repeated update attempts and retry once; if the 403s then return quickly, the shared-IP theory is confirmed (a phone-hotspot update attempt is a quick differential test). v8.54.2 is the version with the critical Octopus fixes, so it's worth persisting with the retry.

Possible improvements if the maintainer wants to harden this

• Support an optional GitHub token (even just a GITHUB_TOKEN env var passed into requests.get) — authenticated quota is 5,000/hour per account instead of 60/hour per IP.
• Honour X-RateLimit-Reset/Retry-After on 403/429 and cache the failure for that interval instead of retrying every 5-minute cycle, so a rate-limited install stops contributing to the problem it's reporting.

No test was run for this one — the failure is a live-API rate limit, which the mocked GitHub/download tests can't reproduce.

[chalfontchubby]

I had issues with this sometime back - I ended up killing a number of other github applications running on other machines in the house - but I suspect most people don't have lots of things all pinging github.

Typically - wait an hour or two and retry.