Load predicting

[AndrewNalty]

Is your feature request related to a problem? Please describe. Load is very difficult to predict from previous use but I often know more.

Describe the solution you'd like The possibility to tell batpred that I know I have a very high or very low load day upcoming.

Describe alternatives you've considered Set numerical value for days in the future. I know I’m out all day tomorrow so 0.8 load factor but know I’m cooking a roast on Sunday so make Sunday 1.5 load factor

Additional context Add any other context or screenshots about the feature request here.

[RobinCu]

There is a way to achieve this using automations to adjust the load factor (the action is Call Service, Number:Set). You could simplify the UI by creating number/date helpers to define the load factor you want on the date you want it and adding them to the dashboard. The automation trigger could then be a date or day of week.

[gcoan]

There is a way to achieve this using automations to adjust the load factor (the action is Call Service, Number:Set). You could simplify the UI by creating number/date helpers to define the load factor you want on the date you want it and adding them to the dashboard. The automation trigger could then be a date or day of week.

Load factor is part of the solution but it only adjusts today's predictions based on load today. If you know tomorrow that you're going to be using a lot of electricity then there's currently no way to signal this (eg for an overnight rate charge up) without adjusting the day's history that are averaged over in apps.yaml.

It is worth making sure you are averaging enough history (and if you want setting weighting to those history days) to average out high and low consumption days. I have my history set to 2, 3, 4, 5, 6, 7, 8 days for just this reason

[RobinCu]

Load factor is part of the solution but it only adjusts today's predictions based on load today. If you know tomorrow that you're going to be using a lot of electricity then there's currently no way to signal this (eg for an overnight rate charge up) without adjusting the day's history that are averaged over in apps.yaml.

Apologies, wrong terminology carryover. I was referring to load scaling, which adjusts the load for the entire plan (forecast hours). I think that is what the OP is referring to. I think you're referring to the Load in-day adjustment factor, which dampens or amplifies the in-day load prediction.

Automation and load scaling would still help if the trigger were timed before the cheap overnight slot started.

I agree on averaging enough history. It may not be perfect, but (for me) the Predbat goal is to set and forget. With so many variables on load usage and timings, whether PV will be nearer PV10 or PV90, how Nordpool rates will translate to actual at 16:00, etc., we do have to accept occasionally losing out on a few pence savings. Still, the overall average has produced significant financial and time savings.

[pewtertankard]

I agree that the OP asks for load scaling per day but then one of the examples given rather contradicts this, the infrequent roast dinner. For an accurate plan, I’d want to be able to, on these one or two times a year, be able to state an expected high usage for those few hours in the middle of the day (very unusual for me, and no amount of whole-day load scaling would result in an accurate plan).

obviously, if this is too different from the OP, then let me know and I’ll create my own issue. However, thought it connected enough to mention here

[AndrewNalty]

Maybe just the ability to manually tweak the load forecast is what I want? Add a couple of kWh when you know you have a plan to use them...

[springfall2008]

Doing this via apps.yaml would be quite easy based on date/time. Doing it via the HA gui would need a good idea on how to represent things without a infinite set of menus

[AndrewNalty]

How about some kind of combo?

In apps.yaml you have your 48 time slots with either a value to use, or left blank to use the load prediction (maybe even +0.5 to add 0.5kWh to the predicted load, or -0.3 to subtract from the predicted etc)

In the GUI you have a switch "for turn on manual load". Possibly even a countdown timer like the holiday one so I wouldn't even have to think about turning it off again!

Does that make sense? Sound feasible?

[Nilogax]

The Drayton Wiser integration has a neat schedule editing card:

https://github.com/asantaga/wiserHomeAssistantPlatform/wiki/Custom-Cards#schedule-card

Could something like that be suitable for amending expected load, but using +/- KWh instead of temperature?

[johnwb87]

I'll add on to this being useful.

It's the classic I know we are having a roast or the weather is bad so the tumble dryer will have to go on tomorrow.

Kind of advanced for those of us really interested in our plans, so happy for it to start in apps.yaml as a load forecast override.

[gcoan]

things have moved on with Predbat and I think you now have all the tools you need to meet this requirement:

Firstly load_scaling https://springfall2008.github.io/batpred/energy-rates/#manually-over-riding-energy-rates you can define in apps.yaml an import rate override for a specific date and time, and specify a load factor for that time period, e.g. load_scaling 2.0 rate and rate_increment are now optional so you can use this to specify a changed load prediction for a time period

Second, editing apps.yaml is a bit fiddly but there is now an alternative of using the predbat manual API to specify an import rate override via select.predbat_manual_api https://springfall2008.github.io/batpred/manual-api/

[johnwb87]

Thanks, yes I had just thought I could use the rate override after I found this thread. I hadn't understood rate_increment until now so thanks for bringing that to my attention.

Still new to the manual API but will have a play at creating something to make use of that.

[gcoan]

the manual api works well, I use it to inject octopus power up, free electricity and DFS events into predbat. I have some input controls on a dashboard for the date, time, etc, and then an automation script to reformat those appropriately and set via the manual api

e.g. this is the script I have for DFS saving sessions:

alias: Send Saving Session event to Predbat manual API
sequence:
  - action: select.select_option
    data:
      option: >-
        rates_export_override?date={{          
        states('input_datetime.octopus_saving_session_date')| as_timestamp |
        timestamp_custom('%Y-%m-%d') }}&start={{          
        states('input_datetime.octopus_saving_session_start_time')
        }}&end={{          
        states('input_datetime.octopus_saving_session_end_time')
        }}&rate_increment={{
        states('input_number.octopus_saving_session_amount')|int 
        }}&load_scaling={{
        states('input_number.predbat_load_scaling_saving')|float }}
    target:
      entity_id: select.predbat_manual_api
mode: single
description: ""