openWB Forum

Hallo zusammen,

ich betreibe nun seit 2 Tagen erfolgreich mein Testsystem in Version 1.9 auf einem Raspberry Pi Zero 2 mit Buster lite.

Nun wollte ich, da ich von openWB überzeugt bin, dass ganze live schalten und dazu eine Installation auf meinem Pi 400 im Serverraum durchführen (der Pi400 bootet von SSD - ich traue SD Karten nicht). Gerade wenn hier täglich massig Schreibzugriffe über openWB sind, dürfte das die SD Karte doch extrem stressen. Auf dem Pi400 läuft Buster als Desktopversion, da ich hier das ein oder andere mal den Pi zur Netzwerkadministrierung nutze. Alles konfiguriert und läuft auch, nur eine Sache verwundert mich:

Schalte ich das Theme auf "Colors", welches mir extrem zusagt, dann gibt es eine starke Verzögerung beim Aufruf der GUI. Der Ladebalken geht bis 78% und verweilt dort für bis zu 10 Sekunden, um dann auf 100% zu springen und die GUI freizugeben. Schalte ich das Theme auf ein beliebiges anderes um, dann ist die GUI faktisch sofort verfügbar.

Wo kann ich ansetzen um das Problem zu identifizieren?

Vielen Dank
Kai

Ich habe auf dem Pi400 nun einmal Buster Lite neu aufgesetzt. Gleiches verhalten...der Startbildschirm bleibt bei 78% für eine gefühlt Ewigkeit hängen.

Ich sehe das auch auf meinem Test-OWB 1.9 (fast immer auf der aktuellen Nightly).
Hardware ist hier ein Raspi 3b+ ohne SD oder SSD, boot und rootfs auf Synology NAS (PXE boot, bzw. NFS mount).
Alles ist mit 1Gbit LAN über etliche Switches verbunden.

Bei 78% gibt auch es immer eine Pause von ca. 15 sec.
Das ist bei mir nicht weiter schlimm, da ich auf diesem System meistens per ssh arbeite und das Web-UI nur zur Kontrolle nutze.

Beim Start des Desktop werden ja jede Menge Javascript-Code und Daten übertragen - ich nehme an das benötigt halt Zeit, vor allem wenn der PI das per NFS von der Synology holt, die auch nicht extrem schnell ist..

Auf meiner Kaufbox mit SD-Karte gibt es diese Pause bei 78% nicht, nur ca. 1 sec bei 56%.

Alle Themen abeiten so das sie während des Forschrittsbalkens
die MQTT-Datemabfrage im Hintergrund laufen haben.
Erst wenn alle als Wichtig eingestuften Daten eingetroffen sind (100%) wird
der Ladeschirm augeblentet.
Wenn es also bei x% stockt, hat der MQTT Server gerade backen.

Ich habe mir gerade mal den Code angeschaut und denke, dass wir das noch beschleunigen können.
Ich test das mal bei mir im Testsystem und reiche dann einen Change ein.

Naja es wird schon seinen Grund haben, aber verdammt merkwürdig ist doch die Tatsache, dass es auf zwei frisch aufgesetzten Systemen zu unterschiedlichen Wartezeiten kommt und das der potente Pi400 10x so lange lädt wie der kleine Pi Zero 2.

Aber wohl gemerkt nur bei dem colors Theme.

Beides identisch konfiguriert, gleiches Image und gleiches Netzwerk.

Würde es gern verstehen…

Ich habe mal einen Change eingereicht (PR ist eh noch offen).
Das Problem war, dass das Colors Theme auf viel zu viele MQTT-Messages gewartet hat, bis es die Anzeige aktiviert. Das ist jetzt deutlich reduziert. Bei mir ist es gefühlt schneller, ich hatte aber auch vorher keine sehr grosse Verzögerung. Der kurze Halt bei 56/57% ist jetzt aber weg.
Warum es auf dem schnelleren Pi langsamer ist, weiss ich auch nicht, aber vielleicht eine unterschiedliche Behandlung der MQTT-Messages oder anderes Handling von Timeouts.
Es wäre gut, wenn Du testen könntest, wenn der Change gemerged ist. Hoffentlich hilft der Fix.

electron hat geschrieben: ↑Do Feb 02, 2023 6:04 pm Ich habe mal einen Change eingereicht (PR ist eh noch offen).
Das Problem war, dass das Colors Theme auf viel zu viele MQTT-Messages gewartet hat, bis es die Anzeige aktiviert. Das ist jetzt deutlich reduziert. Bei mir ist es gefühlt schneller, ich hatte aber auch vorher keine sehr grosse Verzögerung. Der kurze Halt bei 56/57% ist jetzt aber weg.
Warum es auf dem schnelleren Pi langsamer ist, weiss ich auch nicht, aber vielleicht eine unterschiedliche Behandlung der MQTT-Messages oder anderes Handling von Timeouts.
Es wäre gut, wenn Du testen könntest, wenn der Change gemerged ist. Hoffentlich hilft der Fix.

Ich teste gerne - wie bekomme ich mit ob bzw wann die Änderung im nightly gelandet ist?

Ich schreibe es in diesen Thread, sobald gemerged wurde.

kai9555 hat geschrieben: ↑Do Feb 02, 2023 6:21 pm Ich teste gerne - wie bekomme ich mit ob bzw wann die Änderung im nightly gelandet ist?

Meiner Erfahrung nach ist der Pi3B+ (in der Original WB) auch ohne HTTPS deutlich langsamer als
der Pi4 trotz verwendung von HTTPS.
Der Pi3 braucht mit der Orignal OWB Sofware ~5-8 Sekunden beim Start
Mein Test-PI4 mit HTTPS etwa 1-2 Sekunden. Man hat keine Zeit ein Protzentzahlen zu lesen.