Reduce the big inrush current if the CVL jumps from Bulk/Absorbtion to Float #659

Rikkert-RS · 2023-05-21T18:17:19Z

Is your feature request related to a problem? Please describe.

The problem is when a very large battery is present and a voltage drop from bulk 55.2V to 54V float voltage happens in one go. A lot of energy is suddenly discharged from the battery. This can be up to 5kw or more.

Describe the solution you'd like

My solution is in the battery.py.

To reduce the inrush current i do this in steps with the update interval to the float voltage
my change is at line 275

OLD:

self.control_voltage = round(
  (utils.FLOAT_CELL_VOLTAGE * self.cell_count), 3
)
  self.charge_mode = "Float"

NEW

floatVoltage = round((utils.FLOAT_CELL_VOLTAGE * self.cell_count), 3)`
if self.control_voltage:
    if self.control_voltage >= (floatVoltage + 0.005):
        self.control_voltage -= 0.005
    else:
        self.control_voltage = floatVoltage
else:
    self.control_voltage = floatVoltage
self.charge_mode = "Float"

Describe alternatives you've considered

Maybe also something for the coinfig file

Additional context

Nice Driver. ;)
i have installed Version: v1.0.20230508beta

mr-manuel · 2023-05-22T08:25:29Z

Could you please post also your diagrams from the VRM portal where we can see this behaviour before and after?

Rikkert-RS · 2023-05-22T17:52:01Z

Yes, I can do that, but the VRM portal has currently performance problems.
As soon as this is running again I will send pictures.

Rikkert-RS · 2023-05-23T16:53:27Z

Here you can see that the current is not so large and also rises slowly. You can also no longer hear the inverters as they try to lower the voltage as quickly as possible.

Before:

After:

mr-manuel · 2023-05-23T17:02:43Z

Perfect, I will test it a few days and then add it.

Rikkert-RS · 2023-05-23T18:03:47Z

I also have an adaptation for aggregate batteries for this problem but that is probably better placed at @Dr-Gigavolt .
What do you mean? I used the new "Chargemodes" for that.
With Aggregate Batteries the problem is that as soon as the first battery goes into float, all other batteries that are not yet balanced go into float as well.

mr-manuel · 2023-06-11T19:10:24Z

@Rikkert-RS for the aggregate batteries you have to open an issue in the related repository as you said.

@ogurevich what do you think about this code change? Do you see the same in your charts?

ogurevich · 2023-06-11T20:11:49Z

can confirm, the inrush current at the moment the battery goes in float mode is significant (in ESS mode with DC-coupled PV - Feed in excess - ON)

it make sense to reduce control voltage gently wenn going in to float. We could in addition in this time period self.charge_mode = "Float (dynamic)"
the proposed code change is charming. the management function called every second, we achieve the desired effect.

it make sense imho

Dr-Gigavolt · 2023-06-11T20:22:17Z

Hello guys,
ESS does not support the lead-acid algorithm at all, this works only with stand-alone MPPTs or Multis/Quattros. Why do you try to maintain it? Just reduce the CVL and balancing-start voltage in BMS in order to to extend the battery life. What is the gain of charging the battery to 100% and than discharge it into the grid? The battery does not need to be at 100% to be balanced. I tried to reduce my LTOs (although there is the battery life not a limiting factor) from 2.5V to 2.35V and it works without any troubles.

mr-manuel · 2023-06-11T20:39:11Z

@ogurevich thanks

@Dr-Gigavolt I think we already talked about this a few times. It's the flat charging curve of LFP batteries where it's better to balance at voltage where the curve is steeper.

ogurevich · 2023-06-11T20:41:06Z

What is the gain of charging the battery to 100% and than discharge it into the grid? that is a very valid question.

nevertheless, it is not wrong to make the transition to float mode smooth. The user can use the MAX_CELL_VOLTAGE and
FLOAT_CELL_VOLTAGE parameters control how he wants to do that. If you set the parameters the same, you have eliminated the float mode. So everyone would be happy. (...this is a new topic for me, maybe I don't see some moments deeply enough)

Dr-Gigavolt · 2023-06-11T20:44:15Z

LTOs are even flatter. IMHO there is no difference at which voltage the balancing is performed. As there is almost no leakage current, it does not help to balance in the knee. The charge that must be transferred by balancer is always the same. When I built my batteries, I tried the initial balancing at Vmax = 2.7V, it did not help at all. Once above knee (2.5V for LTO) the balancer has no chance against peaking. I reduced to 2.5V and it was OK. And now with 2.35V is OK as well.

from Bulk/Absorbtion to Float fix Louisvdw/dbus-serialbattery#659

mr-manuel · 2023-06-12T12:28:31Z

I had huge problems, if I balanced the LFP batteries in the flat area. Two batteries were much less charged than all others. This happend multiple times with different cells. Right now I'm asking me what would be more efficient. Only balancing in the top voltage section or always? If you don't need it, just set float and max voltage to the same.

mr-manuel · 2023-06-12T14:52:48Z

This was implemented and is available tomorrow in the dev branch. It will be available also in the next version.

Rikkert-RS · 2023-06-12T17:10:22Z

Hello,

Just as feedback. Thanks for the implementation. I've been running this for a few weeks now and you can't hear anything, it runs very smoothly.

@Dr-Gigavolt , @ogurevich
The goal was also not to dictate how anyone charges their battery.
By this function it is only made smother. Everybody can decide for himself. Yes, feeding energy into the grid at all makes no sense at this point. In sum, not much energy is pushed into the grid but in such a short time that does not have to be. For me it is much better to balance at 55.2V (16S) than at less voltage (Lifepo4). And then to keep the battery permanently until the next discharge at 55.2V is also not good.

If someone is still interested in the changes from the "aggregate batteries" code. Then I can also share this and post it here.
@mr-manuel
Keeping everything together on this Issue (topic) makes sense if someone is looking for it?

What I noticed in particular and what does not work with "aggregate batteries" is that if you have for e.g. 2 battery packs installed and the first pack is ready woth balancing, the whole BattterieBank then goes into float mode even if the other pack is not yet finished with the balance process. My change waits until all battery packs are ready with balancing process.

@Dr-Gigavolt If there is also interest here I would rise an "enhancement" Issue in your repo and would share the code there.

best regards Rikkert-RS

mr-manuel · 2023-06-12T17:14:49Z

@Rikkert-RS for the aggregate batteries you have to open an issue in the related repository as you said.

You can then link the issue here by just pasting the URL of the issue.

ogurevich · 2023-06-12T18:16:26Z

What I noticed in particular and what does not work with "aggregate batteries" is that if you have for e.g. 2 battery packs installed and the first pack is ready woth balancing, the whole BattterieBank then goes into float mode even if the other pack is not yet finished with the balance process. My change waits until all battery packs are ready with balancing process.

In abstract terms, aggregator does its job correctly. As soon as one of the several battery packs (the driver) reports "I am full, please reduce the charge voltage", the aggregator forwards the signal to the DVCC logic. Control question: what is more damaging in this case, reducing the voltage, or grilling the fast pack a little longer because of "slow" batteries?

I could see this effect on myself too. For me, reducing the VOLTAGE_DROP parameter to the value 0.03 achieved the desired effect. Thanks to the aggregator (it takes the smaller value for the control), the slower battery lowers the charging voltage in system, that the faster battery does not start absorption mode yet either. The driver does exactly the job for which it is there.

Thanks guys for the driver

seidler2547 · 2023-06-12T20:07:47Z

Sorry for being late to the party. I tested this code as well, and after a few days I changed the slope from 0.005 to 0.001 and I'm more happy with that. Not sure if everybody wants it that slow. but if we go from 3.45 to 3.35, then it will be only 20 seconds (JKBMS Bluetooth only 10 seconds) but with 0.001 it will be 100 or 50 seconds.

mr-manuel · 2023-06-12T20:37:20Z

Maybe in this case it would be better not to use cycles but time. Like every minute 0.10 V.

ogurevich · 2023-06-12T20:44:27Z

or even duration of the transition phase as parameter ?

mr-manuel · 2023-06-12T20:45:41Z

Can you specify this better?

ogurevich · 2023-06-12T20:54:55Z

# Duration in seconds for smooth voltage drop from absorption to float 
TRANSITION_TIME_INTO_FLOAT_MODE_VOLTAGE_LEVEL = 180

mr-manuel · 2023-06-12T20:57:31Z

I would not let the user decide this. This makes the driver unnecessary complex. Better, if we discuss a reasonable V/time for this.

ogurevich · 2023-06-12T20:59:34Z

makes sense, a constant 👍

Dr-Gigavolt · 2023-06-12T23:27:57Z

What I noticed in particular and what does not work with "aggregate batteries" is that if you have for e.g. 2 battery packs installed and the first pack is ready woth balancing, the whole BattterieBank then goes into float mode even if the other pack is not yet finished with the balance process. My change waits until all battery packs are ready with balancing process.

In abstract terms, aggregator does its job correctly. As soon as one of the several battery packs (the driver) reports "I am full, please reduce the charge voltage", the aggregator forwards the signal to the DVCC logic. Control question: what is more damaging in this case, reducing the voltage, or grilling the fast pack a little longer because of "slow" batteries?

This is exactly what I wanted to do.

Another question: why do we need an exact balancing? The only reason I see is full charging, to avoid peaking. But if the goal is 80...90% to extend battery life, who cares about few % difference?

When I'll have some time to do it, I'll try to implement an array of CVLs for each month for Aggregate Batteries. In winter full, in summer less full and e.g. once or twice per month full charging for re-balancing and reset of the SoC counter. A good trade-off between usage and life.

For LTO I found this datasheet:
https://www.global.toshiba/content/dam/toshiba/ww/products-solutions/battery/scib/pdf/ToshibaRechargeableBattery-en.pdf

please look onto "long life", right chart. Do you know such a curve for LFP? Just to understand how harmful is to keep the cells fully charged over certain period of time.

Best regards,
Anton

mr-manuel · 2023-06-13T04:58:26Z

Do you know such a curve for LFP? Just to understand how harmful is to keep the cells fully charged over certain period of time.

See #458 (comment)

ogurevich · 2023-06-16T06:21:05Z

I would not specify the time for the whole transition but for the voltage change (e.g. 0.01 V/10 seconds). Else it's a huge difference if someone is using a 4S system versus a 18S system.

indeed, we have to take that into account. Or some thing like this ?
FLOAT_MODE_TRANSITION_DURATION = self.cell_count * 12

ogurevich · 2023-06-16T06:39:11Z

the variant (0.01 V/10 seconds) is also elegant and good

ogurevich · 2023-06-16T07:05:04Z

The different voltage drop per second is a little scary. If the user sets the float voltage via absorption, the algorithm will fail. It should probably be validated at init time

(pushed in to "voltagedroppersecond" branch)

                chargeMode = "Float"
                if self.control_voltage:
                    if not self.charge_mode.startswith("Float"):
                        self.transition_start_time = int(time())
                        self.initial_control_voltage = self.control_voltage
                        chargeMode = "Float Transition"
                    elif self.charge_mode.startswith("Float Transition"):
                        elapsed_time = int(time()) - self.transition_start_time
                        # Voltage drop per second
                        VOLTAGE_DROP_PER_SECOND = 0.01 / 10
                        voltage_drop = min(
                            VOLTAGE_DROP_PER_SECOND * elapsed_time,
                            self.initial_control_voltage - floatVoltage,
                        )
                        self.control_voltage = (
                            self.initial_control_voltage - voltage_drop
                        )
                        if self.control_voltage <= floatVoltage:
                            self.control_voltage = floatVoltage
                            chargeMode = "Float"
                        else:
                            chargeMode = "Float Transition"
                else:
                    self.control_voltage = floatVoltage
                self.charge_mode = chargeMode

mr-manuel · 2023-06-16T10:50:31Z

Somehow one step is taking 10 second, the next 20 seconds, then 10 seconds, 20 seconds and so on. Can you check that?

ogurevich · 2023-06-16T10:51:43Z

roger, wilco

ogurevich · 2023-06-16T10:58:47Z

how often is this function called?

mr-manuel · 2023-06-16T11:02:03Z

It should be every second

ogurevich · 2023-06-16T11:06:48Z

thank you, there is a bug, i check it and try to fix. (not good)

ogurevich · 2023-06-16T11:23:33Z

https://github.com/Louisvdw/dbus-serialbattery/assets/50322596/a92813cd-5e36-44d0-a4b2-6236a89c0519
hm, probably graph interpolation ?

mr-manuel · 2023-06-16T11:37:08Z

Theoretically it should get and display every change. The reduction seems a bit to steep for me comaring with the measured voltage. How does your graphics look like? Is the measured voltage following the voltage reduction?

ogurevich · 2023-06-16T11:42:53Z

it looks not bad in my setup. There is a table view possible, let's check the values please

ogurevich · 2023-06-16T11:50:34Z

the reduction of maxChargeVoltage seems to be correct. Agreed ?

ogurevich · 2023-06-16T12:16:04Z

sorry, now with a timeline

maybe the difference is due to the loads in our system. (ESS and DC feed in excess)

PS: The SmartShunt displays the voltage much more evenly than the BMS

mr-manuel · 2023-06-16T14:07:00Z

All good the timespan matches exactly the code.

I was only thinking about to increase it, but I looked again at the code on the top of this issue, so this is fine.

inspired by #659

ogurevich · 2023-06-16T15:12:38Z

… please set a bigger value there.

mr-manuel · 2023-06-16T15:44:15Z

Ok, I will set it, so that on a 16S battery it will take about 900 seconds.

ogurevich · 2023-06-16T15:52:46Z

oh, i apologize, the lowering per step was here: https://github.com/ogurevich/dbus-serialbattery/tree/voltagedroppersecond
i had to close this pull request and open a https://github.com/ogurevich/dbus-serialbattery/tree/voltagedroppersecond. Sorry !

ogurevich · 2023-06-16T15:56:20Z

my mistake, should I start a new pull request ?

ogurevich · 2023-06-16T16:02:28Z

... basically both variants are pretty much the same. please choose the variant you like best.

mr-manuel · 2023-06-16T18:45:51Z

Yes please.

Theoretically it should also not change the value more often than LINEAR_RECALCULATION_EVERY as for the other linear calculations. Could you also integrate this and open a new PR?

ogurevich · 2023-06-16T19:11:22Z

ok, implemented here: https://github.com/ogurevich/dbus-serialbattery/tree/voltagedroppersecond
I'll test the code tomorrow and if everything is ok, open a pull request

P.S. what is a reason for LINEAR_RECALCULATION_EVERY ?
I ask myself, is it the task of the battery driver to only pass on the calculated values to the operating system in doses? If you have many batteries in use, the values in the aggregate will change as often. The operating system decides for itself how often it reacts to these values. So the operating system has no chance to have correct current values

mr-manuel · 2023-06-16T19:31:40Z

In a perfect world this would be so, unfortunately in past we had troubles with fast changing CVL, CCL and DCL. The MultiPlus for example was not able to stay behind the changes that were made every second and very strange phenomena appeared. There is a discussion or issue somewhere in this repo.

To solve this, I introduced LINEAR_RECALCULATION_EVERY .

ogurevich · 2023-06-16T19:41:42Z

ok, see, we're trying to bang the error that occurs somewhere else. What happens when we have 10 battery packs? Everyone sets the value 1 time per 10 seconds and in the worst case we will change the value 1 time per second.
Anyway, we've taken that into account (LINEAR_RECALCULATION_EVERY). 👍

mr-manuel · 2023-06-16T20:17:53Z

Only one battery pack can be chosen in DVCC as BMS to control CVL, CCL and DCL. Additionally the limit that I'm aware of is 8 batteries: https://louisvdw.github.io/dbus-serialbattery/faq/#how-many-usb-to-serial-adapters-can-i-connect

ogurevich · 2023-06-16T20:20:49Z

Only one battery pack can be chosen in DVCC as BMS to control CVL, CCL and DCL.

correct. usually it is some battery aggregator, wich takes the values from all connected battery packs. Does it take a care how often it changes CVL, .... values ?

mr-manuel · 2023-06-16T21:19:13Z

I don't know that, since it depends which aggregator you are using. Best you open an issue in the repo of the aggregator to ask this.

ogurevich · 2023-06-16T21:26:13Z

During testing today I couldn't see any anomalies even though CVL was changing every second. It really can't be that that was the reason for strange phenomena. The clouds come and go, the MPPTs change the values very often, with the DC feed-in multipluses have to keep up. Unfortunately I'm not deep enough into this topic.

@peterohman

* Update reinstall-local.sh: Fixed charge current parameter Update reinstall-local.sh: Corrected charge current parameter for initial config.ini * Exclude devices from driver startup This prevents blocking the serial port * implement callback function for update * fix comments to reflect new logic * update changelog * set soc=100% when charge mode changes to float, apply exponential smoothing on current readout * remove scan for devices the scan for devices and check if the BMS to test is present doesn't add value if the device is not within range (or the MAC is wrong), then the subsequent start_scraping call will either fail or fail to produce usable data * JKBMS_BLE driver fixes * added Bluetooth signal strenght, increased debug * Optimized reinstallation procedure - Changed: Optimized restart sequence for the bluetooth installation - Changed: Run serial part first and then bluetooth part. This allows the serial driver to get operative faster - Removed: $DRIVERNAME variable for clearer paths - Removed: Bluetooth system driver restart, since the devices get disconnected by the service before starting the dbus-serialbatterydriver * Improved Jkbms_Ble error handling * optimized disable procedure * small fixes * save custom name and make it restart persistant #100 * changed unique identifier from string to function function can be overridden by BMS battery class * fix typo * fix Sinowealth not loading #702 * fix unique identifier function * enable BMS over config, if disabled by default Now you can also add more then one BMS for BMS_TYPE * show battery port in log * ANT BMS fixes Fixed that other devices are recognized as ANT BMS * Sinowealth BMS fixes Fixed that other devices are recognized as Sinowealth BMS * improved publish_battery error handling switched from error count to seconds * Improve Battery Voltage Handling in Linear Absorption Mode * Refactor change time() to int(time()) for consistency in max_voltage_start_time and tDiff calculation * Refactor battery voltage calculations for efficiency and clarity * Remove penalty_buffer * Reset max_voltage_start_time wenn we going to bulk(dynamic) mode * updated changelog * fix reply processing * Reduce the big inrush current, if the CVL jumps from Bulk/Absorbtion to Float fix #659 * Check returned data lenght for Seplos BMS Be stricter about the return data we accept, might fix the problem of grid meters accidently being recognized as a Seplos * Validate current, voltage, capacity and SoC for all BMS This prevents that a device, which is no BMS, is detected as BMS * removed double check * bump version * fix validation if None * updated changelog * proposal to #659 formatted :) * bugfix proposal to #659 * refactor setting float charge_mode * fix type error, removed bluetooth cronjob * updated changelog * fix rs485 write communication errors by inserting sleeps, add debug print for charge mode and fix crash on write soc failures * fix write problem on set_soc. also changed the switch charge/discharge function, just in case * debug msg * Bluetooth optimizations * Fixes by @peterohman #505 (comment) * fix #712 * fix meaningless time to go values * fix meaningless time to go values * Duration of transition to float depends on number of cells * Float transition - Voltage drop per second * Update hlpdatabms4s.py * Validate setting of FLOAT_CELL_VOLTAGE and avoid misconfiguration * consider utils.LINEAR_RECALCULATION_EVERY to refresh CVL * cleanup * consider utils.LINEAR_RECALCULATION_EVERY to refresh CVL * small refactor, introduced set_cvl_linear function to set CVL only once every LINEAR_RECALCULATION_EVERY seconds * fix typo * updated changelog * remove debug msg * remove debug msg * undo debug change * Daly BMS make auto reset soc configurable * added debug and error information for CVL * fix proposal for #733 (#735) * Added: Tollerance to enter float voltage once the timer is triggered * Add bulk voltage Load to bulk voltage every x days to reset the SoC to 100% for some BMS * JKBMS disable high voltage warning on bulk reenable after bulk was completed * fixed error * disable high voltage warning for all BMS when charging to bulk voltage * fix error and change default value measurementToleranceVariation from 0.025 to 0.5 else in OffGrid mode max voltage is always kept * Added temperature names to dbus/mqtt * Use current avg of last 300 cycles for TTG & TTS * Calculate only positive Time-to-SoC points * added current average of last 5 minutes * make CCL and DCL more clear * fix small error * bugfix: LLTJBD BMS SOC different in Xiaoxiang app and dbus-serialbattery * black formatting * JDB BMS - Control FETs for charge, discharge and disable / enable balancer (#761) * feature: Allow to control charge / discharge FET * feature: Allow to enable / disable balancer * bugfix: Cycle Capacity is in 10 mAh Fixes SoC with factor 100 * 100% percentage * JBD BMS show balancer state in GUI page IO (#763) * Bump version * Fix typos * Smaller fixes - fixes #792 (comment) * Removed comments from utils.py This should make more clear that there are no values to change * Updated changelog * possible fix for LLT/JBS connection problems #769 #777 * bugfix: LLT/JBD BMS general packet data size check * improved reinstall and disable script * LLT/JBD BMS - Improved error handling and automatical driver restart in case of error. Should fix: - #730 - #769 - #777 * Fixed Building wheel for dbus-fast won't finish on weak systems Fixes #785 * Support for Daly CAN Bus (#169) * support for Daly CAN Bus * fix constructor args * revert port, needs fix * add can filters * comment logger Some changes are still needed to work with the latest version. They will follow in a next PR. --------- Co-authored-by: Samuel Brucksch <[email protected]> Co-authored-by: Manuel <[email protected]> * JKBMS BLE - Introduction of automatic SOC reset (HW Version 11) (#736) * Introduction of automatic SOC reset for JK BMS (HW Version 11) * Fixed value mapping * Rework of the code to make it simpler to use without additional configuration. Moved execution of SOC reset. It's now executed while changing from "Float" to "Float Transition". * Implementation of suggested changes Persist initial BMS OVP and OVPR settings Make use of max_cell_voltage to calculate trigger value for OVP alert * Added: Daly CAN and JKBMS CAN * added CAN bms to installation script optimized CAN drivers * smaller fixes * Trigger JK BLE SOC reset when using Step Mode * Moved trigger_soc_reset() * fixes LLT/JBD SOC > 100% #769 * changed VOLTAGE_DROP behaviour * Fix JKBMS not starting if BMS manuf. date is empty * corrected bulk, absorption and soc reset terms * fix typo * add JKBMS_BLE debugging data * fix small error * added logging to config * add sleep before starting driver prevents lot of timeouts after reinstalling the driver, since the restart is now much faster than before * changed post install info * fix error * Daly BMS fixed embedded null byte #837 * added info for SoC reset to default config file * fix for #716 #716 * fix for #716 and JKBMS model recognition #716 * optimized logging * fix JKBMS recognition * added debugging * fixes #716 #716 --------- Co-authored-by: Holger Schultheiß <[email protected]> Co-authored-by: Stefan Seidel <[email protected]> Co-authored-by: Bernd Stahlbock <[email protected]> Co-authored-by: seidler2547 <[email protected]> Co-authored-by: ogurevich <[email protected]> Co-authored-by: wollew <[email protected]> Co-authored-by: Oleg Gurevich <[email protected]> Co-authored-by: peterohman <[email protected]> Co-authored-by: Strawder, Paul <[email protected]> Co-authored-by: Paul Strawder <[email protected]> Co-authored-by: Samuel Brucksch <[email protected]> Co-authored-by: Samuel Brucksch <[email protected]> Co-authored-by: ArendsM <[email protected]> Co-authored-by: Meik Arends <[email protected]>

@peterohman

* fix Sinowealth not loading #702 * fix unique identifier function * enable BMS over config, if disabled by default Now you can also add more then one BMS for BMS_TYPE * show battery port in log * ANT BMS fixes Fixed that other devices are recognized as ANT BMS * Sinowealth BMS fixes Fixed that other devices are recognized as Sinowealth BMS * improved publish_battery error handling switched from error count to seconds * Improve Battery Voltage Handling in Linear Absorption Mode * Refactor change time() to int(time()) for consistency in max_voltage_start_time and tDiff calculation * Refactor battery voltage calculations for efficiency and clarity * Remove penalty_buffer * Reset max_voltage_start_time wenn we going to bulk(dynamic) mode * updated changelog * fix reply processing * Reduce the big inrush current, if the CVL jumps from Bulk/Absorbtion to Float fix #659 * Check returned data lenght for Seplos BMS Be stricter about the return data we accept, might fix the problem of grid meters accidently being recognized as a Seplos * Validate current, voltage, capacity and SoC for all BMS This prevents that a device, which is no BMS, is detected as BMS * removed double check * bump version * fix validation if None * updated changelog * proposal to #659 formatted :) * bugfix proposal to #659 * refactor setting float charge_mode * fix type error, removed bluetooth cronjob * updated changelog * fix rs485 write communication errors by inserting sleeps, add debug print for charge mode and fix crash on write soc failures * fix write problem on set_soc. also changed the switch charge/discharge function, just in case * debug msg * Bluetooth optimizations * Fixes by @peterohman #505 (comment) * fix #712 * fix meaningless time to go values * fix meaningless time to go values * Duration of transition to float depends on number of cells * Float transition - Voltage drop per second * Update hlpdatabms4s.py * Validate setting of FLOAT_CELL_VOLTAGE and avoid misconfiguration * consider utils.LINEAR_RECALCULATION_EVERY to refresh CVL * cleanup * consider utils.LINEAR_RECALCULATION_EVERY to refresh CVL * small refactor, introduced set_cvl_linear function to set CVL only once every LINEAR_RECALCULATION_EVERY seconds * fix typo * updated changelog * remove debug msg * remove debug msg * undo debug change * Daly BMS make auto reset soc configurable * added debug and error information for CVL * fix proposal for #733 (#735) * Added: Tollerance to enter float voltage once the timer is triggered * Add bulk voltage Load to bulk voltage every x days to reset the SoC to 100% for some BMS * JKBMS disable high voltage warning on bulk reenable after bulk was completed * fixed error * disable high voltage warning for all BMS when charging to bulk voltage * fix error and change default value measurementToleranceVariation from 0.025 to 0.5 else in OffGrid mode max voltage is always kept * Added temperature names to dbus/mqtt * Use current avg of last 300 cycles for TTG & TTS * Calculate only positive Time-to-SoC points * added current average of last 5 minutes * make CCL and DCL more clear * fix small error * bugfix: LLTJBD BMS SOC different in Xiaoxiang app and dbus-serialbattery * black formatting * JDB BMS - Control FETs for charge, discharge and disable / enable balancer (#761) * feature: Allow to control charge / discharge FET * feature: Allow to enable / disable balancer * bugfix: Cycle Capacity is in 10 mAh Fixes SoC with factor 100 * 100% percentage * JBD BMS show balancer state in GUI page IO (#763) * Bump version * Fix typos * Smaller fixes - fixes #792 (comment) * Removed comments from utils.py This should make more clear that there are no values to change * Updated changelog * possible fix for LLT/JBS connection problems #769 #777 * bugfix: LLT/JBD BMS general packet data size check * improved reinstall and disable script * LLT/JBD BMS - Improved error handling and automatical driver restart in case of error. Should fix: - #730 - #769 - #777 * Fixed Building wheel for dbus-fast won't finish on weak systems Fixes #785 * Support for Daly CAN Bus (#169) * support for Daly CAN Bus * fix constructor args * revert port, needs fix * add can filters * comment logger Some changes are still needed to work with the latest version. They will follow in a next PR. --------- Co-authored-by: Samuel Brucksch <[email protected]> Co-authored-by: Manuel <[email protected]> * JKBMS BLE - Introduction of automatic SOC reset (HW Version 11) (#736) * Introduction of automatic SOC reset for JK BMS (HW Version 11) * Fixed value mapping * Rework of the code to make it simpler to use without additional configuration. Moved execution of SOC reset. It's now executed while changing from "Float" to "Float Transition". * Implementation of suggested changes Persist initial BMS OVP and OVPR settings Make use of max_cell_voltage to calculate trigger value for OVP alert * Added: Daly CAN and JKBMS CAN * added CAN bms to installation script optimized CAN drivers * smaller fixes * Trigger JK BLE SOC reset when using Step Mode * Moved trigger_soc_reset() * fixes LLT/JBD SOC > 100% #769 * changed VOLTAGE_DROP behaviour * Fix JKBMS not starting if BMS manuf. date is empty * corrected bulk, absorption and soc reset terms * fix typo * add JKBMS_BLE debugging data * fix small error * Some changes for lost bluetooth connection / hci_uart stack restart * added logging to config * add sleep before starting driver prevents lot of timeouts after reinstalling the driver, since the restart is now much faster than before * changed post install info * fix error * Daly BMS fixed embedded null byte #837 * added info for SoC reset to default config file * fix for #716 #716 * fix for #716 and JKBMS model recognition #716 * optimized logging * fix JKBMS recognition * added debugging * fixes #716 #716 * Bind device instance to unique_identifier #718 * added data types to battery class disabled unused variables * save current charge state #840 * correct file permissions * updated changelog * added periodic saveChargeDetails * fix some small errors * fix issue with ruuvi tags When there are hundreds of unused ruuvi tags in the settings list that where added because thei where nearby the driver does not start correctly. These stale entries are disabled on the driver startup. The issue was already filed to Victron developers * CVL with i-controller instead of penaltysum * cvl_controller: switch to choose PenaltySum or ICOntroller + documentation * docu enhancement * Add setting and install logic for usb bluetooth module * round temperatures * changed battery disconnect behaviour * Fixes #891 #891 * updated changelog * Add bluetooth device note to config.default.ini * Fix typo in bluetooth note in config.default.ini * fixed error in new cvl_controller * fixed float division by zero and code optimization * Restart MAX_VOLTAGE_TIME_SEC if cell diff > CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_TIME_RESTART * Calculation of the SOC based on coloumb-counting (#868) * Calculation of the SOC in the driver based on coloumb-counting * soc_calc: add current correction before integration * soc_calc: correction map for current * Soc_calc: CorrectionMap, switch to turn on/off correction, selectable initial value * soc_calc: Bugfix * soc_calc: Bugfix * store soc in dbus for restart * store soc in dbus for restart (formatted) * store soc in dbus for restart (bugfix) * save soc_calc only after change > 1.0 * store soc in dbus for restart (bugfix) * logger does not work this way. do not know why * writing and reading to dbus works * Removed options: SOC_CALC_CURRENT_CORRECTION, SOC_CALC_RESET_VALUE_ON_RESTART, SOC_CALC_INIT_VALUE sort soc_calc alphabetically * fixed comments * Updated changelog, small fixes * Changed: PUBLISH_CONFIG_VALUES from 0/1 to True/False * Changed: Code optimizations - Changed some variables to be more clear - Added comments for easier code understanding * Calculated SOC: Added two decimals, added BMS SOC for MQTT & Node-RED * Updated changelog, small fixes * Changed: PUBLISH_CONFIG_VALUES from 0/1 to True/False * Changed: Code optimizations - Changed some variables to be more clear - Added comments for easier code understanding * Calculated SOC: Added two decimals, added BMS SOC for MQTT & Node-RED * Fix #898 #898 * Changed: Fix issue loading settings from dbus * Added nightly install option makes it easier for users to pretest fixes * Changed: more detailed error output when an exception happens * Possible fix for #912 #912 * Fixes #919 #919 * Changed: Exit script with error, if port excluded else the serialstarter stops at the dbus-serialbattery * Fixed some smaller errors * Updated pre-release workflow * Fix JK BMS connection restart when bluetooth fails. This fix installs a new thread to monitor the state of the original scraping thread. If scraping thread dies, it verifies that it did not because the scraping was intentionally stopped by calling stop_scrapping. When restarting the scrapper, it first calls the bluetooth reset lambda function that was passed in the class contructor, such that bluetooth is ready to make a proper connection. * Fixes #916 #916 * Added Venus OS version to logfile * Fix #840 #840 * Small code formatting fixes * Optimized reinstall script. Restart GUI only on changes. * Display debugging data in GUI when DEBUG enabled * Install script now shows repositories and version numbers * Update daly_can.py Fixing #950 for DalyBMS * Update jkbms_can.py Fixing #950 for Jk BMS * Fix black lint check * Fixes #970 #970 * Fixed some errors in restoring values from dbus settings * Moved sleep on start for all BMS * Update config description * Reworked a part of the default config * fix typo in stopping services when reinstalling * Fix Time-to-SoC and Time-to-Go calculation * Add changelog info * Round sum and diff voltage * Temperature limitation variables where changed * SoC limitation variables where changed * Added error messages * Remove unneeded code * Reset SoC to 0% if empty * Add GUIv2 for dbus-serialbattery * Check free space before installing * Added new GUIv2 version * Removed Python 2 compatibility * Changelog update * Code cleanup - Removed: get_temperatures() - Removed: update_last_seen() * Bluetooth code optimizations * Fixed some JKBMS BLE not starting #819 * Check if packages are already installed before install * Fixed some SOC calculation errors * Fixed None SOC on driver start * Do not show and allow button change when callback is missing for: - ForceChargingOff - ForceDischargingOff - TurnBalancingOff * Check if a device instance is already used by creating a PID file * Log and execute SOC reset to 100% or 0% only once * Update GitHub workflow and issue templates * Fixed LLT/JBD BMS with only on temperature sensor #791 #971 * Fix warning on reinstall * Fix missing IO control for JBDBMS #992 #992 * Prepare for removing dev branch --------- Co-authored-by: ogurevich <[email protected]> Co-authored-by: Bernd Stahlbock <[email protected]> Co-authored-by: wollew <[email protected]> Co-authored-by: Oleg Gurevich <[email protected]> Co-authored-by: peterohman <[email protected]> Co-authored-by: Strawder, Paul <[email protected]> Co-authored-by: Paul Strawder <[email protected]> Co-authored-by: Samuel Brucksch <[email protected]> Co-authored-by: Samuel Brucksch <[email protected]> Co-authored-by: ArendsM <[email protected]> Co-authored-by: Meik Arends <[email protected]> Co-authored-by: Marvo2011 <[email protected]> Co-authored-by: cflenker <[email protected]> Co-authored-by: cflenker <[email protected]> Co-authored-by: Cupertino Miranda <[email protected]> Co-authored-by: Martin Polehla <[email protected]>

Rikkert-RS added the enhancement New feature or request label May 21, 2023

mr-manuel self-assigned this Jun 11, 2023

mr-manuel added a commit to mr-manuel/venus-os_dbus-serialbattery that referenced this issue Jun 11, 2023

Reduce the big inrush current, if the CVL jumps

80aa06c

from Bulk/Absorbtion to Float fix Louisvdw/dbus-serialbattery#659

mr-manuel closed this as completed Jun 12, 2023

mr-manuel mentioned this issue Jun 12, 2023

Changes 2023.06.12 #708

Merged

mr-manuel added a commit that referenced this issue Jun 16, 2023

Merge pull request #711 from ogurevich/dev

4af10dd

inspired by #659

Reduce the big inrush current if the CVL jumps from Bulk/Absorbtion to Float #659

Reduce the big inrush current if the CVL jumps from Bulk/Absorbtion to Float #659

Comments

Rikkert-RS commented May 21, 2023

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

mr-manuel commented May 22, 2023

Rikkert-RS commented May 22, 2023

Rikkert-RS commented May 23, 2023 • edited Loading

mr-manuel commented May 23, 2023

Rikkert-RS commented May 23, 2023 • edited Loading

mr-manuel commented Jun 11, 2023

ogurevich commented Jun 11, 2023

Dr-Gigavolt commented Jun 11, 2023 • edited Loading

mr-manuel commented Jun 11, 2023

ogurevich commented Jun 11, 2023

Dr-Gigavolt commented Jun 11, 2023 • edited Loading

mr-manuel commented Jun 12, 2023

mr-manuel commented Jun 12, 2023

Rikkert-RS commented Jun 12, 2023

mr-manuel commented Jun 12, 2023 • edited Loading

ogurevich commented Jun 12, 2023

seidler2547 commented Jun 12, 2023

mr-manuel commented Jun 12, 2023 • edited Loading

ogurevich commented Jun 12, 2023

mr-manuel commented Jun 12, 2023

ogurevich commented Jun 12, 2023 • edited Loading

mr-manuel commented Jun 12, 2023

ogurevich commented Jun 12, 2023

Dr-Gigavolt commented Jun 12, 2023

mr-manuel commented Jun 13, 2023

ogurevich commented Jun 16, 2023

ogurevich commented Jun 16, 2023

ogurevich commented Jun 16, 2023

mr-manuel commented Jun 16, 2023

ogurevich commented Jun 16, 2023

ogurevich commented Jun 16, 2023

mr-manuel commented Jun 16, 2023

ogurevich commented Jun 16, 2023

ogurevich commented Jun 16, 2023

mr-manuel commented Jun 16, 2023

ogurevich commented Jun 16, 2023 • edited Loading

ogurevich commented Jun 16, 2023

ogurevich commented Jun 16, 2023 • edited Loading

mr-manuel commented Jun 16, 2023

ogurevich commented Jun 16, 2023 via email • edited by mr-manuel Loading

mr-manuel commented Jun 16, 2023

ogurevich commented Jun 16, 2023

ogurevich commented Jun 16, 2023

ogurevich commented Jun 16, 2023

mr-manuel commented Jun 16, 2023

ogurevich commented Jun 16, 2023 • edited Loading

mr-manuel commented Jun 16, 2023

ogurevich commented Jun 16, 2023

mr-manuel commented Jun 16, 2023 • edited Loading

ogurevich commented Jun 16, 2023

mr-manuel commented Jun 16, 2023

ogurevich commented Jun 16, 2023

Rikkert-RS commented May 23, 2023 •

edited

Loading

Rikkert-RS commented May 23, 2023 •

edited

Loading

Dr-Gigavolt commented Jun 11, 2023 •

edited

Loading

Dr-Gigavolt commented Jun 11, 2023 •

edited

Loading

mr-manuel commented Jun 12, 2023 •

edited

Loading

mr-manuel commented Jun 12, 2023 •

edited

Loading

ogurevich commented Jun 12, 2023 •

edited

Loading

ogurevich commented Jun 16, 2023 •

edited

Loading

ogurevich commented Jun 16, 2023 •

edited

Loading

ogurevich commented Jun 16, 2023 via email •

edited by mr-manuel

Loading

ogurevich commented Jun 16, 2023 •

edited

Loading

mr-manuel commented Jun 16, 2023 •

edited

Loading