Problem mit dem Cerbo-GX

Hallo Zusammen,

ich bin ratlos und benötige Hilfe.

Gestern Abend 20:00 Uhr ging mein Victron System in Durchleiten, nach einem Neustart des Cerbo funktioniert es für eine gewisse Zeit (ca 1h) wieder, dann kommt aber immer wieder das gleiche Problem. Das System läuft nun ca. 7 Monate ohne Probleme, bis gestern.

Wenn der Fehler auftritt werden auch keine Daten mehr über MQTT oder an das VRM gesendet.

Die Benachrichtigungen sind leer, und ich kann keine Fehler im VRM Portal auslesen.

Ein Neustart korrigiert das Problem immer wieder nur für kurze Zeit.

Dann geht das System wieder in "durchleiten"

Auf dem Cerbo Display sehe ich auch keine Fehlermeldungen.

Vermutung war zunächst, dass der Kontakt mit dem EM24 ausfällt, aber der meldet trotz "Durchleiten" weiter Werte.

Ob der Kontakt kurzzeitig ausfällt kann ich nicht sagen.

Mein Setup ist folgendes:

3 x Multiplus 3000

4 x Pylontech US5000

23KW/P gemischt aus Solar Edge / Hoymiles / Victron MPPT 250

EM24 Ethernet als Zähler des Hausverbrauchs

EM24 / 2 x ET112 als Zähler der PV Anlagen

Cerbo GX Firmware v3.01

Was habe ich schon probiert:

Kabelverbindungen gecheckt, passt alles

SSH auf den Cerbo

ein df über ssh zeigt:

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/root 981568 865444 45636 95% /

devtmpfs 465376 4 465372 0% /dev

tmpfs 515040 952 514088 0% /run

tmpfs 515040 564 514476 0% /var/volatile

/dev/mmcblk1p5 4859040 4842656 0 100% /data

tmpfs 515040 952 514088 0% /service

ein top zeigt:

Mem: 504516K used, 525568K free, 3032K shrd, 23900K buff, 130588K cached

CPU: 55% usr 7% sys 0% nic 35% idle 0% io 1% irq 0% sirq

Load average: 0.92 1.12 1.38 3/298 20025

Hier noch ein paar Bilder:

Was kann ich tun ?

Gibt es eine Logdatei wo ich sehen kann was los ist ?

Vielen Dank schon mal für eure Hilfe.

Ich habe jetzt mal alle PV-Meter (einen EM24 und zwei ET112) abgezogen, vielleicht kann ich damit den Fehler etwas eingrenzen.

Verliert denn der CERBO die Netzwerkverbindung? Bist du da mit LAN oder WLAN verbunden?

Kannst du die remote-console per fest vergebener IP-Adresse aufrufen?

Was hat sich denn gestern Abend geändert, oder kam das einfach so?

@saugnapf

Der Fehler kam einfach so, ohne Änderungen am System. Der Cerbo verliert nicht die Netzverbindung er stoppt nur Daten an das VRM Portal zu senden und geht in Modus Durchleiten.

Ich hab mir eine Alarmmeldung eingestellt wenn der Cerbo nicht mehr an das VRM berichtet, daher bekomme ich immer Meldung.

Der Cerbo ist per LAN angeschlossen und ist auch erreichbar im LAN über die IP Adresse.

Als der Fehler das erste mal auftauchte, gestern Abend, war er nicht mehr per LAN erreichbar, daher bin in zum Gerät und wollte am Display schauen was los ist. Das Display war schwarz und war auch nicht zu erwecken. Der Cerbo selbst schien aber noch zu Arbeiten, da die LEDs wie üblich blinkten. Ich habe dann die Stromzufuhr zum Cerbo getrennt und kurz gewartet, danach ist er normal gestartet. Display und LAN funktionierten danach wie gewohnt.

Seitdem bekomme ich nach ca 60 - 90 min immer eine Meldung dass er nicht mehr an das VRM berichtet, dann schaue ich drauf und er ist wieder im Modus "Durchleiten".

Ein Neustart behebt das Problem für die nächste Periode.

Ich bin echt völlig ratlos. Es muss doch eine Log Datei geben, wo aufgezeichnet wird was er für Probleme hat und warum er in den Modus "Durchleiten" wechselt.

