SOC issue - store between reboots

[lorenzo6201]

After each firmware update , reboot , shutdown the controller loses the SOC value. Maybe is a bug , maybe an oversight, I have no idea but would be nice for the controller to remember the last SOC value . I my case it went from 83% to 17% SOC after first reboot , and from 17% to 0% on second reboot.

Also a error log or rules triggered log would be beneficial because some issues are intermittent and hard to discover because no one is watching the web interface 24/7 . Having an error log would help pin point issues. the log can be saved on SD card.

[buddhafragt]

The last SOC is not saved. You are right, a error log will be nice!

[stuartpittaway]

No, the SoC is variable so doesn't survive a reboot. Obviously the controller/current shunt has no idea what has happened to the battery whilst it was powered off (or rebooted) so needs to re-sync after a full charge to 100% again

[lorenzo6201]

No, the SoC is variable so doesn't survive a reboot. Obviously the controller/current shunt has no idea what has happened to the battery whilst it was powered off (or rebooted) so needs to re-sync after a full charge to 100% again

Agreed , but do you know what the downside is? After reboot it goes to an arbitrary SOC value , sometimes 15% , 50% but i had instances where the SOC was 5% , 2% or even 0% and the inverter shutdown. This is valid with communication between the inverter and battery active. The other major issue is , if the inverter is OFF , the WIFI router is off and there is no way to connect to the BMS to set the SOC manually because the controller has no AP. In my case I have an ATS that switches to grid , but if someone is offgrid , they are doomed , the only way to turn on the inverter is to make manual battery settings , them you set the SOC to a higher value and redo the settings in the inverter.

So the logical step would be to save the last known SOC value and re-sync that value when charged back to 100%

[stuartpittaway]

The shunt code used to be hard-coded to 50% SoC on power up. This was changed to "guess" the SoC based on the voltage of the cells, but this assumes its a 24V or 48V LFP battery bank. Now this isn't accurate, just a guess based on the voltage of the cells.

If you are not using an 8 or 16S LFP setup, I can imaging this would cause problems.

[lorenzo6201]

@stuartpittaway I use 14S Lithium ion with internal shunt

[stuartpittaway]

Ah, ok, in which case the voltages would be very different to LFP. I'll add a GITHUB Issue/request to store the SoC

[dougnutz]

I think this would be an easy-ish fix. A. The guess could be updated to use the cell voltage cut off values. B. It could be stored to the sd card periodically (if there is a card) If stored with a time stamp it should be very close on a reboot scenario. I would be willing to submit a pr for this change, if you are looking for contributors :)

[stuartpittaway]

I would probably just use the internal flash on the esp32 as well do for all the other settings, and write that value every minute or so, plus restore on reboot.

The SOC is calculated dynamically based on the amphour counters so those are the values which would be saved and restored

[dougnutz]

Ok, I'll take a shot at this. It seems like an easy enough ask.

[stuartpittaway]

Hi @dougnutz I already started some work on this a few months ago commit number b58632f6a1fc73167c0c5b0d1d3d308b4037d226 and part of the "stateofhealth" branch.

[dougnutz]

@stuartpittaway Oh, nice. I had time scheduled for myself tomorrow to take a look. Are there any other issues that could use tending?

[stuartpittaway]

I could really do with some help testing the next release branch https://github.com/stuartpittaway/diyBMSv4ESP32/tree/stateofhealth

There is a new feature for "state of health" - which tracks the long term health of a battery/cycles.

Plus lots of other changes to the libraries and minor bug fixes

[lorenzo6201]

@stuartpittaway could you take a look at mennigd repository and maybe merge his version with your own?

[midopple]

Hi,

I have seen in the code that SOC is stored in flash every minute. The save to flash function has a rolling operation it always uses the next free memory so that a memory area is not used too often. But there are still 525600 write cycles per year, I think it would be enough to save every 10 minutes.

-->

// Once per minute, store the state of charge into flash, just in case the controller is rebooted and we can restore this value // on power up. if (mysettings.currentMonitoringEnabled && mysettings.currentMonitoringDevice == CurrentMonitorDevice::DIYBMS_CURRENT_MON_INTERNAL)

[stuartpittaway]

But there are still 525600 write cycles per year, I think it would be enough to save every 10 minutes.

If the value of the SoC hasn't changed, then the value shouldn't be written - but agree, increasing the value to more than 1 minute would make sense. On smaller battery systems, the state of charge could change quite quickly depending on the charge rate.

[red0909]

@stuartpittaway strange my soc survive after reboot of the controller but not if i disconnect my external shunt pcb from power then the soc is gone

[stuartpittaway]

strange my soc survive after reboot of the controller but not if i disconnect my external shunt pcb from power then the soc is gone

That's expected - if you use the external shunt, all those SoC calculations are done by its CPU not the controller.

[buddhafragt]

@stuartpittaway , safing the SOC is a very good idea, I use a 15S system and have the same problems! But a SD card dont have so many write cycles, so I think maybe a saving cycle if a full percentage is changed will be enough? Also a good improvement to find problems will be a error log at the SD card.