Idea

thomasw-1 avatar image
thomasw-1 suggested

BatteryLifeAI and Forecast-Based Battery Charging

LiFePo batteries show according to the study “Optimized Operating Range for Large-Format LiFePO4 the best lifetime, when the charge level is mainly used between 20% and 80%. Constantly loading a battery towards 100% is counterproductive (citation “It is worth to note that the large polarization at the EOC (SOC =100%) could result in poor rate performance of the LiFePO4/graphite battery and increased capacity fading at lower SOC regions”).

lifepo.png

Source: “Optimized Operating Range for Large-Format LiFePO4/Graphite Batteries

Some other solar manufacturers like e.g. SMA or Tesvolt have already provided a system enhancements, which allows a forecast-based battery charging in following context.

  • Enhancing battery life
    Keeping SOC shorter time at 100% enhances battery life.
  • Flexible battery charging
    During shorter nights in summer it is sufficient for well dimensioned batteries to charge them only to 70% or 80%, where in winter it could make sense to charge them fully.
  • Improved PV power utilisation
    In some countries a feed-in curtailment (i.e. not more than 70% of nominal peak power) does not let fully use the available PV power. Delayed battery charging prevents that constraint.

During year change I spent some time in elaborating some basics proving that such approach could be possible with minimal investment.

I established a forecast based SOC-limit control, which influences the battery control according to a PV forecast for the next 24 hours. With that prove of concept I can exemplify that controlling the SOC bottom level control can be implemented with less than 50 lines of code in node red. The top line control could be also easily implemented, in case victron solves a bug (which btw. currently is not considered to be corrected by Victron).

Compared to the standard batterylife option in VenusOS this approach does already allow a much more advanced battery usage.

1642715148768.png


The diagram of the last 5 days shows that the prediction and the resulting SOC-adaptation worked more than reliable. I calculated the allowed Min-SOC in that way, so that battery could be loaded next day fully again (even if in major context that behaviour would be not desired).
Interpretation of forecast accuracy: As shorter the 100% SOC was reached as more precise the estimation on the min-SOC was set.

Since my solution bases on a service, which could be used in the majority free of charge for global PV forecasts and which seems to be quite reliable (as the diagram shows), I offer Victron to support them to transfer the solution on VenusOS. In case you would be interested, please contact me via email (email extractable in this board).


@mvader (Victron Energy): It’s your choice, if you like to make VenusOS more enhanced!


@All others: Please vote, in case you would consider such solution as beneficial.

Lithium BatteryVenus OSbatterylife
lifepo.png (60.2 KiB)
1642715148768.png (128.7 KiB)
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

wkirby avatar image
wkirby commented

This would be a good idea. In my case I have very cheap rates from my network for four hours 0030 to 0430. I don't want to take too much energy from the network to leave space for PV energy when the daytime comes a few hours later.

There is a serious flaw with trying to do this. There is no such thing as a competent weather provider. I have never seen a weather provider who can give weather predictions which are remotely like what actually happens - even a few hours before. They will say that it will be sunny but it is actually cloudy or they say it will be raining all day, but it is actually sunny all day.
You can even look at the weather in real time. They will be telling you that at this moment it is raining, but when I look out of the window I can see the actual sun its self.

So it is a case of garbage in - garbage out, a system such as you suggest would inherently not work at all.
It is a good idea though.

1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi wkirby,

You are definitely right. The outcome completely depends on the input quality. I have realized that the reliability of the majority of weather forecast providers is disappointing. Even for Germany, where I collected the experience, most services are crap and not usable for that purpose. I looked more than a year in order to identify a realiable service and applied some additional personal adjustments after nearly 12 months of observation.

Are you located in South Africa? Would be nice to see, if forecast would fit to you as well.

Cheers,
Thomas


nickdb avatar image
nickdb commented

The accuracy of a forecast depends on the accuracy of the weather forecasting model and the number of weather stations available.

This varies greatly country by country and is influenced by the size of that nation.

The UK, for example, is quite accurate.

Come to South Africa and the forecast is at best general and not particularly accurate the night before.

There isn't a machine learning algorithm out there which can compensate for sketchy global forecasting.

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

koche avatar image
koche commented

I think that the solution would be very useful if it is integrated directly in the VenusOS.

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

thomasw-1 avatar image
thomasw-1 commented

I like to share an update on my recent experience:

During last 25 days the Battery LifeAI control did set the SOC

  • 20 times optimally
  • 4-times still satisfying / good
  • only a single time the forecast was completely of reality.

1645990032286.png

Overall that result shows, that an VenusOS related implementation could make perfect sense!

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Mark Maritz avatar image
Mark Maritz commented

"With that prove of concept I can exemplify that controlling the SOC bottom level control can be implemented with less than 50 lines of code in node red. "

@thomasw-1 Are you sharing your NR code somewhere. I am keen to see how it works (since I am based in South Africa) given our patchy forecasts ;)

2 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi @Mark Maritz ,

Currently the code is mixed up in a Power2heat control flow, which also uses the excess power of my PV. When I will have some time, I am going to isolate the flow in an independent solution.
I will let you know.


Thanks very much!
lsgv avatar image
lsgv commented

Regarding forecasts, I'm using Solcast integrated into my Home Assistant instance and it has proven to be very reliable over the last 6 months I've been using it. Maybe it does depend on your location but in my case quite accurate. Below a recent forecast vs. real harvested energy.

1647205859122.png

As for the original idea I'd be interested in following this up.

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Your Opinion Counts

Share your great idea, or help out by voting for other people's ideas.