fix(axle): warn and continue when Axle component is unhealthy

[mgazza]

Summary

Make an unhealthy / erroring Axle Energy VPP component warn and continue instead of influencing (and thrashing) battery control.

Problem

When the Axle component errors on every run — e.g. Axle rotated their API keys and a customer's key expired — fetch.py still trusted Axle:

• fetch_axle_sessions() injected Axle VPP sessions as forced import/export slots into the plan (load_axle_slot).
• fetch_axle_active() could flip PredBat into read-only mode, handing battery control to the (broken) VPP.

Neither path checked component health, so stale / inconsistent Axle state flip-flopped read-only mode and injected phantom forced slots — thrashing charge/discharge. Observed on a live Intelligent Octopus Go customer: ~5-minutely battery charge↔discharge, SOC 98%→49%, and peak-rate grid import during an active IOG car session, for ~2 days until the API key was regenerated.

Fix

• Add Fetch.axle_component_healthy(), using the same "active but not alive" definition already used for the components_healthy dashboard sensor (predbat.py).
• Gate both Axle influence paths on it:
  • Skip loading Axle sessions (self.axle_sessions = []) when unhealthy.
  • Never enter Axle read-only control when unhealthy.
• Logs a single Warn: and continues with the normal tariff plan — the integration degrades to absent rather than actively wrong (fail safe).

A healthy or entirely absent Axle component is unaffected.

Tests

• Extends tests/test_axle.py with unit tests for the predicate: healthy / not-configured / active-and-alive → left untouched; active-but-not-alive → ignored and warns.
• unit_test.py --test axle → 29/29 pass; -k fetch_config passes; Black / flake8 (250) / cspell clean.

🤖 Generated with Claude Code

[springfall2008]

I don't think this does anything useful, all you are doing is preventing a previous scheduled event from running if the API key becomes invalid.

[springfall2008]

Update: moved the fix to the actual root cause

Thanks for the diagnosis and repro on this one — the thrashing symptom is real. Digging into why fetch.py was seeing stale/frozen Axle data, the root cause turned out to be in axle.py itself, so I've replaced the fetch.py-level health gate with a fix at the source.

What was actually happening

AxleAPI.run() only called publish_axle_event() (the code that compares the cached event's start_time/end_time against now to derive on/off state) from inside the fetch functions' success paths, or from an elif (seconds % 60) == 0 branch that's unreachable whenever a fetch is due. Once fetching started failing continuously (e.g. an expired API key), self.updated_at never got refreshed, so fetch_due stayed True forever — meaning publish_axle_event() never ran again at all. The sensor state simply froze at whatever it was the moment the key broke, with no path left to notice that a cached event had since ended.

Same issue on the event_current/event_history side used by fetch_axle_sessions()/load_axle_slot(): since nothing kept re-evaluating the cached data against real time, a frozen "current" session kept being re-applied as long as its own recorded window was still notionally in range.

The fix (axle.py)

• Removed the publish_axle_event() calls from inside _fetch_byok_event() and _fetch_managed_price_curve().
• run() now calls publish_axle_event() unconditionally after every fetch attempt, regardless of success/failure/not-due. This is safe and equivalent in frequency — component_base.py's scheduler already only ever invokes run() when seconds is an exact multiple of 60, so there's no extra overhead, just no more gap.
• This makes the on/off state self-correcting: a stale cached event naturally flips to "off" once its own end_time passes, purely from data already in memory, independent of whether Axle's backend is reachable.

Why the fetch.py gate came out

With state correctly self-expiring at the source, axle_component_healthy() was solving a symptom rather than the cause, and it duplicated the "active but not alive" health formula that already exists independently in predbat.py's components_healthy sensor and web.py's component status page (three copies of the same logic with no shared helper). Removed it, fetch.py's two call sites, and the dedicated test scaffolding in test_fetch_config_options.py.

Tests

• Added _test_axle_publishes_state_after_fetch_failure (TDD — confirmed it fails against the old code with the state never getting published, then verified the fix): covers both an expired cached event correctly flipping to "off" and a still-active one correctly staying "on", in each case with the underlying fetch actively raising.
• test_axle: 30/30 passing.
• Full --quick suite and run_pre_commit (ruff/black/cspell) clean.

Happy to talk through the tradeoff if there's a reason to keep a belt-and-braces health check as well, but wanted to fix the actual freeze first rather than paper over it per-consumer.