Wrong Charge Voltage Limit (FLOAT instead of MAX)

[MisterX1000]

see #415

After installation of v.0.14.3 FLOAT_CELL_VOLTAGE is used for CVL instead of MAX_CELL_VOLTAGE .

MIN_CELL_VOLTAGE = 2.9
MAX_CELL_VOLTAGE = 3.45
FLOAT_CELL_VOLTAGE = 3.35

With v.0.14.2 the CVL limit works like expected!

Here you can see that I installed the v.0.14.3 at 12.Jan - there was the CVL "jump" down.

[rcrc1978]

I'm having the same problem, in the picture you can see the gragh for CVL it starts at 13.8v (linear false). Then enabled you can see CVL goes to 13.4v, then I upped the float voltage to 3.4 and it then goes to13.6v. Finally disabled linear setting and back to 3.45/13.8v. I posted in 3 other places but they were either closed topics or old posts and likely would not be seen. Came on here again this morning and found yours.

[morres83]

Are there any updates on this topic? In my understanding, when looking at the code, linear mode is not usable as it will only charge up to the FLOAT voltage instead of the MAX voltage.

[pkali1]

Inside battery.py change FLOAT_CELL_VOLTAGE to MAX_CELL_VOLTAGE and linear might be working.
I will test it today, if there is a sun..

def manage_charge_voltage_linear(self):
foundHighCellVoltage = False
if CVCM_ENABLE:
currentBatteryVoltage = 0
penaltySum = 0
for i in range(self.cell_count):
cv = self.get_cell_voltage(i)
if cv:
currentBatteryVoltage += cv

                if cv >= PENALTY_AT_CELL_VOLTAGE[0]:
                    foundHighCellVoltage = True
                    penaltySum += calcLinearRelationship(cv, PENALTY_AT_CELL_VOLTAGE, PENALTY_BATTERY_VOLTAGE)
        self.voltage = currentBatteryVoltage    # for testing
    
    if foundHighCellVoltage:
        # Keep penalty above min battery voltage
        self.control_voltage = max(currentBatteryVoltage - penaltySum, MIN_CELL_VOLTAGE * self.cell_count)
    else:
        self.control_voltage = MAX_CELL_VOLTAGE * self.cell_count      #  ............may be this is the problem........

[morres83]

I think this will not fully sove the issue. By doing this, you would most probably be able to charge to MAX voltage, but it will never switch to FLOAT, which is also not the desired behavior.
I guess the code from manage_charge_voltage_step(self) which seems to be working for me needs to be used as basis for MAX-FLOAT switchover.

[pkali1]

Do we really need floating after some max_voltage time?

[MisterX1000]

Do we really need floating after some max_voltage time?

Exactly what I thought - If we use LiFePo4 cells it is unnecessary ;-)

[morres83]

The step mode does reduce to the float value currently and certainly it is out of the LiFePo4's comfort zone if you keep the high voltage forever.
I have to say that I don't understand currently how exactly this PENALTY thing is supposed to be working, if this is ensuring that the high voltage is reduced after some time, it could be okay. But if the cells are not perfectly matched I think high voltage should be kept for some time and the reduction should not occur immediately after one cell hits the high voltage (i.e. to also give the balancer some more time). But as I said, maybe the PENALTY logic is doing all this correctly and the only thing to change then is what pkali1 suggested... ?!

[pkali1]

Bug repair tested and working. (without switching to float) Makes my home solar every day charging cycle more smooth and fluent. Take care with setting penalties. If someone adds lineard tDiff for floating floating, it would be perfect.

Here is my example of setting (16x Lifepo4 200Ah) .

Set Steps to reduce battery current. The current will be changed linear between those steps
CELL_VOLTAGES_WHILE_CHARGING = [3.55, 3.50, 3.45, 3.30]
MAX_CHARGE_CURRENT_CV = [ 0, 10, 30, 50]

if the cell voltage reaches 3.55V, then reduce current battery-voltage by 0.01V
if the cell voltage goes over 3.6V, then the maximum penalty will not be exceeded
there will be a sum of all penalties for each cell, which exceeds the limits
PENALTY_AT_CELL_VOLTAGE = [3.47, 3.55, 3.6]
PENALTY_BATTERY_VOLTAGE = [0.01, 0.05, 0.1] # this voltage will be subtracted

Thanks and I think you can pull this simple bug repair into code.

