# Pylontech Firmware Update Feature Issue **URL:** \ **Category:** Q&A and troubleshooting\ **Tags:** pylontech, vrm, cerbo\_gx, diy\ **Created:** [27 March 2026 19:44 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616 "2026-03-27T19:44:06Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![onceuponatime78](https://avatars.discourse-cdn.com/v4/letter/o/8e7dd6/32.png) [@onceuponatime78](https://community.victronenergy.com/u/onceuponatime78)\ **Post date:** [27 March 2026 19:44 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/1 "2026-03-27T19:44:06Z")
Hi, I wanted to look into the new Pylontech firmware update feature with an **Ekrano GX** , **Venus OS v3.71** , and **Pylontech US3000C** batteries, and as the Pylontech battery did not show up in the list of devices having a potential firmware update in the vrm portal I looked a bit deeper into it ### Setup - Ekrano GX - Venus OS v3.71 - Pylontech US3000C - `vecan0` = **500000 bit/s** - `vecan1` = **250000 bit/s** Manually executing /opt/victronenergy/mqtt-rpc/thirdparty/pylon/py-tool -l shows the battery on **vecan0** : ```auto ``` From the logs, when triggering looking for new firmware versions via vrm the generic scan was invoking: ```auto INFO:streamcommand:Command ('vup', '--xml', '--no-local', '--canbus', 'socketcan:vecan1') terminated with status 0 INFO:streamcommand:Command ('xupt', '--xml') terminated with status 89 WARNING:thirdpartyupdater:"/opt/victronenergy/mqtt-rpc/thirdparty/pylon/py-tool -l" returned abnormal exit code 7 ``` Looking at `/opt/victronenergy/mqtt-rpc/mqtt-rpc.py`, `get_canbuses()` only checks DBus services matching: ```auto com.victronenergy.vecan.* ``` But on my system DBus shows: ```auto com.victronenergy.vecan.vecan1 com.victronenergy.battery.socketcan_vecan0 ``` So `vecan0` is ignored by the generic scan, even though that is where the Pylontech battery actually is. After patching `get_canbuses()` to also include `com.victronenergy.battery.socketcan_*`, the scan started invoking both CAN buses: ```auto INFO:streamcommand:Command ('vup', '--xml', '--no-local', '--canbus', 'socketcan:vecan0') terminated with status 0 INFO:streamcommand:Command ('vup', '--xml', '--no-local', '--canbus', 'socketcan:vecan1') terminated with status 0 ``` and discovery started working, hence the pylontech battery showed up in the vrm firmware update device list. So it looks like `mqtt-rpc.py:get_canbuses()` ignores `com.victronenergy.battery.socketcan_*`, so valid battery CAN interfaces like `vecan0` are missed. Has anyone else seen this with Ekrano GX + US3000C or do you see anyhting obvious that I might have configured/setup wrong? ---
**Author:** ![onceuponatime78](https://avatars.discourse-cdn.com/v4/letter/o/8e7dd6/32.png) [@onceuponatime78](https://community.victronenergy.com/u/onceuponatime78)\ **Post date:** [27 March 2026 20:47 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/3 "2026-03-27T20:47:27Z")
What I’m trying to report is a likely Victron-side issue in the update mechanism itself. On my system, the battery is clearly reachable and detected by the Pylon helper: ```auto ``` However, the generic discovery path in `mqtt-rpc.py` only considers `com.victronenergy.vecan.*`, while my battery is exposed on DBus as: ```auto com.victronenergy.battery.socketcan_vecan0 ``` Because of that, `device-list-2` initially scanned only `socketcan:vecan1` and missed the actual battery CAN interface. After patching `get_canbuses()` to also include `com.victronenergy.battery.socketcan_*`, discovery started working. ---
**Author:** ![M\_Lange](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/m_lange/32/16_2.png) [@M\_Lange](https://community.victronenergy.com/u/M_Lange)\ **Post date:** [27 March 2026 21:18 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/4 "2026-03-27T21:18:33Z")
Maybe the currently installed FW is too old? ---
**Author:** ![alexpescaru](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/alexpescaru/32/270_2.png) [@alexpescaru](https://community.victronenergy.com/u/alexpescaru)\ **Post date:** [27 March 2026 22:51 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/5 "2026-03-27T22:51:53Z")
He already stated that he has Venus 3.71 so it’s not old. And he is right about discovery method because since long the `com.victronenergy.battery.*` is the D-Bus service interface for battery devices and therefore it’s only logical that you should also look there for can buses used for battery communication. For example, below on one of my systems, you can clearly see that …vecan.\* enumeration will only expose can0, which is used only for Cerbo and Multi RS communication. The can1, where the battery is, is exposed through …battery.\* service. So the script should also look at this path. Or better, the can buses can be enumerated from com.victronenergy.platform/CanBus/Interfaces, where you, for sure, find all can buses. ![1](https://europe1.discourse-cdn.com/victron/original/3X/7/a/7a43eaa98d11ac5e9260c53ddb71f701058cb110.png) ![2](https://europe1.discourse-cdn.com/victron/original/3X/5/b/5b5ce109a809ef7858314e9d83a860e950de34f3.png) ---
**Author:** ![jeroen](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jeroen](https://community.victronenergy.com/u/jeroen)\ **Post date:** [27 March 2026 23:10 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/6 "2026-03-27T23:10:14Z")
> [@onceuponatime78](#): > > So it looks like `mqtt-rpc.py:get_canbuses()` ignores `com.victronenergy.battery.socketcan_*`, so valid battery CAN interfaces like `vecan0` are missed. No, it is a plugin. This code is not involved. ---
**Author:** ![alexpescaru](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/alexpescaru/32/270_2.png) [@alexpescaru](https://community.victronenergy.com/u/alexpescaru)\ **Post date:** [27 March 2026 23:15 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/7 "2026-03-27T23:15:02Z")
The code here ```auto def get_canbuses(): dbusSession = dbusConnection() services = dbusSession.list_names() can_services = [x for x in services if "com.victronenergy.vecan." in x] return [ "socketcan:{}".format(x.split(".")[-1]) for x in sorted(can_services)] ``` will not enumerate can1 where the battery is in my system, as seen below The list will only contain [socketcan:can0] In order for the battery to be detected, it should contain [socketcan:can0, socketcan:can1], but the python code above will not populate the socketcan:can1 ![1](https://europe1.discourse-cdn.com/victron/original/3X/7/a/7a43eaa98d11ac5e9260c53ddb71f701058cb110.png) ---
**Author:** ![jeroen](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jeroen](https://community.victronenergy.com/u/jeroen)\ **Post date:** [27 March 2026 23:18 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/8 "2026-03-27T23:18:11Z")
> [@alexpescaru](#): > > will not enumerate can1 where the battery is in my system, as seen below yes, and it shouldn’t for a a not ve.can interface. ---
**Author:** ![alexpescaru](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/alexpescaru/32/270_2.png) [@alexpescaru](https://community.victronenergy.com/u/alexpescaru)\ **Post date:** [27 March 2026 23:20 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/9 "2026-03-27T23:20:09Z")
Are you saying that on old Cerbo MK1, that has a “dedicated” BMS CAN module - so not a VE.CAN interface, you can’t update the firmware in Pylontech batteries? ---
**Author:** ![jeroen](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jeroen](https://community.victronenergy.com/u/jeroen)\ **Post date:** [27 March 2026 23:20 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/10 "2026-03-27T23:20:53Z")
> [@alexpescaru](#): > > In order for the battery to be detected It is Pylontech detecting Pylontech batteries, it has nothing to do with VE.Can. ---
**Author:** ![jeroen](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jeroen](https://community.victronenergy.com/u/jeroen)\ **Post date:** [27 March 2026 23:22 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/11 "2026-03-27T23:22:53Z")
> [@alexpescaru](#): > > Are you saying that on old Cerbo MK1, that has a “dedicated” BMS CAN module - so not a VE.CAN interface, you can’t update the firmware in Pylontech batteries? No, I am just saying that the code you quoted is irrelevant. ---
**Author:** ![alexpescaru](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/alexpescaru/32/270_2.png) [@alexpescaru](https://community.victronenergy.com/u/alexpescaru)\ **Post date:** [27 March 2026 23:27 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/12 "2026-03-27T23:27:01Z")
Correct me if I am wrong… The code I have quoted is enumerating CAN ports on a system. In order for later the script to be able to scan each detected CAN port. ```auto # CAN-bus interfaces interfaces = get_canbuses() for idx, can_interface in enumerate(interfaces): cmds.append(VupCommand(can_interface)) ``` If we don’t have a complete list of CAN ports, is it possible to miss a/the battery on the system? ---
**Author:** ![jeroen](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jeroen](https://community.victronenergy.com/u/jeroen)\ **Post date:** [27 March 2026 23:29 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/13 "2026-03-27T23:29:42Z")
> [@alexpescaru](#): > > Correct me if I am wrong… I will, vup is for VE.Can, Pylontech is a plugin though, has nothing to do with VE.Can. ---
**Author:** ![jeroen](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jeroen](https://community.victronenergy.com/u/jeroen)\ **Post date:** [27 March 2026 23:31 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/14 "2026-03-27T23:31:39Z")
For completeness btw, not saying there might not be a bug in there, but just pointing out that this code isn’t the reason… ---
**Author:** ![alexpescaru](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/alexpescaru/32/270_2.png) [@alexpescaru](https://community.victronenergy.com/u/alexpescaru)\ **Post date:** [27 March 2026 23:33 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/15 "2026-03-27T23:33:28Z")
OK, maybe we are talking about different things… Nevertheless he said: _After patching `get_canbuses()` to also include `com.victronenergy.battery.socketcan_*`, discovery started working._ ---
**Author:** ![jeroen](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jeroen](https://community.victronenergy.com/u/jeroen)\ **Post date:** [27 March 2026 23:34 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/16 "2026-03-27T23:34:45Z")
> [@alexpescaru](#): > > After patching `get_canbuses()` to also include `com.victronenergy.battery.socketcan_*`, discovery started working. I know, but that is likely timing luck… ---
**Author:** ![alexpescaru](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/alexpescaru/32/270_2.png) [@alexpescaru](https://community.victronenergy.com/u/alexpescaru)\ **Post date:** [27 March 2026 23:39 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/17 "2026-03-27T23:39:01Z")
Aaaaa… I finally realized what you are trying to say… Doh… Indeed, the pytool is searching for the battery… ---
**Author:** ![onceuponatime78](https://avatars.discourse-cdn.com/v4/letter/o/8e7dd6/32.png) [@onceuponatime78](https://community.victronenergy.com/u/onceuponatime78)\ **Post date:** [27 March 2026 23:40 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/18 "2026-03-27T23:40:17Z")
I am pretty sure that its not timing luck as I triggered the discovery multiple times with and without the patch applied. For completeness, these are the changes I had to make locally to get past the initial discovery issue: ### 1) Patch in `mqtt-rpc.py` File: ```auto /opt/victronenergy/mqtt-rpc/mqtt-rpc.py ``` Function: ```auto def get_canbuses(): ``` Originally, it only included DBus services matching: ```auto com.victronenergy.vecan.* ``` On my system that only returned: ```auto com.victronenergy.vecan.vecan1 ``` But the actual Pylontech battery was exposed on DBus as: ```auto com.victronenergy.battery.socketcan_vecan0 ``` So `vecan0` was ignored by the generic discovery scan. I patched `get_canbuses()` so it also includes: ```auto com.victronenergy.battery.socketcan_* ``` After that, `device-list-2` started scanning both: ```auto socketcan:vecan0 socketcan:vecan1 ``` and discovery started working. ### 2) Patch in `thirdparty/pylon.py` File: ```auto /opt/victronenergy/mqtt-rpc/thirdparty/pylon.py ``` Because the automatic Pylon helper scan was still not behaving correctly, I changed the Pylon plugin so that `device_list()`explicitly runs: ```auto py-tool -l -c vecan0 ``` instead of relying on the automatic interface scan. This made the Pylon battery show up correctly. ---
**Author:** ![jeroen](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jeroen](https://community.victronenergy.com/u/jeroen)\ **Post date:** [27 March 2026 23:41 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/19 "2026-03-27T23:41:11Z")
> [@alexpescaru](#): > > Indeed, the pytool is searching for the battery… exactly, and on all interfaces and with a doubtful exit code. Anyway as said, that was not the code you should be looking at… ---
**Author:** ![alexpescaru](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/alexpescaru/32/270_2.png) [@alexpescaru](https://community.victronenergy.com/u/alexpescaru)\ **Post date:** [27 March 2026 23:47 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/20 "2026-03-27T23:47:12Z")
Still, there is the _connection\_id_ that is passed to the UpdaterThread for the specific plugin. Isn’t it contain the can port id? ---
**Author:** ![jeroen](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jeroen](https://community.victronenergy.com/u/jeroen)\ **Post date:** [27 March 2026 23:49 UTC](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616/21 "2026-03-27T23:49:57Z")
> [@onceuponatime78](#): > > This made the Pylon battery show up correctly. I guess you are over complicating things, I doubt this ! should be here [py\_tool/pylon\_tool.c at master · pylontech-sw/py\_tool · GitHub](https://github.com/pylontech-sw/py_tool/blob/master/pylon_tool.c#L714). [Next page](https://community.victronenergy.com/t/pylontech-firmware-update-feature-issue/55616.md?page=2)