hominidae avatar image
hominidae asked

(solved) ESS and Pylontech - use Node-Red to avoid high voltage alarms when charging

TLDR - I solved my problem via the Node-Red flow below, where standard ESS would haunt me with triggering many, many high-voltage-alarms while charging my Pylontech Batteries. Hope this helps someone else.

I've been haunted with high-voltage-alarms from my pack of 6xUS3000C, deployed in late october.

The victron recommended solution did not work for me, as even with voltages below 51.4V and charging slowly, sometimes the alarm was triggered, but the pack would never fill up to 100% SoC or start balancing.

Hence, I decided to try an alternative approach and created a NR flow that

  • introduces a "kill-switch", setting the allowed max. charge current in DVCC to 0A, if a cell reaches a Voltage above 3.55V
  • will reduce the allowed max. charge current in DVCC in steps, according to the value of the actual imbalance in the stack, as reported by the BMS.

The flow has been activated over the last four weeks now, and with PV intake increasing due to spring coming, the pack has been charged to 100% SoC just fine for many times, without triggering a single alarm.

In fact, for the last 5 days the pack charged fine, with a max imbalance of 25mV (which is below the value of 30mV, from where the BMS would even start balancing). Here the flow never triggered a counter measure, so I assume my pack is now well balanced enough, but I'll keep the flow running just in case.

Here it is:



With the flow keeping track, there was no need to adjust the charge voltage in DVCC anymore. The pack charged fine up to the victron defined, internal limit of 52.24V for Pylontech batteries, as stated in the documentation.

Note1: This uses MQTT and interaction with my local broker. I am using a bridge to interface with my Cerbo GX. So all mqtt topics, including VRM ID, need to be adjusted/added to suit your local setup

Note2: In my ESS setup, there is no PV via DC (like from a MPPT), only PV via AC-In from my grid-tied inverter.

Note3: This is an empiric approach, where the steps to reduce the max. charge current, according to cell imbalance, might be specific for my pack. I used reports via my TIG Stack setup, to evaluate the best numbers for a given situation.


...these are the values that worked fine for me, configured in the switch node shown above:


  • no max. charge current limit, if imbalance is less-or-equal 21mV
  • max. charge current limit set to 100A if imbalance is between 22-48mV
  • max. charge current limit set to 8A if imbalance is between 49-99mV
  • max. charge current limit set to 1A if imbalance is above 100mV
  • all else, max charge current limit is set to 25A (which is exact 100mV in this case - rarely used, I've seen the need to top-up some charge sometimes, where 8A and 1A would not be enough)

...maybe I am going to adjust these later on, again. For now, these worked fine for me.

Note4: The Cell imbalance needs to be calculated from the Cell-min and Cell-max Voltage, reported by the BMS. In my setup, this is another flow, that publishes this to another mgtt topic. This is the main part to do this: Node-Red-calc-Cell-imbalance-from-Pylontech-BMS.json.txt ... add it to the main flow, if need be.

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

1 Answer
leo9412 avatar image
leo9412 answered ·

Thanks for your explanation, I also have the problem with the high voltage alarm. I have adapted your flow to the Victro client via the integrated Node Red in the large version of the cerbo gx and am now testing it with myself.

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

hominidae avatar image hominidae commented ·
you're welcome. Feel free to ask if questions arise.

Once you have it working, mabe post the version, using the victron-contrib-nodes, here as well.

0 Likes 0 ·
leo9412 avatar image leo9412 hominidae commented ·

It works, I use the 3.00 Beta


0 Likes 0 ·
leo9412 avatar image leo9412 hominidae commented ·

It works on the first daily full charge, as soon as the batteries are full and then briefly discharged again and then charged again by solar, then it does not regulate correctly. I have the PV inverter at the AC output.

0 Likes 0 ·
hominidae avatar image hominidae leo9412 commented ·

When you say, that it doesn't work...what exactly?

Do you run into the kill-switch?

As said, this is an empiric approach. You should try and adjust the current settings according to the size of your pack.

Mine is a 6xUS3000C, so 220A max. Charge current reported by the BMS are 100%/440Ah Capacity and allowed Current is at 0.5C.

Edit: also, I am running a 3ph System, with MP2/48-5000, so good for charging with max. use in allowing a charge higher than either your Muti(s) or Battery Pack can cope with.

Maybe adjust the numbers in the switch accordingly.

I remember, that I started with 50A in the bucket, where now 100A is allowed. When my pack got better, I increased it in order to reach full charge faster. You need to find out, what cell-imbalance is tolerable, while still allow some charge go into.

In principle, charge as slow as you can. Then try to increase levels if it worked, maybe only after 2 or three iterations/days

0 Likes 0 ·
leo9412 avatar image leo9412 hominidae commented ·

The batteries are charged from 25% to 100% throughout the day, this works perfectly with your programming. But if the battery is discharged from 100% to 99% and then charged again to 100%, then the DVCC settings will not take effect. This was explained to me with feedback from the Multiplus and that my battery was too small. I have 2 x Multiplus 2 48-5000 and 4 x US3000C. According to the recommendation I supposedly need 6 batteries. I have reduced the charging current in the respective steps and will try again tomorrow.

0 Likes 0 ·
hominidae avatar image hominidae leo9412 commented ·

OK, that is maybe another, special situation, that's need to be taken care of.

I suggest, that you reduce the allowed charge current well before 97% SoC is reached and don't let this override/go higher by a positive the cell-imbalance again.

Create a safety margin, hence....try 10-12A with 4xUS3000C between 92 and 99% SoC

Edit: another counter measure could be, to sacrifice some energy by discharging at a higher power, that is required by ESS (supposedly grid-setpoint 0W)...set the grid-setpoint to -5000W for a minute...the voltage of the pack should drop faster, increasing the safety margin agan.

You could test the effect with an inject node, connected to the grid-setpoint parameter, once the trigger/event occurs.

0 Likes 0 ·
leo9412 avatar image leo9412 hominidae commented ·

Thanks for your tips. I added an extension based on the BMS SoC that sets the charge limit to 0A >= 90% if the battery has already been charged to 100% once. The charging limit after the switch I now have the steps 32A (100A), 8A (25A), 2A (8A) and 1A.

0 Likes 0 ·
hominidae avatar image hominidae leo9412 commented ·
OK, let's see how that works out for you.
0 Likes 0 ·
leo9412 avatar image leo9412 hominidae commented ·

Thank you, I now always set 8A at 90% and when 100% is reached, I start a discharge into the grid, then the error no longer occurs with me. I also don't let it load from 90% if the system was already at 100% once a day.

0 Likes 0 ·
hominidae avatar image hominidae leo9412 commented ·

Well, that is a strategy that should always work.

You maybe could try to do that more independent of SoC, by monitoring the should be "safe", as long as the Voltage is between 51V and 52V (assuming DVCC is set to default and the GX will use 52.24V as max for Pylontechs anyway). If SoC is 97% and even if voltage is below 52V, the pack will balance to 100%, even if charge current in DVCC is set to least, that is what I see with mine. My GX still follows that parameter, when set manually...I am on v3.00b26 since last weekend...ESS control is much faster, even with my EM24.

Only charging to 100% every once in a while is a good, healthy strategy anyway. I need to find a way to do/add that in the next weeks.

Eidt: looks like you are right...v3.00b is overschooting the target voltage a bit


However, no problem on my pack...this evening, with reported SoC 95% I was able to charge with up to 84.5A before voltage reached 52V and DVCC then reduced the current further down. 88A was the allowed charge according to BMS at that time...based on cell-imbalance (25mV) , no limit was set from my flow, while.PV intake was still >10kW, so plenty available...but all still working safely.

0 Likes 0 ·
1680197775869.png (112.8 KiB)
leo9412 avatar image leo9412 hominidae commented ·

Yes, I will try to optimize it further. It was only important to me to protect the batteries first, so that the BMS does not have to switch off every day. I also had the high charging voltage with the official release version. My batteries report a maximum charge voltage of 53.2V. Preventing daily full charging is probably better for the batteries as well.

0 Likes 0 ·
hominidae avatar image hominidae leo9412 commented ·
Yes, 53.2V is what the BMS itself reports, but DVCC will limit that internally to 52.24V, based on the victron provided documentation for Pylontech Batteries.

My opinion is, that a full charge is doing no harm, when that state is not being held for too long. So my goal, especially during autumn & spring, when my central heatpump is still running, is to reach the 100% approx 1hr before sundown (which is generally the point, when PV intake is forecasted to be less than 2kW at that time).

Going below a minimum SoC is more harmful, as voltages will go well below 47.5V (<3.2V per cell) sometimes, when there is a need to supply higher loads on AC. So I am avoiding to use the advertised DoD of 95% and set minSoC in ESS to 13%.

Pylontechs seem to have a special line at 11% SoC (where my pack can store/deliver over 2kWh (which is 10% capacity) at this single decimal SoC point - the same goes for the 89% mark), hence I am setting MinSoC to 13%.

0 Likes 0 ·