Hallo,
kurz zu mir... habe openHab 4.1.1 in einem Docker auf einer Synology 220+ (10GB RAM, 2 Netzwerkports), weiterhin in jeweils einem Docker Grafana, InfluxDB, Mosquitto an laufen.
Im openHab sind ~1600 Items, 35 Pages, 18 Rules und diverse Widgets... (glaube gibt schlimmeres ... )
Der Zugriff läuft über einen Touchscreen mit einem Raspberry 4 (8GB RAM, aktive Kühlung)...
Das "Problem" sind die Ladezeiten über den Raspberry. Teilweise braucht es ungelogen 20 Sekunden bis sich eine Seite aufbaut. Mit Laptop im Netzwerk dauert die gleiche Seite ca. 3 Sekunden (was für die Anzahl an eingebundenen Items absolut in Ordnung wäre).
Netzwerkeinstellungen am Raspberry, WLAN oder LAN (das anderes jeweils deaktiviert) habe ich alles überprüft. Auch den Raspi neu aufgesetzt mit dem aktuellsten Raspberry Pi OS und neuer SD Karte.
Sind die Layout Seiten im openHab so speicherintensiv?
Wie greift ihr auf eure openHab Installationen zu wenn Sie als Haussteuerung dienen? Hilft ein Umstieg auf einen Raspi5? Oder braucht es sogar einen "normalen" mini PC mit z.B. I5 oder I7 Prozessor und dementsprechend RAM? Wäre schade, denn der Energieverbrauch des Raspi ist halt doch schön...
Ich habe keinen Pi als Client, aber ehrlich gesagt kann ich mir nicht vorstellen, dass das ein grundsätzliches Problem ist. Mein openHAB enthält nur wenige Pages, meist nutze ich die Sitemap, aber mehr aus Gewohnheit als um Zeit zu sparen.
Mein System hat 147 Things, 1454 Items, 8 Pages, 65 Rules und ca. 40 installierte Addons. Mein openHAB System läuft in einem LX-Container (LXC), in etwa vergleichbar mit Docker, aber etwas andere Umsetzung.
Der Container hat 3 GByte RAM zur Verfügung (weil ich es habe...) und kann 4 Cores nutzen, wobei das System selbst unter Last meist unterhalb 10% CPU-Last ist und nie wesentlich über 2 GByte RAM Bedarf hat.
Auf meinem Desktop dauert das Öffnen der Main UI Übersicht jederzeit weniger als eine Sekunde, auf dem Smartphone ebenso, auch wenn ich von Unterwegs über Wireguard zugreife (mein Upload ist auf 30 MBit/s begrenzt).
Ich habe nur wenige Widgets auf meiner Übersichtsseite (wie gesagt, ich nutze meist die Sitemap), aber ich hatte auch schon testweise "größere" Übersichtsseiten gebaut, ohne dass mir da Probleme mit dem Seitenaufbau untergekommen wären.
Wie ist der Pi angebunden? Kann es sein, dass der Pi über WLAN läuft? Es gibt meines Wissens spezielle Images für den Kiosk Modus (also bestens geeignet als Grundlage für Touchscreens) bei denen der Browser sehr leichtgewichtig ist, das wäre evtl. eine bessere Grundlage.
Guten Morgen Udo, vielen Dank für deine Einschätzung...
eben weil ich die Unterschiede zwischen lokalem Zugriff (Touch/ Raspi) und Zugriff PC (Windows-lokal oder VPN) so krass finde bin ich am Suchen was der Fehler sein kann.
Der PI ist mit WLAN eingebunden, habe aber zum Testen das ganze nach der Neuinstallation mit Kabel verbunden und das WLAN deaktiviert. Ergebnis ist das gleiche - LAAANGSAAM...
Momentan ist es ein normales PI OS (m.E. ein abgespecktes Ubuntu) welches ich halt im Kiosk Modus im Chromium betreibe. Alles eigentlich kein Hexenwerk... Sitemaps sind da (aus momentaner Sicht ) eher böhmische Dörfer... habe ich mich bis jetzt gar nicht damit beschäftigt.
Hab schon meine Widgets im Verdacht gehabt, ob ich da irgendeinen Mist drin stehen habe... aber das kann ja eigentlich auch nicht sein.
alex_2112 hat geschrieben: 7. Aug 2024 08:04
Sitemaps sind da (aus momentaner Sicht ) eher böhmische Dörfer... habe ich mich bis jetzt gar nicht damit beschäftigt.
Das stammt halt noch aus "Nur-Text-Zeiten" - damals noch mit der Classic UI (wobei ich unter openHAB 1 gerne GreenT verwendet hab, leider wurde das gar nicht mehr weiter entwickelt).
Die Basic UI (Sitemaps) bietet halt nur eine einfache Ansicht, dennoch ist sie sehr leistungsfähig. Aber wie gesagt, das ist sicherlich nicht Dein Problem.
alex_2112 hat geschrieben: 7. Aug 2024 08:04
Hab schon meine Widgets im Verdacht gehabt, ob ich da irgendeinen Mist drin stehen habe... aber das kann ja eigentlich auch nicht sein.
Sind es selbst entwickelte Widgets, oder solche "von der Stange"? Bei selbst entwickelten musst Du halt schauen, was die Widgets machen.
Ich bin mir nicht sicher, aber hat Chromium nicht auch ein Monitoring für Web Entwickler implementiert? Im Menü unter "Weitere Tools" und dann Entwicklertools. Damit kann man auch den Verlauf einer Session "aufnehmen" um im Anschluss zu schauen, wie viel Zeit für welchen Teil des Seitenaufrufs drauf geht.
Sind es selbst entwickelte Widgets, oder solche "von der Stange"?
Ich würde sagen selbst entwickelt - natürlich zu Beginn gesucht kopiert/ ausprobiert, das behalten und verändert was gefallen und funktioniert hat. Inzwischen denke ich, ich weiß so ungefähr was ich tue... aber mehr auch nicht. Habe dir unten mal das letzte Widget angehängt... wenn du Lust hat schau es dir mal an... Kritik erwünscht...
Chromium nicht auch ein Monitoring für Web Entwickler
Das ist ein guter Hinweis, werde ich in den nächsten Abenden mal machen und berichten...
Dazu gehört natürlich auch eine Rule, die alle 5 Minuten läuft.
Du hattest mal in einem anderen Thread etwas zum Thema Performance und zeitgesteuerte Rules geschrieben... man sollte das vermeiden... Aber sollte es an so etwas liegen, müsste doch die Zugriffzeit von jedem Client aus lange dauern?
Eigentlich sollte ein manueller Refresh (also manuell im Sinne, dass Du extra dafür eine Rule brauchst) unnötig sein. Ich habe ja nur wenige Standard Widgets im Einsatz, aber die aktualisieren ihre Ansicht zuverlässig, ohne dass es dazu einer eigenen Rule bedarf.
Grundsätzlich kann man mit Timer-gesteuerten Rules arbeiten, es ist halt in vielen Fällen unsinnig.
Beispiel: Ich habe eine kombinierte Anzeige von Azimuth und Elevation in einem Item, dessen Daten ich aus dem Astro Binding erhalte.
Ich könnte nun eine Rule schreiben, die diese Werte alle paar Sekunden auffrischt. Aber was nutzt das? Ich muss die Werte ja nur auffrischen, wenn sie sich verändert haben, also abhängig vom im Thing eingestellten Wert (default 5 Minuten).
Wenn meine Rule nun ebenfalls alle 5 Minuten über einen Timer getriggert wird, hat das immer noch den Nachteil, dass der angezeigte Wert unnötig ungenau ist, denn im Schnitt wird der Zeitraum zwischen Änderung des Itemwerts und Triggern der Rule etwa 2,5 Minuten betragen, abhängig davon, wann openHAB gestartet wurde (der Refresh geschieht dynamisch ab dem Zeitpunkt der Aktivierung des Things).
Da sich aber bei jedem Refresh die Werte ohnehin ändern, kann ich die Rule auch auf changed triggern lassen. Damit habe ich dann auch exakt eine Stelle, an der ich die "Refresh Rate" einstellen kann, und zwar im Astro Binding bzw. im zugehörigen Thing, und die Rule löst immer unmittelbar mit der Änderung der Werte aus.
openHAB ist "event driven", das heißt, die Regeln werden durch Ereignisse ausgelöst. Man sollte immer versuchen, die auslösenden Ereignisse so zu wählen, dass die Ausführung der Rules optimiert wird.
Ein Gegenbeispiel: Ich lasse meine Rollläden automatisch auf eine Beschattungsposition fahren, wenn die erwartete Höchsttemperatur des Tages über 23 °C liegt. Die Vorhersage liegt am Vortag vor, aber naturgemäß ist die Vorhersage am gleichen Tag morgens genauer, also prüfe ich um 6 Uhr die Vorhersagen und errechne den Höchstwert. Abhängig davon setze ich die Sollwerte aller betroffenen Rollläden, die dann ab 08:30 Uhr ihre jeweilige Position anfahren. Es wäre Quatsch, den Höchstwert bei jeder Änderung neu zu berechnen, schließlich brauche ich den Wert nur einmal täglich, entsprechend ist ein simpler Timer hier die beste Wahl.
Unabhängig von diesen Beispielen führt eine einzelne Rule, die alle fünf Minuten läuft, sicherlich nicht zu einem Problem im Web Client.