Hello all.

Well, it seems that my MUST 3KW 24V is also plagued with the premature float bug.

I have played with settings, but no luck. I also don't want to enable equalization as I'm using Lifepo4.

I want a more predictable solution.

But before we get into solutions, I would like to understand why the bug happens, and what's the logic behind the bug.

From reading on this forum and on AEVA forum, I understand that if PV charging current is less than 1/5 of max charging current, during the first 50 seconds of the PV production for that day, then the PV charger will not go into absorb, just stay at float.

But what is/was the logic behind this? I mean in early morning sun you might get only a few watts. 

What were the developers thinking of that made them include this (dumb) rule? Maybe we are missing out on something? 

Anyways, would it be beneficial to postpone PV production (by means of a timed relay/contactor), so that when PV is recognized by the inverter, it has enough current to overcome the 1/5 rule?

Will communication between BMS and inverter solve this?

BTW, I am using SolarAssistant, and have asked them to include the SCC charging state (float/bulk/absorb) in the dashboard, so that we can easily monitor what charging state we are in. I hope they include it in future versions.

 

Thanks for your thoughts.

Edited April 18, 20242 yr by meetyg

22 hours ago, meetyg said:

I also don't want to enable equalization as I'm using Lifepo4.

You don't have to set the equalisation voltage higher than the bulk voltage, so there is no contra-indication for equalisation just because you have an LFP battery that equalisation wasn't designed for. For working around the premature float bug, you use equalisation as essentially a way to prolong the bulk charge stage. But of course, a fixed time extension doesn't really solve the problem. It's just that for most people, that's all that there is.

22 hours ago, meetyg said:

From reading on this forum and on AEVA forum, I understand that if PV charging current is less than 1/5 of max charging current, during the first 50 seconds of the PV production for that day, then the PV charger will not go into absorb, just stay at float.

It's not just in the first 50 seconds that the problem exists; it's any time that the charge power is reduced. In particular, when there is cloud or a large load robs the PV of spare charge current.

Think about the ideal charging situation. First, you charge the battery with as much current as you have available, up to the charge current limit. This is the bulk or Constant Current stage. Then there is an absorb stage: you limit the battery voltage so that you don't boil off the electrolyte, or cause bad reactions in a lithium battery. That's the Constant Voltage or absorb stage. Finally, the battery isn't taking much current, we declare it's full, and go to a different constant voltage stage, called the float stage. This is needed to keep a lead acid battery at 100% SoC, but it's also useful with lithium based batteries as an indication of the need for extra charge current. This extra charge current might be because the battery was called on to support the load, or because of losses. When the battery voltage falls below the float voltage, that's the signal to push current back into the battery, until the battery voltage reaches the float voltage setting again. If the battery voltage falls too low, we give up on the float stage and start a new bulk charge.

The transition from bulk to absorb is simple: has the battery voltage reached the bulk/absorb voltage setting. If so, we transition to the absorb stage. It's possible that the battery is called on to support the load and we fall below that voltage, in which case we're really back in bulk stage for a while. For that reason, Voltronic seem to call the absorb stage the bulk/absorb state. This transition is easy, and they don't screw that one up.

The problem is the transition from absorb to float stage. It's when the battery current falls below a threshold (for unpatched firmware, that's the maximum charge current divided by 5), BUT ONLY IF the battery voltage is near the bulk/absorb voltage setting. Otherwise, at the very first cloud, the battery would be declared full and solar charging would be completely useless. Here is the problem: they do check the battery voltage against the setting, but for reasons best known to the developers, they use the wrong setting! They use the float voltage setting, instead of the bulk/absorb voltage setting. In some firmwares, they compare the float and bulk/absorb settings, and choose the lowest of these, instead of the highest of these. It's that simple, and that's why the patch to fix it is so simple: we just change a branch if greater or equal to a branch if less. One byte. The problem is knowing which of the up to 256,000 bytes to change, and what to change it to.

22 hours ago, meetyg said:

Anyways, would it be beneficial to postpone PV production (by means of a timed relay/contactor), so that when PV is recognized by the inverter, it has enough current to overcome the 1/5 rule?

No. As mentioned earlier, the problem can occur at any time, not just at the start of the charge, or at early times of the day. I suppose if you somehow paused charging when available PV power is low, that would work around the problem, while also wasting a fair bit of usable PV energy. It's also tricky knowing when available PV power is low. Is it low right now because there isn't any more to be had, or it it just that we don't have enough charging and/or AC-output load at present? You only know for sure when you need more than you can get.

22 hours ago, meetyg said:

Will communication between BMS and inverter solve this?