[pkali1]

`
def manage_charge_voltage_linear(self):
    foundHighCellVoltage = False
    if CVCM_ENABLE:
        currentBatteryVoltage = 0
        penaltySum = 0
        for i in range(self.cell_count):
            cv = self.get_cell_voltage(i)
            if cv:
                currentBatteryVoltage += cv

                if cv >= PENALTY_AT_CELL_VOLTAGE[0]:
                    foundHighCellVoltage = True
                    penaltySum += calcLinearRelationship(cv, PENALTY_AT_CELL_VOLTAGE, PENALTY_BATTERY_VOLTAGE)
        self.voltage = currentBatteryVoltage    # for testing

        if None == self.max_voltage_start_time:     # zacatek noveho kodu
            if MAX_CELL_VOLTAGE * self.cell_count <= currentBatteryVoltage and True == self.allow_max_voltage:
                self.max_voltage_start_time = time()
            else:
                if SOC_LEVEL_TO_RESET_VOLTAGE_LIMIT > self.soc and not self.allow_max_voltage:
                    self.allow_max_voltage = True
        else:
            tDiff = time() - self.max_voltage_start_time
            if MAX_VOLTAGE_TIME_SEC < tDiff:
                self.max_voltage_start_time = None
                self.allow_max_voltage = False      # konec noveho kodu


    if foundHighCellVoltage:
        # Keep penalty above min battery voltage
        self.control_voltage = max(currentBatteryVoltage - penaltySum, MIN_CELL_VOLTAGE * self.cell_count)
    else:
        if self.allow_max_voltage:										# zacatek noveho kodu
            self.control_voltage = MAX_CELL_VOLTAGE * self.cell_count
        else:
            self.control_voltage = FLOAT_CELL_VOLTAGE * self.cell_count    # konec noveho kodu`

[pkali1]

Floating time added. Not complete testing.

[pkali1]

The code from battery.py was not complletely copied.. sorry. Now corrected and working correctly with driver 14.3 and venus 2.90.
Regards

[mr-manuel]

Someone knows, why this was changed?

3685d15#diff-9d9b25b4a5dcc9b6f162c96264601c1986789dd796a6b170586076a746fabbc0R126-R130

[mr-manuel]

The code from battery.py was not complletely copied.. sorry. Now corrected and working correctly with driver 14.3 and venus 2.90. Regards

@pkali1 you are right, that the time counter for the max voltage is missing.

I added this to my fork. Please try it and let me know. https://github.com/mr-manuel/venus-os_dbus-serialbattery/tree/issue-421

You can install it by executing this commands:

cd /tmp

wget https://github.com/mr-manuel/venus-os_dbus-serialbattery/archive/refs/heads/issue-421.zip
unzip issue-421.zip

cp -rf /tmp/venus-os_dbus-serialbattery-issue-421/etc/dbus-serialbattery/ /data/etc

