So: the test results are a bit of a let-down for me:
In the screenshot taken at 15:31, only controller A is on V3.18; the others are still on V3.13.
The next step was to update all the solar controllers to 3.18. This went quite quickly via the Bluetooth connection. Unfortunately, the result wasn’t as expected. Image from 16:08. Interestingly, the charging outputs of the individual controllers are much higher at first and then drop rapidly. Until only the state shown in the image remains.
Unfortunately, downgrading the solar controllers isn’t quite so straightforward, as the app doesn’t allow you to select a file if the latest version is already running. So I had to plug VE-Direct into each of the seven solar controllers using my laptop.
In the meantime, I’ve been thinking about what’s different in my colleague’s system. As far as I know, he’s connected a battery management system via CAN. That would also explain why the solar controllers initially have more power. Perhaps the GX first tries to retrieve data from the battery management system before it reduces the output.
I solved this in my own system using the driver for the aggregated batteries. At the time I was planning and building my system, there was no sensible solution for this. The LiFePo battery kits that are available now weren’t available back then. And the Pylontech batteries are out of the question in terms of their electrical parameters.
Now all the solar controllers are running V3.13 again.
According with Victron docs, in a network, only the master broadcasts voltage set-point.
In your systems there are two 2 (!!) entities that broadcast on the network the voltage set-point.
One is Cerbo, which broadcast a 0V (yes, zero) voltage set-point.
Second is the controller with the 36 network address, which broadcasts 58.4V voltage set-point.
This is odd…
Maybe the 3.13 firmware is not bothered by this, but 3.18 could see it as an error and stops production.
More of that, it seems the controller 36 is somehow the master in the system.
Sounds like your virtual BMS is missung a value or something else necessary for DVCC. The older v3.13 MPPT firmware does not seem to be affected by that but v3.18 appears to be.
The DVCC was disabled throughout all tests.
Incidentally, I don’t use CerboGX for my live system, but rather the MultiGX integrated into the MutiII, whereby battery measurement is carried out via three SmartChunts, USB and VE.Dierekt, which are then aggregated in Node-RED and made available to the system as a virtual battery via the MQTT driver.
To be honest, I cannot imagine that this problem is caused by the GX software. After all, only a change to the solar controller firmware can ultimately result in changes to the CAN protocol. For example, packets that were ‘forwarded’ by a previous solar controller are ignored or evaluated and ‘forwarded’.
I’d set up the MultiPlussII battery monitor as a backup so that if a USB or SmartChunt connection failed, there would still be a valid reading available.
I now only have one active (visible) battery monitor.
The description of the automatic battery monitor selection suggests that the GX selects a battery monitor from the list, working from top to bottom. Perhaps that is where the problem lies?
@Alex Pescaru,
I repeated the test whilst running the CAN trace.
After deactivating the second battery monitor, updating controller D (the last one on the physical bus) and performing a GX reset, the controller disappeared.
In this context, I also tried again to change the order of the physical connectors on controller D. Initially, the terminating resistor was on the left port and the CAN cable (input) was plugged into the right. However, this did not resolve the issue. I just noticed that whenever the connection to the controller has only been established for a relatively short time, whether after a software update or after plugging in the CAN cables, the power output is initially significantly higher than after about 20 seconds. So there seems to be another reason for this phenomenon.
I have now downgraded my controller G back to V3.13 and reactivated my second battery monitor for safety reasons.
All controllers running on V3.13
To test my theory regarding V3.18 – that this version does not accept ‘forwarded’ CAN packets – I updated the first solar controller in bus ‘G’ to V3.18. Unfortunately, this controller also lost power after the update, whilst the others remain unaffected. This suggests that solar controller firmware >V3.13 behaves completely differently on the CAN bus compared to versions <= V3.13.
Interestingly, a similar behaviour can be achieved for all controllers, either V3.13 or V3.18, when I switch on DVCC.
Only controller “G” is running V3.18 (first on the physicall CAN-bus)
I haven’t been able to sort things out with my colleague yet. In any case, there’s a significant difference in the system architecture. He’s using a BMS via CAN. He hasn’t been able to tell me yet whether it’s on the same interface or using a Cerbo. I also asked him which versions of the GX he’s using. I hope to get the answer next week. As I’ve already mentioned, version 3.16 is running on his two solar controllers, which definitely doesn’t work for me.
But there is definitely someone else who has exactly the same problem. @BecauseRV has already mentioned here in the chat that this is the case.
In my view, the Victron technicians should now have enough information to reproduce and resolve the issue
Most likely not. There certainly are Canbus BMS that use 250kbit/s but the majoroty uses 500kbit/s. So one Cambus on the Cerbo would run 250kbit/s with VE.Can and the other 500kbit/s with BMS Can
I’ve just built and configured a LiFePo kit. You can also set the baud rate on the BMS. If I wanted to run the battery on my MultiII GX without Cerbo, I could connect it to the 250 kbit CAN interface along with the solar controllers. However, as I already have the Node-RED process for battery aggregation running, I’ve connected it via a third SmartChunt, just like the two other batteries.
I’ve just been having a browse through the forum again and found someone else @NosAtVictron who’s having the same problem. Unfortunately, I can’t reply to your chat message anymore, so here’s the answer: You can find firmware version 3.13 at:
You may need to be registered as a Victron Professional to view this.
Thanks for tagging me @ThomasManthey. Yes, I had this issue when I upgraded to 3.15. Then I continued to have this issue when I upgraded to 3.13. You can see my previous post here:
There’s two systems that I setup that have this issue. I troubleshooted it at the time, but since have downgraded the MPPTs to v3.13 on both. Honestly, I gave up on trying to upgrade to newer firmware versions due to no interest or actions from Victron representatives. But let me know if I can help in any way now.
Then perhaps it isn’t exactly the same problem after all.
I’ve already changed my account status from end user to installer in the hope that Victron will give this issue higher priority. I just want to be able to benefit from the improvements to the charge controllers, and if you tell me to use GX version xx, I’d be happy to reconfigure my Node-RED. But all the combinations I’ve tested on my CerboGX have exhibited the same behaviour. From V3.15 onwards, the GX controllers are reduced to 0 charging power after connection. So now I’m waiting for Victron once again.
I got attention for you but when they asked to use remote access via VRM - the toolset they need and use to help solve issues remotely - you refused to enable it, insisting they build a test lab and try magically recreate the issue.
Since that went nowhere, there is little chance of getting further attention and I gave up trying to help.
If you want help, help us to help you.
Until then there is little that the community can do you as it is way beyond our control, and changing a user status will make little difference.
Installers understand that support is provided via their supplier, not the community.
I was afraid of that. But if I have no control over who does what on my system and when, the likelihood that things will be better afterwards than they were before is, in my view, very low. In the chat thread above, @Alex Pescaru asked questions about data and received answers. Why don’t you feel able to do exactly the same? If you tell me which logs you need, I’ll provide you with the data. This business about the VRM portal is just an excuse!
Hi @Nick,
I haven’t ruled out setting up a VRM connection in principle, but then I wouldn’t be able to see who’s making changes to my system. As the Victron documentation is patchy and sometimes contradictory, I’m very pleased to have got my system up and running as it is.
As far as I know, there is no complete backup including all settings, so that I can revert things myself if necessary. Logically, however, this is only possible if I know what has been changed. I’d be happy to give you VPN access to my system, provided any changes are discussed with me and approved by me.
It is rather strange that a company like Victron offers a 5-year warranty on its solar charge controllers, yet releases the software almost ‘blindly’ without carrying out a final test on the hardware (ideally an automatic test on the hardware).