I've wondered about this, not having a battery with a commercial BMS myself. But I don't think it helps; essentially, the BMS is adjusting the maximum charge current setting based on its knowledge of the instantaneous needs of the battery cells, rather than using a fixed value. The inverter's firmware still manages the stages, and hence the voltage threshold that it is aiming for.

Thanks for the informative reply !

I guess I'll have to play with equalization then.

But the odd thing is that most days (even sunny), it seems like the inverter isn't even trying to get to bulk/absorb. 

As I have SA connected to the inverter, I cannot monitor the state of the charger, unfortunately. It seems like the inverter is targeting the float voltage (27.2v), and just stays there.

My bulk is 28.2v, max charging set is 40a, although my PV will generally produce 20-25a at peak (to the battery), sometimes close to 30a. I have two 24v 105Ah Lifepo4's in parallel. Does the inverter have to limit the current in order to go into bulk ? I mean will reducing the max charging current help me somehow? 

My batteries go down to around 26.4v during the night. This is roughly 60-70% SOC. Maybe this is too close to float voltage, in order to re-trigger bulk? I would rather not go lower than that, so that I will have enough battery power if a power outage should occur.

It's a mess trying to figure out all these hidden thresholds in the firmware (unless you are @Coulomb of course 😉)

To summarize: I'm not even sure I am actually seeing the premature float bug, as I'm rarely reaching bulk voltage.

I actually don't mind zero (or close to that) absorb time, as long as my bulk voltage is reached once a day. My Lifepo4's each have a 2a active balancer, so getting to 3.5v per cell is enough for me daily. I don't need extra time to balance, as the packs are fairly balanced anyways.

But what usually happens is that inverter reaches float voltage, and then charging power is decreasing, even though there is more PV available.

 

Edited April 19, 20242 yr by meetyg

 

47 minutes ago, meetyg said:

I have two 24v 105Ah Lifepo4's in parallel. Does the inverter have to limit the current in order to go into bulk ? I mean will reducing the max charging current help me somehow? 

To go back to bulk stage, the battery voltage has to drop below a certain value for a certain time. This threshold is the back to utility voltage (setting 12), or the low cut-off voltage, whichever is higher.

Reducing the max charging current will make the threshold current lower, meaning you have to find a darker cloud before the premature float bug triggers. So that might help some, with some obvious side effects like slower charging of the battery under good conditions.

47 minutes ago, meetyg said:

Maybe this is too close to float voltage, in order to re-trigger bulk? I would rather not go lower than that, so that I will have enough battery power if a power outage should occur.

I find that load surges trigger going to bulk stage, even in factory firmware (without KttleKomp™). If you can see the CHG (charge) LED, it will tell you the charge stage (flashing = bulk or absorb,  solid = float, LED off = not charging).

47 minutes ago, meetyg said:

I actually don't mind zero (or close to that) absorb time, as long as my bulk voltage is reached once a day. My Lifepo4's each have a 2a active balancer, so getting to 3.5v per cell is enough for me daily. I don't need extra time to balance, as the packs are fairly balanced anyways.

Just reaching bulk voltage is not enough to charge a battery (LFP or lead acid) to full. It needs to stay there until the charge current drops.

47 minutes ago, meetyg said:

But what usually happens is that inverter reaches float voltage, and then charging power is decreasing, even though there is more PV available.

Yes, once you reach float stage, the battery will actually discharge about 0.5%, in my experience, and with the voltage settings that I use (55.2 V bulk/absorb, and  53.7, recently 54.0, for float). Obviously halve those voltages for your 24 V battery.

@Coulomb Thank you for your time to explain how the premature float bug affects charging of batteries. There is still something I wonder about. Pylontech batteries do not use a float setting in their Standard operating practice for Axpert inverters. Only bulk/absorb is selected. Will it affect the battery life if 26 and 27 is set the same voltage.

On 2024/04/20 at 5:56 PM, Chris Louw said:

Will it affect the battery life if 26 and 27 is set the same voltage.

The short answer is yes; this will adversely affect battery life. It seems to me that Pylontech are not particularly concerned about the longevity of their products.

I'm digging out this topic because I'm also experiencing premature float bug with my must pv1800.

I tried to work around by raising the float voltage setting to 29V. It works. However, if the battery is fully charged and there is still PV power coming in, the inverter will go into fault for overcharging and turn off AC-out. 

But I had an idea. Since I'm anyway running an esp32 through modbus controller in order to get the data on my home assistant, this morning I set up an automation that automatically sets float voltage to 29V when battery voltage is <28.5V and sets it back to 27.2 when battery voltage is >28.5V. 

 

