Idea

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.

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.

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

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.

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

"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 ;)

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.

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

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

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?

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.

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.

thomasw-1, could you name the day ahead solar forecast service?