im Vordergrund, im Firefox Browser zur gleich Zeit auch im Vordergrund, aber das Fenster war nicht aktiv.
hallo,
also die oeberflaeche war sichbar, nur darauf kommt es an. wenn ein anderes tab ausgewaehlt ist oder ein fenster komplett darueber liegt, dann ist naemlich die cpu/gpu-last niedrig.
aktiv sein muss das fenster nicht, nur sichtbar.
tschuess
Beide Browser Tabs sichtbar (die Werte haben sich auch verändert). Linux, aktueller Kernel (6.14.4-1), KDE als Oberfläche
hallo,
das verwundert mich jetzt aber schon. ich schaetze, ich muss es wohl mal mit allen systemen ausprobieren, ob vieleicht auch die anzahl der angeschlossenen geraete eine rolle spielt.
tschuess
Hallo,
ich würde das Thema gerne nochmal aufgreifen und meine Erfahrungen schildern.
Ich beobachte ähnliches wie @d_ferdi bei einem System von einem Freund (recht großes System: 3 Multis, ESS, 3 MPPT, 2 EM24, Victron Wallbox, 2 DIY-Speicher mit SerialBattery und BatteryAggregator angebunden).Das System lief immer stabil. Seit dem Update vom Cerbo (ein echter Cerbo - kein Raspi) und der Verwendung der neuen GUI haben wir ca. alle 2 Stunden einen Reboot vom Cerbo. Wenn man sich mit ssh draufschaltet und mit top die CPU Auslastung anschaut, sieht man, dass folgender Prozess satte 20% cpu-Last erzeugt:
/opt/victronenergy/gui-v2/venus-gui-v2
Wir haben daraufhin den Monitor (GX Touch 50) vom Cerbo abgesteckt und den Cerbo neu gebootet. Seitdem läuft der Cerbo stabil (zumindest jetzt seit 8 Stunden - wir werden das weiter beobachten).
Wenn man die neue GUI z.B. auf dem Handy öffnet fällt diese CPU Last ja auf dem Handy an. Da ist es vermutlich kein Thema.
Aber der Cerbo in Verbindung mit einem GX Touch 50 mit der neuen V2-GUI scheint ein Problem zu sein (zumindest wenn ansonsten auch noch ein paar andere Sachen dranhängen am Cerbo).
Bedeutet das, dass das man zwingende einen Raspi4 (statt dem echten Cerbo) braucht, wenn man eine solche Anlage mit GX Touch 50 und der neuen GUI-V2 betreiben will?
hallo,
die v2-gui belasten den browser leider sehr stark, das kann auch dazu fuehren, dass er permanent speicher frist, wenn hier noch ein fehler im programm oder im browser ist. die cpu-last selbst macht hoechstens das system langsam, duerfte aber nicht die ursache fuer den absturz und den reboot sein. ich vermute da eher ein speicherproblem.
lass doch auf dem display weiterhin die v1-gui anzeigen, dann sollte das problem auch nicht mehr auftreten.
und was die cpu-last angeht, wenn eine passende grafikkarte verfuegbar ist, wird die anstatt der cpu belastet. aber irgend jemand muss ja die ganze mehrarbeit erledigen.
tschuess
Danke @d_ferdi für die Antwort,
Wir haben mit der alten GUI ein paar Probleme (weißer Bildschirm). Habe gesehen dazu gibt es einen eigenen Thread. Werde ich mir mal durchlesen.
Eine externe Grafikkarte am Cerbo zu betreiben stelle ich mir nicht ganz einfach vor.
Mal schauen wie wir das lösen. Notfalls einen eigenen Raspi der sich nur um das Display kümmert.
Danke!
hallo,
was den weissen bildschirm angeht, so sind da sehr oft zusatzprogramme daran schuld, die installiert sind und sich nach einem update des gx nicht mehr starten lassen. da gibt es auch einige beitraege hier.
tschuess
Hi,
in der V2 ist es die Elektronenanimation was die GPU frist.
Ohne Animation, zwischen 0 u17%, also jedesmal wenn sich ein Wert ändert.
Wenn die Animation eingeschaltet ist um die 70% GPU.
Das ist inzwischen Mode bei den neuen WEB Geschichten das die GPU fressen.
Ist ein Problem wenn keine GPU vorhanden ist u die CPU alles machen muss.
Im Edge brauch selbst der Lade-Gringl die GPU u in Teams sogar die animierten Smileys
Die V2 iat da voll imTrend
sehr richtig; ! die ganze V2 ist überflüssig - es war doch abzusehen, daß dieser graphische Firlefanz Rechenleistung “frißt”, die damit für die eigentlichen Aufgaben des cerbo nicht mehr zur Verfügung steht. Die GUI-V1, zusammen mit packet-manager, GUImods etc ist das, was man benötigt, um die Regelungstechnik zu überwachen bzw zu parametrisieren; das ist ja auch die Aufgabe eines cerbo: Überwachung und Regelung des Gesamtsystems!
Wer graphischen Schnickschnack haben will, der soll sich mit einem externen System die ihn ineressierenden Daten per MQTT vom cerbo schicken lassen und sich seine ‘animated grafics’ selber bauen!
Ich bleibe bei V1!
wünsche noch einen schönen Abend!
J
Nur mal also grundsätzlicher Hinweis: V1 ist für das GX Gerät deutlich rechenaufwendiger als die V2. Das liegt daran, dass das Rendering für V1 auf dem GX Gerät passiert und per VNC Viewer übertragen wird. Bei der V2 GUI wird einmalig die GUI als Download übertragen und danach nur noch MQTT Daten. Das Rendering passiert im Browser. MQTT Daten zu senden erzeugt deutlich weniger CPU Load auf dem GX als das gesamte Rendering. Das ist auch der Grund, warum man keine Veränderungen wie z.B. die GUI Mods in der neuen GUI sehen kann.
Das wird eher das Problem sein.
Wir haben etliche Anlagen verschiedener Größen mit der neuen GUI laufen und haben da noch keine Berichte zu ständigen Neustarts bekommen.
Einiger dieser Fremdsoftware ballert den Speicher des GX Gerätes mit Logs voll. Vielleicht ist das bei dir das Problem und das GX Gerät startet neu um den Speicher frei zu bekommen?
Das Fremdsoftware zu solchen Problemen führen kann ist nix neues.
Wenn die GUI V2 generell Probleme verursachen würde, würde es sie nicht geben.
Die V2 gibt es ja nun offiziell schon seit etwa 10 Monaten und war davor schon einige Monate in der öffentlichen Beta und davor in interner Alpha.
Bin mir nicht ganz sicher, aber ich glaube die GUI ist über HDMI im GX Gerät auch hardwarebeschleunigt, daher funktioniert die V2 auch nicht am rPi über HDMI, weil dort die passende HW-Beschleunigung fehlt.
Hallo zusammen,
Es gibt aus meiner Sicht ein paar Fakten die aus meiner Sicht eindeutig gegen die neue V2-GUI sprechen:
-
Bei der großen Anlage meines Freundes zeigt ein “top” auf dem Cerbo eindeutig hohe CPU-Last:
Wenn man den GX Touch 50 absteckt (das HDMI-Kabel) denn verschwindet der der venus-gui-v2-Prozess und cpu-Last geht um ca. 20% runter.
Dann läuft der Cerbo auch wieder zuverlässig ohne Reboots.Vor dem Update vom Cerbo auf die neue GUI lief die Anlage auch mit GX Touch 50 ohne Probleme.
-
Ich habe selbst ebenfalls eine recht große Anlage mit dem Unterschied, dass ich keinen GX Touch 50 direkt am Cerbo angeschlossen habe, sondern die gui-v2 auf dem Handy oder PC öffne.
Ich habe keine Probleme mit Restarts. -
Klar haben wir (mein Freund und ich) auch Fremdsoftware installiert (serialbattery / batteryaggregator). Das war aber nie ein Problem. Auch die cpu-Last von diesen Prozessen findet man erst deutlich weiter unten in der Liste.
Viele Grüße,
Christian
Aus meiner Sicht spricht eindeutig nichts gegen die GUI V2.
Wir haben mittlerweile sicher dutzende Systeme damit laufen und keinerlei Probleme mit Neustarts.
Wir selbst haben für die Stromversorgung unsere Firma zwei große Systeme.
Jeweils 3-phasig, 4-5 MPPTs, SmartShunt, 2-3 AC Sensoren, CAN-Bus Akku, Victron Ladestation…
Keines der Systeme startet grundlos neu.
Der guiv2-Prozess erzeugt lt. Screenshot 17% CPU-Last. Im Cerbo steckt eine DualCore-CPU, die mögliche CPU-Last liegt also bei 200%. Umgerechnet auf den guiv2-Prozess bedeutet das, er macht ~8,5% der mögl. Gesamtlast aus.
Ich würde sagen, die CPU langweilt sich vor sich hin.
Tut mir leid. Ich schildere nur meine Erfahrungen und Beobachtungen.
Bei Echtzeitsystemen ist 200% cpu-Last ein absolut theoretischer Wert, der nicht berücksichtigt, dass es Last-Schwankungen gibt und sich auch nicht alle Prozesse ideal parallelisieren und auf die cores verteilen lassen.
Du kannst die GUIv2 Animationen in den Einstellungen deaktivieren, das reduziert nochmal die CPU Auslastung der GUIv2.
Einstellungen → Allgemeines → Anzeige & Erscheinungsbild → UI-Animationen: deaktivieren
Meine Anlage besteht aus:
3 x MP2 10k per VE.Bus
1 x MP2 5k per USB MK3
3 x MPPT Laderegler per VE.Direct
3 x RS450 per CAN
3 x Energymeter
2 x Fronius per Internet
1 x Batrium BMS
1 x Smartshunt (5 weitere Akkus)
5 x Microwechselrichter per OpenDTU und Henne49 Plugin
Alles das funktioniert auch mit einem Touch70 problemlos ohne reboots.
Jens
Zum Theme Neustarts: Die Erfahrungen habe ich ebenfalls nur unter Verwendung diverser Fremd-Skripte gemacht. Ganz schlimm waren die Plugins um nen Shelly als PV-Inverter einzubinden. Da hat dann irgendwann der Watchdog auf dem Cerbo “HALT, STOP!!!” gesagt. Generell sollte man mal schauen, ob es zu den Plugins nicht nen Ersatz über NodeRed gibt. Bei den Shellys ist das mittlerweile problemlos über das “Virtual Device”-Node möglich, man spart sich die Fremdsoftware und das System wird weitaus weniger belastet.
GUIv2 läuft hier seit diversen Firmwareständen absolut Problemlos auf nem Cerbo GX.
hallo,
die einstellung gibt es wohl auch erst seit einer neueren firmware. auf meinen cerbos gibt es die naemlich noch nicht!
tschuess