question

Updating this one, as I have been asked to move to "Mods" and even the BMS manufacturer (REC BMS) could not help me.

Long story short: several times a day, one of my two BlueSolar MPPTs (150/45) loses connection to the BMS with error #67. (always only one of two has the problem! Exchange of cables is not the solution)

Both MPPTs are connected via VE.direct USB cable to the Raspi3b, running Venus OS 3.00 ~xx. All other devices on latest.

Only "replug", "Venus reboot" or "Bluesolar reset" solves the issue until next occurance.

Log files indicate a "Timeout":

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

My questions:

1. Might an "increase of allowed feedback time" within VENUS solve the issue as problem comes from a timeout? If so, where to adjust? For a EM24-related problem (WIFI) this was the solution also.

Update : I played around in the meantime and had a full day without any error #67

(but I as a DAU (engl. LUSER/PEBKAC) ;) might not know what exactly I am doing here, so I need advise:

Changed a few timeout values in /usr/share/dbus-1#/session.conf to:

Again: not a single outage today, but need to monitor further.

2. I know there is an automated reboot if VENUS cannot connect to VRM portal implemented, but:

As a reboot of Venus solves this specific 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 and rebooting the whole Raspi several times a day is not the preferred solution.

Just to add: even though I seem to have an unsupported environment, I saw the same error in posts where others used the Cerbo instead a Raspi. I am also aware that the first time, Error #67 occured was v2.80, where Victron made some changes to the image:

https://community.victronenergy.com/questions/118573/does-gx-firmware-280-have-a-abug-with-respect-to-m.html

Maybe the quickly provided repair v2.82 does not consider "Multiple MPPTs" in one system? Matthijs himself was quite active on this one trying to help.

Again, help/advise/insights are much appreciated, I tried to get help from REC BMS, but they've gone totally quiet on this one and cannot help.

Thanks in advance!