solcast_poll_hours 4.8 is silently truncated to 4h, exhausting the Solcast daily quota

[wwicks]

Found and drafted with help of GLM 5.3 Flash in the new AI chat.

predbat (6).log

Describe the bug

UserInterface.get_arg() coerces the resolved value to the Python type of the default it was given:
elif isinstance(default, int) and not isinstance(default, bool):
Convert to int?
value = int(float(value)) # userinterface.py — truncates 4.8 -> 4

Component args are resolved through this path with the defaults declared in COMPONENT_LIST (components.py). solcast_poll_hours is declared "default": 8 (a bare int), so get_arg("solcast_poll_hours", 8) returns int(float(4.8)) = 4, and solcast.py computes max_age = 4 * 60 = 240 minutes.

With two Solcast sites this causes 6 refreshes/day (12 API calls) instead of the documented 5/day (10 calls), which exhausts the hobbyist 10 poll/day limit and produces nightly HTTP 429 failures. Validation doesn't catch this because it validates the raw apps.yaml value (a valid float, per APPS_SCHEMA "type": "float") before get_arg runs — and there is no warning on the lossy coercion, so apps.yaml still says 4.8 while the runtime behaves as 4.

Related: #4296 / #4441 — same mechanism, different code path

#4441 fixed this exact truncation class for CONFIG_ITEMS-driven reads (metric_battery_cycle 0.5 → 0 via the same int(float(value)), because CONFIG_ITEMS declared "default": 0 as an int) by normalising int defaults to float in get_ha_config(). solcast_poll_hours is not a CONFIG_ITEMS entry: it is resolved through the component framework, where Components.initialize() passes COMPONENT_LIST's spec default directly to get_arg(). The get_ha_config() normalisation cannot reach this path because there is no config_index entry to match. v8.54.2 includes #4441 (merged 2026-08-08) and still truncates.

Scope — other keys on the same path

Same int-default/float-schema pattern, all confirmed in the installed source and on main:

Key	COMPONENT_LIST default	APPS_SCHEMA type	Consumer	Impact if user configures a fraction
solcast_poll_hours	8	float	solcast.py:555 max_age = x * 60	poll TTL 4h instead of 4.8h → quota overuse → 429s
forecast_solar_max_age	8	float	solcast.py:458 max_age = x * 60	Forecast.Solar cache TTL silently shortened
open_meteo_forecast_max_age	4	float	solcast.py:236/310 max_age = x * 60	Open-Meteo cache TTL silently shortened
axle_pence_per_kwh	100	float	Axle pricing	money: configured 12.5p/kWh becomes 12p

(Plausible further candidates with int defaults and fractional semantics: octopus_saving_session_rate, car_charging_battery_size.)

Expected behaviour

Either:

1. solcast_poll_hours: 4.8 works as documented (the docs at apps-yaml/#solcast-solar-forecast recommend 4.8 for two-array hobbyist accounts to hit exactly 10 polls/day), or
2. at minimum, a warning is logged whenever get_arg's coercion is lossy — the failure is otherwise invisible: the YAML still says 4.8 and validation passes.

Suggested fix

Mirror #4441's "fix at the source" approach on the component path: when resolving arg specs in Components.initialize(), normalise an int default to float where APPS_SCHEMA declares the key "type": "float" — so a future component author writing 8 vs 8.0 can't change behaviour, rather than hand-editing the four literals above. If a narrower change is preferred, the one-line alternative is float literals in COMPONENT_LIST (8.0, 8.0, 4.0, 100.0). A warning on lossy coercion in get_arg() would also be worth having regardless.

Regression test: extend apps/predbat/tests/test_integer_config.py (the #4296 home) — assert that a component arg spec with an int default and an APPS_SCHEMA float type resolves a configured 4.8 to max_age == 288 minutes.

Workaround in the meantime: set an integer — solcast_poll_hours: 5 gives 5 refreshes/day = 10 calls, the same outcome the 4.8 documentation recommendation was aiming for.

Version: v8.54.2. Still present on main as of 2026-09-03 — apps/predbat/components.py still declares "default": 8 for solcast_poll_hours.

[springfall2008]

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

Classification: bug
Priority: priority_medium — hits anyone following the documented two-array hobbyist setup, but the workaround (set an integer, e.g. solcast_poll_hours: 5) is trivial.

Investigated against current main (v8.54.2-55-g79f28f8f) — mechanism confirmed:

• Components.initialize() resolves component args by passing the COMPONENT_LIST spec default straight into get_arg() — apps/predbat/components.py:767. For solcast there is no config_late_resolve, so this path is live.
• get_arg() keys its coercion on the type of the default: apps/predbat/userinterface.py:257-264 does int(float(value)) when the default is an int. A configured 4.8 becomes 4.
• The four defaults are indeed bare ints while APPS_SCHEMA declares the keys float: solcast_poll_hours (components.py:134 default 8, config.py:2620 float), forecast_solar_max_age (components.py:136, config.py:2785), open_meteo_forecast_max_age (components.py:145, config.py:2789), axle_pence_per_kwh (components.py:572, config.py:2645). Consumers confirmed: solcast.py:555, solcast.py:458, solcast.py:236/310, axle.py:54.
• The docs do recommend 4.8 for exactly this quota reason (docs/apps-yaml.md:1676), and the schema validates the raw value (type: float), so nothing warns — validation passes and apps.yaml still says 4.8 while the runtime poll TTL is 4h.
• The get_ha_config() normalisation from fix(config): give fractional-step input_number items a float default, not int #4441 cannot reach this path — that fix lives on the CONFIG_ITEMS/config_index route, and component args bypass it. Matches the issue's framing.

Log evidence (attached predbat.log, ~111k lines): real Solcast forecast fetches land every 4h — 00:42, 01:12, 05:12, 09:13 on 09-02 (in between, Return cached data lines confirm the cache TTL is what gates it) — i.e. 6 polls/day per site × 2 sites = 12 calls, over the 10/day hobbyist limit. 18 × code 429 in the log, first at 00:42 on 09-02. One caveat: no predbat_debug.yaml was attached, so I can't confirm apps.yaml literally says 4.8 rather than 4 — but a 4h cadence is only reachable from a configured 4.8 via this truncation, so the finding stands either way.

Suggested fix looks sound. The #4441-style fix at the source — normalise an int spec default to float in Components.initialize() when APPS_SCHEMA declares the key "type": "float" — is the right shape and protects future component authors; the float-literal alternative (8.0, 4.0, 100.0) is the minimal change. A warning in get_arg() on lossy coercion would be worthwhile regardless, since the failure is otherwise invisible. test_integer_config (the #4296 home) is registered in TEST_REGISTRY (unit_test.py:603), so the suggested regression test has a natural home.

Possibly related: #4244 (429 responses get no backoff/cooldown — the same nightly 429 symptom, different layer) and closed #2185 (Solcast polling more often than configured, different mechanism).

[springfall2008]

BOT_PR was added but this issue isn't actionable for an automated implementation (closed, or not classified bug/enhancement) - not attempting a PR. Remove BOT_PR_FAILED and re-add BOT_PR once the classification changes.