I think it's the perfect counter for this bug. However, I will let it run for a few days and give you a final report on this work around.

 

 

On 2024/04/21 at 5:02 PM, Coulomb said:

The short answer is yes; this will adversely affect battery life. It seems to me that Pylontech are not particularly concerned about the longevity of their products.

lately I am conceded about if my inverter is charging in the most optimized way or not . I am watching my battery voltage , it seems it bulk charge till 55.6 (sometimes a bit higher) then the voltage slowly goes down till 54.X then it bulk charge again till 55.X . I am conceded about floating and cell balancing . are they been done ? should the voltage fluctuate ? should I find a way to stop the charger to keep my cells away from high voltage  

my inverter is : Triple A axpert VM III twin 6000

my battery is : Felicity LPBA 48200  

Edited October 14, 20241 yr by esmail-kassir
adding my battery and inverter

Are you running patched main firmware? I recently found to my horror that I was patching the VM firmwares incorrectly for the premature float bug. I fixed one of the VM firmware series, but I haven't had time to repatch them all. But the result is to basically never reach float, rather than go to float too early. That doesn't seem to be your problem. 

I don't understand how your battery is staying around 56V for a long time with only a few spikes of charge current. Have you verified that the reported battery voltage agrees reasonably well with a multimeter? 

54 minutes ago, Coulomb said:

Are you running patched main firmware? I recently found to my horror that I was patching the VM firmwares incorrectly for the premature float bug. I fixed one of the VM firmware series, but I haven't had time to repatch them all. But the result is to basically never reach float, rather than go to float too early. That doesn't seem to be your problem. 

No , I am using 60.76 ( and it was the same behavior when I had the older firmware ) 

54 minutes ago, Coulomb said:

voltage agrees reasonably well with a multimeter? 

I don't have one currently but I tried a test where I switch to user mode and  the battery BMS LCD report the same voltage the inverter LCD does (with 0.5 V delta )

  

54 minutes ago, Coulomb said:

a few spikes of charge current.

could it be that it still charging but with very little current that doesn't reported by the inverter 

 

 

Edited October 15, 20241 yr by esmail-kassir

On 2024/10/15 at 6:31 PM, esmail-kassir said:

could it be that it still charging but with very little current that doesn't reported by the inverter 

Yes, that could be the case, but it doesn't feel right to me.

3 hours ago, Coulomb said:

Yes, that could be the case, but it doesn't feel right to me.

for example :

yesterday my battery was fully charged by solar 

1-at 11:18 AM and the voltage was 55.3 when it become full

2-to drop slowly till became 51.1 at 12:50

3- the inverter recharged up again for one couple minutes at 12:50 and become 55.3 at 12:54

4- the same happened at 14:40 then on 16:20 

 

so is that normal and the inverter is compensating for lost current during balancing or it is charging wrong way ?

Well, well, well.
Reminder of the idea: I realized that even in "float voltage" mode, the inverter could charge at full power if the target voltage is higher than the battery voltage. In other words, even in float mode, it will not limit the current if the float voltage target is not reached. The idea, then, was to set up an automation to change the float voltage parameter "dynamically" in order to trick the inverter.

After quite a few tweaks to the parameters, it seems to be working now. The settings are as follows:

• When the battery voltage is >28V, set the float voltage at 27.2V.
• When the battery voltage is <26.5V, set the float voltage at 29V.

Notes: Threshold voltages over 28V trigger the overcharge circuit protection on my setup. I prefer to let the voltage drop to 26.5V (around 70%) before going into bulk charge again, to avoid constant back and forth.

So far, so good.

Edited October 20, 20241 yr by Cagire

My inverter doesn't have the float bug issue (That I'm aware), but I have been using some docker images from Github to make an MQTT and Node Red server where I can automatically read parameters from the inverter from a raspberry pi and push commands to the inverter automatically using Node Red and Mosquitto. Using a fork of the following software: https://github.com/ned-kelly/docker-voltronic-homeassistant. I haven't used the equalisation voltage parameter, but it must be in there if Watchpower can see it. I'm guessing you could use Node Red to switch on the inverter equalisation for a time in the morning and evening or even integrate over time how long the battery has been at equalisation voltage and switch based on that. Just make sure to synchronise docker with system time on the pi to make sure you get daylight savings time for your region.

 

Edit: Found the fork https://github.com/catalinbordan/docker-voltronic-homeassistant. Seems like no adaption I can find has found the equalisation parameter, but you could raise the float to the boost voltage for a time instead.

Edited October 21, 20241 yr by Phalanxer

