openhabforum.de

Hallo zusammen,

mein OpenHab läuft nun schon seit einiger Zeit auf eine RaspberryPi 4 mit 4 GB Ram sehr gut.

Ich habe ein KNX in meine Haus und viele andere Schnittstellen, die ich angebunden habe. Dadurch habe ich eine sehr große Menge an Rules, Things, Items etc.. Ich habe nun seit kurzem gemerkt, dass OpenHab teilweise beim Schalten von Items oder Ausführen von Rules etwas träge geworden ist.

Ich habe über die Java Optionen OpenHab nun 1,5 GB Ram zugewiesen:

EXTRA_JAVA_OPTS="-Xms1500m -Xmx1500m"

das hat schonmal etwas gebracht. Aber trotzdem ist es immer noch nicht so optimal.

Ich habe gelesen, dass man an den Threadpool Einstellungen etwas anpassen kann:

org.eclipse.smarthome.threadpool:ruleEngine=
org.eclipse.smarthome.threadpool:thingHandler=
org.eclipse.smarthome.threadpool:discovery=
org.eclipse.smarthome.threadpool:safeCall=

Bislang sind die Threadpools bei mir alle auf Default gestellt.

Wie hoch kann man die drehen, damit es ordentlich läuft?

Habt Ihr Ideen oder Erfahrung diesbzgl.?

Im Normalfall sollte es nicht notwendig sein, hier Einstellungen anzupassen. Wichtiger wäre, die bestehenden Rules anzuschauen und zu prüfen, ob es Optimierungsmöglichkeiten gibt.

Grundsätzlich macht openHAB bei mir ca. 190 Threads auf (mit Default Einstellungen und etwa einem Dutzend „Extra“ Addons (also Transformation, UI usw. mal außen vor gelassen, die sind bei der Expert Installation schon vorinstalliert).
Allerdings sind da auch etliche Worker Threads mit dabei, die also den Großteil der Zeit nichts tun (z.B. für Rules).
Eine Erhöhung z.B. der Rule Threads bringt auch nur in den Fällen etwas, wo regelmäßig Rules nicht oder erst verspätet ausgeführt werden, weil mehr als fünf Rules gleichzeitig getriggert werden. Das ist dann meist ein Zeichen dafür, dass beim Erstellen der Rules ein Fehler passiert ist.


Gesendet von iPad mit Tapatalk

Ich habe zwar kein KNX, habe aber bei ähnlichen Problemen fast alle meine Rules nach NodeRed ausgelagert.
openHAB und NodeRed ergänzen sich sehr gut.

Holger

Ich habe heute nochmal etwas recherchiert und habe dabei herausgefunden, dass die Rules immer einen Verzögerung haben, die mit dem Deconz Binding für den Deconz zigbee Stick zusammenarbeiten. Vielleicht hängt es damit vielleicht zusammen.

Wie gesagt, es kommt sehr auf die Rules an (Aufbau, Größe, Komplexität, verwendete Resourcen...)

udo1toni hat geschrieben: ↑30. Sep 2020 19:04 Wie gesagt, es kommt sehr auf die Rules an (Aufbau, Größe, Komplexität, verwendete Resourcen...)

Hallo,
Ich habe nun vermehrt zeitverzögerte Schaltungen meiner OH. Laut SystemInfo habe ich auch immer ca 320 Threads laufen...

Da ich sehr viele Regeln geschrieben habe, würde mich interessieren was so die großen Verzögerungen auslösen. Gibt es da irgendwo eine Übersicht?

dirkspostbox hat geschrieben: ↑13. Dez 2020 12:11 Da ich sehr viele Regeln geschrieben habe, würde mich interessieren was so die großen Verzögerungen auslösen. Gibt es da irgendwo eine Übersicht?

Nein, nicht dass ich wüsste.

Generell: je mehr Zeilen Code, desto längere Ausführungszeit. Je mehr fix definierte Variablen/Konstanten, desto höhere Ladezeit. Je mehr Primitives, desto höhere Ladezeit.

Welche Plattform nutzt Du? Welche Version von openHAB läuft? Wieviele Items/Things? Wieviele Addons()Bindings)? Zusätzliche Hardware (USB-Sticks, GPIO usw.)?
Zusätzliche Software (Datenbanken, Konnektoren...)?
Wie sind die Rules aufgebaut? Welche Trigger werden verwendet?

Grundsätzlich: Vermeide unbedingt Rules mit identischem Trigger! Vermeide unbedingt Time cron Trigger mit identischen Trigger Zeitpunkten! Vermeide Time cron Trigger mit hoher Frequenz! Vermeide, wo möglich, Codedoppelungen. Vermeide unbedingt Thread::sleep() mit Werten über 500 (wobei dann Thread::sleep(500) nur einmal in der gesamten Rule ausgeführt werden sollte, also nicht z.B. eine Schleife, in der dieser Befehl zigmal ausgeführt wird).

Welche Plattform nutzt Du? RP4, 4GB RAM
Welche Version von openHAB läuft? openHAB 2.5.8-1 (Release Build)
Wieviele Items/Things? ~ 500 Items und 50 Things
Wieviele Addons()Bindings)? 10 Bindings,
Zusätzliche Hardware (USB-Sticks, GPIO usw.)? Nein
Zusätzliche Software (Datenbanken, Konnektoren...)? RRDJ4 zur Aufzeichnung von Temperaturen

Wie sind die Rules aufgebaut? Welche Trigger werden verwendet?
idR versuche ich als Trigger immer ein Cron zu nutzen, aber natürlich auch Eventgesteuert, wenn zb eine Tür/Fenster geöffnet wird

Vermeide unbedingt Rules mit identischem Trigger!
Vermeide unbedingt Time cron Trigger mit identischen Trigger Zeitpunkten! habe ich keine
Vermeide Time cron Trigger mit hoher Frequenz! Trigger max alle 15 min

Vermeide, wo möglich, Codedoppelungen. --> Ich versende aus unterschiedlichen rules jeweils push-Nachrichten an mehrere Teilnehmer, aber nur wenn diese anwesend sind. Kann ich dieses vielleicht auslagern und in den verschiedenen Scripten jeweils mit einem Parameter aufrufen?

Vermeide unbedingt Thread::sleep() mit Werten über 500 (wobei dann Thread::sleep(500) nur einmal in der gesamten Rule ausgeführt werden sollte, also nicht z.B. eine Schleife, in der dieser Befehl zigmal ausgeführt wird).
nutze nur noch createTimer(now.plusSeconds

Das hört sich eigentlich alles eher nach einem normalen Umfang an. Zum Vergleich: Bei mir 846 Items, 114 Things, 16 (+1) Bindings, ca. 1100 LOC in 55 Rules, 1090 LOC in einer Sitemap. Das läuft bei mir in einem LXC Container mit 1,5 GByte und einem Prozessorkern. Ich spüre keine Verzögerung, es sei denn, ich habe was kaputt gemacht Dabei bezieht sich das kaputt gemacht vor allem auf "VSCode lange mit Zugriff auf Rules Dateien offen gelassen", dann hilft ein Neustart der VM ungemein.

Was die Push Nachrichten angeht, so gab es mal im englischen Forum einen Ansatz dazu, der darauf hinaus läuft, dass man eine Rule anlegt und über eine globale Variable den Empfänger setzt, sowie über ein Item den Text übergibt. Dabei wird das Item als Trigger verwendet (pushString changed) und in der Rule wird dann nur die Nachricht versendet. Dadurch kann man das Verhalten beim Versenden zentral steuern, also z.B. immer bestimmte Rahmentexte mitsenden, eine Logzeile erzeugen, oder auch den Push-Dienst bei Bedarf tauschen.
Mit Codedoppelungen meine ich aber eher z.B. 10 Rules für Items, welche quasi identisch in der Funktion sind, nur für unterschiedliche Räume/Geräte usw., was dann auf 10 Rules mit identischem Code raus läuft, außer die verwendeten Items halt... oder auch Rules, die ein Item auf einen von zig verschiedenen Werten setzt, es ist dann sinnvoller, den eigentlichen Wert in einer Variablen zu speichern und nur einmalig den Setzbefehl zu verwenden (ich nenne das mal Codeeffizienz).

Ich habe jetzt alles weiter optimiert, jedoch habe ich trotzdem zeitweise dahingehend Probleme, das bestimmte Befehle sehr zeitverzögert ausgeführt werden oder aber gar nicht ausgeführt.

Kann ich die maximale Ausführung paralleler Befehle irgendwie erhöhen? Ich habe mal was von default 5 parallelen Befehlen gelesen, vielleicht ist das bei mir zu wenig