There was a change on new versions where it may not recognise a much older backup version. Not sure where the cutoff is.
Now enter on each of these devices and look at the Network address.
Is it different and unique for each of them?
Beware that you’ll not be able to boot back to the previous version if you do that, because the file system has an additional flag and the 3.72 will not recognize the previous version.
v3.60 introduced it and older than 3.60 will not be seen after.
By the way…
Do you have any VE.Smart Network enabled in the MPPTs settings?
Whilst preparing the system update, the following occurred to me:
- I use a driver for a ‘virtual battery’ GitHub - mr-manuel/venus-os_dbus-mqtt-battery: This Venus OS driver gets the data from MQTT and displays it as battery. · GitHub to aggregate my three batteries connected via SmartChunt.
- I have a system browser I wrote myself, which displays current and historical system data via a web interface and saves the current data. Are any problems to be expected when updating the GX and the likely newer version of Node-RED? During the last GX update, I had problems with Node-RED libraries…
Yes, that driver can be a real issue. It probably needa updating first. Best consult their git repository first.
On modern versions of the GX code, third party mods have been a real cause of problems.
Is there any reason why the MPPT-CAN firmware shouldn’t work with my GX version?
To avoid any issues, I would otherwise start by updating the MPPT-CAN charge controllers, beginning with the device connected last on the physical bus. This should ensure that the ‘gateway function’ continues to work, provided it is backwards compatible.
Depends if the issue you experienced was actually a firmware issue or a gx issue.
So, I’ve carried out the update on all the solar charge controllers and restarted the GX. First of all, all the charge controllers are showing up in the list 
Unfortunately, however, the GX doesn’t seem to have any control over the charge controllers, as the status for all of them is ‘Standalone’ (previously ‘Slave’). For this reason, I carried out the GX update on my test system (CerboGX) before any problems arose on my live system. Unfortunately, the network status is the same.
@Alex Pescaru, where can I find these settings? I remember having seen them before, but I don’t know where.
Try power everything off and on again.
This morning, when my solar system started up, my fears from yesterday were confirmed:
Version 3.18 has the same problem with CAN messages as versions 3.16 and later.
It does not accept ‘forwarded’ CAN messages. If a V3.18 is the first unit on the physical bus, followed only by versions 3.13, the system works. As soon as a version 3.18 is placed behind a 3.13 or 3.18, this controller is no longer recognised by the GX. As far as I can tell from my older chat logs, this is the same behaviour as with version 3.16.
In the meantime, I have downgraded the solar controllers back to version 3.13. As my entire house, including my heat pump, is connected to the solar system, I need every kWh.
Here are some more pictures of the step-by-step downgrade process:
@Alex Pescaru, From what I’ve read so far, the “VE.Smart Network” does exactly what I’m doing with the CAN bus. I haven’t activated it for safety reasons. That’s why I opted for the slightly more expensive MPPT-CAN controllers. As the Bluetooth connection can sometimes be disrupted, and safety-critical data such as battery voltage and current are transmitted via it.
The solar controllers all have a unique network address. These settings haven’t changed at all as a result of the software update.
That is good.
What about network status and bus errors?
The network status is OK.
Did you saw any relation in the order of the network addresses and position of the controller on the bus and firmware version?
It would have been a good test to disconnect mppt’s to see if there is a point it restarts, ie if it is related to the number of chargers.
I will try raise this in our community group.
Hi, @guystewart,
Would you be so kind as to inform your fellow developers about this issue? I’ve been waiting for a solution for almost two years now. I’ve also asked Victron if I could get the source code for the solar controller software so I can fix the problem myself, if there are more important issues to deal with. But it seems they’re not really into open source.
Have you tested on a complete factory default system with no custom modifications?
See here how to reset the GX to factory settings.
And then check the “modifications check” and it should be green and say “clean”
Then make sure all connected devices are running latest firmware and list their versions.
That is the first thing to do before R&D can have a closer look to rule out some unsupported 3rd party modification interference.
Yes, I have a CerboGX as a parallel test system. No drivers for battery aggregation are running on it. I would also expect Victron to carry out such a test before releasing any software.
The software we develop in-house is subjected to a final HIL test to rule out any potential interactions with existing functions and to automate repetitive tests.
What is the VRM url?