Battery of charge state 0%

[joe63]

Hallo Reinhard.
I have run a HUB 2000 and a AB 2000 with an HM-800.

I the last week there were 2 times that the Battery of charge state sank to 0%.
Which switches in the ini or on homeassistant I have to set to prevent the dis-charge. the max-dis-charge-level is set to 10%.

Battery of charge state 0%.

thank you

br joe

[reinhard-brandstaedter]

The SoC levels are properties if the hub, not of sf-control, you will find them on the hub device.
Note that your hub can still go down to 0 as it will consume power itself.

[joe63]

But the discharge-limit was/is set to 10%

[reinhard-brandstaedter]

Which means the hub will stop feeding to home at 10%, and only consume from battery what it needs for own operation. Totally fine.
sf-control can’t override the firmware in that regard, even if it would try to get more at 10% the hub won’t provide it.
Even if the hub goes down to 0%, no issue with that either, actually its good to do that from time to time.

[joe63]

thank you for your quick response. I have set an alarm for reaching 11% of discharge and will the observe the log and electricLevel of my AB2000. Because last week I had 2 times 0% charging state.

[joe63]

Hallo,
I think I found the reason: Probably the Battery State of Charge is not right at the end of discharging. In the diagram you see that the SoC decreases 1% every 5 minutes when the demand is about 210W. In the zone of 15% it stays 22 minutes. I think when the SoC-value would show 10% the battery is empty!!

Now I have changed the max discharge level to 15% to stop the discharging to Output to Home.

Do you know how I can calibrate the SoC?

BR Joe

[tuxianerDE]

Hey,

yes we know, this is what the chargeThrough internval is actually doing. In other words, from time to time you are required to charge to 100% and to 0% (i.e. full cycle) in order to get the BMS calibrated - for some time - until it starts drifting again.

in the latest dev build a MinSoC and MaxSoc is configured in the config.ini (optionally). in your case that would be 100% and 10%. When the system goes into CT mode, the system will set the respective values temporarily to 100% and 0% in order to do the full cycle.

[joe63]

Hi @tuxianerDE ,

thank you for the quick answer.
If it's allowed, melde ich mich gegen Ende der Woche (deutsch)

LG Joe

[reinhard-brandstaedter]

I don't see an issue with your observations @joe63.
Discharging of a battery is rarely strictly linear, a faster drop towards the end or a longer duration at one level is rather normal. Also as long as your batteries are not too cold a full charge/discharge cycle between 0 and 100% is also not problematic. As @tuxianerDE said...use the charge-through interval for that.

[joe63]

Hello Reinhard,

I have still problems with my battery-level. In the diagram you can see that a this morning the battery was made empty , beginning with discharging at 8:21 ( Sun: 07:11 - 16:06 offsets are 120min and 30min -> daytime 9:11 - 15:36 , ok?)

At 8:45 the battery is empty.

Battery-level las 7 days

do you have an idea? is the sunrise-offset to long? (value from summer)

thank you
BR Joe

[tuxianerDE]

Hey, can you provide some logs around that time.

Generally I see that the CT mode is set to active, what is does, it lets the battery charge to target of 100% and also resets the minimum charge to 0% for this interval to properly calibrate. But we should see more in the logs ideally from 07:00 till 09.30

[joe63]

HI
here is the logfile, but with UTC-timestamps, the diagram = local time (+1h)
BR Joe
sf_control_log_20241122_0600_0838_UTC.txt

[tuxianerDE]

here is the reason, the SoC was reported as 11% as of