chmod +x /data/etc/dbus-serialbattery/*.sh
chmod +x /data/etc/dbus-serialbattery/*.py
chmod +x /data/etc/dbus-serialbattery/service/run
chmod +x /data/etc/dbus-serialbattery/service/log/run

bash /data/etc/dbus-serialbattery/reinstalllocal.sh

Pay attention, that in this release the configuration is not done anymore in the utils.py, but in a custom config.ini. Just copy the config.sample.ini. This prevents overriding the settings after updating in future versions. It includes also a lot more changes.

[Bonzai10]

hello,
unfortunately no change. it takes allways the info from step, not linear. Time to Soc also not available.

[mr-manuel]

Is this enabled?

dbus-serialbattery/etc/dbus-serialbattery/default_config.ini

Lines 88 to 89 in 6471152

	; Charge voltage control management enable (True/False).
	CVCM_ENABLE = False

Currently the config file is a bit confusing, I will fix that.

[Bonzai10]

no changing :-( i changed MAX_CELL_VOLTAGE = 3.50

[Bonzai10]

I think the whole linear is not activated

[mr-manuel]

Have you a voltage curve how the linear and how the step mode should look? I need some more days for further testing. The curve would help me a lot.

[Bonzai10]

No, after the install of your Version the data is lost 👎

[mr-manuel]

In VRM Portal? Check if the VRM ID changed

[mr-manuel]

no changing :-( i changed MAX_CELL_VOLTAGE = 3.50

If you changed MAX_CELL_VOLTAGE to 3.50 then this should be right. 3.50 * 16 = 56.00 or am I wrong?

[Bonzai10]

But i chosed linear, the changing was under step. Therefore i belive that linear is not avaliable. I check tomorrow the VRM again. I believe the usb Port hast changed. This Bug comes with changing from 14.2 to 14.3.

[mr-manuel]

@WaldemarFech maybe you can help us with that? How should the linear mode you implemented work exactly?

[WaldemarFech]

Sorry - where's the beginning of the "problem"? 😅

short:
the linear mode was to reduce the charge and discharge current limits - instead of jumping around while reaching the next step.

• but no linear change of any max. charging voltage - this is, as the word say, the maximum... so i would set this to 3.6V (because in my case the BMS resets to 100% when one cell reaches 3.6V). The LiFePo4 cells have absolutely no problem with 3.65V - but you should not go over 3.75V. So there should be everything okay with 3.6V - this will be reached just a minute or less after 3.5V (depending on your charge current of course).

anyway:

• the Victron and other chargers are not made to measure currents below 2A. So if we calculate a charge or discharge current limit of less than 2A, let's say 0A - then it should stop (we also send the stop charging command).
  BUT ... the charger goes then in the "ok, let's hold the actual voltage then ..."-mode .... and while it tries to hold this voltage (absorption Phase), then there still flows current into the battery - while it shows 0A - wrong!

What's my solution? A: I've implement the penalty mode.

• You can set a penalty voltage. IF one cell goes over a specific voltage, THEN it means, that the actually "absorption" voltage is too high and there is still a flow of current into the battery. So? So we have to reduce the maximum charge voltage until the cell voltage isn't increasing anymore. But how much have we to lower the voltage? Well - until it stops rising. So as more cells goes over the maximum cell voltages and as higher they go over this maximum, as much the penalty will reduce the CVL.

check? :)

I haven't looked into the newer versions anymore - so i don't know what was changed.

can you post your relevant settings in your utils.py and a short description of your bug or the behavior that you would expect?

[pkali1]

Here are my driver v14.3 and Venus 2.90 with Daly BMS working files. I hope it helps you.

battery.py.txt
utils.py.txt

[Bonzai10]

Hello,
the error arose when changing from 0.14.2 to 0.14.3. there were moved settings from utils.py to battery.py. Since this version it doesn't work for me anymore. Yours (WaldemarFech 0.14.3) works wonderfully.

however, all the innovations would be "nice to have" as well as the Bluetooth version

[morres83]

And even more strange things seem to happen, the battery is discharging by exactly 1.0A some seconds and then charging again with CCL. Seems being in a cycle. I have seen this also in non-linear mode but it occured only after swithing to float (53.6V). NOW CVL is much higher (as I said before it didn't change to fload mode) and still this discharging occures. You know why?

For your comment above, yes my penalty and max values were the same at 3.5V. I will change the first penalty voltage a bit higher and test the result..

[mr-manuel]

The effect you are seeing (charging/discharging) is triggered when the battery hits the CVL voltage. It doesn't matter what the voltage is. As the reasons I described above, the voltage is not lowered.

I update the config file to make that more clear, since it is not clear and I took a lot to understand how all is working.

[mr-manuel]

If you use the latest version from my fork and branch issue-421 you see also more informations about the current charge mode. It was uploaded just now.

[morres83]

OK I will give it again a try with latest version.

Where exactly is it specified that a discharging by 1 A is done? Is it a Victron "feature"?
In the nonlinear mode normally the CVL is hit when it is reduced to Float. Therefore I understand the discharging.
But I still don't get it for the penalty, penalty is acting on CVL, isn't it?

P.S.: The charge/discharge is the same for me when I set the first value of penalty at 3.51 and the Max_cell_voltage to 3.5

[mr-manuel]

Where exactly is it specified that a discharging by 1 A is done? Is it a Victron "feature"?

Nowhere. The battery is used as a buffer and when the battery voltage is the same or very close to CVL then this is the normal behaviour of Victron to maintain stability.

In the nonlinear mode normally the CVL is hit when it is reduced to Float. Therefore I understand the discharging.

No. CVL is reduced in step mode and also in linear mode when the battery voltage is the same as CVL for x seconds.

But I still don't get it for the penalty, penalty is acting on CVL, isn't it?

Thats true. Please read the linked comment for the penalty. #297 (comment)

[morres83]

So, I have been testing your script, that's the result of yesterday:

About 3pm I changed the penalty above the max (3.51V vs 3.5V) with no visible result in behavior.
I am unsure if this behavior works as expected by you (at least I don't like it that CVL and CCL literally change every single second).
As I am very unsure how to reproduce this on two parallel battery packs, so I might switch back to step mode and program something by myself into the aggregate/virtual battery device based on ther serialbattery raw data of the two battery backs.

[mr-manuel]

Have you also checked also the cell voltages? Without them it‘s hard to tell what happens. Also I added the Charge mode field to the GUI to see whats happening. Probably your cell voltage difference is to high. As described above it switches only to float, if the battery voltage reached CVL and all cell voltages are below penalty voltage.

For the linear mode I‘m also a bit sceptic that it changes every second. Maybe it would be better to do it all 60 seconds.

I don’t know how it behaves when two batteries want to change the CVL. More secure would be to respect the lower requested voltage.

[mr-manuel]

at least I don't like it that CVL and CCL literally change every single second

@morres83 I just uploaded a new version, where you can set, how often the penalty voltage is calculated (PENALTY_RECALCULATE_EVERY). So you can set it to 60 seconds or whatever you like.

[wormsman]

@mr-manuel this version seems to work quite well. For a real test I have to wait until it is sunny. When do you think you can put out a new version with your new additions and also the bluetooth for the jkbms?

[mr-manuel]

After this is merged: #459

[rcrc1978]

Mr-manuel

I'm trying to install/test your work, I'm new so have some questions. I copied/pasted each line into putty from your note below and hit enter after each one. After the very last one I rebooted, then went in and verified that "charge mode" shows under my serial batteries and it does.

cd /tmp

wget https://github.com/mr-manuel/venus-os_dbus-serialbattery/archive/refs/heads/issue-421.zip
unzip issue-421.zip

cp -rf /tmp/venus-os_dbus-serialbattery-issue-421/etc/dbus-serialbattery/ /data/etc

chmod +x /data/etc/dbus-serialbattery/.sh
chmod +x /data/etc/dbus-serialbattery/.py
chmod +x /data/etc/dbus-serialbattery/service/run
chmod +x /data/etc/dbus-serialbattery/service/log/run

bash /data/etc/dbus-serialbattery/reinstalllocal.sh

After doing each of the above+enter for each line I logged in and checked the "nano /data/etc/dbus-serialbattery/utils.py" and looked through everything and see it's changed with no options to really adjust charge settings.

Then I went in and tried "nano /data/etc/dbus-serialbattery/config.ini" and all I have is a blank screen with no script. Do I just copy/paste everything from this link https://github.com/mr-manuel/venus-os_dbus-serialbattery/blob/7562c7432988146a19443691a5ae92707116662f/etc/dbus-serialbattery/config.default.ini#L13-L37[](url) into the config.ini on the putty screen?

[Bonzai10]

You have to edit: config.default.ini
This is the right one. only config.ini is wrong.

[mr-manuel]

You have to edit: config.default.ini
This is the right one. only config.ini is wrong.

@Bonzai10 this is wrong. You should not change the config.default.ini, since all changes are lost after a driver update. The intention of the config.default.ini was to maintain the custon configurations, therefore there is a config.ini. If you do not create a config.ini then all settings are fetched from config.default.ini. All you put in config.ini overwrites the settings in config.default.ini and survive a driver update.

@rcrc1978 you have only to insert the values in config.ini which you want to change. You start from a blank file and copy over the setting from config.default.ini you want to change. All other values are fetched from the config.default.ini. If you change config.default.ini it is oberwritten on every update.

[rcrc1978]

Thanks for the help Bonzai! I was able to get in there and adjust things, will test and see how everything goes.

Manuel i'm confused on that portion, there was no data available on the config.ini section. Do I copy and paste everything from the config.default.ini screen and then adjust those and save later so I can paste back in after updates?

[mr-manuel]

No. You create an empty config.ini and insert there only the settings you like to change (not use the default). For example if you want to chage the max charge and discharge current you only insert them into config.ini:

MAX_BATTERY_CHARGE_CURRENT = 70.0
MAX_BATTERY_DISCHARGE_CURRENT = 90.0

[ghost]

Hi Manuel,
I'm also testing your fork, thanks for your work!
I already have it running and I think it already does what it should do, but I must certainly test it a few mor days to be sure to understand everything.

One question:
If I change a parameter in the config.ini how can I activate the changes without restarting my raspi? (don't want to restart if not neccessary because the USB Port of my JK BMS is always changing after a reboot and therfore my node red do not work until I change them again)

Thx!

[morres83]

@locke981 you should just be able to use ./reinstalllocal.sh and it does everything for you.

But is it normal that on reboot ports get changed such that it is not recognized in NodeRed anymore? Seems strange to me... Do the BMS blocks in NodeRed are really (only) dependent on the USB port (and not the name or something else)?

[ghost]

you should just be able to use ./reinstalllocal.sh and it does everything for you.

Thanks will try that the next time I change something.

But is it normal that on reboot ports get changed such that it is not recognized in NodeRed anymore? Seems strange to me... Do the BMS blocks in NodeRed are really (only) dependent on the USB port (and not the name or something else)?

In Node Red the Node is not connected anymore, I have to select the Node inside the configuration of the Node again to get it working. I'm not aware if it's possible to change the node to something which is static like the name. If someone has a hint I would really appreciate it.

[mr-manuel]

But is it normal that on reboot ports get changed such that it is not recognized in NodeRed anymore? Seems strange to me... Do the BMS blocks in NodeRed are really (only) dependent on the USB port (and not the name or something else)?

There are a few issues and discussions about this. One of them is #481

[rcrc1978]

mr-manuel,

Your fork is working great for me so far, took me a while to get things adjusted properly so it would drop to float voltage. But after messing around for a bit things are working pretty good. I'm using two BMS's so sometimes one will drop to float voltage before the second does. So it does go to float voltage before the second BMS's can finish the bulk cycle. I'm slowly bumping up the max voltage time to give it more time to finish and balance, so far i'm at about 45m.

One thing I have noticed is when being blocked from charging due to batteries being to cold the system is not letting the solar chargers make enough current to let the BMS battery heater circuit to come on. There is enough power available but the Solar charges are being held back from producing any output. I can tell by the high voltage on the PV side and plenty of sun available. If I disable DVCC setting the solar chargers produce enough amperage the heater circuit kicks in to heat the batteries. After that gets going I just re enable the DVCC setting, not sure if it did this before trying your fork though. The system is new this year so no prior testing with using the solar chargers only for charging. With Louis's v.0.14.3 version the battery heater would come on when powering the Multiplus from the AC input, have not tested yours with the AC input but will try if it's cold enough here the next couple of days.

[mr-manuel]

Should the heater circuit not come on even if there is no sun and the temperature is to low?

[rcrc1978]

The JBD BMS heater circuit only works if charging current is available (higher system voltage than battery voltage). The BMS will let current out of the battery to maintain system voltage but not let any current to flow into the battery when below cold temp cutoff. What I'm seeing during cold temp cutoff the driver is preventing the solar chargers from producing enough current to completely stop all drain from the battery even though there is some available. I guess it may be a little hard to explain, there is always current flowing from the battery during cold temp cutoff. So in able for the heater circuit to kick in the current from the batteries has to go to zero so system voltage can rise above battery voltage to start the heater circuit. The driver is not allowing the solar chargers to bring the system voltage above battery voltage to stop current the coming out of the batteries. When I turn off DVCC it takes away the drivers control from the solar chargers and then uses the internal solar charger settings. This way it brings the system voltage up high enough to stop battery consumption and then starts the heater circuit, the BMS does block any current to flow into the battery during this state. Current just goes into the heater circuit.

Hopefully this explains it, I may just remove the BMS heater control circuit and use one of the relays on the solar chargers or cerbo gx to control it. At least that way I could turn them on regardless if charge current was available.

[mr-manuel]

I did not see the issue again with https://github.com/mr-manuel/venus-os_dbus-serialbattery/tree/issue-421. I will open a pull request for this next week.

[mr-manuel]

This is fixed in the next version. If you already want to try it you can execute this command

wget -O /tmp/install-nightly.sh https://raw.githubusercontent.com/Louisvdw/dbus-serialbattery/jkbms_ble/etc/dbus-serialbattery/install-nightly.sh && bash /tmp/install-nightly.sh

and select 2 for jkbms_ble. Since it's currently the most up to date branch. You can ignore the Bluetooth part.