FHEMWEB unter iOS9 träge und TimeOuts

[FunkOdyssey]

@FunkOdyssey: aus deinen logs werde ich nicht wirklich schlau, weil ich nicht weiss, wo/wann die Verzoegerung stattfand.

fhemweb2_log.txt
Ich habe FHEM um 18:21:14 aufgerufen und es hat direkt gestockt.

fhemweb3_log.txt
Hier stockte es auch direkt beim Aufruf um 21:15:22 Uhr.

Es gibt bei mir keine Zeilen davor oder danach, die etwas mit FHEMWEB zu tun haben.

[felix.steinbeis]

Der naechste Schritt wird leider viel Daten produzieren, ich habe aber keine bessere Idee: bitte in 01_FHEMWEB.pm in der Zeile 326 (vor "if(!$hash->{HDR}) {" Folgendes einfuegen:

Code Auswählen Erweitern

Log 1, "$name: $hash->{BUF}";

Anbei zwei neue Logs mit einer sehr interessanten Beobachtung:
Ich kann das Verhalten relativ gut reproduzieren. Meist reicht es den Raum zu wechseln. Der erste Wechsel klappt, kurze warten, der Wechsel zurück klappt häufig dann nicht. Aber nur im WLAN! 

Nutze ich eine VPN-Verbindung über 3G habe ich die 30s Timeouts nicht. Die EOFs kommen trotzdem aber direkt.

Viele Grüße
Felix

[Bennemannc]

Hallo,

nach dem ich festgestellt habe, das Chrome besser läuft, habe ich mal auf meinem IPad die Option "Desktop Seite anfordern" aktiviert. Gefühlt sind es dann viel weniger Aussetzer.
Kann das mal jemand testen ?
Wenn ja, dann würde das die Suche je vielleicht einschränken.

Gruß Christoph

[FhemPiUser]

Habe mal ein Log mit verbose 5 mitlaufen lassen.

Es gab ein paar merkwürdige Einträge, z.B.

Code Auswählen Erweitern

2015.09.25 20:01:51 4: HTTP FHEMWEB:192.168.1.118:51756 GET /fhem?XHR=1&inform=type=status;filter=room=Bewegungsmelder;since=1443204109;fmt=JSON&timestamp=1443204133820
2015.09.25 20:01:54 4: Connection closed for FHEMWEB:192.168.1.118:51768: EOF
2015.09.25 20:01:54 5: BUF: EMPTY

oder

Code Auswählen Erweitern

2015.09.25 20:01:51 4: HTTP FHEMWEB:192.168.1.118:51756 GET /fhem?XHR=1&inform=type=status;filter=room=Bewegungsmelder;since=1443204109;fmt=JSON&timestamp=14
43204133820
2015.09.25 20:01:54 4: Connection closed for FHEMWEB:192.168.1.118:51768: EOF
2015.09.25 20:01:54 5: BUF: EMPTY
2015.09.25 20:02:23 4: Connection closed for FHEMWEB:192.168.1.118:51769: EOF
2015.09.25 20:02:23 5: BUF: EMPTY
2015.09.25 20:02:23 4: Connection closed for FHEMWEB:192.168.1.118:51766: EOF
2015.09.25 20:02:23 5: BUF: EMPTY
2015.09.25 20:02:25 4: Connection closed for FHEMWEB:192.168.1.118:51751: EOF
2015.09.25 20:02:25 5: BUF: EMPTY
2015.09.25 20:02:25 4: Connection closed for FHEMWEB:192.168.1.118:51759: EOF
2015.09.25 20:02:25 5: BUF: EMPTY
2015.09.25 20:02:28 4: Connection closed for FHEMWEB:192.168.1.118:51767: EOF
2015.09.25 20:02:28 5: BUF: EMPTY
2015.09.25 20:04:37 4: Connection accepted from FHEMWEB:192.168.1.118:51770
2015.09.25 20:04:37 4: Connection closed for FHEMWEB:192.168.1.118:51756: EOF
2015.09.25 20:04:37 5: BUF: EMPTY
2015.09.25 20:04:37 4: HTTP FHEMWEB:192.168.1.118:51770 GET /fhem?room=Arduino_Heizung


Die Aussetzer waren dabei nicht ganz so schlimm. Hatte das Gefühl, dass es vor allem bei den Bildern mit content-encoding gzip länger gedauert hat, aber es hielt sich im Rahmen und wird wohl nur am kodieren liegen.

[rudolfkoenig]

@Felix: mit deiner Anleitung konnte ich das Problem reproduzieren.

iOS9 hat wohl Probleme mit der if-none-match/HTTP 304 Antworten von FHEMWEB gehabt, und anstatt sich zu beschweren, oder die Daten sofort erneut anzufordern, hat es 30 Sekunden gewartet (warum?).
Ich habe versucht die Antwort jetzt genau RFC konform zu machen, und ich kann das Problem nicht mehr reproduzieren.
Ich habe aber dabei auch die Expires Zeilen repariert (mit dem Nebeneffekt, dass jetzt weniger Dateien angefordert werden, und manche Dateien 15Minuten lang im Browser gecached werden, wie es seit Jahren beabsichtigt war), bin also nicht ganz sicher, woran das Problem eigentlich lag, bzw. ob es nach dem Ablauf (Expires: 15min) das Problem nicht doch auftritt. Bei mir kam das Problem nach 20 Minuten allerdings nicht.

Achtung: fhem.pl muss auch ausgetauscht werden.

[Loredo]

soweit ich weiß baut iOS9 zwei TCP Verbindungen auf, eine über WLAN und eine über WAN und die, die schneller antwortet, wird genommen.


Sent from my iPhone using Tapatalk

[felix.steinbeis]

Mit vorsichtigem Optimismus scheint das Problem gelöst zu sein. Super Sache! Vielen Dank!

Ich werde heute über den Tag mal noch öfters testen.

Felix

[P.A.Trick]

Schließe mich an! Klappt! Danke für den Patch.

[eldrik]

Moin,

Seit dem Update alles besten!

Danke

[felix.steinbeis]

Ja, passt wieder alles. Danke sehr!

Viele Grüße
Felix

[DAREALBA53]

Hallo zusammen,

zunächst vielen Dank für dieses tolle Projekt und den Patch. Dieser hilft bei meinem IOS9 iPhone insofern, als dass nun der Raumwechsel und auch der Aufruf über Safari wieder in der gewohnten Geschwindigkeit geschieht.

Leider habe ich aber weiterhin die Verzögerung, wenn ich FHEM als Webapp (aus Safari zum Homebildschirm hinzufügen und dann als separtes Icon im Springboard) verwende. Hier scheint er die gesamte Seite beim ersten Auftruf immer neu zu laden und es entsteht der Timeout. Sobald sie geladen ist, ist der Raumwechsel nach dem Patch wieder so schnell wie unter IOS8 (vorher war auch hier der Timeout). Er lädt die Seite bei jedem Appwechsel oder neuen Aufruf der Webapp neu und das Problem tritt so häufig auf.

Ich habe zur Verdeutlichung einige verbose 5 Logs gezogen und während dem Auftreten des Problems per Konsole nachverfolgt. (Datei: Aufruf Webapp.txt)

Zum Vergleich habe ich den Raumwechsel, der sehr schnell erfolgt, ebenfalls mitgeloggt. (Datei:  Wechsel Raum in Webapp.txt)

Wäre super, wenn ihr da noch einmal schauen könntet.

[FunkOdyssey]

Noch habe ich keine Logs. Aber ich habe auch mit dem ersten Aufruf zu kämpfen. Danach fluppt es. Ich melde mich wieder, wenn ich mehr weiß.

[rudolfkoenig]

@DAREALBA53: Bitte die Logs mit dem aus meinem Post #27 vorgeschlagenen Ausgabe erneut erstellen.
Noch besser waere eine reproduzierbare Anleitung: z.Zt. kann ich es nicht reproduzieren.

[DAREALBA53]

@rudolfkoenig: Vielen Dank für die schnelle Antwort. Ich habe das detaillierte Log mit der Änderung in Codezeile 321 (nach dem Patch nicht mehr in 326) erstellt und per Email gesendet.

[rudolfkoenig]

Sorry, keine Idee nach studieren des Logs.
Ich kann es auch nicht nachstellen. Was z.Zt. nervt, ist die fehlende Reload-Moeglichkeit unter iOS, nachdem Expires gefixt wurde.