Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Low Battery Voltage Alarm if /Info/MaxDischargeCurrent = 0 #407

Closed
ppuetsch opened this issue Jan 12, 2023 · 17 comments
Closed

Low Battery Voltage Alarm if /Info/MaxDischargeCurrent = 0 #407

ppuetsch opened this issue Jan 12, 2023 · 17 comments

Comments

@ppuetsch
Copy link
Contributor

This is not actually a Bug with dbus-serialbattery, but a request for Help. I hope that someboday had similar observations and can help me out - as I am totally lost now.

Setup: 16S JKBMS, Multiplus II/48/5000/70
Observed pattern:
Everything works like a charm in ESS mode. However, once the battery is "empty" - i.e. dbus-serialbattery sets /Info/MaxDischargeCurrent to 0, venus os shows an Alarm Low Battery Voltage. Unfortunately, this alarm makes the Multi go in "slow charge mode". Now the multi will slowly charge the battery for a while (about 2-5 minutes), and then discharging is allowed again. This process now repeats over and over again.

However, there's no low battery voltage. Battery voltage is (way) above all ESS and Multi protection voltages.

So - how can I simply make the multi stop discharging the battery? How can I avoid this oscillation at empty battery?

@HotteX
Copy link

HotteX commented Jan 12, 2023

Just some brainstorming...no real help:

Did you set the ESS to "Optimized (with BatteryLife)" or without?
The slow charge mode happens with BatteryLife enabled and (at least for me) does not happen when set to "without BL" when the battery reaches 0.

If your Battery gets "empty" shouldn't it be reported as "0%" and trigger the alarms set within the utils.py? Or if alarms in dbus-serialbattery are disabled, maybe the alarm is not disabled but set to 0 instead?

@ppuetsch
Copy link
Contributor Author

ppuetsch commented Jan 13, 2023

Hi HotteX,

thank you very much for your Ideas. I will have a look at that.

For anyone else having a look here some Screenshots:
image
image
image
image
image
image
image
image
image
image

Right now, system behaves nicely: Battery is sitting there waiting for PV surplus to appear to start charging. I had the same situation yesterday - but the system didn't start discharging again when my house was receiving power from the grid. I then played around and had again the oscillation problem.

In case you see "strange" configuration let me know!

I will monitor this today and keep things updated.

@ppuetsch
Copy link
Contributor Author

ppuetsch commented Jan 13, 2023

Just some brainstorming...no real help:

Did you set the ESS to "Optimized (with BatteryLife)" or without? The slow charge mode happens with BatteryLife enabled and (at least for me) does not happen when set to "without BL" when the battery reaches 0.

It's set to "without BL"

If your Battery gets "empty" shouldn't it be reported as "0%" and trigger the alarms set within the utils.py? Or if alarms in dbus-serialbattery are disabled, maybe the alarm is not disabled but set to 0 instead?

No Alarms are coming from dbus-serialbattery right now - and that is as I configured it. The Alarm seems to come from ESS/Venus/Multiplus somehow. The Alarm even appears if MaxDischargeCurrent = 0 and SoC > 0

@kakariki1
Copy link

I think I have exactly the same problem and it was already discussed here:
#363

My solution for now is to set "Minimum SOC (unless grid fails)" to 5%

@ppuetsch
Copy link
Contributor Author

As @Louisvdw explained here:
#363 (comment)
one can see the cause for the Alarm in the error. So here's a Screenshot:
image

Seemingly, the Alarm comes from my Multi. But why? The only reason can be that dischargeCurrent is 0.

I also tried setting /Io/AllowToDischarge on dbus to 0 to prevent this Error - however this seems to not get propagated to vebus/Bms/AllowToDischarge

@MisterX1000
Copy link

Hey ppuetsch,

looks similar to my problem #371 - I saw a oscillating DCL around +/- 1A when one cell reaches the low voltage, set in the "CELL_VOLTAGES_WHILE_DISCHARGING" of 2.9V - "MAX_DISCHARGE_CURRENT_CV" should be at 0A at this point.

What helped for me was to reduce the "Cut off voltage for a discharge current..." in the settings of the ESS assistant.
The ESS voltages (same voltage in all 4 fields) must be a bit higher then 16x2.9V like set in utils.py.

If I set the values like this, the MP2 stops discharging and goes in "Sustain" mode before the serialbattery driver reduced the discharge current to 0A what causes the oscillation problem.

