Maybe I test that tomorrow or the day after.
2 Likes
Let us know how it went, please
I wasn’t in the office today, maybe tomorrow.
1 Like
I just did some tests.
I tested 5 US2000C, one was on 1.7 and the others on 1.4.
First I tested the .zip file you can download from Effekta (German Pylontech Distributor/Support).
I renamed it to .xup.
The VRM portal accepted the file and after a while it showed “Update finished” but the battery wasn’t updated.
Next I wanted to the two files from inside the .zip, but I wasn’t sure which one to use.
So I used the original Pylontech update tool to update one battery.
The update tool showed that it used the US_E2_V2.5_Crc.
That files are .bin and I also renamed them to .xup.
So I used that file for the update via VRM and it worked.
As a next test I intentionally selected the other file.
VRM again showed “Update finished” but it seems like the battery is smart enough to not use that wrong file.
As a last test I connected two batteries together and both got updated.
What I didn’t tested was what happens with the DC output.
It seems like the batteries switch off for a few seconds but I didn’t measure the voltage and the GX got it’s power from another power supply.
I think we have another US3000C somewhere maybe I test that too.
4 Likes
Amazing! Thank you so much for sharing.
One additional question - what version number was shown in the VRM interface prior to the update procedure - both in Device list and also when you scan devices for Firmware update? Were they correct to begin with? Did they change after update?
Thank you for testing thoroughly and sharing the info! 
I think one of the most important things is that the DC from the batteries may interrupt while updating.
So it would be important if it’s an issue for the process if the cerbo is supplied by these battery or not. If the cerbo needs to have uninterrupted power while updating the pylontechs there should be a very explicit notice about this before starting update. And maybe the advice to switch of the multiplus?
The DC-side behaviour is a very interesting point too.
My assumption is that in a grid-tied system (e.g. MultiPlus / Quattro / Multi RS connected to AC-in), it might not be a problem at all, because even if the battery DC output drops for a few seconds, the inverter/charger should still have an energy source available (AC-in → DC bus), and the system stays alive.
Same logic if the update is done during daytime with PV, where MPPT(s) would still keep the DC bus up.
But the real question is this scenario:
off-grid installation
night time (no PV)
GX powered from battery DC
If the Pylontech really switches off its DC output for a few seconds during the update, that could mean:
-
DC bus drops
-
Cerbo loses power and reboots
-
the update process could be interrupted / corrupted
On the other hand: maybe it behaves similarly to Victron device firmware updates — i.e. temporary loss of comms/power occurs, then VRM reconnects and continues once everything comes back online (like when a MultiPlus is remotely updated and the connection drops temporarily due to AC to modem being shutdown).
A sudden interruption of the DC bus could cause a full shutdown if the system is currently pulling much energy from the battery.
It also can cause damage to the MPPTs if they are charging at full power at that moment.
The GX device only sends the FW file to the battery, it doesn’t do the update.
The battery starts the update after it received the file, so theoretically a reboot of the GX device shouldn’t be a Problem.
I will try updating a US3000C later today and I will connect the Cerbo + a load to the battery this time.
It would also be interesting to know what happens if there are different batteries in the system.
For example, a combination of US5000 and US2000C batteries.
Unfortunately I can’t test that.
We don’t sell Pylontech anymore and it’s just a coincidence that we have a few US2000C and one US3000C in our workshop.
Also all US2000C are now on the last FW already.
(not sure if you can downgrade to a lower FW, @alexpescaru you seem to know a lot about updating Pylontech)
If down grading works I could test US2000C and US3000C together.
Okay… so I bit the bullet and tried it myself. Unfortunately — or maybe fortunately — nothing happened. Neither good nor bad.
Test setup / context
-
Remote test on an off-grid installation that connected to internet via DC-powered antenna (so even if the inverter shuts down, I still have connectivity).
-
This was also part of the test: if the battery shut down during FW update even for a second, I would immediately see it because the antenna would drop offline (it takes ~1 minute to reconnect after power loss).
-
System: 1× Pylontech US2000C (serial HPTCR032217XXXXX), MultiPlus 1600 VA, SmartSolar MPPT, Cerbo GX.
What I did
-
As a precaution, I first turned OFF the inverter remotely via Cerbo (so there was no AC draw).
-
Also it’s 5AM on Easter Island, so no solar
-
So battery was basically idle: only the antenna (<5 W) + Cerbo load.
-
Same method as @M_Lange : renamed both firmware files extension to .XUP.
-
In VRM → device list → “Firmware update” the battery shows up correctly (reporting FW 2.2 and serial number displayed correctly).
Result
-
I tried both files from the ZIP (FW 2.5 and 3.1) and neither of them did anything.
-
The VRM update procedure shows the progress bar, it runs very quickly, and then… nothing.
-
Throughout the process I continuously pinged the antenna to detect any DC interruption — no dropped pings at all, so no reboot / no DC disruption.
-
After the “update”, everything still shows exactly the same as before (no visible change).
So overall: I’m glad nothing broke, but at the same time it looks like the update didn’t actually run at all (at least not with these files / format).
Yes you can. 
I just downgraded one of the US2000C to v2.1.
Then I connected that US2000C and an US3000C (I think it was on v2.2) together and did the update via VRM and it also worked.
Both batteries needed the same file (US_E2_V2.5_Crc).
Obviously this can’t work if you have batteries together that requires different FW files, but I can’t test that because we don’t have any other Pylontech batteries in our workshop.
I also had a small MultiPlus with a 400W heater as a load connected.
After the GX finished sending the FW file the DC bus has been switched off for a few seconds!
As I wrote above you need to keep that in mind and maybe need to take precautions.
A reboot of the GX device shouldn’t cause problems.
2 Likes
- The VRM update procedure shows the progress bar, it runs very quickly, and then… nothing.
There’s currently a bug in the tool which is why the user isn’t properly notified of the result. If the update procedure runs very quickly, it most likely bailed in one of the early stages (FW compatibility check, CRC check, etc.).
This will be fixed soon.
It’s about the board type and chipset used.
In the name of the firmware, there is the board type. In your case, that E2.
If you take a look at the history and/or event data of the battery, obtained through the BatteryView software from Pylontech, in first lines it says the board version, which the firmware file must match.
2 Likes
Awesome — I’m really excited to see this feature being developed by Victron and Pylontech.
From an installer/integrator perspective, this is a huge step forward: having one unified interface (in this case VRM) where we can monitor, diagnose, and remotely maintain / update basically all key parts of the system — even when some parts are from other manufacturers (in this case Pylontech batteries) — is a big deal.
This kind of “single platform controls everything” experience is typically limited to vertically integrated ecosystems (Tesla is a good example: they design the hardware, software, batteries, inverter, platform, etc.). The beauty of Victron is exactly the opposite: the ecosystem plays nicely with many different brands — and it’s amazing to see that this philosophy is now extending to something as important as battery firmware updates.
Another important point: batteries are still expensive, and in many installations they represent one of the biggest parts of the total system cost. So when we sell battery storage to a client, we really need to be reasonably confident that the batteries will remain reliable, supported, and updatable throughout the lifetime of the product — so clients are still happy many years after the initial installation.
And realistically, it’s just not feasible to visit every single client personally for battery service tasks. So being able to manage and maintain them remotely through VRM is not just a “nice extra” — it’s a huge deal for long-term support and professional deployments.
3 Likes
Personally, most of my installations use Pylontech, so this is very welcome news.
And looking forward: if/when we consider alternative battery brands for future projects, one of the key evaluation criteria will definitely be how tightly the battery manufacturer is integrated into the Victron ecosystem, including remote serviceability through VRM.
That makes sense. Follow-up Question: is there a way to determine the battery board/chipset type remotely (without BatteryView + cable)?
I really want this whole workflow to be 100% remote (VRM/GX), because visiting each client just to plug in cable and launch BatteryView isn’t scalable.
Ideas that might work:
-
Does Venus OS expose board/hardware version anywhere on D-Bus (e.g.
com.victronenergy.battery.*or similar)? -
Or can the VRM update tool/compatibility check provide a clearer message like: “Detected board type E2, expected file US_E2_…” (or log it somewhere visible)?
If the GX already reads enough info to reject the wrong file, it feels like the system must know why — it would be amazing to surface that to the user so the correct firmware package can be selected remotely.
I couldn’t agree more. We use Pytes batteries for 48V battery installations and Pytes has told me they are working with Victron on a similar feature. This solves a huge pain point to be sure.
1 Like
In this moment, only the battery’s SN can be read by the means of the current network topology (CAN bus).
No matter if it’s published by the battery or interrogated by the update procedure.
In theory, you can deduce the board type based on the SN, but only Pylontech knows how to correlate the SN with the board type.
Some info here:
Pylontech Low Voltage Battery Mornitoring and Maintenance Tool Guidance 1101.pdf (3.2 MB)
1 Like