Battery is force charged after being below minimum

[MaStr]

System was reaching its lower bound (notstrom dose) with 7% and stopped using the battery. I started batcontrol ( 0.2.10 preview with the different charge calculation) afterwards and batcontrol wants to recharge. But it makes no sense, because price target (0.18 Cent) is not met.

2024-11-13 18:35:28 DEBUG [FC Cons] predicting consumption: [433.9 335.7 339.4 305.6 258.  288.5 244.5 212.2 236.1 236.1 369.6 329.9
 326.1 318.2 327.8 345.1 349.3 337.4 449.9 431.4 430.  366.5 385.9]
2024-11-13 18:35:28 DEBUG [BatCTRL] Production FCST: [  0.   0.   0.   0.   0.   0.   0.   0.   0.   0.   0.   0.   0.  22.
 236. 452. 623. 738. 793. 809. 829. 744. 232.]
2024-11-13 18:35:28 DEBUG [BatCTRL] Consumption FCST: [433.9 335.7 339.4 305.6 258.  288.5 244.5 212.2 236.1 236.1 369.6 329.9
 326.1 318.2 327.8 345.1 349.3 337.4 449.9 431.4 430.  366.5 385.9]
2024-11-13 18:35:28 DEBUG [BatCTRL] Net Consumption FCST: [ 433.9  335.7  339.4  305.6  258.   288.5  244.5  212.2  236.1  236.1
  369.6  329.9  326.1  296.2   91.8 -106.9 -273.7 -400.6 -343.1 -377.6
 -399.  -377.5  153.9]
2024-11-13 18:35:28 DEBUG [BatCTRL] Prices: [0.4   0.385 0.342 0.329 0.328 0.32  0.314 0.312 0.307 0.302 0.301 0.302
 0.316 0.33  0.344 0.34  0.342 0.341 0.338 0.344 0.352 0.362 0.368]
2024-11-13 18:35:28 DEBUG [BatCTRL] Evaluating next 23 hours until 16:59
2024-11-13 18:35:28 DEBUG [BatCTRL] Reserved Energy: 0.0 Wh. Available in Battery: -7.7 Wh
2024-11-13 18:35:29 DEBUG [BatCTRL] Discharging is NOT allowed
2024-11-13 18:35:29 DEBUG [BatCTRL] Charging allowed: True
2024-11-13 18:35:29 DEBUG [BatCTRL] Additional Energy required: 7.7 Wh
2024-11-13 18:35:29 DEBUG [BatCTRL] Mode: grid charging. Charge rate : 18 W

beside of that, it seems the Fronius does not charge from the grid 👎 : , might be another issue

[MaStr]

Yeah, this is the reason why we see some flattering on some users. We should add a margin on min_battery level, that we are not fighting against fronius min value.

[MaStr]

Merged into Release-0.2.11 branch for testing

[johannesghd]

I've had this issue too and my approach was slightly different:

I've set a new config flag in my local fork that adds x% of SoC to the calculations as a iron reserve and changed the discharge logic. I chose 2, ergo with 8% as the backup power reserve, I end up having a 2% buffer between what batcontrol will plan to (i.e. 10% SoC) and beyond which the fronius inverter will stop discharging (i.e. 8% SoC). I've also floored the SoC/stored energy with 0, thus can't get negative charge rates in the calculation either.

Setting the discharge logic from > to >= also avoids one drawing from the grid in the morning if the pv power starts to ramp up a bit slower than forecast.

I've had this running for a few days locally and it appears to be an improvement.

[MaStr]

I'm on the %buffer side above the MIN_SOC delivered by Fronius. It also keeps the system more away from a "forced recharge" by the internal inverter logic. But to implement this, we should a config parameter MIN_SOC-Margin or something. If we hide that in the code, more questions will rise.

[muexxl]

Hi, I think we do not really need a new parameter here. I fixed it ensuring that the force charge process is only triggered if the required energy is >0. Should do the job, without overcomplicating things.

[MaStr]

Hey, I am not sure if staying at MIN_SOC is something we should do.

My case yesterday: the produced energy did not lift the battery by 1%. So the battery hovered around 6% (7% is backup up). During the evening, it dropped down to 5% due to self discharge. In the night the battery was forced charged to 7% again by Fronius.

[muexxl]

What do you suggest though? I mean if we forbid discharging at level X being greater than min_soc actually X becomes the new min_soc.

[MaStr]

Sure, it is a new minimum, which is true.

My main goal is to avoid the internal forced recharge during high prices.

Currently, im losing 2-3% while staying at batcontrol Minimum...

I can create an external logic which schedules a forced recharge, or increase the backup power threshold to have a higher margin.

[muexxl]

Makes sense! So basically we want to shift the forced recharge from a random time to a controlled time at the cost of having a little less capacity available.

[MaStr]

So, we will add a % margin above the MIN_SOC reported by Fronius.

I had another "incident" today, while the battery was hovering around our minimum, was released and dropped below MIN_SOC - was recharged by the inverter immediately.