VEdirect-interface crashes since v3.8021

DIY
, , ,
1

vedirect-interface crashes since v3.8021 (first crash 4 min after update). Rollback to v3.731 does not fix. v3.72 was stable for 83 days. Both MPPTs affected simultaneously. svc -u recovery needed.

Date time notes
2026-02-19 20:17–21 MPPT FW update: 1.68->1.74 a 3.16->3.18
(83 days ok) v3.72 stabile ✓
2026-05-11 14:56 Cerbo GX: v3.72 → v3.80~21 (beta)
2026-05-11 15:00 #67 mppt error— 4 min po FW update!
2026-05-13 20:54 Rollback: v3.8021 → v3.731
2026-05-14 17:36 #67 mppt error (v3.73~1 the same bug)
2026-05-29 07:01 + 11:32 #67 ×2
2026-06-01 15:45 + 19:55 #67 ×2
2

Hi,

This is not vedirect-interface crashing. This is an error coming from the MPPT, namely error #67 BMS missing. This means that at one point, the MPPT was receiving BMS information. This fact was stored by the MPPT. Then the GX stopped sending BMS information (for whatever reason) and now just to be safe, the MPPT stops charging (as it does not know how much is is allowed to charge) and shows error #67.

To solve this, there is a “Reset” button in the BMS control settings menu when connecting to the MPPT.

With kind regards,
Thiemo van Engelen

3

Thank you for the explanation. After deep investigation I can share a detailed timeline which may help others facing the same issue.
Setup:
• Cerbo GX, Venus OS v3.73~1
• SmartSolar MPPT 250/70 rev2 VE.Direct (FW v1.74) — instance 279
• SmartSolar MPPT VE.Can 250/70 rev2 (FW v3.18) — instance 280
• 6× Pylontech US5000/US3000C (23 kWh), DVCC enabled
• Fronius Symo 4.5 AC-coupled

Key findings:

  1. v3.72 was completely stable for 83 days after MPPT FW update
  2. The first #67 appeared 4 minutes after upgrading to v3.80~21 — clearly a regression introduced in that build
  3. Rolling back to v3.73~1 did not resolve the issue — v3.73 shares the same problem
  4. During long outages, vedirect-interface entered daemontools “down” state (not just crashed) — svc -t had no effect, svc -u was needed to recover
  5. DVCC is enabled — MPPTs receive BMS control from Cerbo, which is why they throw #67 when communication is interrupted
    What helped:
    • BMS control Reset via VictronConnect on both MPPTs — as suggested by Victron support. Monitoring to confirm if this resolves it permanently.
    • Node-RED watchdog running svc -u on both vedirect-interface services as automatic recovery fallback
    Question for Victron:
    What changed in v3.80~21 (and carried into v3.73) regarding DVCC/BMS communication to VE.Direct devices? Is there a fix planned, or is rollback to v3.72 the recommended path?