Best regards!

@HotteX
Copy link

HotteX commented Jan 13, 2023

Nothing obvious in your config to me. Looks a lot like mine (with small differences):
ESS Assistant
My Sustain is 3V * Cells
Cutoff is 2,8V * Cells.

I cannot really say a lot about the setup and its functionality as it is very fresh and Germany is lacking sun for sorrow testing. Ahh the moment it runs flawless.

[kakariki1] ...that looks a bit alike.

@Louisvdw
Copy link
Owner

I wonder of the 0% Min SOC is the issue. Normally you would not want to draw your battery that low, but I guess your BMS SOC value is not that accurate and you want to bypass it? So my first suggestion would be to change the min SOC to 5% or 10%

For information: the difference between Battery Life and Without Battery Life is that the system will increase the Min SOC value if it sees the battery was not fully changed in the previous day. The idea being that you want to have the battery up to 100% so that the ballancers can fix any cells. So if you use With Battery Life your Actual Min SOC will be sometimes higher that what you set Min SOC.

@ppuetsch
Copy link
Contributor Author

Hi @MisterX1000 ,

What helped for me was to reduce the "Cut off voltage for a discharge current..." in the settings of the ESS assistant. The ESS voltages (same voltage in all 4 fields) must be a bit higher then 16x2.9V like set in utils.py.

If I set the values like this, the MP2 stops discharging and goes in "Sustain" mode before the serialbattery driver reduced the discharge current to 0A what causes the oscillation problem.

Oh - that's a cool idea as well. Let the Multi handle the cutoff - not the BMS.

Now Battery is "too full" - it was quite sunny. I will monitor the current setup when battery is running low - and if oscillations occur, I will try your solution.

@ppuetsch
Copy link
Contributor Author

@Louisvdw
I just made a Test: I deployed a Version of dbus-serialbattery that always reports 20% SoC and AllowedDischargeCurrent=0. I did set ESS->Minimum SoC to 10%.
I immediately receive an Error about Low Battery Voltage - even though the battery is nicely charged:

image

So to my understanding this means: The Multi will understand a battery that reports "MaxDischargeCurrent" as 0 as "Low Battery Voltage". For now I don't see how to avoid this. And this will make the Multi slowly charge the battery, because the multi fells it's an alarming state ;-)

May I suggest to summarize those findings somewhere in your Documentation? I really like the proposal of @MisterX1000. BMS should only report MaxDischargeCurrent=0 in cases where the BMS wants to get the battery out of this state soon. So If no current is supposed to be drawn out of the battery, this needs to be managed by the Multi - e.g. by the ESS SoC Limit or the ESS Cutoff Limits.

What do you think?

@ppuetsch
Copy link
Contributor Author

Or - if ESS is not to be touched - one could also think about an algorithm/setup where MinimumSOC is set to some threshold (e.g. 5%). If BMS wants to stop current drawn, it will report a SoC <5% (e.G. 0%). If BMS wants to allow discharge, it needs to report a SoC > 5%.

@HotteX
Copy link

HotteX commented Jan 13, 2023

What helped for me was to reduce the "Cut off voltage for a discharge current..." in the settings of the ESS assistant. The ESS voltages (same voltage in all 4 fields) must be a bit higher then 16x2.9V like set in utils.py.

That might explain why my setup seem to work. My Cutoff is 2.8V and a little higher than the 0A-Value of serialbattery.

@MisterX1000
Copy link

MisterX1000 commented Jan 16, 2023

Just to be honest :-) With my settings I also get an "low battery alarm" message from the MP". But the "oscillation charge current problem" is solved and the alarm does not appear every 3-5 seconds like before.

I read somewhere in the Victron forum that this low battery alarm can not be completely suppressed, because many users use the MP2 in caravans or boats and if the alarm won't appear it could be dangerous for them.

image

So it is OK for me...the alarm disappears when the battery is charged again.

@kakariki1
Copy link

Hi ppuetsch,

do you have any news regarding this problem ?
Right now I have 3 systems, each in a slightly different configuration, and they all have this issue.
My solution for now is to set "Minimum SOC (unless grid fails)" high enough so the minimum battery voltage always stays above 16xMIN_CELL_VOLTAGE like set in utils.py.

Best regards,
lakeroe

@mr-manuel
Copy link
Collaborator

Could you all please try to set a value of 0.1 instead of 0 and see what happens?