2024-11-22 07:22:10,901:INFO: �[31;20mHUB: S:96.0W [ 96.0,96.0 ], B: 11% (11), V:46.8V (46.8), C: 0W, P:False (manual, possible), F:18.7h, E:143.7h, H: 93W, L:800W�[0m

this is when the SF Hub allowed the discharge this was not coming frm the SF control script.

What then happened, was that it dropped during a single interval from 11% to 0%, so the control script had no chance to react to the 10% charge and possibly even the firmware could not react as they could not shut down so quickly (that is an assumption however)

2024-11-22 07:43:08,729:INFO: �[31;20mHUB: S:86.5W [ 87.0,87.0,86.5 ], B: 11% (11), V:42.4V (42.4), C:-132W, P:False (manual, possible), F:19.1h, E:144.0h, H:211W, L:800W�[0m

2024-11-22 07:45:08,730:INFO: �[31;20mHUB: S:90.0W [ 90.0,90.0 ], B: 0% ( 0), V:41.9V (41.9), C:-133W, P:False (manual, possible), F:19.1h, E:0.0h, H:217W, L:800W�[0m

[joe63]

I think this behavour is also visible in the diagram from the last 12 days

Do you have any idea ? Is the battery goinig to defekt?
a work around? increase the max discagelevel to 12%

[tuxianerDE]

Hey,

that is typically a calibration problem. What is your ChargeThrough interval? It simply happens over time that the SoC starts to differ substantially from the actual charge in the battery.

I had once actually 1kWh in my batteries whilst my SoC wasa reporting 1% for like 6hrs (until it dropped to 0%) because of miscalibration.

[reinhard-brandstaedter]

As already mentioned I don't necessarily see an issue with going down to 0%.
There are two things to keep in mind:

• it's only one battery pack, so there is no averaging across multiple packs that would make this drop from 10 to 0 "slower"
• your hub solely can operate on this one battery
• sf-control doesn't report every tick of SoC change. so from the logs t looks like it went from 11% to 0%, which took 2 minutes (still fast but I also see those accelerated drops at the end with around 15minutes though).

If you look at those drops in your timeseries data, what do you see in reported values during the decline?
11-10-9-8-7-6-5-4-3-2-1-0 or rather a 11-5-0.

E.g. for me if I set the minSoC to 2%, the decline from 10% to 2% is rally fast but then it turns off the hub and the 2% stays for a few hours.

Also, do you have any recordings of the minVol/maxVol values?

[joe63]

@tuxianerDE
full_charge_interval = 120
the last cycle began vor about 4 days, yesterday the battery was full.

@reinhard-brandstaedter

0% -> it's the fear to destroy the battery!

in my influxdb I see only the 2-minutes values from sf-control
measurement % date
electricLevel 11 2024-11-22T07:42:00.000Z
electricLevel 11 2024-11-22T07:44:00.000Z
electricLevel 3.6 2024-11-22T07:46:00.000Z
electricLevel 0 2024-11-22T07:48:00.000Z
electricLevel 0 2024-11-22T07:50:00.000Z
electricLevel 0.3 2024-11-22T07:52:00.000Z
electricLevel 1 2024-11-22T07:54:00.000Z
electricLevel 1 2024-11-22T07:56:00.000Z

@also, do you have any recordings of the minVol/maxVol values?
not at the moment, but I will try to store them also.

what do you mean about to increase the max discharge-level to 12% / 13% for the next days ?

[reinhard-brandstaedter]

0% -> it's the fear to destroy the battery!

while a full discharge on LiFePo doesn't have the same negative impacts like on lead batteries, however shallow cycling between 20/90% might increase lifetime. So going down to 0 once in a while isn't that problematic.
And additionally the BMS should already take care of that (reporting a SoC that keeps this in mind)

in my influxdb I see only the 2-minutes values from sf-control
sf-control doesn't report any values in a two minute interval. Values are pushed by the hub itself at times when they change to MQTT. So if you are using a mqtt-telegraf-influx export then you should see more regular values. If you query your influxDB with a 30s aggregation window you should see more accurate data...
... unless you push the data in a different way.

what do you mean about to increase the max discharge-level to 12% / 13% for the next days ?
you can try to do that, but it pushes the problem likely only out. The root cause is that your SoC drops faster than expected.

[joe63]

@you can try to do that, but it pushes the problem likely only out. The root cause is that your SoC drops faster than expected.

yes I only postpone the 'problem' only. But the idea was not to stress the battery in short time to often. At the moment the SoC is again for longer at 15%. I think this level is not really right. the battery is sucked (out) and then it 'lays down' by 0% over the night.

the SoC was 29mintues at 15% (output 210W). the intervals before hat a duration about 5minutes.
In case of decreasing to 13% it stays over night (until the next load-begin) at 13 /12%.

[joe63]

Hi,

now I have also values for the battery voltage. At about 9:03 I changed the sunrise offset from 120m to 30m to end the discharging(At this time the charge-level was 11%). Then I saw in Grafana that the level then was 10% and so I missed the opportunity to see if the discharging would end.......