fix(config): read float-declared keys with float defaults (#4925)

[chalfontchubby]

Fixes #4925.

Problem

get_arg() coerces its return value on the type of the default it is handed, and applies that to whatever value was resolved - real configured value or not. So get_arg("solcast_poll_hours", 8) ran a configured 4.8 through int(float(value)) and returned 4, shortening the Solcast poll TTL from 4.8h to 4h and pushing a two-site hobbyist account past its 10 poll/day quota into nightly HTTP 429s. Nothing warned: validate_config() checks the raw apps.yaml value against the float schema and passes it.

Fix

Float literals at every call site that reads an APPS_SCHEMA float-declared key with an int default - eight of them:

Where	Key	Default
components.py spec	solcast_poll_hours	8 → 8.0
components.py spec	forecast_solar_max_age	8 → 8.0
components.py spec	open_meteo_forecast_max_age	4 → 4.0
components.py spec	alphaess_api_delay	2 → 2.0
components.py spec	axle_pence_per_kwh	100 → 100.0
octopus.py	octopus_saving_session_rate (twice)	100 → 100.0, 0 → 0.0
octopus.py	octopus_saving_session_min_octopoints_per_kwh	0 → 0.0

The issue's own suggestion (normalise in Components.initialize()) would miss the three direct octopus.py reads. A configured alphaess_api_delay of 0.5, for example, no longer becomes 0 and switches the AlphaESS throttle off.

This fixes the callers rather than get_arg(), as asked on review: the accessor stays keyed on its default, and a guard test stops the callers regressing instead.

User-visible, cosmetic only: a whole-number value now shows with ".0" - the Axle scheduled-event notification ("100.0 p/kWh"), the web UI's component config table, the Axle event attribute, Octopus saving-session octopoints_per_kwh when no reward is reported, and one Octopus log line.

Not included: the issue's second ask, a warning on lossy coercion. It would fire every cycle on keys that are integer by design, and the guard below prevents the float-key case at source.

Testing

• test_float_declared_keys_never_read_with_int_default scans the source for any get_arg() call or COMPONENT_LIST spec giving a float-declared key an int literal default, and fails naming each. Against main it names all eight. It sees literals only - a default passed through a variable, or a wrapper accessor, is not checked.
• test_component_arg_specs_resolve_float_declared_keys_as_float resolves each float-declared spec that has a default the way Components.initialize() does, and checks a configured 4.8 survives (5 specs). Fails against main's components.py.
• ./run_all --quick and pre-commit run --all-files pass (exit 0).

---

Written by Claude on behalf of @chalfontchubby.

🤖 Generated with Claude Code

[springfall2008]

Not sure about this, shouldn't we fix the caller for get_arg()?

[chalfontchubby]

(Posted by Rik; written by Claude.)

Fair challenge, and normally I would agree — fix the caller, not the accessor. Two things pushed me the other way here.

"The caller" is not one place. Auditing main: 15 float-declared APPS_SCHEMA keys, affected in two unrelated mechanisms.

Where	Keys
components.py arg specs	solcast_poll_hours, forecast_solar_max_age, open_meteo_forecast_max_age
octopus.py direct get_arg() calls	octopus_saving_session_rate (x2), octopus_saving_session_min_octopoints_per_kwh

The original issue proposed normalising in Components.initialize(), which fixes the first three and cannot reach the octopus.py ones — those never go through the component framework. So the caller-side fix is six edits across two mechanisms rather than one.

More to the point, it only holds while every future caller keeps getting it right. The trap resets every time someone writes 8 instead of 8.0 against a float-declared key, and it fails silently in the worst way: validate_config() reads the raw apps.yaml value against the float schema and passes it, so apps.yaml still says 4.8 while the runtime behaves as 4. Nothing warns, and the symptom surfaces somewhere unrelated — in #4925 as nightly Solcast HTTP 429s. A correctness property that depends on every call site remembering an invisible convention will drift back.

The framing that convinced me: the type is already declared authoritatively in APPS_SCHEMA, and get_arg() currently prefers an incidental literal over it. That reads as the accessor being wrong, not the callers.

There is also direct precedent — #4441 fixed this exact mechanism on the CONFIG_ITEMS route inside get_ha_config(), normalising an int default to float at the source for the same reason. This is the same bug on the apps.yaml/APPS_SCHEMA route, which get_ha_config()s normalisation cannot reach because there is no config_index entry to match. Fixing it in get_arg() keeps both routes consistent.

Two honest costs, so they are on the record rather than buried:

• it adds an APPS_SCHEMA lookup to a hot accessor (dict .get on a resolved-once global, but it is not free); and
• it makes get_arg()s return type depend on that global rather than purely on its arguments.

If you would rather keep the accessor dumb, the alternative I would want is all six call sites fixed plus a test that fails when a new int default appears against a float-declared key — the sweep in test_component_arg_specs_resolve_float_declared_keys_as_float already does roughly that for the component specs and could be widened. Without the guard I think it regresses quietly. Happy to switch it round if you prefer that shape — just say which.

[chalfontchubby]

(Posted by Rik; written by Claude.)

@springfall2008 following up — my reply above (2026-09-10) laid out the case for fixing this in get_arg() rather than at each caller, plus an alternative if you'd rather keep the accessor dumb (fix all six call sites + a regression test). Just flagging so it doesn't fall off your radar; happy to switch approach if you tell me which way you'd prefer.

[chalfontchubby]

(Written by Claude, posted by @chalfontchubby.)

@springfall2008 I've switched this to your suggestion: the get_arg() change is gone, and the callers are fixed instead.

A correction to my earlier reply: it said six call sites, but there are eight - I had missed alphaess_api_delay and axle_pence_per_kwh in components.py. All eight now use float defaults (the table in the description lists them).

To stop a ninth appearing, there is a guard test that scans the source for any get_arg() call or COMPONENT_LIST spec giving a float-declared key an int literal default, and fails naming it. Against main it names all eight. The branch is rebased onto current main as one commit, and the description is rewritten to match.

[springfall2008]

Approved. The callers now pass float defaults and get_arg() is unchanged, as asked for earlier. I checked every read of the 15 float-declared settings on current main: all are covered, and nothing downstream needs an integer. Both new tests passed on a local merge with main before the rebase.

One nit for a follow-up, not a blocker: test_component_arg_specs_resolve_float_declared_keys_as_float restores with my_predbat.args = original_args, which rebinds to a copy rather than restoring the shared dict in place.

(Review written by Claude on behalf of @springfall2008.)