Über MQTT lasse ich mir einige Daten an mein Home Assistant melden, diese Meldungen bleiben dann auch aus.

Ich hab mir jetzt ein Skript geschrieben dass per Ping die Erreichbarkeit prüft und melde wenn der Cerbo / EM24 im Lan nicht mehr erreichbar sind. Das scheint bisher nicht der Fall zu sein.

Bis jetzt war ich so zufrieden mit dem Victron Aufbau, an dem ich echt richtig lange gebastelt hab. Aber irgendwie ist man ja jetzt auch ein Stück weit abhängig von dem System, wenn da was nicht geht und ich kann nicht ergründen warum, macht mich das verrückt.

Kannst du mal einen screenshot einstellen, von dem Zustand, wenn der MP2 auf Durchleiten ist?

Der EM24 ist per ethernet verbunden, oder?

Wenn der MP2 auf Durchleiten geht, würde ich als erstes einen Fehler in der Kommunikation EM24 - MP2 vermuten.

Dann würdest du in der remote-console die drei Phasen bei "Netz" und "AC-Lasten" nicht mehr sehen.

Das scheint bei dir aber nicht der Fall zu sein? Also die Daten des EM24 kommen an?

Die BMS-Verbindung ist auch stabil?

@mdkeil

Ja ich denke schon, die Pylontech sind in unmittelbarer Nähe zu den Multiplus und dem Cerbo, es ist alles mit original Kabeln verbunden.

Ich bekomme auch keine Fehlermeldungen aus der Richtung.

Kennst du eine Möglichkeit die Verbindung zu logen ?

Also Unstimmigkeiten aus einem Logfile auszulesen ?

Was logging angeht kann ich keine Tips geben.. aber schonmal die aktuellste stabile VenusOS versucht?.. die 3.01 ist ja schon was älter.

@saugnapf

Leider kann ich den Screenshot gerade nicht machen, da mit meinen Modifikationen gestern, die Anlage bis jetzt wieder normal läuft.

Folgendes habe ich gemacht:

Heute Nacht um ca 0:30 Uhr:

Alle ET112 Datenleitungen die per USB Kabel angeschlossen waren, getrennt. (waren 2 Stück, einer mit 1m Kabel und einer mit ca. 20m Kabel)

Den MPPT 250 getrennt, Datenleitung und Plus/Minus Kabel.

Die Netzwerkverbindung zum EM24 Erzeugungszähler Carport getrennt.

Cerbo neu gestartet.

Ergebnis: Anlage läuft seitdem normal.

Heute im Laufe des Tages habe ich erst den MPPT 250 wieder verbunden.

Nach ein paar Stunden den EM24 Ethernet Carport wieder verbunden.

Nach ein paar Stunden den ET112 mit 1m Kabel wieder verbunden.

Ergebnis: Anlage läuft normal bis jetzt.

Was noch fehlt ist das USB Kabel der Datenverbindung zum ET112 der ca 20m entfernt ist.

Da liegt denke ich der Fehler, kann ich aber noch nicht belegen.

Warum hab ich das gemacht ?

Mir ist aufgefallen, dass der Cerbo immer in den Modus "Durchleiten" geht wenn irgend ein Zähler die Verbindung verliert.

Wie komme ich darauf ?

Ich habe vor ein paar Monaten abends an meinem Carport noch eine Leitung verlegt, dazu habe ich das Carport komplett vom Strom getrennt, und somit auch den EM24.

Nachdem ich fertig war habe ich alles wieder verbunden und mir ist aufgefallen, dass der Cerbo seit dem Verbindungsabbruch "Durchleitet"

Ein paar Wochen später habe ich noch einen FI/LS in die Unterverteilung eingebaut um das Licht unabhängig von dem eigentlichen RCD zu machen.

Dazu auch wieder Strom getrennt ...... und sieh da, das gleiche Verhalten, der Cerbo geht in "Durchleiten"

Ein Neustart des Cerbo hat das Problem beide Male behoben.

Was ich nicht angefasst habe ist der EM24 Ethernet, der als Grid Zähler konfiguriert ist und an meiner Hauptverteilung sitzt.

Ohne es genau zu wissen, behaupte ich mal dass dieser problemlos funktioniert.

