I took a look at my Pylontech stack, which has grown over time, today and noticed that the firmware versions are actually quite different.
See the screenshot showing Device 1 (oldest) through to 5 (newest). I noticed this because, when the charging voltage is set to 52 V in the Multiplus units, my batteries always show a voltage difference of 30 mV between the cell with the lowest voltage and the one with the highest voltage in each block.
Does it make sense to bring the firmware versions into line? Is a 30 mV difference between cells a cause for concern, or should I simply carry on using them?
First of all … updating the firmware via VRM really is a breeze … it worked brilliantly with my 6 x US3000C.
A cell voltage difference of 30 mV is perfectly fine and would not be a reason to carry out an update. A few months ago, I would have advised you against it because of the possibility of the wrong firmware being used for an older or newer chip. But that has changed now.
The more important adjustment to reduce wear came through the GX firmware … and top balancing is still being adjusted … So far, this has usually been done via Node-RED … see Pylontech Ladekurve passt nicht
the current firmware versions for the US300C are 2.5 and 3.1, and they can be downloaded from Effekta.
I have a US3000C battery module which, according to the PDF accompanying the firmware, should contain the new chip (= firmware 2.5), but it requires the firmware for the old chip (= 3.1).
When expanding the system, the new module should always become the master.
I would change that.
As I’ve already said, a cell voltage difference of 30 mV is completely fine and harmless.
An update wouldn’t necessarily be required in this case, but it probably wouldn’t do any harm either.
Pylontech has released quite a few updates recently and apparently adjusted the charging algorithm in the process.
If I remember correctly, in particular the CVL was reduced from 53.4 to 52.8.
That hasn’t only changed in the last few months.
Pylontech’s update tool has been smart enough for a few years now to select the correct file for the battery from the ZIP archive.
The only new thing is that, for some time now, you’ve been able to perform the update via the VRM portal.
However, the firmware on the master must not be too old.
I’m currently in contact with a customer whose batteries aren’t being displayed in the VRM portal for the update because the firmware on the batteries apparently is too old.
We installed the system in mid-2022.
When updating via VRM, you have to upload the unzipped BIN file, which means the automatic selection of the correct firmware is no longer available.
@M_Lange is there any information on how this works via VRM when you have Pylontech batteries with different hardware versions—in other words, when one battery needs firmware X and the other needs firmware Y?
The newest battery should always be the master.
The master then also controls the other batteries using its data.
This means that all the batteries are controlled according to the firmware version of the newest battery.
As I understand it, this should actually make a firmware update unnecessary for your old batteries.
However, the update tool built into Venus OS is smart enough to stop with an error message when given the wrong file.
With the update tool on a PC, manually selecting the wrong file can potentially brick the BMS.
As already mentioned, the module with the latest available firmware should be the master; it will then handle updating the slaves.
Unfortunately, I wasn’t able to test what happens when you have a system containing a mixture of different modules that also require different firmware files (US2000C/3000C + US5000, or 2000/3000 models without the C + models with the C).
However, that wouldn’t be relevant here, since all the modules have the E2 board.
I have two US3000Cs and one US2000C, each with a C in the 8th position of the serial number.
From the Effekta instructions:
US2000/3000 Type C (new/old chip) „US2000_C3000C_C_V3.1&E2_2.5
This is how I interpret Effekta’s instructions:
Serial number with X in the 8th/9th position
C = FW V3.1
E2 = FW 2.5
The US3000C block that is three months older wants FW 3.1, which is actually for the E2 version; the newer one wants 2.5; US200C wants 2.5.
Either I’m misunderstanding something or the instructions are wrong.
In the end, I updated all the Pylontechs individually, without link cables, using the console cable and the Pylontech Flash software.
The update for the US5000s that were purchased together went smoothly via VRM.
However, I haven’t yet checked on site whether all the blocks actually have the same firmware installed.
The E2 boards have firmware 2.5.
The board with firmware 3.1 reports NULL as the board
That may not be a problem with the Pylontech Flash Tool.
But how am I supposed to know remotely what kind of board is installed in the batteries and extract the correct firmware from the ZIP file?
And even in Battery View, at least in my version, you have to search for quite a while to find the board version.
As I said, the update aborts via VRM if you select the wrong file.
At least, that’s what happened in my test, where I deliberately selected the wrong file.
So, basically, nothing can go wrong.
Unfortunately, I couldn’t test a scenario like yours, as I only had US2000C/3000C units with the same board available.
So I can’t say for certain whether the master forwards the “wrong” file to the corresponding module or simply stops with an error.
I might ask our former Pylontech supplier whether they have the possibility to test this.
For the update, I simply disconnected the communication between the different blocks of my Pylontech system and carried out the update in two stages. This also has the advantage that, if the BMS switches off discharge during the update, the Cerbo remains powered.
That’s also the most important point here. The same thing happened to me. Otherwise, people following along might think they’re about to brick their boards.
The issue with the different firmware versions only came up when the US2000 battery was added.
Okay, so updating via the VRM site is fairly safe. Should/must I power the Cerbo from another source during the process, or do the batteries only boot once all the data has been written?
Quote:
„When expanding the system, the new module should always become the master.“
I actually didn’t do that, but always added the new modules at the end. However, if I do go ahead with the update, it shouldn’t matter, since they’ll all have the same software version afterwards.
Well, we’ll see if I can pluck up the courage to do it over the next few days.
Hi everyone, I ended up here via a Google search. I think my problem is also related to the different firmware versions in my Pylontech stack. There are five US5000s, produced between 2023 and 2026. I can’t set the newest battery as the master, or even run it on its own, because the inverter (SolarEdge SE 8K RWS) doesn’t receive a valid SOC and, after a while, blocks charging and discharging.
I suspect that the firmware on the newest module is no longer compatible with the inverter workaround (configured in the inverter as BYD LV14). But perhaps the version is buggy. Maybe there’s some known issue with 2026 production units.
I’d be very grateful for any tips or further information.
Hi Dirk, I’d only do that if I had specific information about which firmware version becomes problematic from what point onwards.
After everything I’ve read on forums about bricked batteries, I consider firmware updates on a Pylontech too risky if done on a whim. There would have to be a clear benefit, such as a high probability that the module would then be able to communicate with the inverter. Until I find something to that effect, I’m not going to touch the firmware and will just run the unit as a slave. Luckily, that works.
Be careful when you write: “When expanding, the new module should always become the master.” This is true ONLY if the new module has newer firmware, and with old stock from some retailers, this is not always the case, especially if your purchases are made close together!
Be careful with the statement: “When expanding, the new module should always become the master.” This is only true if the new module has newer firmware; with stock held by certain retailers, however, that is not always the case—especially if the purchases are made close together.
