fix(output): apply load_scaling_dynamic and manual_load_adjust to today_remaining

[chalfontchubby]

Summary

Follow-up to #4506 on #4496 - the merged fix applied the flat load_scaling factor to load_today_comparison()'s predicted curve (fixing the reported gap for the original reporter), but missed two other multipliers step_data_history() (fetch.py) also applies when building the plan's own load_minutes_step:

• load_scaling_dynamic (per-minute) - carries saving-session/free-electricity-event scaling (load_scaling_saving/load_scaling_free), as well as any per-window override from rates_import_override or the manual API.
• manual_load_adjust (additive, per-minute).

Caught by a second reporter on the same issue after reviewing the #4506 diff directly - they had a 2-hour "power up" (free electricity) event set to load_scaling: 1.5 via the manual API, and correctly identified that the merged fix only accounted for the flat 1.05 base load_scaling, not the dynamic per-window override.

Verification

Downloaded and replayed their attached debug.yaml directly (not just read the code). Confirmed load_scaling_dynamic genuinely carries 1.5 for the reported 12:00-14:00 window in their real config. Before this fix, load_today_comparison() never looked at that dict at all. After the fix, the same replay's plan-vs-sensor ratio drops to 1.0076 - matching the same small residual seen on the original #4506 replay (i.e. this closes the gap to the same baseline level as the first fix did for the original reporter).

Test plan

• New tests in test_load_today_comparison.py: today_remaining scales with load_scaling_dynamic applied uniformly across the remaining day (mirrors the existing flat load_scaling test), and reflects a single manual_load_adjust entry additively at the correct scale
• Both new tests confirmed to fail without this fix and pass with it (temporarily reverted just output.py, reran, restored)
• Existing load_today_comparison tests (None-guard, import-exceeds-load, flat load_scaling) pass unchanged
• Verified against the reporter's actual debug.yaml (see above), not just unit tests
• ./run_all --quick passes
• ./run_pre_commit passes

🤖 Generated with Claude Code

[chalfontchubby]

Rolled in a small related fix: the `days_previous_auto` log line in `fetch_config_options()` fired every cycle unconditionally ("...using weighted-bucket historical load forecast...") regardless of whether it was actually used that cycle - Load ML taking precedence skips it entirely, confirmed via the `not self.load_forecast_only` guard in `fetch_sensor_data()`, no double-application occurs. Reworded so it doesn't read as confirming active usage on every cycle. This is what prompted gcoan's original "is predbat double applying in-day load adjustment?" question further up the issue - answer is no, but the log line was genuinely misleading.

[Copilot]

Pull request overview

This PR is a follow-up fix to align load_today_comparison()’s published predicted/adjusted “today_remaining” values with the plan’s step_data_history() load construction, by incorporating the remaining multipliers (load_scaling_dynamic and manual_load_adjust) that were previously not applied.

Changes:

• Update load_today_comparison() to apply manual_load_adjust (additive) and load_scaling_dynamic (multiplicative) to future minutes, matching step_data_history() behavior.
• Add a regression test covering load_scaling_dynamic and manual_load_adjust effects on today_remaining.
• Clarify days_previous_auto logging to reflect that it’s a fallback when other forecast sources take precedence.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
apps/predbat/output.py	Applies manual_load_adjust and load_scaling_dynamic to future predicted load buckets so today_remaining matches plan load stepping.
apps/predbat/tests/test_load_today_comparison.py	Adds regression coverage for load_scaling_dynamic and manual_load_adjust behavior in today_remaining.
apps/predbat/fetch.py	Refines a configuration-time log line to avoid implying weighted-bucket forecast is always used each cycle.

Suppressed comments (1)

apps/predbat/tests/test_load_today_comparison.py:392

• Similarly, the manual_load_adjust case only asserts the predicted sensor. Since load_energy_adjusted is derived from the predicted curve (difference_cap applied), it should also be asserted here to prevent regressions where only one sensor path is corrected.

        # manual_load_adjust applied additively at a single future minute
        my_predbat.load_scaling_dynamic = {}
        manual_adjust_minute = minutes_now + 60
        manual_adjust_kwh = 6.0
        my_predbat.manual_load_adjust = {manual_adjust_minute: manual_adjust_kwh}
        my_predbat.load_today_comparison(load_minutes, load_forecast, {}, import_minutes, minutes_now=minutes_now, step=5, save=True)
        manual_adjusted_remaining = my_predbat.dashboard_values[my_predbat.prefix + ".load_energy_predicted"]["attributes"]["today_remaining"]

        expected_delta = manual_adjust_kwh * 5 / float(my_predbat.plan_interval_minutes)

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.