Also Stand heute 23:05 Uhr:

Mir fehlt zwar der ET112 mit 20m im System aber die Anlage funktioniert.

Daher glaube ich, dass dieser das Problem ist.

Morgen werde ich den mal wieder per USB Kabel verbinden und beobachten was passiert.

Vielen Dank schon mal für eure Ideen und Fragen.

@mdkeil

Hab ich auch schon überlegt, aber bisher war ich der Meinung, never change a running System.

Wenn ich die Firmware des Cerbo aktualisiere, muss ich dann nicht auch die Firmware der drei Multiplus anpassen ?

Wenn ja, welche Reihenfolge ist da ratsam ?

Ich bin eher von einem Fehler im System ausgegangen, da ich der Meinung bin, dass diese Victron Komponenten problemlos laufen müssen bis sie umfallen.

Mein Solar Edge System läuft seit vier Jahren ohne ein einziges Problem, das erwarte ich eigentlich auch von Victron.

Natürlich bietet das Solar Edge nicht so viele Möglichkeiten des eingenen Zugriffs, aber es läuft.


[quote data-userid="13444" data-postid="197872"]

Wenn ich die Firmware des Cerbo aktualisiere, muss ich dann nicht auch die Firmware der drei Multiplus anpassen ?

[/quote]

Jein, welche Fw. läuft dort denn aktuell?

Ich glaube eigentlich nicht, dass es am ET112 liegen kann, da pv-zähler keine regelungstechnische Relevanz haben..

Du machst das systematisch, und wirst den Fehler sicherlich eingrenzen können. :+1:

Bin gespannt, ob es dann der ET112 war. RS485 sollte mit 20m eigentlich keine Probleme machen... Hast du da einen USB-HUB am CERBO angesteckt?

Wenn ja, aktiv, passiv? Bei mir läuft das passiv ohne Probleme, aber i.d.R. wird aktiver HUB empfohlen.

Und du weißt sicher, dass der USB-Port am CERBO neben dem HDMI-Anschluss nicht für Kommunikation geeignet ist... :wink:

Insgesamt würde ich auch nicht von einem VICTRON-Problem ausgehen, eher etwas in deiner Peripherie.

Nun ist der Fehler wieder aufgetaucht.

Diesmal habe ich aber noch eine Fehlermeldung bekommen:

Warum liefert der MPPT 250/60 diese Meldung ?

Der Grid Zähler liefert weiterhin plausible Werte.

@mdkeil: Auf den Multiplus läuft Version 492.

Welches Monitoring-BMS/ Controlling-BMS ist unter Settings/System Setup / DVCC eingestellt?

Bei meinem MP2 läuft seit Inbetriebnahme die 498.

@mdkeil Autom. ausgewählt: Pylontech battery on CAN-bus

Wenn ich mir nochmal alles so durchlese, könnte auch der Cerbo selbst das Problem sein.. kannst du mal auf der CL mit top schauen, welche Prozesse die Hauptlast verursachen? Was sind denn in VenusOS die relevanten Systemlogs? Vielleicht läuft auch die root-Partition voll.

sonst mal unter /var/log/ schauen..da gibt es ja diverse Unterordner mit entsprechenden Systemdiensten..

Hast du schonmal versucht, ob das Problem auch kommt, wenn MQTT deaktiviert ist?

Der Fehler, dass der Cerbo stehen bleibt und auf "Durchleiten" geht, kommt mir bekannt vor.
Das passiert meistens, wenn die Root-Partition voll ist.
Also per Console auf den Cerbo einloggen und dort mit
df
das Dateisystem abfragen. Sollte "root" bei 100% stehen, dann den folgenden Befehl anwenden:
/opt/victronenergy/swupdate-scripts/resize2fs.sh
Das gibt Platz für das Root-Verzeichnis und das Problem sollte sich erledigt haben.

Ich denke auch dass der Cerbo das Problem ist.

In meinem ersten Post hatte ich bereits df und top gepostet. Noch mal aktuell nachdem das System wieder in "Durchleiten" gegangen ist: Df und Top zeigt folgendes:

Du scheinst auch noch Überreste von einem shelly-dbus-treiber am Laufen zu haben.. ich denke, eine saubere Neuinstallation wird das Problem vermutlich beheben.