question

The error 67 is reporting that its loosing the BMS connection to the cerbo, I have had this also (but not with rec units as we dont use them so cant comment on that BRAND)

but for us it was a comms error and in particular interference with the data coming to the Cerbo. we moved the data cable away from ANY OTHER CABLES and if we crossed any cables then we did that at at right angles we also changed to Cat6 cable for better shielding.

or try reducing the data cable length.

just some thoughts it may help it may not

Thanks for your reply, Paul.

But in my case the system was working for several years, without any problem. Only, since the SmartSolar was changed from 150/50 (also connected via same cable VE.Direct) to 250/85 the trouble started.

Also I have no Tx/Rx errors of ABMS and no interruption of data transmission (as per graphics on VRM). So I believe it has something to do with the Solar Charger.

May anybody from VICTRON could login to the system and check the configuration?
Is there any possibility to prevent the SolarCharger switching to "external control" when connected to Cerbo in conjunction with a BMS?

As for external control, that is how the system is designed to work, you want DVCC coordinating charging so everything works nicely together, though if you understand the consequences of turning it off nothing should prevent you doing so.

All, this is still unsolved and I am not understanding, why this one is not picked as it's affecting several users including those using the Cerbo, so not Raspberry specific!

With 2.80 it seems changes have been made which first caused the #67; an immideate v2.82 was shot quickly to go for the CAN issues but I see lots of #67 posts still.

As reported several times, I (and others) have this behaviour repeatingly, most of the times the setup works as expected, but several times a day, one of my two MPPTs (always only one, the other one stays connected) gets error #67 and turns into standby. After rebooting or reconnecting, it works again. (exchanged cables, not the issue)

I am on almost latest v3.00 ~xx, same error when I was on 2.89. BMS is REC BMS 16s, connected via CAN HUT (tried several different models, same error applies always). Both MPPTs connected via USB / VE.direct cable. All devices up-to-date.

Mostly starting in the morning, but not "on sunrise / MQTT operation start" it happens later, already in operation:

Two questions: @Guy Stewart (Victron Community Manager) , hope you might be able to advise?

1. Here are parts of two log file and it seems, an "increase of allowed feedback time" within VENUS could solve the issue as problem comes from a timeout:

Question to Victron: Can I as a superuser somewhere adjust the allowed reply timing for the BMS before getting a timeout error? (I remember another issue with the EM24 where increasing allowed threshold was exactly the solution!)

GNU nano 4.9.3 @4000000063f9cfaa3884c9c4.u @4000000063f9529d17a4d564 *** starting can-bus-bms ***
@4000000063f9529d181a305c can-bus-bms v0.39
@4000000063f9b53c3571a5f4 *** CCGX booted (0) ***
@4000000063f9b5541e76d20c *** starting can-bus-bms ***
@4000000063f9b554307c123c can-bus-bms v0.39
@4000000063f9c2111e1433f4
@4000000063f9c2111e14477c -------- dumping backlog -------
@4000000063f9c2111e145334 INF.canhw_drv: adding driver socketcan
@4000000063f9c2111e145eec INF.: Using can8
@4000000063f9c2111e1462d4 INF.can-bms: Product ID from settings: B022
@4000000063f9c2111e147274 INF.can-bms: dbus_service: registering name com.victronenergy.battery.socketcan_can8 (yes, I am using can8 in order not disturb any pre-reserved can1, 2, 3 interfaces after latest FW Changes, but same error w/ can1, 2, 3, also)
@4000000063f9c2111e148214 INF.can-bms: Manufacturer: 'REC-BMS'
@4000000063f9c2111e148dcc ERR.bms: bms timeout
@4000000063f9c2111e14959c INF.can-bms: disconnecting from dbus
@4000000063f9c21c1d87518c INF.can-bms: dbus_service: registering name com.victronenergy.battery.socketcan_can8

____________________

another logfile, same applies for ttyUSB1 as well:

@4000000063fdf737328f2744 *** starting vedirect-interface ***

@4000000063fdf737340d8214 vedirect-dbus 3.71

@4000000063fdf73a346e7664 -------- dumping backlog -------

@4000000063fdf73a346e821c 000.096 INF.task: using ttyUSB0 as unique service part

@4000000063fdf73a346e91bc 000.096 INF.VE.Direct: Setting status to VdUnknown

@4000000063fdf73a346ea544 000.106 INF.settings: connected to settings on dbus (com.victronenergy.settings)

@4000000063fdf73a346ec86c 003.006 ERR.values: timeout connecting device

@4000000063fdf73a346edfdc 003.006 INF.task: done in 003.006

@4000000063fdf7461bcd4194 *** starting vedirect-interface ***

@4000000063fdf7461d522444 vedirect-dbus 3.71

@4000000063fdf7491d7aca84

@4000000063fdf7491d7ade0c -------- dumping backlog -------

@4000000063fdf7491d7ae9c4 000.092 INF.task: using ttyUSB0 as unique service part

@4000000063fdf7491d7af964 000.092 INF.VE.Direct: Setting status to VdUnknown

@4000000063fdf7491d7b051c 000.099 INF.settings: connected to settings on dbus (com.victronenergy.settings)

@4000000063fdf7491d7b18a4 003.001 ERR.values: timeout connecting device

@4000000063fdf7491d7b245c 003.001 INF.task: done in 003.001

@4000000063fdf757065bc4fc *** starting vedirect-interface ***

@4000000063fdf75707d1bb5c vedirect-dbus 3.71

@4000000063fdf75a0b576b64

2. In the meantime: As a reboot of Venus solves the problem: is there a "MQTT-Write" available to reboot Venus automated using Node-Red? I am just bored of rebooting my ESS 10-20 times every day manually to be able to harvest.

BTW: another user mentioned, the Raspberry might be at its limit and cause the timeout. I have then built a monitor-dashboard in Node-Red; performance of raspi is not an issue, as it's max. going to 20% in peak if any.

Thank you Alexandra! I will do. As the question was raised from a Cerbo-user and saw the same issue with others, I thouhgt it's more a general issue and not related to "unsupported" setup.

Let's see where we end up with ;)