Problem with DESS in green mode and Battery Monitor

@dfaber

Hello Dirk-Jan,

I have the following 2 problems, the first with DESS, the second with the battery monitor from the VE-Config software.

  1. This morning the battery was recharged from the mains, although 100% SOC was predicted for the day and prices were much lower later in the day. That’s uneconomical for me.

It would be nice if you would take a look.

My Portal ID: c0619ab10be7

  1. To explain first: I have an external BMS that is not coupled with the Multiplus II.

I found an error in the calculation of the SOC by the battery monitor in the VE configure, I think. It is set to 48.2 volts with SOC 90% for the transition from bulk/absorption.
However, the following happens: Always at 0.4 volts before the voltage is reached, the SOC switches to 90%, the battery remains in bulk mode. Then the SOC stays at 90% to 48.20 volts, then the battery jumps from bulk to absorption and the SOC continues to count up. It would be right if the SOC followed the green line.

This always leads to problems in the DESS, because the SOC jumps like that. I have tried several voltages, the jump in the SOC value always happens 0.4 volts too early. Can this be fixed by Victron?

Thanks a lot,
Dieter

And again the same bad situation, the loads are fed from the grid, the battery simply continues to charge instead of discharging.


image

What software version are you running?3.41?

Yes

and what about battery life? optimize with or without battery life?

Without Battery life.

We had this behavior of unconditionally reloading to the target Soc in the spring. But my system hasn’t done that for a few weeks now and I thought that was over.

1 Like

And again the same situation, the battery is not discharged or at least charged less. This will continue until the end of the hour unless the sun is shining and everything is powered by solar.
Even if more consumers are turned on, the battery doesn’t stop charging at full power. The difference is then drawn from the grid.


I am completely aware that this only concerns a few Wh, but the functionality is simply wrong.

As I have already mentioned, I am curious to see what the system does when there is not enough sun to charge the battery, only then do the strengths/weaknesses of such a system become apparent.

Today was the first time, what can I say…

In order:

approx. 2:45 p.m. Hardly any PV energy available, the house’s power consumption at 2kW is fed from the battery, everything OK

approx. 2:50 p.m. Power consumption of the house at 2.8 kW, the MPII can no longer supply this from the battery, the entire 2.8 kW is suddenly supplied from the grid and the control system starts to charge the battery with an additional 1 kW. Nothing is OK

approx. 2:55 p.m. The load of the house drops to 0.5 kW, the sun appears again, the battery is charged from the sun, everything is OK again

approx. 3:00 p.m. The forecast is recalculated, suddenly the battery starts to discharge and excess PV energy also goes into the grid, that is ridiculous and so not OK.

approx. 3:30 p.m. (now) Battery and PV energy are still going into the grid, even though the SOC is at 61% and PV energy is needed for the night, none of this makes any sense.

It would be very helpful if a developer would take a look at this, for me it all makes less and less sense, I have been observing this for about 4 weeks now and for me the system is, I have to be honest, getting stranger and stranger.

I forgot the screens:

now:

This is from my control:

image

Yellow/Gold: Discharge Battery
Orange: Charge Battery
Red: From the Grid
Darkgreen: Loads supplied by PV
Green and light green: Feeding PV into the grid

update 16:00 Uhr, the forecast is recalculated, now the battery is recharged with PV, even though it was discharged the hour before, crazy.

Thanks for all of the screenshots. Your system is also on the list of systems to further investigate, @bubu.
Can’t promise a swift answer though.

1 Like

OOPS, he did it again.

The calculated target SOC must be achieved at all costs, even if the energy for this comes from the grid.

Am I actually the only one with this problem?

Screenshot 2024-09-06 095549

@BuBu We just rolled out a fix (on the VRM side) for this. At the moment only active for your system. Can you check if this improves things?

Ok i will do this, thank you!

So from what I can see, things have gotten worse rather than better…

9:00-10:00 0.60kWh from Grid to Battery

Thank you. That 0.60 kWh is a graphing issue on the energy graph. In fact it was 0.26 kWh. So the problem is half as bad, but still not good. We’ll check where that 0.26 kWh comes from.

We are working on updating the energy graph to show the accurate values separately from this.

Looked further into that 0.26 kWh together with a colleague.
While the graph suggests the 0.26 kWh going from the grid to the battery, in reality that number is based on a best effort estimate of how the energy flows in the system. In your setup, you don’t have a battery monitor or smart shunt, so the calculation for that estimation can only be based on what info we do have. Which consists of the solar yield of the pv inverters, the energy use of the multi and the numbers we get from the energy meter.
So we are quite sure that the battery didn’t get charged from the grid during yesterday between 9:00 and 10:00. If it was charged, it would have been from the PV-inverters.

And I am curious where you made this screenshot from:

Is that from that Tesla powerwall? What did that one tell between 9:00 and 10:00 yesterday?

Let’s do the following: From Wednesday I’ll have a Smartshunt connected, then I’ll take a closer look at the matter again…

The screenshot is from a self-programmed controller based on a RasPi. Unfortunately, the daily process is not saved; the resolution is also too low for 0.26 kWh.

Having the smartshunt in wil definitely make the values more accurate and better traceable. Sounds good to me.