Storage of current SOC not up to date and thus lower on restart of cerbo than before

[lex2k0]

Describe the bug

I am using the nightly at the moment and I realize that the SOC value differs from the last one after I restarted the cerbo.
I had 97.2% aggregated and after the restart it was at 90.4%. So all the three battery instances lost power.
On the second try this day I had 91.9% and after the restart 90.3%.

I don't know this behavior from the

How to reproduce

1. Install the newest nightly
2. Charge your batteries
3. Restart the cerbo
4. Look for the differene

Expected behavior

I would expect a closer SOC than this big difference after a restart

Installation method

Install script from the documentation

Driver version of the currently installed driver

v2.1.20260312dev

Driver version of the last known working driver

v2.0.20250729

Venus OS device type

Cerbo GX

Venus OS version

3.70

Venus OS image type

Large

BMS type

Daly BMS

Cell count

8

Battery count

3

Connection type

CAN

USB hub

Yes, with external power supply

Config file

[DEFAULT]
; ---> GENERAL SETTINGS ---------------------------------------------------------
LOGGING = WARNING
;PUBLISH_CONFIG_VALUES = True
GUI_PARAMETERS_SHOW_ADDITIONAL_INFO = True
TELEMETRY = False
POLL_INTERVAL = 2.0

; Keinen Serial starter verwenden, der für eine Endlosschleife wegen dem Duppa Quadport sorgen würde. Alternative 'EXCLUDED_DEVICES'
;SERIAL_STARTER_ENABLED = False
; Ausschließen des Duppa Quadport VE.direct Extenders, da dies eine Endlosschleife erzeugt und immer wieder serialBattery gestartet wird.
EXCLUDED_DEVICES = /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2, /dev/ttyUSB3

; CABLE INSTALLATION DATA (Zum Ausgleich eines Spannungsunterschieds zwischen Shunt und BMS)
;VOLTAGE_DROP = 0.00
; <--- GENERAL SETTINGS ---------------------------------------------------------

; ---> EVE LF280K BATTERY DATA --------------------------------------------------
MAX_BATTERY_CHARGE_CURRENT = 100.0
MAX_BATTERY_DISCHARGE_CURRENT = 100.0

; 23.2V (SOC 0%)
MIN_CELL_VOLTAGE = 2.900

; 28.0V Bulk/Abs. (SOC 100% & CVL Max.)
MAX_CELL_VOLTAGE = 3.500

; 27.6V Float (CVL nach Erreichen von CVL Max.)
FLOAT_CELL_VOLTAGE = 3.450

; Gelegentliches Top Balancing bzw. Voll-Ladung nach einer bestimmten Anzahl an Tagen, falls die Batterien ansonsten nie unter SWITCH_TO_BULK_SOC_THRESHOLD oder SWITCH_TO_BULK_CELL_VOLTAGE_DIFF Fallen würden
SOC_RESET_CELL_VOLTAGE = 3.525
; Alle x Tage wird die Ladespannung auf SOC_RESET_CELL_VOLTAGE erhöht, so dass die Batterien regelmäßig vollgeladen werden
SOC_RESET_AFTER_DAYS = 14

; <--- EVE LF280K BATTERY DATA --------------------------------------------------

; ---> DALY SETTINGS ------------------------------------------------------------
BMS_TYPE = Daly_Can
CAN_PORT = can0
BATTERY_ADDRESSES = 0x01, 0x02, 0x03
;BATTERY_ADDRESSES = 0x01

INVERT_CURRENT_MEASUREMENT = -1
CURRENT_REPORTED_BY_BMS   = -300, -100, -97.4, -42.0, -19.6, -1.9, -0.01, 0.00, 0.01, 10.0, 33.1, 50, 300
CURRENT_MEASURED_BY_USER  = -300, -100, -96.6, -40.0, -19.1, -1.2, -0.50, 0.00, 0.50, 10.4, 33.8, 50, 300

SOC_CALCULATION = True
AUTO_RESET_SOC = True

; Temperatursensoren, aus denen die Batterietemperatur ermittelt wird (gemittelt)
TEMPERATURE_SOURCE_BATTERY = 1, 2, 3, 4
TEMPERATURE_1_NAME = C7
TEMPERATURE_2_NAME = C4
TEMPERATURE_3_NAME = C2
TEMPERATURE_4_NAME = C6
; <--- DALY SETTINGS ------------------------------------------------------------

; CVL/CCL/DCL VALUES -------------------------------------------------------
; Linearer Lademodus
CHARGE_MODE = 1

; Setzen von CVL zur Nutzung von Bulk-/Abs- und Float-Spannungswerten erlauben
CVCM_ENABLE = True

; Der Ladestrom (CCL) muss angepasst werden, damit potentielle Runner-Zellen eingefangen werden, bevor das BMS trennt --->
CCCM_CV_ENABLE = True
CELL_VOLTAGES_WHILE_CHARGING      = 3.620, 3.580, 3.520, 3.450, 3.440
MAX_CHARGE_CURRENT_CV_FRACTION    = 0.000, 0.010, 0.030, 0.500, 1.000
; <---

