Load with and without the new ML feature

[ppmt]

Hello,
I don't want to write a bug as it is entirely possible that I am misunderstanding something.
I am using version 8.33.3 so I realised that there was a need to relearn the data.

Also note that I have activated the feature because I wanted to see what it does not because I need it :)

So I activated the new feature for ML Load Forecaster and I have noticed a few things between the components being active or not. Mainly that the load forecasted doesn't seem to reflect the historic data.

Here is a screenshot when ML forecast is disabled:

The load between 17h30 and 21h30 is high because every Thursday I have 2 ovens that are on during that time. So it is an expected load and so far PredBat was very good at being ready for it (battery at 100% just before)

And here is screenshot with the feature activated

As you can see now the expected load is gone and the battery is no longer at 100% because of course as far as it is concerned there is no need for it.

So my question is:

Am I misunderstanding what it is meant to do or does it take longer to learn or is there a problem.

If there is a problem does providing the usual log is enough or do I need to find different logs?

[gcoan]

Load ML should work just the same as the original load feature, just give you a more accurate forecast, AND take account of temperature (if you want) in your forecast.

Do you have an EV configured in Predbat? There is a new gotcha of needing to turn switch.predbat_car_charging_hold Off if you don't have an EV - high load could be treated as being an EV charging.

See latest version of my docs https://github.com/gcoan/batpred/blob/main/docs/apps-yaml.md#car-charging-filtering and the linked FAQ

The normal log is sufficient, but do share your load_today sensor history graph as that's what load ML uses, and the load ml chart from the web console as that shows what is being forecast and the forecast accuracy

[ppmt]

My bad! I remember seeing this step while setting up my days_previous and thought I had done it...Well obviously I did not!

So I will do it and wait 2 weeks then see how it goes.

Hopefully this mistake is what caused the inconsistency in my case.

I will report when I have more data.

[gcoan]

If you find your database gets too big, I have some config changes you can make. Its something I need to writeup properly for the documentation, but I have some quick-wins

[ppmt]

The database is currently at 2.9G but will keep an eye on it

[gcoan]

Ouch. Mine was at that kind of size and I was forever running out of room on my google drive when backing up. Its now down to 700Mb, about 300 when compressed in the backup.

In another thread Trefor has said that the training only takes place on the first 7 days of data (which I have suggested ought to be increased to the HA history length), but that the model retrains itself as time goes on, so when you roll through another weekend it should better start understanding your weekly cycle

[ppmt]

Ouch. Mine was at that kind of size and I was forever running out of room on my google drive when backing up. Its now down to 700Mb, about 300 when compressed in the backup.

My HA is running is a Proxmox VM that is backed up to a Proxmox PBs with 5 Terabyte of disk so I am not bothered about the size and as I have not noticed any slow down I don't see it as a problem...yet :)

[ppmt]

Not really adding anything but just putting it here to see how it will evolve as the history build up.

This is Saturday/Sunday which are normally very low power days and yet here ML is assuming that it is going to be high load for both days

[gcoan]

no it doesn't use the database manager

read the documentation https://springfall2008.github.io/batpred/load-ml/#basic-setup

it doesn't use the database component https://springfall2008.github.io/batpred/load-ml/#model-persistence

the description the size of the database history is slightly conflicted as to whether you need to configure it or not. I didn't initially configure it and predbat did create a ML database file, so it probably isn't needed to use the database, but to be sure I have configured the database size in my apps.yaml

[ppmt]

I have a question about the documentation actually.

# Enable ML load prediction
 load_ml_enable: True
 # Use the output data in Predbat (can be False to explore the use without using the data)
 load_ml_source: True

Is the setting meant to be True. In the rest of the apps.yaml setting are always true or false with no capital letters. It works with it so I guess True is correct but it seems strange.

[gcoan]

looking at the code that gets the apps.yaml setting, its get_arg in userinterface.py:

                            elif isinstance(org_value, bool) and isinstance(value[idx], str):
                                # Convert to Boolean
                                if value[idx].lower() in ["on", "true", "yes", "enabled", "enable", "connected"]:
                                    value[idx] = True
                                else:
                                    value[idx] = False

its case insensitive, and any one of a set of 'on' terms (as above) can be used

In the documentation the True/False settings were generally all written in upper case, but there were some in lower case.

I have changed all of the references to lower case as that is what predbat writes to apps.yaml if you update the config via the web console

[ppmt]

I thought I would put the latest graph

It is still early since I started improving my config with your help @gcoan but it seems a lot more closer to my consumption already and the plan is also more in line with how it was before I activated ML.

Looking forward to see what happens in the next week or 2 once I have had my ovens turned on :)

[gcoan]

👍 I am seeing my own Load ML prediction much more closely matching my own demand. 8.33.5 and ,6 seem much less sensitive to changing temperature than .4 and below

we should see the forecast improve now with the ability for long term data collection