My only concern with these programmatic solutions is wearing out the EEPROM on the inverters.

I have discussed this before with @Coulomb on this forum. 

If I recall correctly, he confirmed that this is a real concern, but just how fast the EEPROM will wear out, is still unknown. It depends on the quality of the components used in these inverters.

 

 

Would it not be possible to de-solder some EEPROM chips from a dead inverter (If there are available units out there) and write to one in hundreds of writes per day using something like an Arduino with I2C? Averaging a few would probably give some confidence as to the lifetime, although components across all models aren't guaranteed to be the same!

14 hours ago, meetyg said:

My only concern with these programmatic solutions is wearing out the EEPROM on the inverters.

I have discussed this before with @Coulomb on this forum. 

If I recall correctly, he confirmed that this is a real concern, but just how fast the EEPROM will wear out, is still unknown. It depends on the quality of the components used in these inverters.

 

 

It seems like EEPROM is given for 100 000 writing cycles. On average, it will be 1 writing per day (2 when it is sunny and 0 on cloudy days), so we can imagine a life of ... 100000/365 = 273 years. I don't think I will be there to see the EEPROM fail.

@Phalanxer I'm not sur what you are trying to explain but I already have my own setup working perfectly. I'm using an ESP32 connected to the inverter via RS485, together with esphome and home assistant.
 

Edited October 23, 20241 yr by Cagire

32 minutes ago, Cagire said:

It seems like EEPROM is given for 100 000 writing cycles. On average, it will be 1 writing per day (2 when it is sunny and 0 on cloudy days), so we can imagine a life of ... 100000/365 = 273 years. I don't think I will be there to see the EEPROM fail.

@Phalanxer I'm not sur what you are trying to explain but I already have my own setup working perfectly. I'm using an ESP32 connected to the inverter via RS485, together with esphome and home assistant.
 

In what moments EPROM is been writing?

6 hours ago, Cagire said:

It seems like EEPROM is given for 100 000 writing cycles. On average, it will be 1 writing per day (2 when it is sunny and 0 on cloudy days), so we can imagine a life of ... 100000/365 = 273 years. I don't think I will be there to see the EEPROM fail.

@Phalanxer I'm not sur what you are trying to explain but I already have my own setup working perfectly. I'm using an ESP32 connected to the inverter via RS485, together with esphome and home assistant.
 

If you have a setup already running with ESP32 then that's all good. I was just laying out some options with a Raspberry pi if you didn't. I think Meetyg's point is that good quality EEPROM is generally, as you say, in the range of 100,000 writes in a lifetime, but we don't know the quality of the EEPROM used in the machine. Some EEPROM can have as few as 10,000 or less writes in a lifecycle.

5 hours ago, bratpit said:

In what moments EPROM is been writing?

EEPROM is writing when sending the commands for change of float voltage in Cagire's case with the automation using the ESP32.

Edited October 23, 20241 yr by Phalanxer

1 hour ago, Phalanxer said:

If you have a setup already running with ESP32 then that's all good. I was just laying out some options with a Raspberry pi if you didn't. I think Meetyg's point is that good quality EEPROM is generally, as you say, in the range of 100,000 writes in a lifetime, but we don't know the quality of the EEPROM used in the machine. Some EEPROM can have as few as 10,000 or less writes in a lifecycle.

EEPROM is writing when sending the commands for change of float voltage in Cagire's case with the automation using the ESP32.

Even with a mediocre one, it would still be 27 years of service. I can't imagine such a cheap inverter lasting that long anyway.

Reached out to the Voltronic Engineering department through Voltacon about this, they have come back and confirmed the EEPROM chips their licenced inverters use are guaranteed to one million erase/write cycles from the manufacturer. Obviously this wouldn't cover clone units.

10 hours ago, Phalanxer said:

Reached out to the Voltronic Engineering department through Voltacon about this, they have come back and confirmed the EEPROM chips their licenced inverters use are guaranteed to one million erase/write cycles from the manufacturer. Obviously this wouldn't cover clone units.

That's good to know.

As you mentioned, we still don't know about the clones.

But I would assume that not only settings are saved to EEPROM. I think that also usage statistics/totals are also saved in these inverters. So we need to take this into consideration too.

@Coulomb can you confirm this please?

8 hours ago, meetyg said:

I think that also usage statistics/totals are also saved in these inverters. So we need to take this into consideration too.

@Coulomb can you confirm this please?

Yes, good point, EEPROMs store all sorts of data, organised into about half a dozen separate blocks. Only one of these contains the "user" settings. There are calibrations, serial numbers, and lots more, including regular data on statistics for most models. I don't know how often these statistics are written.