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.
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.
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.
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 ?
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.
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.
