[Bug]: prefer battery loading instead of feeding pv / solar to grid

[disaster123]

Contact Details

through github

VRM portal ID

e45f019ec891

Country / region

Germany (de)

B max

10

TB max

4

FB max

4

TG max

4

FG max

4

Battery costs

0.01

Buy price

(p+0.1574)

Sell price

0.07

feed-in possible

no

feed-in control

no

Version

0.1.6

What happened?

Not sure if this is a bug but at least it is a problem to me.

I would like to see that the systems uses all free available pv / solar power to feed the battery even the target soc is reached. This ensures that if the wheather is cloudy or changes the battery is full. Currently it could happen that the battery is later loaded by grid which is expensive.

Relevant log output

No response

Screenshots

![DESCRIPTION](LINK.png)

[DennisBosmans]

Check Issue #70

[MichaKersloot]

As the Dess is biased to optimal profit, it could be it's more profitable to import the needed power from the grid NOW and sell the excessive PV power later. Or the other way around ;-) As the whole calculations are based on forecasts, it has to rely on forecasts to figure out the best strategy. Even if it seems counter-intuitive.

[disaster123]

@DennisBosmans @MichaKersloot current problemn is that at least my forecast is not very accurate if it's cloudy or rainy. It differes in those cases up to 70%.

For example today with "only" 50% difference:

[MichaKersloot]

In my opinion this is a result of the switch from SOC to Setpoint. I've posted my idea's about this in issue #96. By steering on the SOC, it means you can make sure the battery is charged to a certain level, even if the forecast is less than predicted. The downside is that excessive solar is send to the grid for a low price. I'm not sure if it's the case for everyone, but for me having less power in the battery than predicted is preferred over 'wasting' solar for a low price. And maybe there is a solution in between. Maybe they could work with something like a minimum SOC for an hour on charging and a maximum SOC on discharging. In that case you could follow the predictions and allow overcharging by solar and take that in account with the calculations for the next hour. Same on the dis-charging. Although that is probably already the case because of the limits you can set. If you want to discharge you battery with 40%, but there is a lot more solar then forecasted the Multiplus current limit would limit the capacity you are really allowed to feed in the grid from the battery and could leaf you with more charge in your battery than expected.

[andreashackel]

From my point of view, this situation is a bug, because of different processing in the same hour, depending on the Battery SOC. I saw the same situation in my system (Node-Red V0.1.7) when most PV power went to the grid instead of the battery. For simulation, planned SOC (msg.soc for Schedule 0) was set to 50 by my own extension. I deactivated the DESS and the battery (48% SOC) was charged as usual with max power. At the scheduled 50% state of charge, I reactivated the DESS and the system is charging at max. Power to the battery. So, if the current SOC of the battery is slightly below the planned SOC, the DESS will try to reach the target SOC in the current hour. However, since only a small amount of power is required for this, most of the PV power is fed into the grid. At this point, optimization is required to provide more power to the battery when the PV output is higher than planned.

[pokeplayer2]

Sell to grid should not start before the battery is at x % of SOC and this % should be a parameter. From October is x like 100 % and beginning with April is x maybe 80%.

[dirkjanfaber]

From the latest candidate release (3.20~17 and higher) it became possible to add restrictions (see https://github.com/victronenergy/dynamic-ess#restrictions). Can you switch to that and test? I'll close this bug for now. Please create a new one if the problem persists with that new version.