Fhemweb sehr langsam, neu Laden dauert "ewig" ios7

rudolfkoenig · 03 März 2014, 09:05:23

@Sandra:
- gibt es ein Problem auch ohne Wifilight?
- gibt es ein Problem ohne standby?
- mit App meinst du Safari oder WebApp (d.h. Shortcut auf dem Desktop?)

Zitat README_DEMO.txt:

ZitatPrerequisite:
- perl
- stop any existing FHEM process first (if started any).

HOWTO:
Start FHEM with a demo configuration with
perl fhem.pl fhem.cfg.demo
(typed in a terminal) and point your browser to http://YourFhemHost:8083
Use the startfhemDemo skript on the FritzBox.

Stopping:
- type shutdown in the browser command window, followed by RETURN
or
- type CTRL-C in the terminal window

This demo:
- it won't overwrite any settings in the productive FHEM installation
- it uses its own log-directory (demolog) and configfile (fhem.cfg.demo)
- it won't start in the background, the FHEM-log is written to the terminal
- it won't touch any home-automation hardware (CUL, ZWawe dongle, etc) attached
to the host.
[/quote

Blackcat · 03 März 2014, 09:10:37

Zitat von: rudolfkoenig am 03 März 2014, 09:05:23
gibt es ein Problem auch ohne Wifilight?

Teste ich heute Abend.. Modul auch aus dem FHEM Ordner löschen, oder nur die defines / attr aus der config nehmen?

Zitatgibt es ein Problem ohne standby?

ich glaube bei Appwechsel trat es auch auf (bin mir aber nicht mehr sicher), teste ich aber nach. Ansonsten werde ich auch mit WP8 und Android nochmal testen

Die WebApp (d.h. Shortcut auf dem Desktop) meine ich mit App. (Ist ja auch nur ein Safari)

Demo wird getestet -> Ergebnisse folgen

rudolfkoenig · 03 März 2014, 09:44:14

ZitatModul auch aus dem FHEM Ordner löschen, oder nur die defines / attr aus der config nehmen?

Config entfernen (oder deaktivieren) reicht.

ZitatDie WebApp (d.h. Shortcut auf dem Desktop) meine ich mit App. (Ist ja auch nur ein Safari)

Oberflaechlich betrachtet ja, aber de-facto sind das unterschiedliche Programme, z.Bsp. war in 4.3 JIT in Safari aktiviert, aber nicht in WebApp, damit war die gleiche Seite in Safari deutlich schneller.

det. · 03 März 2014, 10:59:49

Hallo Rudolf,
Sorry, das es so lange gedauert hat mit dem Demo Test. Erst mal einen RPI dafür einrichten. Auf dem produktiv Cubie2 konnte ich mich nicht entschließen FHEM dafür zu stoppen.
Also mein subjektiver Eindruck: mit dem iOS7touchpad Style geht das Demo sauschnell, ohne die sonst allgegenwärtige Meldung über den reconect in 5s. Nach Wechsel in den von mir sonst verwendeten hellgrünen Standard Style touchpad - langsam wie gewohnt. Da ist auch kein Unterschied zwischen der Demo und dem minimalen FHEM.cfg auf dem RPI mit paar wenigen angelegten OWdevice, einem Max COC und einem Arduino.
Ist wie schon geschrieben aber nur ein subjektiver Eindruck. Wenn Du Hinweise hast, wie ich was messbar testen soll - gerne. Hab die Woche Urlaub mit Haustier Gründen, daheim zu bleiben.

herrmannj · 03 März 2014, 11:34:31

ZitatZitat von: rudolfkoenig am Heute um 09:05:23

gibt es ein Problem auch ohne Wifilight?

Teste ich heute Abend.. Modul auch aus dem FHEM Ordner löschen, oder nur die defines / attr aus der config nehmen?

ich hab (noch) einen experimentellen slider im wifilight modul. Kombination aus IOS7, longpoll und slider und standby ist genau die kritischste die man finden kann

kommt als Ursache bei sandra gut in Frage. Da schlägt die 2 quellen restriction bei ios7 zu. Und btw: bitte nur ein browser-tab pro ipad zu fhem öffnen, ist ein ios7 thema $:-\$

Testen: der slider wird nur geladen wenn wifilight im Raum oder auf dem floorplan ist, reicht also den lampe aus dem floorplan zu nehmen oder einen neuen leeren Raum zu erstellen und zu testen.

Auf meiner todo ist es sowieso.

vg
Jörg

Blackcat · 03 März 2014, 12:47:25

Zitat von: herrmannj am 03 März 2014, 11:34:31
Kombination aus IOS7, longpoll und slider und standby ist genau die kritischste die man finden kann kommt als Ursache bei sandra gut in Frage. Da schlägt die 2 quellen restriction bei ios7 zu. Und btw: bitte nur ein browser-tab pro ipad zu fhem öffnen, ist ein ios7 thema $:-\$

Hi Jörg,

Ich nutze noch IOS 6, weißt du ob es da auch schon war?

Viele Grüße
Sandra

herrmannj · 03 März 2014, 12:58:37

Hi,

ios7 ist, glaub ich, schlimmer. ios6 hat genau an der ecke aber auch probs. Vielleicht isses ja auch was anderes, der thread existierte ja schon unabhängig.

Aber im Bezug auf Wifilight kenne ich die kleine "Baustelle" daher die msg.

Ich benutze übrigens ipad / ios7 und, surprise, auch wifilight und das ohne große Probleme. Nicht über den homescreen sondern browser, nach standby refresh und ganz wichtig: nur ein browser tab zu fhem. Das mit dem einen tab gilt für alle module wegen longpoll (ohne svg), je nach situation kann sonst sowas auftreten.

vg
jörg

Blackcat · 03 März 2014, 18:02:47

So Test mit der Demo config auf ios 6 ipad4:
Safari
-Problem tritt auf in Form von langsamen Laden mit weißen Bildschirm beim mehrmaligen umschalten von homescreen zu Safari / anderen Apps
Webapp
-problem (weißer Bildschirm) tritt auf wenn man home-webapp-home... Mehrmals drückt, hab dabei sogar mehrmals das ipad zum totalabsturz gebracht

Liegt also nicht an wifilight...

fruemmel · 17 März 2014, 09:13:23

Hallo Allerseits,

ich habe bei mir auch auf den Apfel-Geräten (iPhone 5, iPad jeweils ios7) im WLAN das Problem, dass beim Aufruf von fhem oft nur ein weißer Bildschirm kommt.
Meistens ist dann nach genau 30 Sekunden die Seite da. Der Server läuft bei mir auf einem Raspberry PI (512MB).

Außerdem fällt auf, dass bei jedem Room-Wechsel das iPhone kurz anzeigt "Connection lost, trying again ..."

Ich habe dann mal auf einem PC mittels Virtual Box und Debian die gleiche fhem-Konfiguration gestartet. Und siehe da: keine Probleme mehr mit
dem iPhone. Weder weißer Bildschirm, noch "Connection lost ...".
Mit einer minimalen fhem-Grundkonfiguration (also installieren und starten) habe ich auch im WLAN mit RPI weder weißen Schirm noch Connection Lost.

Für mich sieht das so aus, als ob es in Verbindung mit Safari ein Timing-Problem gibt, wenn der Server nicht schnell genug ist.
Wenn ich über Funk (3G) und VPN auf den Raspberry PI zugreife (also mit einer vergleichsweise langsamen Verbindung) habe ich
das Problem mit dem weißen Bildschirm nicht.

Vielleicht helfen diese Infos ja zu einem gemeinsamen Lösungsansatz.

Gruß Wolfgang

micomat · 17 März 2014, 09:49:02

Hallo zusammen,

ich hab ja das gleichen Problem schon seit Monaten.
Mir ist jedoch aufgefallen, dass das Problem nach einem RPi reboot erst mal weg ist.
Wenn das Problem beispielsweise im WLAN auftritt, ich das WLAN trenne mich via VPN einwaehle ist das Problem weg, verbinde ich mich dann wieder mit WLAN ist es sofort wieder da.

Nun mal eine Mutmaßung: Kann es sein das hier irgendwelche Connection/Session-Limits erreicht werden pro Host? Von anderem Host funktionierts ja zu gleiche Zeit problemlos. Oder das irgendwelche Sessions nicht sauber geschlossen werden? Es handelt sich hier ja um einen integrierten Webserver der vielleicht einfach mit der Zahl der Sessions ein Problem hat?

Gruß
Markus

fruemmel · 17 März 2014, 10:11:27

@micomat: Bei mir bringt ein Neustart des RPi nichts. Und das Problem tritt zumindest bei mir nur in Verbindung mit Safari auf.
Mit einem Android-Gerät oder Aufruf vom PC ist immer alles ok. Das spricht m. E. gegen Deine Vermutung der Sessionanzahl
oder connection-limits.

Deine Aussage zum Thema WLAN/VPN würde ich eher so deuten, dass bei einer langsameren Verbindung über VPN der
RPi und Safari sich "besser verstehen" als bei einer schnellen Verbindung über WLAN. Dass das ziemlich komisch klingt ist klar,
aber irgendeinen Grund muss es ja haben.

Wobei man wohl festhalten kann, dass es ein besonderes Verhalten des Safari ist. Ich habe leider keinen Mac, sonst hätte ich mal
versucht, den iPhone-Safari zu debuggen. Das remote-debugging geht aber leider nur mit einem parallelen Safari auf einem Mac.

micomat · 17 März 2014, 10:42:10

hm... also bei 50MBit/s ist von langsam wohl nicht mehr die Rede

Aber okay, vielleicht hat auch der Safari hier das Problem. Wobei ich im FHEMWEB schon manchmal sehr viele "instanzen" oder whatever it is... sehe. Muss mal nen Screenshot machen.

fruemmel · 17 März 2014, 11:00:00

Zitat von: micomat am 17 März 2014, 10:42:10
hm... also bei 50MBit/s ist von langsam wohl nicht mehr die Rede
Aber okay, vielleicht hat auch der Safari hier das Problem. Wobei ich im FHEMWEB schon manchmal sehr viele "instanzen" oder whatever it is... sehe. Muss mal nen Screenshot machen.

Bei mir sind es 35 MBit über VPN, aber ich vermute, dass hier eher die Latenzzeit eine Rolle spielt.
Ich hatte mir die Web-Connections mal mit verbose=4 angesehen. Da fällt nur auf, dass der Aufbau und das Close der connections nicht immer in derselben Reihenfolgen kommen.
Ich habe aber noch nicht geprüft, ob sich die Reihenfolge direkt mit geht/geht nicht in Verbindung setzen lässt. Vielleicht reagiert Safari ja auch empfindlich in Abhängigkeit
davon, in welcher Reihenfolge die geöffneten Connections vom RPi gefüllt bzw. wieder geschlossen werden.

micomat · 17 März 2014, 11:07:52

Naja TCP Sessions haben ja bekannterweise eine Session-ID bzw eine Zuordnung zu einem dynamischen Port.
Von daher sollte das kein Problem sein. Ein Close kann ja nur passieren wenn vorher ein open da war

Verkehrte welt. Bestimmt die NSA...

fruemmel · 17 März 2014, 11:16:33

Zitat von: micomat am 17 März 2014, 11:07:52
Naja TCP Sessions haben ja bekannterweise eine Session-ID bzw eine Zuordnung zu einem dynamischen Port.
Von daher sollte das kein Problem sein. Ein Close kann ja nur passieren wenn vorher ein open da war Verkehrte welt. Bestimmt die NSA...

Das hatte ich auch eher dämlich formuliert. Ich habe mal ein log von mir angehängt (Zugriff über VPN, iPhone funktioniert einwandfrei).
Die Close-Einbträge kommen erst deutlich später, z. B. beim Schließen von Safari. Ich meinte mit Reihenfolge die Durchmischung der
verschiedenen GETs mit den "Connection Accepted". Mir fehlt aber das Detailwissen, ob diese Reihenfolge einen Einfluss auf den Safari haben kann.