Automatic Charge Voltage v2 (recently introduced) - Too slow and too aggressive ?

[luckylinux]

The default value of charge_v_factor = 2.0 didn't work at all for me (it actually went "full" power and caused cell 11 to hit OVP as usual).

When charge_v_factor = 3.0 instead it seems to work WONDERS.

However, near the top of the charge and possibly at the end of the day when not enough solar power is available (thus battery charges/discharges/charges/discharges/... constantly), there is a huge ringing with many cells getting dangerously close to OVP.

This is somewhat of a physical issue (it doesn't take much charge / Ah at that high SOC/voltage to increase the voltage a lot, and normally the charge should stop far sooner)

[MrPabloUK]

Yes, the behaviour is quite extreme on your system as cell 11 is just so far ahead of the others. With just one cell triggering CVL changes, it becomes much more likely that full CVL is requested as soon as cell voltage drops.

My personal experience has been with multiple cells starting to become runners, so the CVL changes tend to be more steady.

I have a few ideas that I'll mock up, then update on the associated branch. Thanks for testing and proving the graphs above

[luckylinux]

You're welcome, thanks for providing support. Somebody got to play guinea pig I guess (me) :D.

Yeah, I don't know why cell 11 on battery 02 is so weird.

Battery 01 all cells go up together nice an steady right now (knock on wood ...).

Either a slew rate limiter or PI controller, possibly with a more non-linear method.

Basically:

• If cells are shooting up (dangerous), reduce IMMEDIATELY THE VOLTAGE (but not if only 0.001 VDC above bulk yet 0.200 VDC BELOW OVP !)
• If cells went below bulk, LIMIT RATE to something that can be handled in practice. Maybe 0.1 V / hour (for the whole pack) or so.

[MrPabloUK]

@luckylinux, can you provide a graph showing requested charge voltage and total battery voltage for the time period above please?

[luckylinux]

@MrPabloUK Requested Charge voltage is in the plot, isn't it ? Or you mean you want them on the same plot ?

EDIT 1: On a single chart:

[luckylinux]

@MrPabloUK Keep in mind that the charger can have up to 1 minute (or maybe even 1.5 minutes) delay to react to the limits sets by MQTT - if those limits are LOWER than the set point in my EXCEL sheet.

EDIT 1: I might be able to reduce it somewhat (reduce by up to 1 minute) by getting rid of CRON to execute that "Strategy" part and just do a Python "Infinite Loop" that I will start as a Systemd Service (just like I do to set the parameters to the charger)

[luckylinux]

Some testing with Inverter alone and no charger (only possible today since there was a lot of sun for once ...).

I tuned a bit up the bulk voltage (to see if I could increase the battery current and compensate for the voltage drop across cables etc - see Related Issue https://github.com/Sleeper85/esphome-jk-bms-can/issues/44 for that) and down the bulk voltage (since I had to absent myself from home for a while and did not want stuff to go out of control when I could not intervene.

Zoom 14h30-17h00:

Total Battery Voltage and Requested Charge Voltage

So this seems MUCH less amplification of oscillation, although it's still quite "violent" in my opinion. It's NOT the Charge Voltage Aggressivity Factor that is at play here. It's just the "discontinuity" caused by the min() function when one cell is above bulk voltage: it's either 55.2 VDC (bulk) or 54.2 VDC - kaggressivity * (U_cell_max - 3.45 VDC). Essentially 55.2 VDC - 54.2 VDC - 55.2 VDC - 54.2 VDC etc.

This seems to indicate that it's an issue with my charger due to the huge delay, NOT with the inverter.

There is a "ramp" function in the charger in order to slowly change the voltage, but the problem is that it needs to REDUCE IMMEDIATELY, and INCREASE GRADUALLY (asymmetric).

So I might need to implement a "slew rate limiter" in my Python script I guess :(.

[MrPabloUK]

@luckylinux, I have updated the branch associated with this issue.

The code is now utilising a PI controller which will target a cell voltage of 3.45v (assuming that's your cell bulk voltage). PI output cannot be greater than total bulk voltage, or lower than total float voltage. Rather than considering all cells over target, it will consider the max cell voltage only. It also will not instantly reduce to current battery voltage, but apply correction to the current CVL value.

An integral deadband is in place, lower bound is cell bulk voltage, upper bound is cell bulk voltage + balancer delta voltage.

I have not tuned the kp and ki values at all, they are currently substitutions, feel free to set up as you need. If needed, I would try out the Ziegler-Nichols method for tuning, but I would be very interested to see how long it performs at 'stock' settings.

[luckylinux]

Thanks for the update ! I'll have a look during the weekend when I hopefully can upgrade the software.

About the "target" of the PI controller being only the MAX cell voltage I'm a bit skeptical.

That only leaves the band between 3.43VDC (balance) to 3.45VDC (target of PI controller) in order to "bring up" all the cells.

And as you say, I could raise bulk voltage to 56 VDC instead of 55.2 VDC, then coding this 3.45 VDC as a separate parameter like Target_Cell_Charge_Voltage or something. This can also solve the "Boost" problem like you mentioned in the other issue.

Did I understand this correctly ?

[MrPabloUK]

I'd prefer you test the default code and parameters before making any changes please, it's less variables for me to review. Stick with 3.45v bulk, for the first full test at least.

The main point of this logic is to maintain a steady cell voltage around bulk, resulting in constant balancing from max to lower cells, whilst ensuring charge current doesn't overwhelm the balancer. That's why I'm wanting default parameters, to see how successful it is at maintaining that voltage.

Once that testing is done (and possibly PI tuning for your setup), then it might be appropriate to try out sending a CVL above bulk.

I have no doubt that getting your battery balanced will take a sustained period of time with software control only. Ultimately, this imbalance is either caused by electrical connection (balance lead or busbar) or cell quality issues.

[luckylinux]

Well, you previously told me NOT to balance it, to leave it unbalance, so we could try these edge case strategies ;).

I'll make all these things a "state" that can be changed on the go from Home Assistant (target voltage, Kp, Ki, etc), but I will stick with the default values for the first run.

[MrPabloUK]

@luckylinux, I see you were testing out the boost approach with the PI voltage control. How has testing gone so far?

[luckylinux]

@MrPabloUK Not yet started. Lost 2 days trying to get OTA fixex for ESPHome ...

[luckylinux]

@MrPabloUK With the older code I am getting all Cells EXCEPT Cell 11 Converging towards bulk (unless some other colors are not visible in the Chart)

[luckylinux]

@MrPabloUK Still with the old-ish code but after 2 days of relatively good sun, the battery seems to be quite well top balanced with bulk of 56.4 VDC

[luckylinux]

Just in time before the clouds arrived right now :+1:

[MrPabloUK]

@luckylinux, have you been able to test the new logic yet? I have it in use here, but I don't have a cell that spikes anywhere near as much as yours.

[luckylinux]

@MrPabloUK Not yet. Unfortunately a lot of other stuff is happening right now.

I fixed the OTA upgrade issue (due to improper/wrong/nonsense networking configuration).

Now I have another (unrelated) issue where all of my containers (Docker/Podman) are stuck in a loop because I exceeded DockerHub limit ... So need to setup a Local Registry Proxy Cache / Mirror that isn't so straightforward to do (currently trying Harbor but not making a lot of progress).

The spike seems to occur every day, so it's not a "one off".

Yesterday we had quite a lot of sun (not sure I can replicate today with all these clouds) and the battery got fully charged again:

It even looks like the battery managed to enter float state in a reasonable amount of time. This was the setting for the EOC Delay Cycles (IIRC you had 60 as default, I set 300 "to make sure" which should be approx. 5 minutes after balancing is complete):

[luckylinux]

But the behaviour is always weird. First overshoot, then undershoot, then takes a long time to rise again to reach all the others.

[MrPabloUK]

@luckylinux, branch https://github.com/Sleeper85/esphome-jk-bms-can/tree/automatic-charge-voltage-v2.1 has been updated with revised windup protection logic. My Solis inverter is pretty poor at adhering to requested CVL changes, but this is how CVL adjusted during some testing today, specifically 16:45 to 16:50. I run a 17s setup, hence the higher CVL. Let me know if you get a chance to test it out.

[luckylinux]

@MrPabloUK

Seems like today's ESP32 Restart (and required Reflashing - still same Version) broke everything.

With BMS_Err-Stop ENABLED, it seems that things went COMPLETELY out of control.

It hit 3.69 V :sob:.

I hope the Battery is not damaged now ...

On the Deye Side I am getting error F41 (Parallel Communication) out of nowhere ...

[virus100b]

I know that is over 2 month since nobody post here.

Regarding your cell nr 11. Did you try cu re-make the connection between the cell and busbar? May be some oxidation occurred between aluminum terminal of cell and copper busbar. I have a similar problem with my new setup. I have 3 cells going on top of others when charging and go below other when discharging. I do not hit OVP, but i have a 0.160V Delta at peak. I am planning to remove the busbar, clean and apply some ALU-PLUS Wago protection paste on the terminals trying to keep the as low as possible the contact resistance.

[luckylinux]

@MrPabloUK: Apologies, I wasn't able to test your new Code yet. I had some talks with @Sleeper85 on the Forum where I informed him that I have some complicated Situation at the Moment.

I got the PVBrain2 Board a few Weeks ago and most Components from Aliexpress for it. IIRC I miss the UART-CANBus Converter (to allow for longer Cables, @Sleeper85 was in doubt whether it's really required, but I was like ... Let's just get those, I don't want to be stuck in case wire length of 5-10 meters causes Problems with UART Communication).

I still need to build these new 2 Batteries though. I recently was injured which made me lose a few Weeks :disappointed:.

@virus100b: Thank you for the Suggestion.

I did NOT remake the connection between the Cell and the Busbar. Somehow I doubt that is the reason why it's behaving so weirdly. I say that because I properly cleaned the Alu Terminals (Red Scotchbrite + Isopropyl Alcohol), the Busbars (Isopropyl Alcohol) and immediately applied a decent amount of MG 847 Carbon Paste to ensure a good Contact and Prevent Oxidation. Then Torqued to the same Value everywhere (cannot remember by heart now the exact value though).

Through the use of the MG 847 Carbon Paste I somehow doubt that the Connection is getting oxidized.

A possible other explanation might be that when I modified these Busbars (drilled extra Holes and inserted a self-clinching Nut for the Voltage Sensing wires), they might have become not-so-flat / bent (when you press the self-clinching Nut in the Hole with 1 Ton Pressure, it tends to bend the Copper Busbar). I nevertheless checked that they were flat enough before installing. And it is weird that only that single one is giving Problems.

I would NOT use the WAGO Protection Paste to be Honest. While you could use Dielectric Greases or Silicone Grease or the likes I guess since the Torque is enough to "squeeze" the excess out, the MG 847 has the advantage that it also improves the Electrical Conductivity, to compensate e.g. for rough / non-flat Surface, while at the same time Preventing Oxidation.

IIRC the MG 847 is based on "Mineral Oil" plus Carbon Particles.

@virus100b: At the same time, with my current Setup, maintenance is difficult. I have 2 Batteries in the same Box, and if I want to do what you suggest (disconnect and remake the connection to cell 11), I'll probably need to take both Batteries out of Operation. Maybe not strictly required, I have to see. That setup has several other maintenance-related issues though.

I'd prefer to do that when I have the new 2 Batteries installed and I can afford to take these 2 out for a while ...

And of course I'd need to remake both connections between Cell 11-10 and Cell 11-12, since one or both could be affected.

However, I think that it's weird that the 2 neighboring cells don't have issues, don't you think ?

[virus100b]

@luckylinux Yeh, after i read your comment i agree that the possibility to have an oxide issue is farr less than in my case. I did not think that i may have a bad contact because I have double holes terminal which have a bigger surface are but i guess i was wrong or i hope that there is a bad connection and not a case for week cells. I am not at home for another 2 weeks so i can't do nothing on the battery except look at the voltages.

[Sleeper85]

@MrPabloUK planned improvements following the addition of the new Auto CVL Boost V. function.

Will be tested again next.

[MrPabloUK]

@Sleeper85, ok if this issue is closed? I'll be tackling the autoCVL and possibly autoCCL enhancements in the next couple of weeks.

[MrPabloUK]

Actually, ignore me. I got mixed up with the repository I was in!