@mr-manuel
Copy link
Collaborator

I was not able to reproduce this anymore.

@brunnema
Copy link

Hi HotteX,

thank you very much for your Ideas. I will have a look at that.

For anyone else having a look here some Screenshots:
image !
image image !

Right now, system behaves nicely: Battery is sitting there waiting for PV surplus to appear to start charging. I had the same situation yesterday - but the system didn't start discharging again when my house was receiving power from the grid. I then played around and had again the oscillation problem.

In case you see "strange" configuration let me know!

I will monitor this today and keep things updated.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hi ppuetsch and all other Reader comming to this point - I found the issue and could explain the behavior 👍

I'm still using driver 0.14 but think to upgrade to 1.0.x where I currently don't know the behaviour there...

Now - I'm facing the same issues cause my BMS slowly drift to 0% and in the meantime I reach the dicharge limit with 0A.
I tried an additional value before the 0A dicharge limit with 0,2A but then it only slow down the toggeling effect arround this issue.

THE IMPORTANT PARAMETER WHICH NEED TO BE ADJUSTED IS:

"allow inverter to discharge again when the Value rises above 1.2V cutoff (0)"
need to be higer to cover low batt alarm with 0A instead of ESS discharge volatge limit set value above the current Battery voltage!!

In more detail explained:
Based on ppuetsch screenshoots and comments in the thread and arround - I have these findings:

1# Inverter Values in VEconfigure will be overwriten with ESS discharge if it's in place.
2# ESS settings will be to values the Multi use as long that no Batterie Alarm occurs.
3# I assume that the Victron MP2 detects the battery Voltage but is not allowed to dischage cause of the 0A Command injected via DVCC
4# There must be a fault or battery protection in the ESS which trigers the MP2 not only on the ESS discharge limits setting
5# A battery low alarm triggers the MP2 charging the battery somehow with "slow charging" (approx 1-3A) at a certain time often the Discharge limit 0A will be removed by the DCL (via the script) cause of the raising Voltage and the Inverter Kicks in to discharge ...
#6 Difficult to explain in view words but it shlould be clear what happens.

Solution how to fix this - like HotteX decriebed - let the MP2 stopp this discharge and remain with sustain under the level where the inverter getes allowed to discharge (diff cutoff(0)) but why does it occour wasn't really clear for me because my serialbattery and ESS settings were much lower then the Battery Voltage were I stop at least Cell_Min Voltage at 3.2V during the winter time!

I fixed it in the opposite method but successfull with raising the diff value cause I would like to have the cut off voltage a bit variable and not using batterylife (I do my own controll with mode 3 via smarthome) - when you compare the screenshoots from ppeutsch - the really importend value to stop the toggeling is the setting >> "allow inverter to discharge again when the Value rises above 1.2V cutoff (0)"

here is the famus "ZERO" again in relation to the sustain feature (check Victron man to this if interested)

In my case I have same settings as in the screenshoots... Battery has 51.2V AND STOPS discharing 0A cause of the discharge DCL =0 at 3.2V setting in the serialbattery script.
The charger allways kicks in even if 0A rise a Sustain battery alarm, in ESS the sustain is set much lower (44.8V) same as the discharge limits, so there is no need to charge (cause the target sustain is lower then battery value)
This will result that the MP2 stops charging after less minutes and remain in the low battery alarm.
AND here comes the calculation how I avoid that the inverter kicks in staring it's discharging...

ESS limit 44.8V + 1.2V = 46V > if your CURRENT battery volatage is lower than this all fine... BUT all having this issue it DON'T like me (51.2V) !

I put this "allow inverter start discharge to a 7V value >> 44.8V (ESS setting) + 7V (allow discharge) = 51.8V

This value is now above my current battery voltage when reaching the 0A discharge settings and all is fine now :)

The charger starts charging the batt at sometime when PV is available and low batt alarm + inverter gets active >> back to normal.

Hope this will help all try to understand that pain after hours of dicking this issue
I'm not so happy that this behaviour occours in that way and victron will not clearly explain or state this in the ESS!

ESS is not really a offshore or camper feature therefore I can't understand why a BMS DCL =0 need to perform this sustain or slowcharge feature when the current battery value is over the ESS voltage settings ?!?

It would be interesting if someone can explain this reason or if it's aVictron BUG and it would be fixed soon.

BR Martin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants