Cerbo GX - Venus large rebooting

My Cerbo GX is rebooting and I would like to learn how I can collect the correct logs to find the reason to report it to the community.

Can someone tell me what is the correct procedure to do so?

Thanks!

It usually happens when CPU use is really high.
You can see also on the vrm advanced d bus round trip as well.

There are a couple deeper ways to look at the uptime on this thread here if you know how to ssh.

Check how full the storage is as well

Thank you!

Most what I could so far understand is that Node Red may be too much for the standard Cerbo GX device.

This said, do you know if there is any implementation where we can install Node Red on a, lets say, raspberry, that would then do its job? My question here is if it could be possible to off load this function (Node Red) into another device, saving the processing power and memory of Cerbo GX to what it was designed for.

And yes, you may suggest any forum/place where I could freely discuss this approach.

Cheers!

Or the flows need to be optimised a bit to take the load off the cpu.
I have a fairly large install running on the cerbo. Its fine

You can install Venus os on a pi and use the node red instance to control the system with the cerbo with the system as well (on the same network). That way you have all the same options available.

The flows that I have are quite small and simple, look:


That is it, nothing else!

Now, by other hand, going over several logs, in/var/log/messages, I saw a lot of:

May 12 07:47:41 einstein user.notice kernel: [81864.017846] mcp251xfd spi0.0 vecan1: CRC write command format error.
May 12 10:41:08 einstein user.notice kernel: [92271.874043] mcp251xfd spi0.0 vecan1: CRC write command format error.

I am afraid this may be the source of the problem. On CAN-bus 1 I got the BasenGreen BMS:

Any clue about what may be happening?

@lxonline, is this kind of error a subject that I should request help here or in the Venus OS github?

I have a question as to why anything would need to be written to the battery can?

Would the battery sending information or requests not receiving anything?

I got the very same question as it does not make sense. The BMS should just send information but, in some how, it is more like that the VCAN controller needs to write something and it is failing to do so. I could check that when it happens the CPU goes very high and this is also related to the reboots.

Now, looking into the Venux Linux source code, if you do:

git clone https://github.com/victronenergy/linux.git
cd linux
grep -rn "CRC write command format error"

Then you get:

drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c:1448: netdev_notice(priv->ndev, "CRC write command format error.\n");

So the message comes from the mcp251xfd driver, that is the VCAN controller.

At this point I really stopped! Too complex for me to analyze. I guess this can only be responded by Venus developers.

Notice that the system will fail this CRC, sometimes reboot. But it keeps working, what is good.