; Einstellungen für CVL zwecks Bulk-/Absorption und Float
; Keine dynamische Berechnung des CVL, so dass dieser auf MAX_CELL_VOLTAGE*8 (28,4V), bzw. FLOAT_CELL_VOLTAGE*8 bleibt
CVL_CONTROLLER_MODE = 0
CVL_RECALCULATION_ON_MAX_PERCENTAGE_CHANGE = 20

SWITCH_TO_FLOAT_CELL_VOLTAGE_DIFF      = 0.015

; Setzt den Timer für den Wechsel zu Float bei einer Spannungsdifferenz von xV  zurück
SWITCH_TO_FLOAT_CELL_VOLTAGE_DEVIATION = 0.005
SWITCH_TO_FLOAT_WAIT_FOR_SEC = 600

; Setzt das CVL auf CVL Max anhand von MAX_CELL_VOLTAGE bzw. der Differenzspannung zwischen der niedrigsten und höchsten Zelle
SWITCH_TO_BULK_SOC_THRESHOLD = 60
SWITCH_TO_BULK_CELL_VOLTAGE_DIFF = 0.050

TEMPERATURES_WHILE_CHARGING      =    7,    8,    9,   10,   40,   46,   47,   48
MAX_CHARGE_CURRENT_T_FRACTION    = 0.00, 0.25, 0.50, 1.00, 1.00, 0.50, 0.25, 0.00

TEMPERATURES_WHILE_DISCHARGING   =  -10,    0,    5,   10,   40,   46,   47,   48
MAX_DISCHARGE_CURRENT_T_FRACTION = 0.00, 0.25, 0.50, 1.00, 1.00, 0.50, 0.25, 0.00

CHARGE_CURRENT_RECOVERY_THRESHOLD_PERCENT = 0.015
DISCHARGE_CURRENT_RECOVERY_THRESHOLD_PERCENT = 0.015

Driver startup log

nothing relevant

Relevant log output

nothing relevant

Any other information that may be helpful

No response

Please confirm that you have completed the following steps before submitting your support request

• I have carefully read all the instructions above including the descriptions.
• I have tried the nightly build first, if I was not already using it. This means the logs I provide are from the nightly build.
• I have rebooted at least once after I saw the issue.
• I have read the complete changelog.
• I have provided the logfiles in the correct format with a HUMAN READABLE timestamp by piping it through tai64nlocal.
• I have clicked all checkboxes because I did not read the instructions.

[lex2k0]

@mr-manuel. One interesting thing I saw today is, that the SOC is going back to the same value after I restarted the driver when it was charged to 100%.
Yesterday:

1. Battery 1 went to 90.2%
2. Battery 2 went to 95.6%
3. Battery 3 went to 95.0%

Today: Exactly the same.

But the other thing is... If I am doing another restart, in the morning... Then the SOC is increasing.

[lex2k0]

Update to my last comment.... Restarted the driver this morning to see the behavior as it is rising in the morning.
I recognized that it is also going to the same level like when I restart it when the batteries are full. Meaning 90.2, 95.6 and 95.0%.
You can also see this in the two pictures I sent in my last comment on the left.

So somewhere those values seems to be stored...?

[lex2k0]

@mr-manuel: Update to this topic... It seems that there are also other data issues for that. Had the driver running for many days but today I've done a restart of the driver and then I recognized that also the time of the last reset of the driver was not stored. It went into the reset directly.
This is after the restart:

And after the reset was done, you see the time of the last reset went to 0 days (battery 2):

For testing purposes I've done another restart of the driver after this and then I saw what I thought. The days since last soc reset are some old stored data (battery 2):

So for some reason the driver is maybe not updating the data persistent or whatever the reason is. So it is not longer only the SOC, it is also the SOC reset data. But maybe others, what I don't know yet.

Hope this helps and you have an idea where the issue is belonging to.

[lex2k0]

@mr-manuel: So, I found the root cause of the problem. Nearly a month ago my cerbo created new devices for my three batteries giving them also new vrm ids. For this reason there are new entries created in the settings area. The newer ones were written uppercase, the older lowercase:

The driver successfully identifies this and was also taking the newest id to work with and was writing the settings into this newest entry.

But while starting of the driver, because of the sorting of the devices, the last data read where from the old device... For this reason it was always the same on a restart. It loaded the old device data but stored it in the new device.

I was doing a rework of the code to solve this. It loads the data from the newest lastseen device.

Also I found a potential lack with the 15 seconds store limit using the modulo operator... This could probably not work if POLL_INTERVAL so it is maybe later than this...

And also a rework of the store procedure of the values because if one of the store trials is not working, all following other settings will also stop from saving.

I will add a pull request for this.

[mr-manuel]

Thanks! Yes I changed the way it's stored and made it all lowercase, to prevent such issues in future, but it made a new issue (:

[cgoudie]

Related dbushelper cleanup (does not address this bug; see #429): merge coordination with that PR is noted in #433

[cgoudie]

Scope / other tickets: The persistence behaviour here (duplicate `serialbattery_*` settings entries, load order, save cadence) is what PR #429 targets — separate from the D-Bus multi-battery crash in issue #410.

For setups like the original report (several packs on one CAN), both should be on `master`: #410’s keyed `get_bus` pattern (see #410 and PR #402 follow-up comment) and #429 for correct SOC/settings continuity. Fixing only one side can still leave reboot or multi-instance behaviour wrong.