ability to add additional non-forecasted load into the predbat forward plan

[ragg987]

Is your feature request related to a problem? Please describe. Predbat works best when it has good forecast of loads, solar, tariffs. I see a gap in the current methods available to inform it of loads. This feature request is to allow an enhancement to the current API and / or manual adjustment methods available. See this discussion of one example.

Describe the solution you'd like Ideally it would allow:

• multiple inputs that are labelled and managed by the label - e.g. heating load, DHW load, cooking dinner load etc
• start and end-times (or duration) of the load
• load delta
• optionally load profile e.g. at start it is higher, at steady state lower

Describe alternatives you've considered The linked discussion shows the options I have considered - i.e. use of the API or the manual select. They both work with limitations - e.g. the select method is "all or nothing" - you can set the load delta once or turn it off, nothing in between and no ability to manage multiple inputs.

Additional context I don't see this as replacement of the existing methods - i.e. the load forecast built into predbat or the use of predAI. Both these mechanisms are effective and simple to use for forecasting loads based on history. I suspect they will cover most of the future load with sufficient accuracy for predbat to do it's thing. This would allow users to complement the load forecast with external data. In my example heating demand varies daily based on external temp etc, so a historical-based forecast is less meaningful.

[gcoan]

Just to add to your FR (and if you agree, suggest you update the title), based on the prior conversation what you want is the ability to add additional non-forecasted load into the predbat forward plan.

You can use car_charging_energy to add additional filters of historical load to remove from the predbat plan https://springfall2008.github.io/batpred/apps-yaml/#car-charging-filtering what you want is to be able to more easily add future predicted load of different types.

I'd suggest that for extensibility it would be a list of sensors in apps.yaml, e.g.

  house_load_additional_forecast:
    - sensor.cooker_load_forecast
    - sensor.ashp_load_forecast

and each of these have an attribute formatted similar to the solar forecast entities, i.e. a series of start time/end time/kWh forecast figures

[ragg987]

Your suggestions are spot-on @gcoan , thanks.

One slight hesitation on the part about using sensor attributes as the mechanism to store the load - HA does not provide any front-end based mechanism to maintain attributes of as far as I can establish. e.g. UI created helpers, automations or scripts cannot do so directly. There is an add-on pyscript that can maintain attributes but the changes do not survive a restart.

So this would require writing a template in yaml direct, something I try not to do and I suspect might become an obstacle to less-capable users like me. I have not tried managing custom attributes from e.g. configuration.yaml so don't have an understanding of the capability or limitations...

[gcoan]

I suggested using entity attributes because that gives us a structured data format, but good point, this is an annoying HA limitation that you can't set attribute values in a script or template. We don't want a solution that relies on third party components to populate the entity attributes.

The trouble is that without using attributes it could require lots and lots of helper entities being created in HA to do what you want, e.g.:

  house_load_additional_forecast:
    - name: cooker
      start_time: sensor.cooker_start_time
      end_time: sensor.cooker_end_time
      load: sensor.cooker_load
    - name: ashp
      start_time: sensor.ashp_start_time
      end_time: sensor.ashp_end_time
      load: sensor.ashp_load

And this only gives a simple start/end/load figure (presumably load is divided by :30 to give load per half hour slot). If you want more richer modelling of increasing/decreasing load then either need yet more entities or something like:

  house_load_additional_forecast:
    - name: ashp
      start_time: sensor.ashp_start_time
      end_time: sensor.ashp_end_time
      load_baseline: sensor.ashp_load
      load_adjustment_per_slot: sensor.ashp_load_adjustment_per_slot

To give a variance that is added to each slot after the first (baseline).

I'm just conjecturing here, anything is possible, but for most people variable load adjustments are probably not needed and are over-complicating things.

[ragg987]

Here is my suggestion, borrowed from the way Target Timeframes integration (ex Octopus) works:

Config (shown here as zero hours duration denoting "not required" by default):

  house_load_additional_forecast:
    - name: heating
      start_time: 17:00
      duration: 0
      load: 0.5
      weighting: *

New Action so that users can over-write the default in an automation:

action: target_timeframes.update_target_timeframe_config
data:
  start_time: "15:00"
  duration: 2.0
  load: 0.5
  weighting: 2,2,*
target:
  entity_id: >-
    binary_sensor.predbat_load_forecast_delta_heating

resulting binary sensor that tracks the new forecast load:

binary_sensor.predbat_load_forecast_delta_heating
target_times: 
- start: '2025-11-19T15:00:00+00:00'
  end: '2025-11-19T15:30:00+00:00'
  energy 1.0
- start: '2025-11-19T15:30:00+00:00'
  end: '2025-11-19T16:00:00+00:00'
  value: 1.0
- start: '2025-11-19T16:00:00+00:00'
  end: '2025-11-19T16:30:00+00:00'
  energy: 0.5
- start: '2025-11-19T16:30:00+00:00'
  end: '2025-11-19T17:00:00+00:00'
  energy: 0.5

[gcoan]

New Action so that users can over-write the default in an automation:

action: target_timeframes.update_target_timeframe_config

Good idea, ... would require the existing Predbat API extending to handle new action calls