FTUI3 - Initiales Laden verzögerte Readinginhaltsanzeige

[Axel1971]

Hallo,

die FTUI3 ist wirklich große klasse - vielen Dank dafür.
Wie kann ich herausfinden, warum es beim ersten Laden zu einer ca. 2-3 Sekundenverzögerung kommt, bevor alle Daten von fhem geladen wurden?
Dies äussert sich dadurch, dass statusabhängige Icons verzögert dargestellt werden und readingabhängige Werte verzögert (2-3 Sekunden nach Aufruf der FTUI3 Seite) angezeigt werden.
Wenn die Seite erstmal geladen ist, dann läuft alles wunderbar flüssig.

Das darunterliegende HW-System ist ausreichend performant.

[OdfFhem]

Im Normalfall (Desktop) sorgt das Entwickler-Tool des Browsers für mehr Durchblick ...

- werden in der console Fehler gemeldet
- wie lange dauert die FHEM-Anfrage
- ...

So könnte man versuchen, das Problem bzw. die Ursache ausfindig zu machen ...

[Axel1971]

Danke für den Tipp. In der Console kann ich keine Fehler sehen auch bei einem Debug-Level 4

Der Aufbau der Seite dauert ca. 135ms - also prima
Das Laden der Chartdaten ist auch zügig ca. 700ms.
Die Abfrage der Readingsdaten von Fhem benötigt auf dem PC jedoch ca. 3 Sek., bis die Rückmeldungen vorliegen.

Auf einem Mobile dauert es deutlich länger, ca 15 Sek. und das unter guten Wifibedingungen (>90 Mbps)

[OdfFhem]

Die Abfrage der Readingsdaten von Fhem benötigt auf dem PC jedoch ca. 3 Sek., bis die Rückmeldungen vorliegen.

Klingt nach großem Aufwand für die Zusammenstellung der Antwortdaten ...
Wie sieht am PC im Entwickler-Tool des Browsers das Timing der zeitaufwendigen Abfrage aus ?

Bei mir stellt sich eine FTUI3-FHEM-Abfrage z.B. so dar (Desktop: pi4B ; Server: pi3B ohne +):
... Request ca. 6000 bytes
... Gesamter Zeitaufwand für Abfrage: 953.71 ms (ohne Vorlauf: 916,47 ms)
    - Request sent ... 2.88 ms
    - Waiting ... 907.67 ms
    - Content Download ... 5.92 ms
... Response ca. 10000 bytes
Diese Abfrage wird autom. alle 15 Minuten mit sehr ähnlichem Zeitverhalten wiederholt.
Vom Zeitverhalten her ist das Tablet ("gefühlt") auch nicht viel langsamer.

Das Tablet ist allgemein recht flott
... bekommt aber erfahrungsgemäß arge Probleme, wenn z.B. ein sehr großer Logfile via FHEM-Oberfläche dargestellt werden soll
... ein großer Logfile bei PC oder pi4B hat da deutlich weniger zu "kämpfen"

[Axel1971]

Klingt nach großem Aufwand für die Zusammenstellung der Antwortdaten ...
Wie sieht am PC im Entwickler-Tool des Browsers das Timing der zeitaufwendigen Abfrage aus ?

Danke, dass Du mir hier antwortest  Ich muss nun erstmal verstehen, wie die Chrome Entwicklertools verwendet werden. Webentwicklung ist bisher nicht mein Gebiet und die Dev Tools anscheinend nicht ganz intuitiv.
Auf dem PC dauert der erste Aufbau ca. 2-3 Sekunden. Auf dem Mobil habe ich das nun ebenfalls getestet und dort benötigt der Aufbau ca. 15 Sekunden.
Lt der Dev Tools sind  davon ca. 13 Sek. für Scripting enthalten.

Die LogDB Daten sind zügig da und lassen sich auch frühzeitig ansehen. Der Status bei den Buttons und Badgets benötigt nur die lange Zeit, bis sie angezeigt werden. Und es sind <20 Knöpfe.

Wenn ich verstehe, was ich wie in den Dev Tools sehe, melde ich mich hier wieder. Oder soll ich dir ein gespeichertes Profil senden, du weisst wahrscheinlich besser wonach man gucken muss.

[OdfFhem]

Wenn ich verstehe, was ich wie in den Dev Tools sehe, melde ich mich hier wieder. Oder soll ich dir ein gespeichertes Profil senden, du weisst wahrscheinlich besser wonach man gucken muss.

Die Info, die ich oben gezeigt habe, steht in der Regel im Netzwerk-Tab: was wurde angefragt, wie lange hat es gedauert und was war die Antwort.

Wenn Du sagst, dass der Scripting-Teil diese lange Zeitspanne beansprucht, dann ist vermutlich das Mobilgerät zu diesem Zeitpunkt gegenüber dem Desktop "überlastet"
... allerdings bleibt die Frage, wie oft ist denn überhaupt solch eine komplette Neudarstellung notwendig ?
Mache ich höchst selten, da "gestaute" Events beim Wachwerden normalerweise verarbeitet werden und die Ansicht anschließend autom. aktuell ist.