Inflated and Fluctuating Load Prediction
Describe the bug
My load prediction is much higher than I would expect. Over the past 3 months the predicated load is consistently 10-20% higher than actual loads which further indicates that the predicated loads are being calculated higher than they should be. Further investigation (see later updates) shows that it starts off higher and then gradually reduces to a more accurate value hours later.
Expected behaviour
I use the same day last week load profile and I use 4 weeks history. The calculation for Fri 4th July used the following previous historic load values:
27th June = 16.2 kWh 20th June = 18.7 kWh 13th June = 15.2 kWh 6th June = 14.2 kWh
Modal filter is turned on so lowest reading of 14.2 kWh would be dropped. This leaves an average of the other loads of 16.7 kWh.
I have load scaling set to 1.05 which should give a final load value of 17.5 kWh, however the prediction was calculated by Predbat at 18 kWh.
Predbat version
8.22.0
Environment details
- GE AIO
- Standard HAOS installer
Screenshots
Load settings:
Sensor for previous 4 weeks:
Log files is stating much higher values than the sensor above:
Log file
Predbat debug yaml file
Log and debug files attached
Looking at Predbat Predicated Load graph seems to highlight the problem better. The prediction made at 00:00 is way overinflated and it gradually lowers to a lower value and stabilises around 05:30:
The reduction in load seems to coincide with my 5 hour off-peak rate period (00:30-05:30) in that you get a static high stable prediction between 00:00-00:30, then a reducing prediction until 05:30 and then a fairly static expected prediction from 05:30 onwards. The export/charging in the off-peak period should have no impact on the expected house loads.
Not sure why it makes a high prediction (based on inaccurate historical data) which fluctuates down at the end of the off-peak charge period. It should be a straight line from 00:00 - 23:59. There are also a couple of blips in the day which drop the prediction and then immediately restore it back to the correct value.
This also explains why the in-day adjustment is inconsistent measuring predicated vs actual as you have a moving set of goal posts in respect to the predicated load. The predicated load should remain stable. I currently have in-day adjustment turned off so that the actual and adjusted values are the same. .
Any updates on this issue?
You haven't supplied your apps.yaml, but it looks like you have 0 cars configured but have 'car_charging_hold' turned on, this maybe the cause of it (confusing some charging with car data). I would turn this off unless you have something set for 'car_charging_energy'
You haven't supplied your apps.yaml, but it looks like you have 0 cars configured but have 'car_charging_hold' turned on, this maybe the cause of it (confusing some charging with car data). I would turn this off unless you have something set for 'car_charging_energy'
Yes your right. I don't have an EV but I was using the 'car_charging_energy' sensor to exclude energy of an electric heater we have in our garden room. I think this came about when asking for a way of excluding add-hoc energy from the historic load and this was the method suggested. The sensor hasn't changed value since last Winter.
What would you suggest is best way forward?
You haven't supplied your apps.yaml, but it looks like you have 0 cars configured but have 'car_charging_hold' turned on, this maybe the cause of it (confusing some charging with car data). I would turn this off unless you have something set for 'car_charging_energy'
I tried turning off 'car charging hold' and commenting out the 'car charging energy' sensor sensor before midnight but it seemed to have no affect on the load prediction. Still have a high prediction of 15.8 kWh at 00:00 and a low prediction of 12.5 kWh from 05:30 onwards. Expected prediction was 15.1 kWh based on my historical data.
Any chance someone could look at this as its been consistently providing inaccurate forecasts for over 5 months now and I cannot seem to work out what is causing it or where it is getting the historical datapoints from to be so far out. Let me know if you need further info.