I don’t have a VRM account yet. What’s the point of it?
Allows for remote support and troubleshooting
To know exactly who is doing what on my system and when, I prefer to use WireGuard VPN access.
Surely it won’t be a problem for Victron to detect a fault using two MPPT-CAN charge controllers and a CerboGX.
As well as a remote support function, VRM logs data from the Victron system. This is what an engineer will want to look at first.
If you don’t want to enable VRM for remote support, I would suggest getting in touch with someone locally who has experience with Victron systems and asking if they would be willing to do an on site physical inspection.
Maybe a 2-3 minutes log on the can0 could be of use here?..
Of course when it’s not working properly, although another one from a working system could be good for comparison.
candump can0 …
Ok, thats no problem. If you could provide me the commands Im using on the GX commandline.
Dear Mr Stewart, I do find that a bit rude. I’m running a power generation system here, so a bit of respect and deference wouldn’t go amiss. I’m very glad I chose Victron and set up and operate the system this way. With power outputs like this, you really need to know what you’re doing to avoid setting my house on fire. Above all, following these incidents, I would refuse to be your beta tester if you don’t even have a test bench with the basic equipment needed to reproduce this simple error.
That is the reality of the matter, to get engineers to connect remotely will require VRM access, you can remove it afterwards though it has many options now to disable access as needed.
If this was an obvious issue it would have been found in initial testing, or subsequently in the last couple of years. The lack of further reports would indicate there is something unique in your environment and the few that did respond about this years ago.
Expecting Victron to build a lab to try recreate your issue with little insight to your environment is unrealistic.
Putting barriers up to people helping you will not get this issue resolved.
Good luck, hope you come right.
Hi Alex, I’m sure we can identify the problem this way too. Here’s the log file:
CanDump20260406.txt.zip (203,7 KB)
I’ve prepared another log for you here. All the solar controllers are running on V3.13. I started the log file before updating solar controller A from 3.13 to 3.18 and then left it running for a few minutes after the update.
The physical order on the bus, as seen from the GX, is G, B, C, F, E, A, D with termination. As you can see, controller A is still in the list, but is no longer controlled by the GX and no longer has any charging power.
CanDump20260406_A-V3.81.txt.gz.zip (207,9 KB)
Generally all is OK on these logs with a single observation.
All devices are complying with CAN2.0B and J1939 specs.
There is something that is emitting on the same 29bit bus some 11bit frames that resemble with a “master” device broadcasting inverter presence for a BMS to report its data.
BTW…
How is defined the CAN port of the GX device?
GX device → Settings → Services → VE.Can port → CAN bus profile?
If it’s VE.Can & CAN-bus BMS, try the other one, VE.Can & Lynx Ion BMS
Hi Alex, I wasn’t expecting to hear from you this morning. Thank you very much for your analysis. For the test, I used the VE.CAN CAN-bus BMS profile, as shown in the image.
I’ve now selected a different CAN profile and will repeat the test.
Regarding the message you saw, I imagine it might be one from the ESS. It must be some sort of gateway function, as is also seen with other interfaces. Only the Multi (MultiGX) and the charge controllers are connected to the physical bus.
So here’s the first part of the logs, with version 3.13 on all controllers and the VE.CAN + Lynx profile.
CanDump20260407_A-V3.13_VE.Can+Lynx.txt.gz.zip (488,2 KB)
Indeed those 0x3XX IDs were there because of the profile selected and now are gone.
The rest is the same.
But did you tried to sum-up all those powers and see if they check?
What I am trying to say…
If at some point the total “consumed” power is 7000W, then maybe A+B+C+D+E+F+G=7000 and A=B=C=D=E=F=G=1000.
Or…
A+B+C+D+E+F+G=7000, but A=2000, B=0 and C=D=E=F=G=1000 and the sum is still 7000, even if one is 0.
Hi Alex, I’m really looking forward to seeing the results of the test today. The reason is that my colleague has also set up a Vitcron system and he now has the same CAN profile settings as me. He’s running version 3.16 on the CAN charge controllers without any issues, whereas for me, with the other CAN profile, it didn’t work at all – or only with V3.13.
What a shame! I’d really hoped that after updating controller A to V3.18, it would still support this CAN profile. It seems, however, that its performance has definitely been reduced. But as it works just fine for my colleague, I’ll update the other solar controllers to V3.18 as well and hope that they’ll all work properly again.
Do you have some another scripts that are running on Cerbo?
I can see something that it’s getting the temperature of each controller. Probably through vreg utility…
Either a shell script or a node-red flow… Is that right?
No offense, but the advice from others was to try to run it clean.
That’s right, I’ve used Node-RED to set up a cyclical query for the temperatures of all the solar controllers so that I can log these values. I’d had problems with this before; before I converted all the solar controllers to fan-based ones, they used to get so hot that they couldn’t operate at full capacity.