Cerbo GX - ESS Manager periodisch nicht erreichbar

Hallo Zusammen,

ich habe ein Victron System mit Multiplus-II, Cerbo-GX und Pylontech-Speicher installiert. Für die Messung am Netzanschlusspunkt wird ein Shelly verwendet. Die Messwerte des Shelly 3EM werden über WLAN in den Cerbo GX (ebenfalls per WLAN eingewählt) gespeist. Außerdem laufen dort auch die Werte von einem SMA Tripower-Wechselrichter rein.

Nachdem selbst die Oberfläche des Cerbo GX in Version 3.42 nicht mehr erreichbar war und der Cerbo jeden Tag mehrmals vom Strom getrennt wurde um ihn neuzustarten, habe ich nun zurück auf Version 3.41 gewechselt. Dort läuft der Cerbo und ist erreichbar. Allerdings setzt manchmal der ESS-Manager aus und das Interface am Cerbo sieht wie auf dem Screenshot aus. Nach einem Neustart über die VRM geht es dann wieder für 1-2 Tage und der Fehler fängt wieder von vorne an.

Hatte jemand schon einmal das Problem oder kann Hilfestellung geben?
Vielen Dank

Klingt nach einer fehlerhaften Integration des Shelly. Da laufen dann wohl die Speicher voll und der Cerbo streikt. Da kenn ich mich aber nicht aus, aber vielleicht hilft es bei der Lösungssuche

Ich habe die 3.42 auf ein PI 4 mit einigen Shellys problemlos am laufen. Check doch einmal, ob die irgendein Script den DiskSpeicher voll schreibt. Logge Dich dazu am Venus ein und setze den Befehl

df -h

ab. Interessant sind vor allem die “Mounted on” Pfade / und /data Linux mag es nicht, wenn ihm der Speicherplatz auf der Disk ausgeht.

Schau mal in den Threat “Statistik stimmt nicht. Hätte gern DESS” ähnliches Problem

Danke für den Tipp. Gibt es eine Möglichkeit die Abtastrate von DBUS irgendwie zu reduzieren oder die Schreibvorgänge im Cerbo zu reduzieren? Hatte den Shelly, go-eCharger und SMA Tripower-Wechselrichter damals über ein DBUS-Script in den Cerbo eingebunden. Weiß aber nicht ob man da noch viel selber einstellen konnte.

Hi,
der Pfad "dev/mmcblklp5 ist mit 4,6GB zu 100% used (voll) und mounted on /data

Wie kann ich dies nun behebene?

Außerdem habe ich rausgefunden das im dbus des shelly 3EM die current.log sehr sehr groß ist

Ich habe jetzt einmal das loglevel im dbus des shelly 3EM von “error” auf “critical” gestellt und das log-file einmal gelöscht. Hoffe, dass mit critical nicht mehr so viel in die Datei geschrieben wird

in das Verzeichnis /data wechseln (cd /data) und dort du -d 1 -h absetzen, das zeigt Dir dann, in welchem Verzeichnis wieviel verbraucht wird, in das Verzeichnis wechseln und dort dann zum Beispiel mit ls -l die einzelnen Files anzeigen lassen. Sollte ein .log File der Verursacher sein, kannst du das mit rm FileZumLöschen entfernen.

lösche es mit rm current.log (nicht vergessen, vorher in das Verzeichnis zu wechseln, funktioniert mit cd und dem Verzeichnisnamen)

Danke. Das selbige habe ich auch für den go-eCharger (wallbox) dbus getan. Gibt es eine Einstellung gar kein Loggin im dbus zu machen? Vielleicht LogLevel=none ?

Das hängt vom jeweiligen Script ab, je nachdem was der Programmierer gemacht hat.

hallo,
man kann die logs auch dauerhaft eleminieren. entweder mit ln -s /dev/null logfile oder mit mknod ein null-device mit dem namen des logfiles-erstellen.

es ist auch moeglich, einen cron-job anzulegen, der das logfile regelmaessig leert.

generell sollte man jegliches loggin in eine datei unterbinden, solange man da nicht fuer die fehlersuche braucht.

tschuess

Die CronJobs verschwinden leider bei jedem Update. Aber das Umleiten auf /dev/null mit einem symbolic link ist eine coole Idee, Danke

hallo,
also ich habe einmal an cron-job auf einem cerbo angelegt, der war auch nach einem update noch aktiv.

allerdings ist die partition, auf der die cron-jobs gespeichert werden, schreibgeschuetzt. man muss den schreibschutz vor dem anlegen des cronjobs deaktivieren und danach wieder aktivieren!

wie hast du den cron-job denn angelegt ?

das mit dem null-device habe ich auch schon gemacht, wenn ich keine moeglichkeit gefunden habe, ein logging zu deaktivieren. das funktioniert unter linux naemlich immer.

tschuess

Ganz oldschool mit crontab -e :grinning: