OpenHAB Treiber Timeout

[wu3mi]

Hallo,

Ich hatte das Thema schon mal angesprochen und habs bis dato leider noch nicht lösen können:
Leider hab ich beim openhab Treiber immer ein TimeOut. Hab nun im openhab.js file das Timeout hinaufgestellt (8sekunden) und es funktioniert nun - sollte aber nicht die Lösung sein, mEn.

Beim NetworkPerformance hab ich bei ein paar Werten (states) ne Dauer von ca 8s.
Könnte mir eventuell jemanden nen Hint geben, an was das liegen könnte?

Danke im Voraus
P.S.: Falls es nicht in dieses topic passt, bitte um Info, dann erstell ich einfach nen neuen Thread.

Gruß
wu3mi

[PatrikG]

wu3mi :
Warum du bei dir den Timeout höher stellen musst, kann dir hier wahrscheinlich keiner beantworten. Entweder deine Hardware hat nicht genügend Ressourcen um die Anfragen zeitnah zu bearbeiten oder du hast ein Netzwerkproblem.

Gruß
Patrik

EDIT: Themen getrennt. wvhn

[wu3mi]

Hallo,

danke fürs Feedback. Ich bin schon auf mehreren Seiten dran dies zu evaluieren (HW, Webserver, ...) bin aber noch wirklich dahintergekommen.
habs auf der gleichen HW laufen lassen, auf eigenen Instanzen und der gleichen. Mal sehen - bin noch dran.
Kann es auch mit der Anzahl der Items welche es in OH gibt zu tun haben?

Gruß
wu3mi

[PatrikG]

Wie ist denn das zeitliche Verhalten, wenn du die REST-API auf dem Server und vom Client aus über Administration -> Entwickler Tools -> API Explorer oder curl direkt anspricht? (openHAB REST API | openHAB)

[wu3mi]

Hallo PatrikG ,

das zeitliche Verhalten via beide Wege ist "normal" (also keine Verzögerung bemerkbar)

Anbei noch ein screenshot von der Network Analyse der SV.
Wie gesagt, ein Ausschnitt. Es sind einige die so lange dauern.


networkPerformance.png

Hast du etwas in der OH config eingestellt? (Stichwort Websocket, ...) Anbei ein Bild der driver_debug page.

driver_debug.png

Grüße
wu3mi

[wvhn]

Beim Laden einer Seite muss der Treiber alle items beim Backend anfordern, die auf der Seite verwendet werden. Während die mir bekannten Backends dazu eine Liste der items entgegen nehmen und auch wieder eine Liste mit den Istwerten zurückgeben, benötigt OpenHAB für jedes einzelne item einen eigenen Ajax-Request. Diese sind asynchron, d.h. der Treiber schießt die Requests in schneller Abfolge raus und hat Promise-Funktionen, die die nacheinander eintreffenden Ergebnisse verarbeiten.

Ich denke bei Visu-Seiten mit vielen items ist die Performanz des OpenHAB Servers für die Ladezeit der items ausschlaggebend. Das Problem ist hier nicht die Ladezeit einzelner items, sondern die Menge der items, die alle quasi gleichzeitig angefragt, aber sequentiell beantwortet werden. Je mehr items es sind, desto größer muss der Timeout sein. Vermutlich - da fehlt mir der Einblick - verlangsamt die Authorisierung die Abarbeitung der Requests zusätzlich.

Gruß
Wolfram

[PatrikG]

Hallo wu3mi ,

es ist so wie wvhn es bereits geschrieben hat. Man kann bei openHAB entweder alle oder nur ein Item in einer Anfrage anfordern.
Angenommen es sind 10 Widgets auf eine Seite und der Server benötigt ca. 1 Sekunde für die Ausführung einer Anfrage, dann bekommst du nach einer Sekunde die Daten vom ersten Widget, nach zwei Sekunden die Daten fürs zweite Widget usw. Beim Standard-Timeout von 5 Sekunden, bekommst du also nur für die ersten fünf Widgets die Daten und für alle Weiteren einen Timeout.

Zur Lösung gibt es nun mehrere, auch kombinierbare, Möglichkeiten:

• Ressourcenerhöhung des Servers
• Erhöhung des Timeouts in Zeile 33 (aktuell deine Lösung, wenn ich es richtig verstanden habe)
• Verringerung der Widgets auf einer Seite
• Anpassung des Treibers:
  • für synchrone Verarbeitung in Zeile 192 (async : false,), dann wird jede Anfage nacheineinander, anstatt gleichzeitig, abgearbeitet
  • Abruf aller verfügbaren, anstatt nur der auf der Seite verwendeten, Items beim Aufruf der Seite

Gruß
Patrik

[wu3mi]

Hallo zusammen,

besten Dank für eure Inputs.
Werde diese Woche mal die oben genannten Punkte durchprobieren.

Betreffend Ressourcenerhöhung: meint ihr damit eine HW Erweiterung?

beste Grüße
wu3mi

[PatrikG]

Werde diese Woche mal die oben genannten Punkte durchprobieren.

Für den letzen Punkt müsste ich den Treiber anpassen. Ist kein großes Ding, kann ich bei Gelegenheit mal machen.

Betreffend Ressourcenerhöhung: meint ihr damit eine HW Erweiterung?

Ja, wenn es kein virtuelles Gastsystem oder Container ist und der Host noch Ressourcen übrig hat.

PS:
Ich verwende ne Intel NUC mit nem i5, 8GB RAM, SSD und Windows 10. Damit schaffe ich ca. 300 Items innerhalb 5 Sekunden.

[PatrikG]

Hallo wu3mi ,

ich habe aufgrund deiner Problematik die Funktionsweise des Treibers nochmals überdacht. Kurze Hintergrundinfos dazu:
Wie bereits geschrieben ist es bei openHAB nur möglich, entweder nur ein oder alle Items abzufragen. Nur beim EventListener ist es möglich mehrere verschiedene Items zu abonnieren. Weiter ist es so, dass openHAB nicht mit 0 und 1 als Werte arbeitet, und auch noch weitere Eigenheiten hat, und dadurch müssen diese Werte, sowohl beim Lesen, als auch beim Schreiben konvertiert werden und dazu ist es notwendig den ItemType zu kennen, da die Werte, je nach Type, unterschiedlich notiert sind.

Bisher wurde das so gelöst, dass beim Aufruf der Seite alle Daten der dort benötigten Items einzeln gelesen wurden. Sofern die Echtzeitabfrage aktiviert ist, wurde anschliessend versucht die Statusänderung dieser Items zu abonnieren. Schlägt dies fehl, wird ein Timer aktiviert, der den Status der benötigten Items jede Sekunde wieder einzeln abruft. Dies schont zwar den Speicherplatz am Client, benötigt aber mehr Ressourcen am Server. Daher folgende Änderung:
Beim Erstaufruf von smartVISU werden die ItemTypen von allen openHAB-Items mit einem Aufruf gelesen. Die Laufzeit dieses Aufrufs wird gemessen, auf volle Sekunden aufgerundet, und als Karenzzeit auf alle vorgegebenen Zeitwerte für Timeout und Timer addiert. Beim Aufruf einer Seite wird, wie bisher versucht die dort benötigten Items zu abonnieren. Schlägt dies fehl, wird per Timer jede Sekunde + Server-Karenzzeit mit einem Aufruf der Status aller openHAB-Items, anstatt nur der Benötigten einzeln, abgefragt.

Bei Seiten mit nur wenig Widgets, wirkt dies zwar unsinnig und lädt mehr Daten in den Clientcache als nötig, ist aber summasumarum kaum langsamer, benötigt dafür aber weniger Serverressourcen.

Anbei mal für dich zum Testen die Betaversion des Treibers.

[wu3mi]

Hallo PatrikG ,

sehr sehr cool.
Ich bin leider im Moment zeitlich etwas unter Druck und kann leider nicht soo viel an meiner HomeAutomation machen.
Ich hab gestern mal quick'n'dirty den neuen Treiber eingespielt und keinen Error zurückbekommen. 😃

Betreffend den Ressourcen bin ich dran, aber noch nicht ganz schlau.

Ich melde mich diesbezüglich nochmals.

thx für deine Bemühungen

wu3mi

[PatrikG]

Ich hab gestern mal quick'n'dirty den neuen Treiber eingespielt und keinen Error zurückbekommen. 😃

Betreffend den Ressourcen bin ich dran, aber noch nicht ganz schlau.

Wenn für dich die Reaktionszeiten so ok sind, dann musst du dir darüber auch keine Gedanken mehr machen.