Allow a configurable LoadML forecast horizon up to 96 hours

[jacobidsmith]

Is your feature request related to a problem? Please describe.
I use a 96-hour planning horizon, but LoadML currently generates only 48 hours of predictions. With LoadML selected as the load source, my plan shows zero load after the ML forecast ends, even though the plan continues for another two days.

I extended the horizon by editing PREDICT_HORIZON in load_predictor.py. This generated 1,152 five-minute predictions covering 96 hours. However, updating to v9.3.3 replaced the modified file and restored the 48-hour limit.

A supported setting would make longer forecasts available without maintaining Python edits after each update.

Describe the solution you'd like
Add a configurable LoadML forecast horizon, for example an Expert Mode setting allowing 48, 72 or 96 hours, with the existing 48-hour default.

Ideally:

The predictor, published forecast entity and charts would support the selected horizon, allowing the plan to use the full forecast.

Extending the horizon would preserve the existing blending behaviour through the first 48 hours. Any additional taper toward the historical forecast could be handled separately.

If the plan extends beyond available ML predictions, Predbat would use a historical fallback for the remaining period rather than assume zero load.

Describe alternatives you've considered
I manually changed the prediction horizon to 96 hours and adjusted the blending calculation to preserve its original behaviour through 48 hours. This worked, but the changes were overwritten during an update.

Reducing the planning horizon to 48 hours would avoid the coverage mismatch, but I would like to retain four-day planning.

Additional context
Running Predbat v9.3.3 as a Home Assistant add-on, with forecast_hours and “Plan forecast hours” set to 96.

Before the update, the modified predictor logged:

Starting autoregressive prediction loop for 1152 steps (96.0 hours)

After the update, it logged:

Starting autoregressive prediction loop for 576 steps (48.0 hours)

The exported forecast contains 576 energy points, and the exported plan shows zero load throughout its remaining approximately 48 hours.

load_ml_energy_forecast_48h_redacted.csv
load_ml_power_forecast_48h_redacted.csv
predbat_horizon_log_excerpts_redacted.txt
predbat_plan_96h_load_excerpt_redacted.html
README.txt

[springfall2008]

🤖 Automated first-pass triage — a maintainer will review before any action is taken.

Classification: enhancement — a request for a configurable LoadML forecast horizon (the current 48-hour cap is hardcoded). No priority label is applied to feature requests.

I verified the behaviour you describe against current main and found no existing duplicate — the closest issues are #3388 (ML training improvements) and #4820 (whether ML accounts for rates), both different asks.

What I confirmed in the code:

• The cap is PREDICT_HORIZON at load_predictor.py:35 (48 * (60 // CHUNK_MINUTES) = 576 five-minute steps). It is used only by the prediction rollout: the loop at line 1766, the blend schedule at line 1824 (which is relative to the horizon), the log lines and the model's saved metadata. Training does not depend on it, and load() validates only model version and architecture — predict_horizon in the saved metadata is informational — so existing saved models remain usable with a different horizon. That matches your observation that extending it to 1152 steps worked with the unchanged blending character through the first 48 hours.
• The zero-load tail is a real consequence of the cap, not a display artefact: with load_ml_source enabled fetch.py:1029 sets load_forecast_only = True, which skips the weighted-bucket historical forecast (fetch.py:1354), and the plan builds its future load from self.load_forecast alone (plan.py:1826) — so past minute 2880 there is no data and load is 0. Your plan excerpt showing zero load from Saturday 12:30 to Monday 12:00 fits that exactly. The "Generated … over 48h" message is a hardcoded label in the log string (load_ml_component.py:695), as your README notes — the step count is the real horizon value.
• A supported setting looks architecturally straightforward: a config item (e.g. load_ml_forecast_hours, 48/72/96 with 48 as today's default, likely under expert mode), plumbing through the load_ml component spec and predict(), and an update to the two tests that currently pin 576 steps (test_load_ml.py:948 and :979). The published forecast entity and chart already scale with the prediction dict length, and fetch_ml_load_forecast re-samples into forecast_days + 1, so a 96-hour plan would consume a 96-hour forecast without further changes there.

One caveat to be aware of: at 96 hours the rollout increasingly outruns the forward temperature and rate forecasts, so more of the later steps run on the last-known-value fallback. That path already exists and is logged ("Forward temperature/rate forecast ran out for N of M rollout steps…"), so it degrades visibly rather than silently — but prediction quality past 48–72 hours is inherently softer, and that's a reason the horizon is a setting rather than a raised default.

[jacobidsmith]

Thanks for checking this. A couple of clarifications about my workaround and the forecast coverage:

Blending: I changed both the prediction horizon and the blending calculation. Increasing PREDICT_HORIZON alone changes the blend throughout the first 48 hours because the calculation is relative to the horizon. My separate blending edit preserved the original behaviour through 48 hours, then gradually reduced the ML contribution afterward. It would be useful to keep the horizon and blending schedule independent.

Temperature coverage: I also extended the LoadMLPower chart’s temperature display from two to four days by changing prune_future_days=2 to 4 in web.py. This changes chart visibility; LoadML reads the temperature sensor’s full forecast separately. My earlier export showed temperature throughout the four-day forecast, so a 96-hour rollout does not necessarily exceed the available temperature data. I agree that the last-known-value fallback remains relevant whenever temperature or rate forecasts genuinely run out.

Missing-load fallback: Please retain this part of the request. When the plan extends beyond available ML predictions, historical load should cover the remaining period rather than leave a zero-load tail. This would also help users who keep the default 48-hour ML horizon but configure longer planning.

Keeping 48 hours as the default, with longer horizons available through an optional setting, sounds sensible. My local horizon and blending edits were overwritten by the v9.3.3 update, which is why a supported setting would be valuable.

[gcoan]

instead of introducing a new load ml forecast hours why not get load ml to use the existing forecast hours config item?

reduces config bloat and makes load ml follow the existing config

the future load forecast duration in the web.py chart could be dynamically calculated from forecast hours, again no extra config

[jacobidsmith]

That makes sense—I agree that LoadML should follow the existing forecast_hours setting. My main goal is consistent coverage between the ML forecast and the plan, without maintaining Python edits after updates.

Deriving the chart’s future display window from the same setting would also keep everything aligned without adding configuration.

Two details would still be worth addressing:

• Keep the blending schedule independent of the total horizon, so extending the forecast does not unintentionally change the existing blend through the first 48 hours.
• If ML predictions are unavailable for part of the planning period, use historical load for that portion rather than assume zero load.

The temperature and rate fallback caveat still applies whenever the underlying source data runs out, regardless of the selected horizon.

[jacobidsmith]

I’ve opened PR #5398 to implement this using the existing YAML forecast_hours setting, as suggested above:

#5398

LoadML predictions and the chart’s future temperature window now follow that setting without adding another configuration item. The original blending schedule is preserved through 48 hours, with a 50% ML / 50% historical blend thereafter.

The PR also extends standard Open-Meteo temperature requests where possible, refreshes cached forecasts when their coverage is insufficient, and respects the provider’s 16-calendar-day limit. The existing logged temperature/rate fallback remains in place when those inputs run out.

I tested 96 → 24 → 31 → 168 → 412 → 96 hours on my Home Assistant installation. Prediction counts and chart horizons followed each setting, and subsequent plan runs completed without new exceptions. Automated tests and validation details are included in the PR.

The broader historical-load fallback requested earlier, for periods where ML predictions are unavailable, remains a separate improvement.