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.

thomasw-1 avatar image thomasw-1 commented ·

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


0 Likes 0 ·
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 ;)

3 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.

thomasw-1 avatar image thomasw-1 commented ·
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.


0 Likes 0 ·
Mark Maritz avatar image Mark Maritz thomasw-1 commented ·
Thanks very much!
0 Likes 0 ·
pau1phi11ips avatar image pau1phi11ips thomasw-1 commented ·
Awesome, I'd love to give this a try too!
0 Likes 0 ·
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.

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.

thomasw-1 avatar image thomasw-1 commented ·
Can confirm the reliability of solcast
0 Likes 0 ·
thomasw-1 avatar image
thomasw-1 commented

This weekend finally I discovered a way to bypass the leaking DVCC functionality "limit charge current". With that I will enhance the BatteryLifeAI module with following functionalities:

  1. Deferral of battery charging to peak hours (but only if forecast predicts sufficient energy for peak hours).
    In some countries like Germany it is only allowed to feed in 70% of peak capacity. Especially in summer times I lose more than 10% of potential compensation fees. In case I charge battery only during peak hours, I can use all energy (internally and externally).
  2. Battery Lifetime increase
    There are several studies that have proven, that charging a LiFePo battery frequently only up to 80% can increase battery lifetime and capacity duration by more than 30%.
    I know that there are smart-alecs trying to say the opposite without having any scientific prove for that. My simple request: Please don't comment in that threat and spare us your assumptions.
    In my case I require full battery capacity only during winter time. In summer however I need between 40% and 55% of the capacity. Therefore it would be sufficient to charge the battery only up to 80% and to keep it at that level assuming next day also generates sufficient energy.

As soon as the module is completed, I will make it available as donationware with proven donation record. I'll keep you posted

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.

pau1phi11ips avatar image pau1phi11ips commented ·

What system are you using to control Venus? Node-RED?

0 Likes 0 ·
thomasw-1 avatar image thomasw-1 pau1phi11ips commented ·

Yes, I use node-red located on a NAS (docker based on Synology). For my overall home automation solution I also require iobroker, influx and grafana, which would be a bit of overload for GX. However BatteryLifeAI is only implemented on node-red.

1656968376947.png

0 Likes 0 ·
1656968376947.png (36.9 KiB)
gainestr avatar image
gainestr commented

What voltage are you considering to be 80% and are you using tail current or just charging to a specific voltage and stopping the charge?

3 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.

pau1phi11ips avatar image pau1phi11ips commented ·
Pretty sure it will be the SOC from the BMV instead of voltage.
0 Likes 0 ·
thomasw-1 avatar image thomasw-1 commented ·

Hi @gainestr ,

It is both, SOC and voltage.

SOC is considered by MultiPlus'es for (AC-OUT attached inverters) and voltage by MPPTs.
Indeed it was a more intensive test to discover what voltage does the best job. Btw. during that exercise I concluded, that it would be useful to set the voltage by 2 decimals. 1 decimal is actual too less to exactly achieve a very good result.

@mvader (Victron Energy): For the future I would desire that the battery voltage could set by 2 decimals and not only by 1.

Now about the magic number: I think that it might be different for any manufacturer, for my BYD battery 53,5V seems to be favourable. Interestingly it seems to be the same voltage for a cap at 90%.

Currently I am still busy with fine-tuning and the implementation of automatic and PV-forecast dependent balancing (full-charge) after a predefined period.

Example of today (P2H active during 80% float phase):

1656966461682.png


Pattern from yesterday (EV charging active during 80% float phase)

1656966618994.png


0 Likes 0 ·
1656966461682.png (17.4 KiB)
1656966618994.png (15.6 KiB)
thomasw-1 avatar image thomasw-1 commented ·

Apropos still a comment about GX floating setting.

When SOC reaches 100% SOC, GX sets for BYD batteries immediately a max-voltage of 55,0V. Because of that bold approach, the battery feeds-back >4.000W for a period of at least 1 minute. From my point of view the battery is unnecessarily loaded because of that effect.

My BatteryLifeAI will have a smooth voltage setting preventing that scenario!


0 Likes 0 ·
thomasw-1 avatar image
thomasw-1 commented

Brief update:

  • Overall principle of maximum charge control seems to work (see overall graph).
  • I have still to work a bit on stability (red mark). It seems, when exceed-power is exclusively fed-in grid, that voltage control of Multiplus or MPPT is not stable. I would have to adjust voltage during that period or to find another workaround. This will be a bit more time consuming to optimize, in particular because of the coarse voltage definition capability.
  • the maximum charge at 65% on July, 7th was a mistake. I have not realized that I unintentionally shifted a configuration slider in nodered. However it shows, that function would work also at other levels ;-)
  • The full charge after a specific period seems to work (green mark) in order to assure balancing.
  • The smooth voltage setting to avoid unnecessary discharge is still pending.

1657746395057.png

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

Dear engaged GX-Enthusiasts,

The BatteryLifeAI module reached a phase, which can be called as beta-ready. In the meantime the

  • forecast related SOC-minimum setting is successfully operative in my environment since > 5 months and
  • the SOC limitation with a time controlled balancing reached a status, which I would like to test with another advanced expert.


You can apply becoming the beta tester, if you cover following conditions.

  • Your installation uses
    1. BYD LiFePo battery,
    2. MultiPlus-II (single or 3-phase installation)
    3. Grid-connection (no island solution in first beta test)
    4. Victron MPPT
    5. GX version >=2.80, MultiPlus-II >=494, MPPT >=3.10
    6. optimally also a Fronius inverter (but not mandatorily required)
  • You consider yourself as an advanced user of Node-Red (you should know about “persistent context” without looking into the manual)
  • For debugging purpose you make your system (Node Red and GX) available via VPN or a remote console like TeamViewer, Teams or Zoom.
  • You are willing to provide extended descriptions of your system behaviour.
  • After any change you spend major attention from your side by observing the system reaction on longer term.
  • You accept that I will not be liable for any damages on your system caused potentially by this modul.
  • You confirm that you will not redistribute any parts of the code (also not in an adapted version).


You can apply to attend the beta by sending me an email to gx-betatest@wconsult.eu.

2 |3000

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

shop6 avatar image
shop6 commented
thomasw-1, could you name the day ahead solar forecast service?

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.

thomasw-1 avatar image thomasw-1 commented ·

I decided for Solcast

0 Likes 0 ·

Your Opinion Counts

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