FHEM Forum

Hi,

Ich nutze fhem (raspberry) über Port 8085 webtablet mit ios7touchpad auf meinem iPhone und iPad und das Laden der Seiten dauert recht lange, wenn ich zu einem späteren Zeitpunkt wieder Safari öffne und die letzte Seite/Raum laden möchte wird diese erst nach langer Zeit > 30 Sekunden neu aufgebaut, schneller geht es nur wenn man die URL dann wieder auf die Home URL Host:Port/fhem setzt und dann den gewünschten Raum auswählt...

Eine kurzfristiges bedienen von Funktionen ist so jedoch nur schwer möglich.

Jemand ähnliche Phänomen bekannt?

Greetz
Eldrik

Sind vielleicht Plots in dem Raum vorhanden?
Ich hatte mal ein ähnliches Problem, oft half es denn ladevorgang an der adresszeile zu stoppen und neu anzustoßen... fhem ist aktuell?
Letztendlich habe ich neu aufgesetzt auf dem BBB danach war alles gut.

Hmm nee keine Plots und Fhem ist auf dem letzten Stand, kann mir das nicht erklären, gibt es denn keinen Weg dem ganzen näher auf den Grund zu gehen?

Greetz
Eldrik

Es gibt noch Perfmon und apptime...
Geb einfach mal apptime ins eingabefeld ein...
Perfmon musst du glaube ich runterladen - findest du sicher hier im Forum...

Zitat von: eldrik am 15 Februar 2014, 22:46:20
Hi,

Ich nutze fhem (raspberry) über Port 8085 webtablet mit ios7touchpad auf meinem iPhone und iPad und das Laden der Seiten dauert recht lange, wenn ich zu einem späteren Zeitpunkt wieder Safari öffne und die letzte Seite/Raum laden möchte wird diese erst nach langer Zeit > 30 Sekunden neu aufgebaut, schneller geht es nur wenn man die URL dann wieder auf die Home URL Host:Port/fhem setzt und dann den gewünschten Raum auswählt...

Eine kurzfristiges bedienen von Funktionen ist so jedoch nur schwer möglich.

Jemand ähnliche Phänomen bekannt?

Greetz
Eldrik

Ja, bei mir hängt es auch ab und zu mal. (FHEM auf FritzBox 7390, keine Plots)

Habe  es auf meinem Raspi laufen. Hängt leider auch fast immer. Das ist kein Performance Problem. Beim Schliessen und wieder öffnen sofort da.

Generell habe ich dieses Problem über 8085 auch. Egal ob iPad oder ein Android Tablet.

Mhh interessant ich habe das auch seit einiger Zeit, jetzt lese ich das hier zufällig ... Dachte erst das liegt an mir weil ich doch mehr und mehr eingebunden habe, aber komisch ist das schon ja.

Und an der Hardware kann es nicht liegen, das läuft bei mir auf einem Server der mehr als genug Leistung hat.

Gruß
Daniel

@all,
bei mir läuft FHEM auf einem Cubie2 (Dualcore 2x 1GHZ), die Unterschiede der Aufrufzeiten am iPad3 (IOS 7, Safari) und am PC (W7, Chrome) sind nicht wegzudiskutieren. Oft hilft am iPad Safari schließen und gleich noch mal aufrufen, dann gehts sofort. Eindruck auch von mir -> da läuft was nicht rund, und das ist nicht FHEM geschuldet.

Habt ihr auch mit dem demo config Probleme?

Das muss etwas mit dem Safari zu tun haben, wegen mehrere Streams zur Website. Habe jetzt auch festgestellt, wenn man auf das X für Abbrechen drückt und sofort aktualisiert, wird die Seite angezeigt.

@all

scheint nicht nur am Safari zu liegen, ich habe genau das selbe Verhalten mit Dolphin. Ich kann diese schlechte performance nur bei IOS7 Geräten beobachten. Android, Windows und Linux funktionieren perfekt. Ist schade, aber FHEM ist zur Zeit vom Ipad einfach nicht nutzbar.

Gruss

Karl

Jungs (oder Maedels?): wenn ihr meine Fragen nicht beantwortet, dann wird die Sache nur zufaellig geloest, ein "bei mir tut es auch nicht" zaehlt nicht als Antwort. Wer wirklich an einer Loesung interessiert ist, der baut eine minimale Konfiguration mit Bedienungsanleitung.

Hallo Rudolf,

habe leider zur Zeit kein Testsystem zur Verfügung. Habe zwar letze Woche mein CB2 bekommen, bin aber noch nicht dazugekommen das aufzusetzen.
Das produktive System steht für solche Tests nicht immer zur Verfügung, ohne dem geht fast nichts mehr (eigentlich bedenklich....).

Heute vormittag habe ich es mal ausprobiert, Antwortzeiten in der Demokonfiguration gut. Danach die produktive Konfiguration zurückkopiert und dann gleich mal neu gebootet.

Tja, und jetzt habe ich auch wieder mit dem Ipad vernünftige Antwortzeiten.

Also mein Problem ist jetzt mal gelöst, ich werde das aber mal weiter beobachten.

Gruss

Karl

Hallo Rudolf,

ich habe das Problem auch auf IOS 6 (Safari und Schnellverknüpfung - sowohl auf Port 8083, 8084 und 8085) Skins: ios7, ios7smallscreen und ios7touchpad
und mein System ist jetzt neu und daher noch sehr klein (auch noch ohne HM / FS20 Komponenten)

Mein System:
- Initial aufgesetzt letzten Freitag (sprich 3 Tage alt) mit Version 5.5 Dev (gestern nochmal geupdatet)
- Hardware: Raspberry Pi
- Inhalt: 2 Wifilight Lampen, ein Raumplan, 2 Cronjobs

Wann tritt das Problem auf?
- Safari mit Fhem war geöffnet.. ipad/iphone(problem mit beiden geräten identisch) gehen in Standby. Entsperren und z.B. Lampe anschalten -> es läd :/... oben schließen und neu laden -> geht
- Selbes Spiel mit einer Shortcutappverknüpfung: wenn App bereits offen -> keine Verbindung, Lösung App schließen und neustarten.
Ich tippe auf ein caching Problem im Safari :/

Teste heute Abend gerne auch mit Mercury und Crome

Viele Grüße
Sandra

PS: bin noch neu, daher was ist die demo config?
Ich kann meine gerne config gerne heute Abend zur Verfügung stellen, wie gesagt ist klein :)

@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

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

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.

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.

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

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

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

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...

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

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

@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.

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.

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.

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 :D Verkehrte welt. Bestimmt die NSA...

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 :D 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.

Vielleicht hilft mein aktueller Stand beim Lokalisieren: iOS Safari macht bis zu 6 parallele Verbindungen beim Laden auf, FHEMWEB bedient diese nur insoweit parallel, dass man nicht "aktiv" wartet. Separate Prozesse gibts nur fuer SVGs.
Wenn Safari meint, dass die Seite fertig geladen ist, wird nur noch eine Verbindung zu FHEMWEB zugelassen. Diesen braucht fhemweb.js fuer longpoll, aber das heisst, dass Safari keine Bilder (.png/.gif) nachladen kann.  Die SVGs werden "inline" in der longpoll Verbindung gesendet, deswegen funktionieren sie. Eine Session-Begrenzung gibts in FHEMWEB nicht, und Speicher-Engpass kommt auch nur fuer Plots mit gesetzten plotfork Attribut in Frage. Selbst das sollte auf einem RPi kein Problem sein, hoechstens auf einer FB.

Koennt ihr folgendes testen:
- Existiert das Problem auch ohne longpoll
- verbose 5 fuer die FHEMWEB Instanz, und mseclog fuer global setzen, und das Problem provozieren. Die 30-Sekunden muessen im Log sichtbar sein, das kurz davor und kurz danach interessiert mich.

Muss ich heute abend mal testen.

Gruß
Markus

Hallo Rudolf,

so, getestet. Longpoll auf 0 bringt nichts, auch da bleibt der weiße Bildschirm. Dann sogar deutlich länger.
Im Anhang die Logfiles. verbose=5 für die Web-Instanz, allerdings kommen nur Meldungen mit level 4.

In beiden Fällen kam ohne weitere Bedienung am iPhone nach einer Minute bzw. ohne Longpoll nach fast
zwei Minuten der fertige Screen.

Gruß Wolfgang

interessant...
beim whitescreen genau 5 geoeffnete sessions, genau das hab ich auch beobachtet.

so jetzt eben nochmal getestet...
mein iphone hat jetzt seid bestimmt 45sek nen weißen screen gehabt bevor was angezeigt wurde.
währenddessen

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53293 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:59233 pi-energy.fritz:cfinger ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53286 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53304 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54067 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53301 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53268 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54066 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53305 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54064 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:56036 fritz.box:1012          ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54062 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53302 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54065 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54063 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:ssh   micoeee-win8.frit:53307 ESTABLISHED


nach dem laden

Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 pi-fhem.fritz.box:59233 pi-energy.fritz:cfinger ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53268 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53305 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54068 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:56036 fritz.box:1012          ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54062 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:ssh   micoeee-win8.frit:53307 ESTABLISHED

jetzt kann ich problemlos zigmal nacheinander den ios-browser schließen und wieder aufmachen, alles bestens.
öffne ich jetzt webphone auf dem PC:

tcp        0      0 pi-fhem.fritz.box:59233 pi-energy.fritz:cfinger ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53354 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53353 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53352 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53305 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:56036 fritz.box:1012          ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53351 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53350 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53355 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:ssh   micoeee-win8.frit:53307 ESTABLISHED


und schon habe ich auf iphone wieder nen whitescreen.
es scheint dabei egal zu sein wieviele sessions auf welchem port zu sehen sind.

gruß
markus

Ich kann das auch bestätigen. Aktuelles IOS7 auf ipad2 und ipod 5 -> gleiches Sympton! Sobald ich auf abbrechen und neuladen klicke funktioniert es schnell (bei allen 3 Ports 8083-85)

Zitat von: P.A.Trick am 18 März 2014, 20:21:56
Ich kann das auch bestätigen. Aktuelles IOS7 auf ipad2 und ipod 5 -> gleiches Sympton! Sobald ich auf abbrechen und neuladen klicke funktioniert es schnell (bei allen 3 Ports 8083-85)

Ist bei mir auch exakt so.

Aber wie oben schon erwähnt: den Effekt habe ich nur auf meinem RPi als FHEM-Server. Verlagere ich die gleiche Installation auf ein debian auf einem schnellen PC, läuft auch auf dem iPhone alles perfekt. Ich habe nur keine Ahnung, wie man dem Grund (ggfls. Timing) auf die Schliche kommt.

hm... ein aehnlich "blockiertes" verhalten kenne ich sonst nur von plots.
wenn ich meinen heizungsraum aufrufe in dem 5 groessere plots drin sind blockier fhem auch solange bis alle plots gerendert sind. aber die werden ja beim blossen aufruf nicht erstellt...

Zitat von: micomat am 18 März 2014, 21:11:44
hm... ein aehnlich "blockiertes" verhalten kenne ich sonst nur von plots.
wenn ich meinen heizungsraum aufrufe in dem 5 groessere plots drin sind blockier fhem auch solange bis alle plots gerendert sind. aber die werden ja beim blossen aufruf nicht erstellt...

Selbst wenn ich als "Startraum" einen Raum mit nur einem einzigen Gerät anlege, ändert das nichts an dem Effekt mit dem weissen Schirm. Aber eine Blockade seitens FHEM scheidet ja eigentlich sowieso aus, da es auf nicht-Äpfeln das Problem ja auch nicht gibt ...

Stimmt unter Linux mit Firefox löppt alles perfekt und sauschnell. Ich glaube auch, dass es die Anzahl der gleichzeitig geöffneten Verbindungen ist, mit dem FHEM Probleme hat. Das würde auch zu dem Problem mit dem verschwindenen SVG Icons erklären.

Zitat von: fruemmel am 18 März 2014, 21:05:15

...den Effekt habe ich nur auf meinem RPi als FHEM-Server. Verlagere ich die gleiche Installation auf ein debian auf einem schnellen PC, läuft auch auf dem iPhone alles perfekt...

das war für mich der Grund im Herbst 2013 FHEM auf ein Cubie2 Board umzuziehen. Als es nach einiger Zeit da auch anfing, habe ich konsequent alle überflüssigen readings rausgeworfen (event-on-change-reading, event-on-update-reading, do_not_notify 1 etc.) Im Event monitor ansehen was so kommt und alles was man nicht braucht unterbinden - seither sind die Hänger auf dem iPad im größtenteils weg.

Ich bin aber ein Freund davon diese Kausalität aufzulösen und nicht einfach mit Ressourcen totzuschlagen, besonders da sich mein fhem sonst langweilt!

Koennt ihr in 01_FHEMWEB.pm vor der Zeile 386:
exit if(defined($pid));
folgende einfuegen
TcpServer_Close($hash); delete($defs{$hash->{NAME}});
und nochmal testen?
P.S: Ich weiss auch nicht wirklich, was los ist, und tappe nur im dunkeln...

tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62376 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62372 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62359 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62373 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62354 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62368 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62360 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:60187 pi-energy.fritz:cfinger ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54519 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62370 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:56990 fritz.box:1012          ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62367 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62375 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62364 ESTABLISHED
tcp        0    175 pi-fhem.fritz.box:8083  mico.fritz.:62369 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62374 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62365 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62355 ESTABLISHED
tcp        0    236 pi-fhem.fritz.box:ssh   mico.fritz.:62342 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62371 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54529 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62363 TIME_WAIT


Habs jetzt mal eingebaut.
Seitdem sind mehr Connections auf TIME_WAIT und gefuehlt auch schnelle wieder weg.
Ich werd mal testen :)

Markus

Es geht voran!

Zitat von: rudolfkoenig am 19 März 2014, 11:52:33
Koennt ihr in 01_FHEMWEB.pm vor der Zeile 386:

Code Auswählen Erweitern

exit if(defined($pid));
folgende einfuegen

Code Auswählen Erweitern

TcpServer_Close($hash); delete($defs{$hash->{NAME}});
und nochmal testen?
P.S: Ich weiss auch nicht wirklich, was los ist, und tappe nur im dunkeln...

Nach dem Tipp von Rudolf kann ich den weißen Bildschirm derzeit nicht reproduzieren. Gefühlt reagiert fhem beim Erstaufbau allerdings
etwas träger als vorher. D. h. vom Anklicken des WebApp-Icons von fhem bis zur Darstellung des Startraumes dauert es ca. 3 Sekunden.
Das muss ich aber noch einmal genauer testen.

Zumindest hat die Änderung definitiv etwas gebracht.

@Rudolf: Lässt das aus Deiner Sicht nun eine Erklärung der Ursache zu? Wenn ich meine subjektiven Tests zusammenfasse bleibt
folgendes Fazit (vor der Anpassung): Langsamer Server oder komplexe fhem-config: Weisser Schirm. Schneller Server / magere config: alles gut.
Weitere Vermutung: langsame Verbindung (DSL/VPN) dann geht es auch mit langsamem Server. Schnelles Netz (WLAN oder WLAN/VPN) geht nicht.

Gruß Wolfgang

Kann ich bestaetigen.
Den Fehler konnte ich bislang ebenfalls nicht mehr reproduzieren.

Gruß
Markus

Guten Morgen...

auch nicht wenn ihr einen weiteren Tab zu FHEM öffnet. Dieser läd bei mir jetzt nicht, so lange bis ich auf dem ersten Tab einen Änderung hervorrufe, dann wird auch der zweite fertig geladen. Ist zwar nicht weiter tragisch, aber erwähnen wollt ich das dann doch.
Die Meldung Connection Lost habe ich aber immernoch im Moment des neu ladens.

ZitatLässt das aus Deiner Sicht nun eine Erklärung der Ursache zu?

Mit viel Fantasie: auf langsamen Hardware wird bei einer Verbindung zu iOS Geraeten der TCP-Puffer nicht immer geleert. Ich habe jetzt das FHEMWEB Attribut closeConn eingebaut, damit Ihr FHEMWEB nicht immer patchen muesst. Falls jemand eine bessere Erklaerung bzw. bessere Loesung hat, bitte melden.

Mit der Loesung sollte es zwar langsamer werden, da man nicht mehr mehrere Dateien ueber die gleiche Verbindung holen kann, allerdings wuerde mich ein Faktor 2 ueberraschen.

Die Connection-Meldung ist normal, und nicht iOS/RPi spezifisch.

Zitat von: rudolfkoenig am 20 März 2014, 10:28:17
Mit viel Fantasie: auf langsamen Hardware wird bei einer Verbindung zu iOS Geraeten der TCP-Puffer nicht immer geleert. Ich habe jetzt das FHEMWEB Attribut closeConn eingebaut, damit Ihr FHEMWEB nicht immer patchen muesst. Falls jemand eine bessere Erklaerung bzw. bessere Loesung hat, bitte melden.

Mit der Loesung sollte es zwar langsamer werden, da man nicht mehr mehrere Dateien ueber die gleiche Verbindung holen kann, allerdings wuerde mich ein Faktor 2 ueberraschen.

Die Connection-Meldung ist normal, und nicht iOS/RPi spezifisch.

Hi Rudi, kommt das als Update?

soweit ich gesehen hab ist es bereits eingechecked.

Zitat von: micomat am 20 März 2014, 21:12:33
soweit ich gesehen hab ist es bereits eingechecked.

UPD 2014-03-17_07:45:16 106738 FHEM/01_FHEMWEB.pm
Update sagt aber noch nix, evt. morgen?

Wenn Du kurz einen Blick ins "fhem Code Changes" Board wirfst

FHEMWEB: closeConn attribute for forum issue #20294 Neu
gestern um 19Uhr :)

Gruß
Markus

Merci ;-)

Also ich habe es getestet, allerdings habe ich immer noch das gleiche Problem mit einem ipad2 und fhem auf der Fritte (7390).

Zitat von: P.A.Trick am 23 März 2014, 10:29:38
Also ich habe es getestet, allerdings habe ich immer noch das gleiche Problem mit einem ipad2 und fhem auf der Fritte (7390).

Hast Du auch beim richtigen FHEMWEB (WEBphone oder so) das connClose gesetzt? Bei mir klappt es mit der Änderung von Rudolf weiterhin einwandfrei.

Kann ich bestätigen. Mit gesetztem Attribut connClose (=1) für FHEMWEB WEBPhone und WEBTablet funktioniert es jetzt bestens mit iPhone und iPad auf dem jeweiligen Port 8084 und 8085. Für diese beiden FHEMWEB Instanzen habe ich auch iconPath auf openautomation:fhemSVG gesetzt, damit die Icons beim LongPoll nicht verschwinden.

Die normale FHEMWEB Instanz WEB auf Port 8083 habe ich unverändert gelassen.

Gruss
Tobias

Zitat von: tpm88 am 23 März 2014, 12:17:31
Kann ich bestätigen. Mit gesetztem Attribut connClose (=1) für FHEMWEB WEBPhone und WEBTablet funktioniert es jetzt bestens mit iPhone und iPad auf dem jeweiligen Port 8084 und 8085. Für diese beiden FHEMWEB Instanzen habe ich auch iconPath auf openautomation:fhemSVG gesetzt, damit die Icons beim LongPoll nicht verschwinden.

genau so! Und danke an die Entwickler.

Zitat von: tpm88 am 23 März 2014, 12:17:31
Kann ich bestätigen. Mit gesetztem Attribut connClose (=1) für FHEMWEB WEBPhone und WEBTablet funktioniert es jetzt bestens mit iPhone und iPad auf dem jeweiligen Port 8084 und 8085. Für diese beiden FHEMWEB Instanzen habe ich auch iconPath auf openautomation:fhemSVG gesetzt, damit die Icons beim LongPoll nicht verschwinden.

Die normale FHEMWEB Instanz WEB auf Port 8083 habe ich unverändert gelassen.

Gruss
Tobias

Das war es! Ich Depp hatte nicht das Attribut gesetzt :-/ Danke jetzt klappt es!

Bei mir dauer es leider auch ewig, bis die WebApp den Floorplan auf iPhone und iPad lädt.

Mit "attr WEBphone connClose 1" komme ich nicht weiter, da FHEM dieses Attribut nicht kennt. Oder wo muss ich das setzen?

FHEM auf FritzBox 7390

Bitte update durchfuehren.

Bei mir heisst das attr closeConn und *nicht* connClose ....

closeConn ist richtig, sorry fuer die Verwirrung.

Hallo,
oh zufällig habe ich diesen Thread entdeckt welcher genau mein Problem welches ich im EinplatinencomputerThread bereits berichtet habe.
Ich kam hier selbst zu diesem wait state für connection closed.
Allerdings nicht nur unter IOS sondern auch unter Windows mit Firefox. Mit Chrome geht es ohne jegliche Verzögerung.
Die Vermutung das es mit der Browser Engine zusammen hängt kann ich also bestätigen.

Soeben habe ich nun noch das update durchgeführt damit ich das Attribut setzen kann.
Bei meinem System möchte ich es aber global setzen da auch mein Firefox betroffen ist.
Hier holen mich scheinbar aber grade meine nicht vorhanden Perl Kenntnisse ein dich ich zwar noch beheben will aber das dauert noch etwas.

Ich habe das Attribut so wie es aussieht mangels Kenntnis falsch gesetzt. Falsche Stelle oder Syntax.
Ich habe die Beschreibung in Zeile 3420 gefunden und
     <a name="closeConn (=1)"></a>
gesetzt. Allerdings ohne wirkung.

Muss ich dies nun in Zeile 389 setzen damit es global fuer alle Browser wirkt ?

Gruss
Peter

Ich bewundere deine Fantasie, das Attribut so zu setzen waere mir nicht eingefallen.

Als Benutzer sollte man in der FHEM Eingabezeile (FHEMWEB oder telnet) folgendes eingeben:
attr TYPE=FHEMWEB closeConn 1
Alternativ kann man in Unsorted oder Everything alle FHEMWEB Instanzen einzeln anklicken, um in der Datail-Ansicht, Attribut Abschnitt aus dem Dropdown closeConn auswaehlen, und auf attr klicken zu koennen.

In beiden Faellen gefolgt von einem save.

Hallo,

nun die synatx hatte ich mehr oder weniger aus einem quote hier im Thread abgeleitet ;)
Also meine Änderungen rückgängig. Via Webinterface abgesetzt, save config und shutdown restart.
In der conf ist nun auf Zeile 128 ->     closeConn:1,0

Allerdings selbes Verhalten mit dem Firefox. Chrome weiterhin schnell.

Bzw die ersten beiden Aufrufe waren schnell und der dritte dannn wieder "ewig" gedauert.
Nach dem ConnClose gehts dann weiter
Die Lampensymbole bei beiden haben nun statt dem Lampenicon drei Fragezeichen

Ich brauche wohl doch dies hier :

ZitatFür diese beiden FHEMWEB Instanzen habe ich auch iconPath auf openautomation:fhemSVG gesetzt, damit die Icons beim LongPoll nicht verschwinden

Frage aber lieber nochmal nach wie ich dies machen soll bevor ich wieder zu Fantasievoll bin  ;)
Ob über Web oder direkt via Vi ist mir gleich ...

Apple devices muss ich noch testen.
Bisher war es so ... Firefox latenz 20-30sec, Apple IOS 60sec

Update Apple ... mit dem iphone kann ich aktuell nicht mehr nachstellen. Ich werde weiter testen.
Méin Firefox scheint weiterhin eine Krücke zu sein. Frage mich ob das nur an diesem Rechner liegt.
Habe aktuell grade kein anderes Win mit FF hier werde aber weiter beobachten.
Ich scheine ja der erste mit diesem Problem zu sein ... Firefox V28

Anbei das Log :

Zitat
Chrome

2014.04.06 16:43:40 4: Connection closed for FHEMWEB:x.x.x.x:33230
2014.04.06 16:43:40 4: Connection accepted from FHEMWEB:x.x.x.x:33346
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33346 GET /fhem?room=FS20
2014.04.06 16:43:40 4: /fhem?room=FS20 / RL:1298 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.04.06 16:43:40 4: Connection accepted from FHEMWEB:x.x.x.x:33347
2014.04.06 16:43:40 4: Connection accepted from FHEMWEB:x.x.x.x:33348
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33347 GET /fhem/pgm2/style.css
2014.04.06 16:43:40 4: Connection accepted from FHEMWEB:x.x.x.x:33349
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33348 GET /fhem/pgm2/svg.js
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33349 GET /fhem/pgm2/fhemweb.js
2014.04.06 16:43:40 4: Connection accepted from FHEMWEB:x.x.x.x:33350
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33347 GET /fhem/pgm2/fhemweb_slider.js
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33349 GET /fhem/pgm2/fhemweb_textField.js
2014.04.06 16:43:40 4: Connection accepted from FHEMWEB:x.x.x.x:33351
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33348 GET /fhem/pgm2/fhemweb_svg.js
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33350 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33351 GET /fhem/pgm2/fhemweb_multiple.js
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33349 GET /fhem/images/default/icoEverything.png
2014.04.06 16:43:40 4: Connection accepted from FHEMWEB:x.x.x.x:33352
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33348 GET /fhem/pgm2/dashboard_darkstyle.css
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33347 GET /fhem/pgm2/fhemweb_time.js
2014.04.06 16:43:40 4: HTTP FHEMWEB:x.x.x.x:33352 GET /fhem/pgm2/fhemweb_noArg.js
2014.04.06 16:43:41 4: HTTP FHEMWEB:x.x.x.x:33352 GET /fhem/images/default/fhemicon_dark.png
2014.04.06 16:43:41 4: HTTP FHEMWEB:x.x.x.x:33352 GET /fhem?XHR=1&inform=type=status;filter=room=FS20&timestamp=1396802617066


Firefox :


2014.04.06 16:44:57 4: Connection accepted from FHEMWEB:x.x.x.x:33378
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33378 GET /fhem?room=FS20
2014.04.06 16:44:57 4: /fhem?room=FS20 / RL:1298 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.04.06 16:44:57 4: Connection accepted from FHEMWEB:x.x.x.x:33379
2014.04.06 16:44:57 4: Connection accepted from FHEMWEB:x.x.x.x:33380
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33379 GET /fhem/pgm2/style.css
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33380 GET /fhem/pgm2/svg.js
2014.04.06 16:44:57 4: Connection accepted from FHEMWEB:x.x.x.x:33381
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33380 GET /fhem/pgm2/dashboard_darkstyle.css
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33381 GET /fhem/pgm2/fhemweb.js
2014.04.06 16:44:57 4: Connection accepted from FHEMWEB:x.x.x.x:33382
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33379 GET /fhem/pgm2/fhemweb_time.js
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33380 GET /fhem/icons/favicon
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33382 GET /fhem/pgm2/fhemweb_noArg.js
2014.04.06 16:44:57 4: Connection accepted from FHEMWEB:x.x.x.x:33383
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33383 GET /fhem/pgm2/fhemweb_slider.js
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33381 GET /fhem/icons/favicon
2014.04.06 16:44:57 4: Connection accepted from FHEMWEB:x.x.x.x:33384
2014.04.06 16:44:57 4: Connection accepted from FHEMWEB:x.x.x.x:33385
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33384 GET /fhem/pgm2/fhemweb_svg.js
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33385 GET /fhem/pgm2/fhemweb_textField.js
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33383 GET /fhem/images/default/fhemicon_dark.png
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33383 GET /fhem/images/default/icoEverything.png
2014.04.06 16:44:57 4: HTTP FHEMWEB:x.x.x.x:33383 GET /fhem?XHR=1&inform=type=status;filter=room=FS20&timestamp=1396802693643
2014.04.06 16:45:09 4: Connection closed for FHEMWEB:x.x.x.x:33383
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33382 GET /fhem?room=Unsorted
2014.04.06 16:45:09 4: /fhem?room=Unsorted / RL:1329 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33380 GET /fhem/pgm2/svg.js
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33385 GET /fhem/pgm2/fhemweb_textField.js
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33381 GET /fhem/pgm2/fhemweb.js
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33384 GET /fhem/pgm2/fhemweb_svg.js
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33379 GET /fhem/pgm2/style.css
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33380 GET /fhem/icons/favicon
2014.04.06 16:45:09 4: Connection accepted from FHEMWEB:x.x.x.x:33386
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33386 GET /fhem/pgm2/fhemweb_time.js
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33385 GET /fhem/pgm2/dashboard_darkstyle.css
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33381 GET /fhem/icons/favicon
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33384 GET /fhem/images/default/fhemicon_dark.png
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33379 GET /fhem/images/default/icoEverything.png
2014.04.06 16:45:09 4: HTTP FHEMWEB:x.x.x.x:33380 GET /fhem?XHR=1&inform=type=status;filter=room=Unsorted&timestamp=1396802705610
2014.04.06 16:45:12 4: Connection closed for FHEMWEB:x.x.x.x:33380
2014.04.06 16:45:12 4: HTTP FHEMWEB:x.x.x.x:33386 GET /fhem?room=FS20
2014.04.06 16:45:12 4: /fhem?room=FS20 / RL:1298 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.04.06 16:45:12 4: HTTP FHEMWEB:x.x.x.x:33385 GET /fhem/pgm2/style.css
2014.04.06 16:45:12 4: HTTP FHEMWEB:x.x.x.x:33381 GET /fhem/pgm2/svg.js
2014.04.06 16:45:12 4: HTTP FHEMWEB:x.x.x.x:33384 GET /fhem/pgm2/fhemweb.js
2014.04.06 16:45:12 4: HTTP FHEMWEB:x.x.x.x:33379 GET /fhem/pgm2/fhemweb_svg.js
2014.04.06 16:45:12 4: HTTP FHEMWEB:x.x.x.x:33385 GET /fhem/pgm2/fhemweb_time.js
2014.04.06 16:45:12 4: HTTP FHEMWEB:x.x.x.x:33381 GET /fhem/icons/favicon
2014.04.06 16:45:12 4: HTTP FHEMWEB:x.x.x.x:33384 GET /fhem/pgm2/dashboard_darkstyle.css
2014.04.06 16:45:12 4: HTTP FHEMWEB:x.x.x.x:33385 GET /fhem/icons/favicon
2014.04.06 16:45:43 4: Connection closed for FHEMWEB:x.x.x.x:33379
2014.04.06 16:45:43 4: HTTP FHEMWEB:x.x.x.x:33381 GET /fhem/images/default/fhemicon_dark.png
2014.04.06 16:45:43 4: HTTP FHEMWEB:x.x.x.x:33384 GET /fhem/images/default/icoEverything.png
2014.04.06 16:45:44 4: HTTP FHEMWEB:x.x.x.x:33385 GET /fhem?XHR=1&inform=type=status;filter=room=FS20&timestamp=1396802739862

Nach dem Umstieg auf Cubietruck keine Hänger mehr bei Apple Devices auch ohne gesetztem Attribut. Hat man bei gesetztem CloseConn eigentlich irgendwelche Nachteile?

Mit closeConn ist FHEMWEB etwas uneffizienter als ohne, da der Browser fuer alle Bilder/.css/.js/etc eine separate Verbindung aufbauen muss.

gilt das fürs komplette FHEMWEB oder nur für Webtablet z.b. ?

Ich kram das mal nochmal hervor: Ich bin vor einer Weile vom Raspberry auf den Cubietruck umgezogen - und im Vergleich zu normalen Webseiten hat FHEM trotz nun überdimensionierter Hardware und bei unter ca. 2% CPU-Load immer sehr träge reagiert. Ich hab das mal mit Firebug angeschaut: Latenzen über zwei Sekunden für den Seitenaufbau (auch bei wenig vollgestopften Seiten) - das merkte man und nervte.

Ich hab mich dann an closeConn erinnert - ausgemacht - und siehe da: Immens schneller, jetzt bin ich bei 200-300ms für vollgestopfte Räume und es ist wieder angenehm zu benutzen! Das beantwortet vllt. lolos noch offene Frage.

Natürlich hab ich nun unter IOS 7 / Safari wieder die gleichen Issues. Also gelegentlich weiße Seiten - aber weniger oft als mit dem Raspberry. Mein Workaround ist aktuell ein anderer Webbrowser (Atomic Webbrowser) ... Mit dem klappt es auch aufm Ipad.

Hallo,
habe bei mir leider das selbige Problem. Es ist wirklich ärglerlich wenn man sich etwas ansehen will (zeichne eigenlich nur auf mit FHEM, fürs erste) und dann dauert es ewig bis die Seite aufgeht. Ich habe natürlich mehrere Graph's auf der Seite. Aber es macht irgendwie keinen Unterschied. Und das lustige ist ja das nicht mal der Prozessor belastet wird. Ich kann mir nicht vorstellen das es sozusagen also an zu schwacher Hardware liegt. Den ein Dual-Core Prozessor mit 2,7Ghz sollt das ja bewerkstelligen.

Ist das Problem bei mir vielleicht wirklich das ich die Daten in eine MYSQL-DB schreibe und z.b. nicht in eine SQL-Lite? Bilde mir ein im Forum mal gelesen zu haben das das zu Problemen führen kann.

Wäre wirklich sehr sehr dankbar wenn wir das irgendwie flotter hinbekommen könnten oder mir jemand einen Ratschlag geben könnte was man wo optimieren kann.

Danke!
Sg
Manuel

1. Hilft es, wenn du closeConn setzt?
2. Kannst du bitte einen Seitenaufbau mit "attr global verbose 5" protokollieren, und das Log hier zeigen?
3. Mich wuerde interessieren, ob im HTTP-Header "Connection: keep-alive" gesetzt ist. Das kriegt man auch raus, indem man FHEM/01_FHEMWEB.pm modifiziert, und vor der Zeile
  delete($hash->{HDR});
folgende beiden einfuegt:
  Log 1, "\n\n\n";
  Log 1, $hash->{HDR};


hallo,

ich hatte auch Probleme dass plötzlich die Seite nicht mehr aufgebaut wird. Mit 'netstat -an' hab ich dann gesehen, dass viele TCP-Verbindungen zum FHEM-Server offen sind. Ich hab dann im Browser (Opera) die Anzahl der Verbindungen zu einem Server von 16 auf 64 erhöht. Seither hatte ich keine Probleme.

lg didi

Kann jemand bestätigen, daß es mit IOS8 wieder wieder extrem lange dauert die Seite zu laden? WinDose, C64 und Android laden wie immer im Sprinttempo FHEM. Auch das schon gesetzte Attribut CloseConn hilft diesmal bei mir nicht.

es gibt mit ios8 scheinbar inverse probleme. siehe auch hier: http://forum.fhem.de/index.php/topic,27211.msg201366.html#msg201366 (http://forum.fhem.de/index.php/topic,27211.msg201366.html#msg201366)

gruss
  andre

Zitat von: Dittel am 21 September 2014, 15:34:57
Kann jemand bestätigen das es mit IOS8 wieder wieder extrem lange dauert die Seite zu laden? WinDose, C64 und Android laden wie immer im Sprinttempo FHEM. Auch das schon gesetzte Attribut CloseConn hilft diesmal bei mir nicht.

Ja, kann ich bestätigen (ipad2 mit IOS8). Siehe auch hier: http://forum.fhem.de/index.php/topic,27211.msg201366.html#msg201366

Leider kann es Rudi im Emulator nicht nachvollziehen.

Gruss
Tobias

Elendig langsam auch bei mir (iOS 8.02).

genau so, iOS 8.02 auf iPad 3 - mußte von Sandras IOS6 Style wieder zum gelben Standart Style wechseln, sonst ging es garnicht mehr. Spaß macht das so nicht!

...hat zwar nichts mit FHEM zu tun, aber der ganze Safari ist verhunzt. Wie man den bisher einfachen und guten Browser derart verwurschteln kann ist mir ein Rätsel. Fängt bei der sinnlos verschwindenden Navleiste an, die vllt 3mm mehr Bildschirm schafft, geht über die Bookmarks die man erst wieder weg drücken muss und hört beim umständlichen Private Handling wieder auf. Aber Hauptsache die Spotlight Suche wird immer fetter. [emoji34]

Zitat von: det. am 30 September 2014, 18:12:11
genau so, iOS 8.02 auf iPad 3 - mußte von Sandras IOS6 Style wieder zum gelben Standart Style wechseln, sonst ging es garnicht mehr. Spaß macht das so nicht!

Das hat bei mir leider gar nichts gebracht.

habt ihr schon mit mercury oder chrome getestet?

Habe leider kein iOS 8 zum testen, nicht dass es doch wieder ein Longpoll Problem ist, dass sich so eingeschlichen hat.
Welche Seiten sind denn besonders langsam?

@det. Schade :( wahrscheinlich schafft er die CSS Befehle nicht (runde Ecken, Einfärben SVGs, Schatten etc.) obwohl das Standard HTML5 Sachen sind und eigentlich ein neuer Browser das können sollte.... aber der IE ist ja auch eine Sache für sich

Mit Chrome und dem neuen Attribut plotEmbed kann ich unter IOS 8.02 einwandfrei arbeiten (Dark Style). Dazu gibts auch einen eigenen Thread hier im Forum...

Gruss
Tobias

Ich versuche  immer noch, die apple-Problematik einzugrenzen. Auf meinem iPhone 5S ist der Safari für FHEM-Web nicht zu gebrauchen. Entweder geht gar nichts, oder es dauert ewig.
Ich habe gestern abend hoffnungsvoll auf iOS 8.1.1 updgedatet, aber geändert hat sich nix.
Andererseits läuft FHEM-Web auf meinem iPad4 (iOS 8.1) realtiv reibungslos, auch als WebApp über den Homescreen. Es sieht also für mich so aus, als gäbe es doch irgendwas gerätespezifisches, was das Verhalten beeinflusst.
Mit google chrome läuft FHEM-Web auch auf dem iPhone, aber das kann vom Komfort her eben nicht mit dem direkten Aufruf über ein WebApp-Icon mithalten. Mercury und Dolphin verhalten sich bei mir auf dem iPhone genauso mies wie der Safari.

Bei mir läuft als Server ein Raspberry PI. Ich dachte bisher immer, dass die Probleme stark durch die eingeschränkte Performance des RPI begründet sind. Nun sehe ich aber hier z. B. etliche Cubieboard-User, die anscheinend die Probleme auch haben, oder sehe ich das falsch?

Andersrum: Gibt es iPhone-User mit iOS 8, die mit einem Raspberry oder vergleichbarer Hardware gut mit Safari bzw. einem Homescree-Icon arbeiten können?

Gerade erst über den Thread gestolpert. Ich hatte auch Performance-Probleme, hier mal mein Phänomen (ich brauche keine Lösung mehr, vielleicht hilfts Euch ja).
Ich habe ein wenig rumexperimentiert, wollte zuerst Dashboard einsetzen, bin jetzt aber beim Floorplan gelandet.
FHEM ist auf raspberry, Konfigurieren auf Laptop mit Chrome, Bedienen über Tablet (Galaxy Tab 10.1 mit Cyanogen, iPad Air mit iOS 8).

- Aufruf über Laptop: alles wunderbar für normale FHEMWEB-Oberfläche, Floorplan, Dashboard
- Aufruf über Tablet & iPad (gleiches Verhalten): Standard-GUI mit normaler Speed, aber schweinelangsam beim Floorplan (Direktaufruf der Floorplan-URL), der kam erst nach ein paar Minuten. Beim iPad kein maßgeblicher Unterschied zwischen Chrome und Safari.

Ich hab alles mögliche ausprobiert, z.B. auch das closeconn-Attribut, hat nix geholfen. Die Lösung war dann: ich hatte als defaultRoom noch das Dashboard drin. Attribut rausgenommen, und *schwupp* schon hat sich der Floorplan vernünftig laden lassen. Keine Ahnung, warum beim Direktaufruf der URL der defaultroom einen Unterschied macht, ggf. auch so gewollt...

Jedenfalls kann ich so weiterarbeiten. Raspi-Performance ist nicht das Problem, weil's ja vom Laptop auch funktioniert. CSS geht auch prinzipiell, der Floorplan nutzt das ja auch - vermutlich aber nicht so massiv wie das Dashboard.

Leider hat auch ein Test mit dem defaultRoom keine Veränderung gebracht. Außerdem musste ich feststellen, dass auch meine ursprünglich positiven Versuche am iPad nicht von dauerhafter Natur sind. Auch am iPad kommt es zu extrem langen Wartezeiten beim Seitenaufbau. Außer eben bei Google Chrome.

Kannst du so eine Wartezeit mit "attr global verbose 5" protokollieren und evtl. kommentieren (hier habe ich geklickt, hier kamen die Daten an, usw.). Und kannst du es danach mit "attr WEB longpoll 0" auch probieren?

Hallo Rudi,

ich hab die Hänger ebenso. iPhone 6 iOS 8.1.1

Hier mal ein auszug aus dem Log.
2014.11.18 17:19:18.458 4: Connection accepted from FHEMWEB:10.0.0.1:51304
2014.11.18 17:19:18.461 4: HTTP FHEMWEB:10.0.0.1:51304 GET /fhem?room=1.%20Wohnzimmer
2014.11.18 17:19:18.476 5: ENIGMA2 wzReceiver: called function ENIGMA2_Set()
2014.11.18 17:19:18.483 5: ENIGMA2 wzReceiver: called function ENIGMA2_Set()
2014.11.18 17:19:18.491 5: plotcommand: get lp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 FileLog:FileLog_wzMacMini:4:wzMacMini.power\x3a:: FileLog:FileLog_wzMacMini:4:wzMacMini.consumptionTotal\x3a::
2014.11.18 17:19:18.491 5: Cmd: >get lp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 FileLog:FileLog_wzMacMini:4:wzMacMini.power\x3a:: FileLog:FileLog_wzMacMini:4:wzMacMini.consumptionTotal\x3a::<
2014.11.18 17:19:18.491 4: lp: calling get FileLog_wzMacMini CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzMacMini.power\x3a::
2014.11.18 17:19:18.491 5: Cmd: >get FileLog_wzMacMini CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzMacMini.power\x3a::<
2014.11.18 17:19:18.491 4: FileLog_wzMacMini get: Input file ./log/wzMacMini-2014-11.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.508 4: FileLog_wzMacMini get: line 1, regexp:wzMacMini.power\x3a, col:3, output lines:1941
2014.11.18 17:19:18.508 4: lp: calling get FileLog_wzMacMini CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzMacMini.consumptionTotal\x3a::
2014.11.18 17:19:18.509 5: Cmd: >get FileLog_wzMacMini CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzMacMini.consumptionTotal\x3a::<
2014.11.18 17:19:18.509 4: FileLog_wzMacMini get: Input file ./log/wzMacMini-2014-11.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.518 4: FileLog_wzMacMini get: line 1, regexp:wzMacMini.consumptionTotal\x3a, col:3, output lines:23
2014.11.18 17:19:18.537 5: plotcommand: get lp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 FileLog:FileLog_Wohnzimmer:4:Wohnzimmer.T\x3a:: ConstY:$data{avg1} FileLog:FileLog_Wohnzimmer:6:Wohnzimmer.T\x3a:: FileLog:FileLog_wzHeizungSollTemp,predict:4:desired\x3a:: FileLog:FileLog_wzPID:4:wzHeizung.actuation\x3a:: ConstX:$data{maxdate1},$data{avg1},$data{max1} ConstX:$data{mindate1},$data{avg1},$data{min1} ConstX:logProxy_shiftTime($data{currdate1},0),$data{currval1}+0.00001 ConstX:logProxy_shiftTime($data{currdate3},0),$data{currval3}+0.00001 ConstX:logProxy_shiftTime($data{currdate5},0),$data{currval5}+0.00001 ConstX:logProxy_shiftTime($data{maxdate1},0),$data{max1}+0.00001 ConstX:logProxy_shiftTime($data{mindate1},0),$data{min1}+0.00001 ConstX:logProxy_shiftTime($data{currdate4},0),$data{currval4}+0.00001
2014.11.18 17:19:18.538 5: Cmd: >get lp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 FileLog:FileLog_Wohnzimmer:4:Wohnzimmer.T\x3a:: ConstY:$data{avg1} FileLog:FileLog_Wohnzimmer:6:Wohnzimmer.T\x3a:: FileLog:FileLog_wzHeizungSollTemp,predict:4:desired\x3a:: FileLog:FileLog_wzPID:4:wzHeizung.actuation\x3a:: ConstX:$data{maxdate1},$data{avg1},$data{max1} ConstX:$data{mindate1},$data{avg1},$data{min1} ConstX:logProxy_shiftTime($data{currdate1},0),$data{currval1}+0.00001 ConstX:logProxy_shiftTime($data{currdate3},0),$data{currval3}+0.00001 ConstX:logProxy_shiftTime($data{currdate5},0),$data{currval5}+0.00001 ConstX:logProxy_shiftTime($data{maxdate1},0),$data{max1}+0.00001 ConstX:logProxy_shiftTime($data{mindate1},0),$data{min1}+0.00001 ConstX:logProxy_shiftTime($data{currdate4},0),$data{currval4}+0.00001<
2014.11.18 17:19:18.538 4: lp: calling get FileLog_Wohnzimmer CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:Wohnzimmer.T\x3a::
2014.11.18 17:19:18.538 5: Cmd: >get FileLog_Wohnzimmer CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:Wohnzimmer.T\x3a::<
2014.11.18 17:19:18.538 4: FileLog_Wohnzimmer get: Input file ./log/Wohnzimmer-2014.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.543 4: FileLog_Wohnzimmer get: line 1, regexp:Wohnzimmer.T\x3a, col:3, output lines:346
2014.11.18 17:19:18.543 4: lp: calling get FileLog_Wohnzimmer CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 6:Wohnzimmer.T\x3a::
2014.11.18 17:19:18.543 5: Cmd: >get FileLog_Wohnzimmer CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 6:Wohnzimmer.T\x3a::<
2014.11.18 17:19:18.543 4: FileLog_Wohnzimmer get: Input file ./log/Wohnzimmer-2014.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.548 4: FileLog_Wohnzimmer get: line 1, regexp:Wohnzimmer.T\x3a, col:5, output lines:346
2014.11.18 17:19:18.549 4: lp: calling get FileLog_wzHeizungSollTemp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:desired\x3a::
2014.11.18 17:19:18.549 5: Cmd: >get FileLog_wzHeizungSollTemp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:desired\x3a::<
2014.11.18 17:19:18.549 4: FileLog_wzHeizungSollTemp get: Input file ./log/wzHeizungSollTemp-2014.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.549 4: FileLog_wzHeizungSollTemp get: line 1, regexp:desired\x3a, col:3, output lines:8
2014.11.18 17:19:18.549 4: lp: calling get FileLog_wzPID CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzHeizung.actuation\x3a::
2014.11.18 17:19:18.549 5: Cmd: >get FileLog_wzPID CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzHeizung.actuation\x3a::<
2014.11.18 17:19:18.549 4: FileLog_wzPID get: Input file ./log/wzPID-2014-11.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.551 4: FileLog_wzPID get: line 1, regexp:wzHeizung.actuation\x3a, col:3, output lines:107
2014.11.18 17:19:18.571 4: /fhem?room=1.%20Wohnzimmer / RL:25144 / text/html; charset=UTF-8 / Content-Encoding: gzip

/
2014.11.18 17:19:18.661 4: Connection accepted from FHEMWEB:10.0.0.1:51305
2014.11.18 17:19:18.662 4: Connection accepted from FHEMWEB:10.0.0.1:51306
2014.11.18 17:19:18.666 4: HTTP FHEMWEB:10.0.0.1:51305 GET /fhem/pgm2/ios7smallscreenFabian.css
2014.11.18 17:19:18.667 4: HTTP FHEMWEB:10.0.0.1:51306 GET /fhem/pgm2/style.css
2014.11.18 17:19:18.677 4: HTTP FHEMWEB:10.0.0.1:51305 GET /fhem/pgm2/fhemweb.js
2014.11.18 17:19:18.792 4: HTTP FHEMWEB:10.0.0.1:51306 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.11.18 17:19:18.793 4: Connection accepted from FHEMWEB:10.0.0.1:51307
2014.11.18 17:19:18.795 4: Connection accepted from FHEMWEB:10.0.0.1:51308
2014.11.18 17:19:18.796 4: Connection accepted from FHEMWEB:10.0.0.1:51309
2014.11.18 17:19:18.796 4: Connection accepted from FHEMWEB:10.0.0.1:51310
2014.11.18 17:19:18.797 4: HTTP FHEMWEB:10.0.0.1:51307 GET /fhem/pgm2/svg.js
2014.11.18 17:19:18.797 4: HTTP FHEMWEB:10.0.0.1:51307 GET /fhem/pgm2/fhemweb_restart.js
2014.11.18 17:19:18.798 4: HTTP FHEMWEB:10.0.0.1:51307 GET Mobile/12B436
2014.11.18 17:19:18.798 4: WEBphone: redirecting Mobile/12B436 to /fhem
2014.11.18 17:19:18.798 4: HTTP FHEMWEB:10.0.0.1:51305 GET /fhem/pgm2/ios7Common.css
2014.11.18 17:19:18.798 4: HTTP FHEMWEB:10.0.0.1:51306 GET /fhem/images/default/Prev.png
2014.11.18 17:19:18.799 4: HTTP FHEMWEB:10.0.0.1:51308 GET /fhem/pgm2/fhemweb_multiple.js
2014.11.18 17:19:18.801 4: HTTP FHEMWEB:10.0.0.1:51309 GET /fhem/pgm2/fhemweb_noArg.js
2014.11.18 17:19:18.801 4: HTTP FHEMWEB:10.0.0.1:51310 GET /fhem/pgm2/fhemweb_readingsHistory.js
2014.11.18 17:19:18.815 4: HTTP FHEMWEB:10.0.0.1:51306 GET /fhem
2014.11.18 17:19:18.827 5: ENIGMA2 wzReceiver: called function ENIGMA2_Set()
2014.11.18 17:19:18.834 5: ENIGMA2 wzReceiver: called function ENIGMA2_Set()
2014.11.18 17:19:18.842 5: plotcommand: get lp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 FileLog:FileLog_wzMacMini:4:wzMacMini.power\x3a:: FileLog:FileLog_wzMacMini:4:wzMacMini.consumptionTotal\x3a::
2014.11.18 17:19:18.842 5: Cmd: >get lp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 FileLog:FileLog_wzMacMini:4:wzMacMini.power\x3a:: FileLog:FileLog_wzMacMini:4:wzMacMini.consumptionTotal\x3a::<
2014.11.18 17:19:18.842 4: lp: calling get FileLog_wzMacMini CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzMacMini.power\x3a::
2014.11.18 17:19:18.842 5: Cmd: >get FileLog_wzMacMini CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzMacMini.power\x3a::<
2014.11.18 17:19:18.842 4: FileLog_wzMacMini get: Input file ./log/wzMacMini-2014-11.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.859 4: FileLog_wzMacMini get: line 1, regexp:wzMacMini.power\x3a, col:3, output lines:1941
2014.11.18 17:19:18.859 4: lp: calling get FileLog_wzMacMini CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzMacMini.consumptionTotal\x3a::
2014.11.18 17:19:18.859 5: Cmd: >get FileLog_wzMacMini CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzMacMini.consumptionTotal\x3a::<
2014.11.18 17:19:18.860 4: FileLog_wzMacMini get: Input file ./log/wzMacMini-2014-11.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.869 4: FileLog_wzMacMini get: line 1, regexp:wzMacMini.consumptionTotal\x3a, col:3, output lines:23
2014.11.18 17:19:18.888 5: plotcommand: get lp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 FileLog:FileLog_Wohnzimmer:4:Wohnzimmer.T\x3a:: ConstY:$data{avg1} FileLog:FileLog_Wohnzimmer:6:Wohnzimmer.T\x3a:: FileLog:FileLog_wzHeizungSollTemp,predict:4:desired\x3a:: FileLog:FileLog_wzPID:4:wzHeizung.actuation\x3a:: ConstX:$data{maxdate1},$data{avg1},$data{max1} ConstX:$data{mindate1},$data{avg1},$data{min1} ConstX:logProxy_shiftTime($data{currdate1},0),$data{currval1}+0.00001 ConstX:logProxy_shiftTime($data{currdate3},0),$data{currval3}+0.00001 ConstX:logProxy_shiftTime($data{currdate5},0),$data{currval5}+0.00001 ConstX:logProxy_shiftTime($data{maxdate1},0),$data{max1}+0.00001 ConstX:logProxy_shiftTime($data{mindate1},0),$data{min1}+0.00001 ConstX:logProxy_shiftTime($data{currdate4},0),$data{currval4}+0.00001
2014.11.18 17:19:18.888 5: Cmd: >get lp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 FileLog:FileLog_Wohnzimmer:4:Wohnzimmer.T\x3a:: ConstY:$data{avg1} FileLog:FileLog_Wohnzimmer:6:Wohnzimmer.T\x3a:: FileLog:FileLog_wzHeizungSollTemp,predict:4:desired\x3a:: FileLog:FileLog_wzPID:4:wzHeizung.actuation\x3a:: ConstX:$data{maxdate1},$data{avg1},$data{max1} ConstX:$data{mindate1},$data{avg1},$data{min1} ConstX:logProxy_shiftTime($data{currdate1},0),$data{currval1}+0.00001 ConstX:logProxy_shiftTime($data{currdate3},0),$data{currval3}+0.00001 ConstX:logProxy_shiftTime($data{currdate5},0),$data{currval5}+0.00001 ConstX:logProxy_shiftTime($data{maxdate1},0),$data{max1}+0.00001 ConstX:logProxy_shiftTime($data{mindate1},0),$data{min1}+0.00001 ConstX:logProxy_shiftTime($data{currdate4},0),$data{currval4}+0.00001<
2014.11.18 17:19:18.888 4: lp: calling get FileLog_Wohnzimmer CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:Wohnzimmer.T\x3a::
2014.11.18 17:19:18.888 5: Cmd: >get FileLog_Wohnzimmer CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:Wohnzimmer.T\x3a::<
2014.11.18 17:19:18.888 4: FileLog_Wohnzimmer get: Input file ./log/Wohnzimmer-2014.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.893 4: FileLog_Wohnzimmer get: line 1, regexp:Wohnzimmer.T\x3a, col:3, output lines:346
2014.11.18 17:19:18.893 4: lp: calling get FileLog_Wohnzimmer CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 6:Wohnzimmer.T\x3a::
2014.11.18 17:19:18.893 5: Cmd: >get FileLog_Wohnzimmer CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 6:Wohnzimmer.T\x3a::<
2014.11.18 17:19:18.894 4: FileLog_Wohnzimmer get: Input file ./log/Wohnzimmer-2014.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.899 4: FileLog_Wohnzimmer get: line 1, regexp:Wohnzimmer.T\x3a, col:5, output lines:346
2014.11.18 17:19:18.899 4: lp: calling get FileLog_wzHeizungSollTemp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:desired\x3a::
2014.11.18 17:19:18.899 5: Cmd: >get FileLog_wzHeizungSollTemp CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:desired\x3a::<
2014.11.18 17:19:18.899 4: FileLog_wzHeizungSollTemp get: Input file ./log/wzHeizungSollTemp-2014.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.899 4: FileLog_wzHeizungSollTemp get: line 1, regexp:desired\x3a, col:3, output lines:8
2014.11.18 17:19:18.899 4: lp: calling get FileLog_wzPID CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzHeizung.actuation\x3a::
2014.11.18 17:19:18.899 5: Cmd: >get FileLog_wzPID CURRENT INT 2014-11-18_00:00:00 2014-11-19_00:00:01 4:wzHeizung.actuation\x3a::<
2014.11.18 17:19:18.899 4: FileLog_wzPID get: Input file ./log/wzPID-2014-11.log, from:2014-11-18_00:00:00  to:2014-11-19_00:00:01
2014.11.18 17:19:18.900 4: FileLog_wzPID get: line 1, regexp:wzHeizung.actuation\x3a, col:3, output lines:107
2014.11.18 17:19:18.917 4: /fhem / RL:25144 / text/html; charset=UTF-8 / Content-Encoding: gzip

/
2014.11.18 17:19:23.131 5: JeeLink/RAW: /OK 24 7 4 13 141 228 0 0 0
2014.11.18 17:19:23.147 5: JeeLink/RAW: OK 24 7 4 13 141 228 0 0 0/ 0 0


2014.11.18 17:19:23.147 5: jeelink dispatch OK 24 7 4 13 141 228 0 0 0 0 0
2014.11.18 17:19:23.148 5: Triggering kuKaffeemaschine (0 changes)
2014.11.18 17:19:25.174 5: CUL/RAW: /T4C3D00B63CEA


2014.11.18 17:19:25.174 4: CUL_Parse: CUL1 T4C3D00B63CEA -85
2014.11.18 17:19:25.174 5: CUL1 dispatch 810c04xx0909a0014c3d0000b63c
2014.11.18 17:19:25.174 4: FHT fhtWohnzimmer actuator: 24%
2014.11.18 17:19:27.634 4: raspiVT_s0EingangAllgemein: RPI_GPIO raspiVT_s0EingangAllgemein Pinlevel: high
2014.11.18 17:19:27.634 5: Triggering raspiVT_s0EingangAllgemein (1 changes)
2014.11.18 17:19:27.634 5: Notify loop for raspiVT_s0EingangAllgemein Pinlevel: high
2014.11.18 17:19:27.638 4: eventTypes: RPI_GPIO raspiVT_s0EingangAllgemein Pinlevel: high -> Pinlevel: high

Dieses mal ist direkt nach dem anklicken des Homescreen Icons nichts mehr gegangen, das passiert aber eher selten. Meistens kommt der Hänger beim Raumwechsel, Device Detail Seite aufrufen klappt meines Erachtens öfter, aber so wirklich sicher bin ich mir da auch nicht.

FHEM läuft bei mir auf einem Quadcore MacMini mit 16GB Ram, da ist im Normalfall die Seite direkt nach dem anklicken schon da, ohne Ladezeit.

Zitat von: rudolfkoenig am 18 November 2014, 15:12:27
Und kannst du es danach mit "attr WEB longpoll 0" auch probieren?

Du meinst WEBphone, oder?

Hab beides auf 0 gesetzt, selbes Ergebnis, nach dem 2. klick (raumwechsel) passiert nichts mehr. Brauchst du davon auch ein Log?


Grüße

Und ab welcher Sekunde/Millisekunde hast du das Frontend gestartet? Und ja, ich meinte WEBphone. Und: gibts die Haenger auf dem iPhone auch mit dem "normalen" (nicht smallscreen/touchpad) FHEMWEB Instanz?

Wie man sieht, ich habe z.Zt. keine Theorie, und sammele nur Fakten. Falls jemand eine Theorie hat, bitte melden. Ich bin nur sicher, dass es nicht an der Geschwindigkeit des Backends liegt, oder an irgendwelchen FHEM-Klemmer. Entweder ist iOS8 einfach nur buggy, oder FHEMWEB verwirrt Safari, oder beides.

Hallo Rudolf,
ich habe gerade das Problem mit der fhem.cfg.demo erzeugt. iPhone komplett neu gebootet, WebApp aufgerufen (Link auf 192.168.10.23:8084), und dann lange bei weißem Schirm gewartet. Nach 1,5 Minuten kam plötzlich die Anzeige:

*** HIER WEBAPP AUFGERUFEN
2014.11.18 21:57:26 4: Connection accepted from FHEMWEB:192.168.10.50:49197
2014.11.18 21:57:26 4: HTTP FHEMWEB:192.168.10.50:49197 GET /fhem
2014.11.18 21:57:26 4: /fhem / RL:8242 / text/html; charset=UTF-8 / Content-Encoding: gzip /
2014.11.18 21:57:27 4: Connection accepted from FHEMWEB:192.168.10.50:49198
2014.11.18 21:57:27 4: Connection accepted from FHEMWEB:192.168.10.50:49199
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49198 GET /fhem/pgm2/style.css
2014.11.18 21:57:27 4: Connection accepted from FHEMWEB:192.168.10.50:49200
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49199 GET /fhem/pgm2/fhemweb.js
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49200 GET /fhem/pgm2/svg.js
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49198 GET /fhem/pgm2/fhemweb_slider.js
2014.11.18 21:57:27 4: Connection accepted from FHEMWEB:192.168.10.50:49201
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49199 GET /fhem/images/default/dim37%.png
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49200 GET /fhem/pgm2/fhemweb_textField.js
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49201 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.11.18 21:57:27 4: Connection accepted from FHEMWEB:192.168.10.50:49202
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49202 GET /fhem/pgm2/fhemweb_multiple.js
2014.11.18 21:57:27 4: Connection accepted from FHEMWEB:192.168.10.50:49203
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49203 GET /fhem/pgm2/fhemweb_noArg.js
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49203 GET /fhem/pgm2/defaultCommon.css
2014.11.18 21:57:27 4: HTTP FHEMWEB:192.168.10.50:49203 GET /fhem/pgm2/dashboard_style.css
2014.11.18 21:57:57 4: Connection closed for FHEMWEB:192.168.10.50:49203

*** HIER KOMMT AUF DEM IPHONE DIE WEB-ANZEIGE
2014.11.18 21:58:54 4: Closing connection FHEMWEB:192.168.10.50:49199
2014.11.18 21:58:54 4: Closing connection FHEMWEB:192.168.10.50:49198
2014.11.18 21:58:54 4: Closing connection FHEMWEB:192.168.10.50:49201
2014.11.18 21:58:54 4: Closing connection FHEMWEB:192.168.10.50:49200
2014.11.18 21:58:54 4: Closing connection FHEMWEB:192.168.10.50:49202
2014.11.18 21:58:54 4: Connection accepted from FHEMWEB:192.168.10.50:49212
2014.11.18 21:58:54 4: Connection accepted from FHEMWEB:192.168.10.50:49213
2014.11.18 21:58:54 4: HTTP FHEMWEB:192.168.10.50:49212 GET /fhem/pgm2/fhemweb_svg.js
2014.11.18 21:58:54 4: Connection accepted from FHEMWEB:192.168.10.50:49214
2014.11.18 21:58:54 4: HTTP FHEMWEB:192.168.10.50:49213 GET /fhem/images/default/dim37%.png
2014.11.18 21:58:54 4: HTTP FHEMWEB:192.168.10.50:49214 GET /fhem/images/default/FS20.off.png
2014.11.18 21:58:54 4: Connection accepted from FHEMWEB:192.168.10.50:49215
2014.11.18 21:58:54 4: HTTP FHEMWEB:192.168.10.50:49215 GET /fhem/images/default/dim12%.png
2014.11.18 21:58:54 4: Connection accepted from FHEMWEB:192.168.10.50:49216
2014.11.18 21:58:54 4: HTTP FHEMWEB:192.168.10.50:49216 GET /fhem/pgm2/fhemweb_time.js
2014.11.18 21:58:54 4: HTTP FHEMWEB:192.168.10.50:49212 GET /fhem/images/default/fhemicon_smallscreen.png
2014.11.18 21:58:54 4: Connection accepted from FHEMWEB:192.168.10.50:49217
2014.11.18 21:58:54 4: HTTP FHEMWEB:192.168.10.50:49217 GET /fhem/images/default/fhemicon_ios.png
2014.11.18 21:58:54 4: HTTP FHEMWEB:192.168.10.50:49212 GET /fhem?XHR=1&inform=type=status;filter=room=Cinema&timestamp=1416344335785


Ich habe den Effekt auch auf Port 8083, im folgenden Fall mal aus Safari direkt:

*** AUFRUF IM SAFARI
2014.11.18 22:04:41 4: Connection accepted from FHEMWEB:192.168.10.50:49255
2014.11.18 22:04:41 4: HTTP FHEMWEB:192.168.10.50:49255 GET /
2014.11.18 22:04:41 4: WEB: redirecting / to /fhem
2014.11.18 22:04:41 4: HTTP FHEMWEB:192.168.10.50:49255 GET /fhem
2014.11.18 22:04:42 4: /fhem / RL:853 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.11.18 22:04:42 4: Connection accepted from FHEMWEB:192.168.10.50:49261
2014.11.18 22:04:42 4: Connection accepted from FHEMWEB:192.168.10.50:49262
2014.11.18 22:04:42 4: Connection accepted from FHEMWEB:192.168.10.50:49263
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49261 GET /fhem/pgm2/style.css
2014.11.18 22:04:42 4: Connection accepted from FHEMWEB:192.168.10.50:49264
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49261 GET
2014.11.18 22:04:42 4: WEB: redirecting  to /fhem
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49263 GET /fhem/pgm2/svg.js
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49262 GET /fhem/pgm2/fhemweb.js
2014.11.18 22:04:42 4: Connection accepted from FHEMWEB:192.168.10.50:49265
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49263 GET /fhem
2014.11.18 22:04:42 4: /fhem / RL:853 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49264 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49262 GET
2014.11.18 22:04:42 4: WEB: redirecting  to /fhem
2014.11.18 22:04:42 4: Connection accepted from FHEMWEB:192.168.10.50:49266
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49264 GET /fhem/pgm2/defaultCommon.css
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49265 GET /fhem/pgm2/fhemweb_multiple.js
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49266 GET /fhem/pgm2/fhemweb_noArg.js
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49263 GET /fhem/pgm2/dashboard_style.css
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49262 GET /fhem
2014.11.18 22:04:42 4: /fhem / RL:853 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.11.18 22:04:42 4: HTTP FHEMWEB:192.168.10.50:49263 GET /fhem
2014.11.18 22:04:42 4: /fhem / RL:853 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.11.18 22:05:12 4: Connection closed for FHEMWEB:192.168.10.50:49264
2014.11.18 22:05:13 4: Connection closed for FHEMWEB:192.168.10.50:49266
2014.11.18 22:05:13 4: Connection closed for FHEMWEB:192.168.10.50:49265

*** AB HIER KOMMT PLÖTZLICH DIE WEB-SEITE
2014.11.18 22:06:21 4: Closing connection FHEMWEB:192.168.10.50:49261
2014.11.18 22:06:21 4: Connection accepted from FHEMWEB:192.168.10.50:49269
2014.11.18 22:06:21 4: Connection accepted from FHEMWEB:192.168.10.50:49270
2014.11.18 22:06:21 4: HTTP FHEMWEB:192.168.10.50:49270 GET /fhem/pgm2/fhemweb_slider.js
2014.11.18 22:06:21 4: HTTP FHEMWEB:192.168.10.50:49269 GET /fhem/pgm2/fhemweb_svg.js
2014.11.18 22:06:21 4: HTTP FHEMWEB:192.168.10.50:49269 GET /fhem/images/default/fhemicon.png
2014.11.18 22:06:21 4: HTTP FHEMWEB:192.168.10.50:49269 GET /fhem?XHR=1&inform=type=status;filter=&timestamp=1416344782697


Kannst Du damit etwas anfangen? In beiden Fällen dauert es also ca. 1,5 Minuten, bis die Web-Seite sichtbar wird. Auf jeden Fall schonmal vielen Dank, dass Du auch in diesem Fall mal wieder versuchst, eine Lösung zu finden!!

Hier noch ein Nachtrag zu meinem vorherigen Post: Ich habe jetzt noch einmal mit attr WEPphone longpoll 0 getestet. Beim ersten Aufruf (wieder nach Neustart iPhone) war das Frontend sofort da:
2014.11.19 06:59:45 5: Notify loop for global ATTR WEBphone longpoll 0

*** Hier Aufruf FHEM am iPhone, Anzeige am Frontend sofort da
2014.11.19 07:00:22 4: Connection accepted from FHEMWEB:192.168.10.50:49194
2014.11.19 07:00:22 4: HTTP FHEMWEB:192.168.10.50:49194 GET /fhem
2014.11.19 07:00:23 4: /fhem / RL:8197 / text/html; charset=UTF-8 / Content-Enco                                                ding: gzip
/
2014.11.19 07:00:23 4: Connection accepted from FHEMWEB:192.168.10.50:49195
2014.11.19 07:00:23 4: Connection accepted from FHEMWEB:192.168.10.50:49196
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49195 GET /fhem/pgm2/style.css
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49196 GET /fhem/pgm2/svg.js
2014.11.19 07:00:23 4: Connection accepted from FHEMWEB:192.168.10.50:49197
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49197 GET /fhem/pgm2/fhemweb.j                                                s
2014.11.19 07:00:23 4: Connection accepted from FHEMWEB:192.168.10.50:49198
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49195 GET /fhem/pgm2/fhemweb_m                                                ultiple.js
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49196 GET /fhem/pgm2/fhemweb_n                                                oArg.js
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49198 GET /fhem/pgm2/fhemweb_c                                                olorpicker.js
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49195 GET /fhem/pgm2/fhemweb_s                                                vg.js
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49196 GET /fhem/pgm2/fhemweb_t                                                ime.js
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49197 GET /fhem/pgm2/fhemweb_s                                                lider.js
2014.11.19 07:00:23 4: Connection accepted from FHEMWEB:192.168.10.50:49199
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49195 GET /fhem/images/default                                                /FS20.off.png
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49199 GET /fhem/pgm2/fhemweb_r                                                eadingsHistory.js
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49196 GET /fhem/pgm2/defaultCo                                                mmon.css
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49198 GET /fhem/images/default                                                /dim37%.png
2014.11.19 07:00:23 4: Connection accepted from FHEMWEB:192.168.10.50:49200
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49200 GET /fhem/pgm2/fhemweb_t                                                extField.js
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49196 GET /fhem/pgm2/dashboard                                                _style.css
2014.11.19 07:00:23 4: HTTP FHEMWEB:192.168.10.50:49196 GET /fhem/images/default                                                /fhemicon_smallscreen.png
2014.11.19 07:00:53 4: Connection closed for FHEMWEB:192.168.10.50:49196
2014.11.19 07:00:54 4: Connection closed for FHEMWEB:192.168.10.50:49200
2014.11.19 07:00:54 4: Connection closed for FHEMWEB:192.168.10.50:49199
2014.11.19 07:00:54 4: Connection closed for FHEMWEB:192.168.10.50:49197
2014.11.19 07:00:54 4: Connection closed for FHEMWEB:192.168.10.50:49198
2014.11.19 07:01:01 4: Connection closed for FHEMWEB:192.168.10.50:49195


Dann ein zweiter Versuch (einfach nochmal das WebApp-Icon am Homescren aufgerufen). Diesmal auch mit longpoll 0 der Hänger:2014.11.19 07:01:10 4: Connection accepted from FHEMWEB:192.168.10.50:49210

*** Aufruf am Iphone
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49210 GET /fhem
2014.11.19 07:01:10 4: /fhem / RL:8197 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.11.19 07:01:10 4: Connection accepted from FHEMWEB:192.168.10.50:49211
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49211 GET /fhem/pgm2/style.css
2014.11.19 07:01:10 4: Connection accepted from FHEMWEB:192.168.10.50:49212
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49212 GET /fhem/pgm2/svg.js
2014.11.19 07:01:10 4: Connection accepted from FHEMWEB:192.168.10.50:49213
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49213 GET /fhem/pgm2/fhemweb.js
2014.11.19 07:01:10 4: Connection accepted from FHEMWEB:192.168.10.50:49214
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49212 GET /fhem/pgm2/fhemweb_readingsHistory.js
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49214 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49211 GET /fhem/pgm2/fhemweb_noArg.js
2014.11.19 07:01:10 4: Connection accepted from FHEMWEB:192.168.10.50:49215
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49212 GET /fhem/pgm2/fhemweb_textField.js
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49213 GET /fhem/pgm2/fhemweb_slider.js
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49215 GET /fhem/pgm2/fhemweb_multiple.js
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49214 GET /fhem/images/default/dim37%.png
2014.11.19 07:01:10 4: Connection accepted from FHEMWEB:192.168.10.50:49216
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49215 GET /fhem/pgm2/defaultCommon.css
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49216 GET /fhem/pgm2/fhemweb_svg.js
2014.11.19 07:01:10 4: HTTP FHEMWEB:192.168.10.50:49214 GET /fhem/pgm2/dashboard_style.css
2014.11.19 07:01:40 4: Connection closed for FHEMWEB:192.168.10.50:49214
2014.11.19 07:01:41 4: Connection closed for FHEMWEB:192.168.10.50:49215
2014.11.19 07:01:41 4: Connection closed for FHEMWEB:192.168.10.50:49216

*** Ab hier zeigt das Frontend am iPhone FHEM an
2014.11.19 07:02:28 4: Closing connection FHEMWEB:192.168.10.50:49212
2014.11.19 07:02:28 4: Closing connection FHEMWEB:192.168.10.50:49213
2014.11.19 07:02:28 4: Closing connection FHEMWEB:192.168.10.50:49211
2014.11.19 07:02:28 4: Connection accepted from FHEMWEB:192.168.10.50:49227
2014.11.19 07:02:28 4: HTTP FHEMWEB:192.168.10.50:49227 GET /fhem/pgm2/fhemweb_time.js
2014.11.19 07:02:28 4: Connection accepted from FHEMWEB:192.168.10.50:49228
2014.11.19 07:02:28 4: HTTP FHEMWEB:192.168.10.50:49228 GET /fhem/images/default/FS20.off.png
2014.11.19 07:02:28 4: Connection accepted from FHEMWEB:192.168.10.50:49229
2014.11.19 07:02:28 4: HTTP FHEMWEB:192.168.10.50:49229 GET /fhem/images/default/dim12%.png
2014.11.19 07:02:28 4: HTTP FHEMWEB:192.168.10.50:49227 GET /fhem/images/default/fhemicon_smallscreen.png
2014.11.19 07:02:28 4: Connection accepted from FHEMWEB:192.168.10.50:49230
2014.11.19 07:02:28 4: HTTP FHEMWEB:192.168.10.50:49230 GET /fhem/images/default/fhemicon_ios.png
2014.11.19 07:02:58 4: Connection closed for FHEMWEB:192.168.10.50:49227
2014.11.19 07:02:59 4: Connection closed for FHEMWEB:192.168.10.50:49229
2014.11.19 07:02:59 4: Connection closed for FHEMWEB:192.168.10.50:49230
2014.11.19 07:02:59 4: Connection closed for FHEMWEB:192.168.10.50:49228


Also scheint die Einstellung von longpoll das Ergebnis auch nicht dauerhaft zu verbessern.

Ich meine folgendes festellen zu koennen:
- es werden 7 Verbindungen geoeffnet, und ueber diese Dateien bestellt, telweise mehrere Dateien pro Verbindung. Aber erstmal nicht alle benoetigten. Ich vermute, dass alle bestellten Dateien korrekt geliefert wurden, da nur in einem Fall (dim37) eine Datei erneut bestellt wurde.
- nach eine halbe Minute werden 1-3 dieser Verbindungen zugemacht.
- nach eine weitere Minute werden die restlichen Verbindungen zugemacht, sofort neue geoffnet, und weitere Dateien bestellt. Scheinbar laeuft es diesmal besser, da die Seite angezeigt wird.
- das Problem haengt nicht mit longpoll zusammen, da es auch ohen auftritt, weiterhin kommt longpoll (mit XHR) erst zum Schluss dran, wenn alle Dateien geladen sind.
- es hat auch nichts mit den webapp HTML-Tags zu tun, da die "normale" (nicht smallscreen/touchpad) FHEMWEB-Instanz diese nicht generiert.

Theorie: es hat was mit HTTP-Header Parameter zu tun.
1. kann jemand pruefen, ob das Problem auch mit einem zischengeschalteten Apache/etc Proxy auftritt?
2. in 01_FHEMWEB.pm, Zeile 315 (vor delete($hash->{HDR}) ;) eine LogMeldung:
Log 4, $hash->{HDR};
einbauen, und das Experiment wiederholen.
Punkt zwei brauche ich erst dann wenn Punkt 1 als Workaround sich bewaehrt.
Oder jemand hat andere Ideen.

Koennte jemand noch ein "verbose 4" log auch mit gesetzten closeConn erstellen?

Kurze Zwischenmeldung: Ein Proxy (in dem Fall squid auf einer Synology) scheint das Problem teilweise zu entschärfen. In einem kurzen Test kam es allerdings zu Wartezeiten bis zu ca. 20 Sekunden, und dann wurde die FHEM-Seite mit falscher Formatierung dargestellt (als ob teilweise das css nicht greift). Die Hänger von über 1 Minute waren aber in dem kurzen Test nicht mehr zu provozieren.
Ich werde das Ganze incl. der gewünschten Logs heute abend noch einmal durchtesten.

Hallo Rudolf,
jetzt kommen die gewünschten Logs. Alles mit fhem.cfg.demo getestet.

Hier erstmal das Log mit WEBphone, verbose 4 und closeConn=1. Dauert wieder die gewohnte Zeit bis sich was tut:
2014.11.19 18:06:58 4: Connection accepted from FHEMWEB:192.168.10.50:49917
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49917 GET /fhem
2014.11.19 18:06:59 4: /fhem / RL:8242 / text/html; charset=UTF-8 / Content-Enco                                         ding: gzip
/
2014.11.19 18:06:59 4: Connection accepted from FHEMWEB:192.168.10.50:49918
2014.11.19 18:06:59 4: Connection accepted from FHEMWEB:192.168.10.50:49919
2014.11.19 18:06:59 4: Connection accepted from FHEMWEB:192.168.10.50:49920
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49919 GET /fhem/pgm2/svg.js
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49918 GET /fhem/pgm2/style.css
2014.11.19 18:06:59 4: Connection accepted from FHEMWEB:192.168.10.50:49921
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49919 GET /fhem/pgm2/fhemweb_t                                         ime.js
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49921 GET /fhem/pgm2/fhemweb_c                                         olorpicker.js
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49918 GET /fhem/images/default                                         /dim37%.png
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49920 GET /fhem/pgm2/fhemweb.j                                         s
2014.11.19 18:06:59 4: Connection accepted from FHEMWEB:192.168.10.50:49922
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49922 GET /fhem/pgm2/fhemweb_m                                         ultiple.js
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49921 GET
2014.11.19 18:06:59 4: WEBphone: redirecting  to /fhem
2014.11.19 18:06:59 4: Connection accepted from FHEMWEB:192.168.10.50:49923
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49922 GET /fhem/pgm2/defaultCo                                         mmon.css
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49923 GET /fhem/pgm2/fhemweb_n                                         oArg.js
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49919 GET /fhem
2014.11.19 18:06:59 4: /fhem / RL:8242 / text/html; charset=UTF-8 / Content-Enco                                         ding: gzip
/
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49922 GET /fhem/pgm2/dashboard                                         _style.css
2014.11.19 18:06:59 4: Connection accepted from FHEMWEB:192.168.10.50:49924
2014.11.19 18:06:59 4: HTTP FHEMWEB:192.168.10.50:49924 GET /fhem
2014.11.19 18:06:59 4: /fhem / RL:8242 / text/html; charset=UTF-8 / Content-Enco                                         ding: gzip
/
2014.11.19 18:07:29 4: Connection closed for FHEMWEB:192.168.10.50:49922

*** Ab hier kommt die Anzeige am iPhone:
2014.11.19 18:08:15 4: Closing connection FHEMWEB:192.168.10.50:49920
2014.11.19 18:08:15 4: Closing connection FHEMWEB:192.168.10.50:49921
2014.11.19 18:08:15 4: Closing connection FHEMWEB:192.168.10.50:49918
2014.11.19 18:08:15 4: Closing connection FHEMWEB:192.168.10.50:49923
2014.11.19 18:08:15 4: Connection accepted from FHEMWEB:192.168.10.50:49932
2014.11.19 18:08:15 4: HTTP FHEMWEB:192.168.10.50:49932 GET /fhem/pgm2/fhemweb_svg.js
2014.11.19 18:08:15 4: Connection accepted from FHEMWEB:192.168.10.50:49933
2014.11.19 18:08:15 4: HTTP FHEMWEB:192.168.10.50:49933 GET /fhem/pgm2/fhemweb_textField.js
2014.11.19 18:08:15 4: Connection accepted from FHEMWEB:192.168.10.50:49934
2014.11.19 18:08:15 4: HTTP FHEMWEB:192.168.10.50:49934 GET /fhem/images/default/FS20.off.png
2014.11.19 18:08:15 4: Connection accepted from FHEMWEB:192.168.10.50:49935
2014.11.19 18:08:15 4: HTTP FHEMWEB:192.168.10.50:49935 GET /fhem/images/default/dim12%.png
2014.11.19 18:08:15 4: HTTP FHEMWEB:192.168.10.50:49932 GET /fhem/images/default/fhemicon_smallscreen.png
2014.11.19 18:08:15 4: Connection accepted from FHEMWEB:192.168.10.50:49936
2014.11.19 18:08:15 4: HTTP FHEMWEB:192.168.10.50:49936 GET /fhem/images/default/fhemicon_ios.png
2014.11.19 18:08:15 4: HTTP FHEMWEB:192.168.10.50:49932 GET /fhem?XHR=1&inform=type=status;filter=room=Cinema&timestamp=1416416897893
2014.11.19 18:08:15 4: HTTP FHEMWEB:192.168.10.50:49933 GET /fhem/images/default/dim37%.png


Und hier noch die Variante mit Rudolfs zusätzlichem Log-Eintrag (Zeile 315), closeConn nicht gesetzt, Wartezeit wie gehabt:
2014.11.19 18:14:05 4: HTTP FHEMWEB:192.168.10.50:49952 GET /fhem/pgm2/fhemweb_noArg.js
2014.11.19 18:14:35 4: Connection closed for FHEMWEB:192.168.10.50:49952
2014.11.19 18:14:35 4: Connection closed for FHEMWEB:192.168.10.50:49950
2014.11.19 18:14:35 4: Connection closed for FHEMWEB:192.168.10.50:49947

*** Ab hier kommt dann wieder die Anzeige am iPhone
2014.11.19 18:15:15 4: Closing connection FHEMWEB:192.168.10.50:49949
2014.11.19 18:15:15 4: Closing connection FHEMWEB:192.168.10.50:49951
2014.11.19 18:15:15 4: Connection accepted from FHEMWEB:192.168.10.50:49959
2014.11.19 18:15:15 4: Connection accepted from FHEMWEB:192.168.10.50:49960
2014.11.19 18:15:15 4: GET /fhem/images/default/dim37%.png HTTP/1.1
Host: 192.168.10.23:8084
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_1_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12B435
Accept-Language: de-de
Referer: http://192.168.10.23:8084/fhem
Accept-Encoding: gzip, deflate
2014.11.19 18:15:15 4: HTTP FHEMWEB:192.168.10.50:49959 GET /fhem/images/default/dim37%.png
2014.11.19 18:15:15 4: GET /fhem/pgm2/fhemweb_slider.js HTTP/1.1
Host: 192.168.10.23:8084
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_1_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12B435
Accept-Language: de-de
Referer: http://192.168.10.23:8084/fhem
Accept-Encoding: gzip, deflate
2014.11.19 18:15:15 4: HTTP FHEMWEB:192.168.10.50:49960 GET /fhem/pgm2/fhemweb_slider.js
2014.11.19 18:15:15 4: GET /fhem/images/default/fhemicon_smallscreen.png HTTP/1.1
Host: 192.168.10.23:8084
Connection: keep-alive
If-None-Match: "1382641821"
Accept: */*
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_1_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12B435
Accept-Language: de-de
Referer: http://192.168.10.23:8084/fhem
Accept-Encoding: gzip, deflate
2014.11.19 18:15:15 4: HTTP FHEMWEB:192.168.10.50:49959 GET /fhem/images/default/fhemicon_smallscreen.png
2014.11.19 18:15:15 4: Connection accepted from FHEMWEB:192.168.10.50:49961
2014.11.19 18:15:15 4: GET /fhem/images/default/fhemicon_ios.png HTTP/1.1
Host: 192.168.10.23:8084
If-None-Match: "1387095804"
Accept: */*
User-Agent: Web/1.0 CFNetwork/711.1.16 Darwin/14.0.0
Accept-Language: de-de
Accept-Encoding: gzip, deflate
Connection: keep-alive
2014.11.19 18:15:15 4: HTTP FHEMWEB:192.168.10.50:49961 GET /fhem/images/default/fhemicon_ios.png
2014.11.19 18:15:15 4: GET /fhem?XHR=1&inform=type=status;filter=room=Cinema&timestamp=1416417317879 HTTP/1.1
Host: 192.168.10.23:8084
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_1_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12B435
Accept-Language: de-de
Referer: http://192.168.10.23:8084/fhem
Accept-Encoding: gzip, deflate
2014.11.19 18:15:15 4: HTTP FHEMWEB:192.168.10.50:49959 GET /fhem?XHR=1&inform=type=status;filter=room=Cinema&timestamp=1416417317879


Das warst erstmal wieder. Wenn weitere Logs oder Tests hilfreich sind, bitte Bescheid sagen.

Hallo!

Ich habe die gleichen Probleme mit meinem iPhone 5s. Seltsamer Weise läuft FHEM auf dem iPhone meiner Frau, auch ein 5s ohne Probleme. Beide Male mit Safari getestet.

Einziger Unterschied: mein iPhone ist schwarz und wurde 2 Wochen früher geliefert, ihres Silber...

LG,

Roland

@Bubbles71: ich vermute dein iPhone laeuft mit iOS8, das deiner Frau mit iOS7. Oder ist es doch die Farbe?
@fruemmel: kannst du ueber deine Experimente mit squid mehr sagen?

Ich habe die Logs angestarrt, und eine Weile mit dem iOS Simulator experimentiert: closeConn war nicht fuer alle Code-Pfade implementiert, das habe ich jetzt nachgeholt. Hat aber mAn nicht so recht geholfen. Auch meine anderen Experimente haben nichts Wesentliches gebracht: mit fhem.cfg.demo werden die SVGs nur im seltensten Faellen geladen.

Hallo Rudolf,
ich habe heute morgen noch einmal etwas mit dem Proxy getestet. Hintergrund: Ich habe ein Synology-NAS im Netz, dafür gibt es ein Standard-Paket "Proxy-Server". Dahinter verbirgt sich ein squid, den man mit einfachen Mitteln über die Oberfläche der Synology rudimentär konfigurieren kann. Ich habe nichts besonders eingestellt, sondern Cache, Authentifizierung und Protokollierung ausgeschaltet.
Dann noch auf dem iPhone in den Einstellungen des WLANs die Synology als manuellen Proxy eingetragen.

Resultat: 80-90% der FHEM-Aufrufe funktionieren tadellos. Beim Rest kommt es zu Wartezeiten von geschätzten 10 Sekunden, dann kommt die Antwort in Form einer optisch verunstalteten Seite. Die Icons sind dann (iPhone-)bildschirmfüllend, haben aber noch ihre Funktion. Ruft man die nächste Seite (einen anderen Raum) über die DropDown-Auswahl auf, geht es wieder korrekt weiter.
Getestet habe ich bisher nur mit meiner produktiven Umgebung, die deutlich komplexer ist als die Demo. FHEM hatte ich heute morgen noch per update auf den letzten Stand gebracht. Mit SVG-Plots gab es keine Probleme.

Als Gegenprobe habe ich dann den Proxy am iPhone noch einmal rausgenommen. Nach dreimal Springen zwischen verschiedenen Raum-Seiten hing das Frontend dann wieder.
Hilft es, wenn ich mit der squid-Konstellation noch einmal ein Protokoll von FHEM poste? Mir scheint der Proxy dank Deiner Idee schon ein Weg zu sein, die Ursache für die Probleme einzugrenzen.
Gruß Wolfgang

Schaut mal bitte auch die aktuellen Aenderungen an, ob sie was bewirken.

Also mit meinem iPhone 5 (iOs 8.1.1) lädt er jetzt nach einem frischen Fhem-Update meine Fhem-Seiten jetzt absolut zufriedenstellend, Start über LTE / DNS dauert 1 bis 2 Sekunden, aber dann sind die Seiten blitzschnell aufgebaut.

Mit den SVG's hatte ich mit Safari nie Schwierigkeiten.

Super, vielen Dank, so macht das wieder Spaß!!!

VG Volker

Hab vorhin ein Update gemacht! Bis jetzt keinen einzigen Hänger! Juhui!

Danke Danke Danke!

Hallo Rudolf,

das ist echt klasse, auch ich konnte in meiner Produktivumgebung keinen Hänger mehr produzieren! Herzlichen Dank.
Lag das jetzt an den fehlenden closeConn's, oder hast Du noch etwas anderes verändert?

Gruß Wolfgang

Ich habe nur die closeConn Behandlung ueberall reingebaut: bis gestern war closeConn nur fuer die Hauptseite aktiv, aber nicht fuer die "gestreamten" Dateien (.js/.css/.png/etc).


Ich hatte auf meinem Simulator aber weiterhin etliche Probleme gehabt, das SVG Problem haengt vermutlich mit dem nicht gesetzten plotEmbed zusammen, die anderen Probleme mit dem alten Simulator (iOS 8-beta)

Hallo!

Gerade ein Update gemacht und das Problem ist weg!
Danke!!

Grüße

Auch bei mir seit dem Update alles gut!
Ganz herzlichen Dank!

ipad2 mit iOS 8.1.1

=> mit dem heutigen Update keine Hänger mehr  :D

Was ich aber nicht ganz verstehe:

- es funktioniert jetzt auch vollständig mit dem normalen WEB Frontend (8083, longpoll=1, weder plotEmbed noch closeCon sind bei dieser Instanz explizit gesetzt). Dabei werden die normalen Icons (nicht SVG) über longpoll auch nach Schaltvorgängen korrekt nachgeladen  :D :D
- das FHEM Frontend funktioniert jetzt auch wieder als WebApp vom HomeScreen (FHEMWeb und FHEMphone). Seit iOS 8.1.1 werden diese aber nicht mehr im Vollbild angezeigt. Es öffnet sich ein neuer Tab im Safari, Browserleiste oben ist vorhanden. Ist das nur bei mir so? Hat Apple den FullScreen abgeschafft?

Gruß
Tobias

PS: Noch ein Nachtrag. Auch vor dem heutigen Update hatte ich keinerlei Probleme mit Hängern, wenn ich das Frontend über einen Apache Reverse Proxy (sogar mit SSL) aufgerufen habe.

Edit: Korrektur nach kurzer Verwirrung meinerseits.

Zitat von: tpm88 am 20 November 2014, 18:02:37
Dabei werden die normalen Icons (nicht SVG) über longpoll auch nach Schaltvorgängen korrekt nachgeladen  :D :D

Das funktioniert bei mir, wenn ich mich jetzt nicht komplett irre, schon immer. in web und smallscreen. Bei dir nicht?

Zitat von: tpm88 am 20 November 2014, 18:02:37
- das FHEM Frontend funktioniert jetzt auch als "App" vom HomeScreen. Seit iOS 8.1.1 werden diese aber nicht mehr im Vollbild angezeigt. Es öffnet sich ein neuer Tab im Safari, Browserleiste oben ist vorhanden. Ist das nur bei mir so? Hat Apple den FullScreen abgeschafft?

Ich hab keine Probleme mit dem Vollbild, smallscreen wird immer im Vollbild gestartet. Versuch mal das Icon löschen und leg es dann neu an.

Grüße

Zitat von: fhainz am 20 November 2014, 18:11:18
Das funktioniert bei mir, wenn ich mich jetzt nicht komplett irre, schon immer. in web und smallscreen. Bei dir nicht?

Das hat eine ganze Weile nicht funktioniert. Deshalb gab es ja den Workaround mit den SVG Icons, die inline und nicht via longpoll geladen wurden (Attribut iconPath = openautomation:fhemSVG )

Zitat
Ich hab keine Probleme mit dem Vollbild, smallscreen wird immer im Vollbild gestartet. Versuch mal das Icon löschen und leg es dann neu an.

Du hast Recht - bei WEBphone und WEBtablet geht es wie früher auch.

Ich rede ausdrücklich nicht von WEBphone (smallscreen) oder WEBtablet. Sondern vom normalen WEB. Das ist immer vom HomeScreen aus im Vollbildmodus gestartet. Seit iOS gab es (zumindest beim DarkScreen) unten einen weißen Balken, weil die obige iOS Statuszeile (z.B. mit den Icons für WLAN und Batterladeanzeige) über die Webseite geblendet wurde. Neuanlegen des Icons ändert nichts - öffnet sich trotzdem als Tab im Safari...

Edit: Korrektur nach kurzer Verwirrung meinerseits...

Cool, auch von mir mal ein herzlichen Dank an Rudi.

FHEM rennt jetzt auch auf den iOS Geräten mit Safari wie Schmitz Katz.

(http://www.smiliesuche.de/smileys/lachende/lachende-smilies-0101.gif)

Habe gerade ein iPad mini mit iOS8.1.1 in der Hand gehabt:
- fhem.cfg.demo funktioniert ohne Probeme, das "blink 5 1" wird angezeigt, selbst wenn es von einem anderen Client ausgeloest wurde.
- ich kann mit longpoll .png's anzeigen (das wurde wohl inzwischen repariert)
- ich kann bei Port 8085 (WEBtablet) FHEM zum Homescreen hinzufuegen (== webapp)
- webapp funktioniert, kein Safari.

Einziger Bug beim webapp: nach home-doppel-klick sieht man nur einen schwarzen screenshot. Das ist aber vmtl. ein iOS Bug, und ich kann es nicht fixen.

plotEmbed und closeConn wird fuer iPhones/iPads automatisch aktiviert, bzw. das default ist andersherum, wie fuer die anderen Clients. Leider sendet der iOS Simulator manchmal(!) einen anderen UserAgent, als ein iPhone/iPad, was das debuggen mit Simulator erschwert.

iOS funktioniert wunderbar und flüssig.

leider habe ich jetzt mit safari den effekt das fast alle seiten beim aufbau ein paar mal zappeln bevor die anzeige ruhig steht.

hast du eine idee woran das liegt?

Und noch eine - eigentlich off topic - Bitte:

Könnte man bei der WebApp (phone und tablet) den hässlichen weissen Balken am unteren Rand fixen?

Hallo Rudolf,

Vielen Dank! Läuft richtig gut und ich bin wieder glücklich  :) :) :)

Danke, Roland

P.S.: und ich muss meiner Frau nicht immer ihr Handy klauen ;-)

Hallo Zusammen,
auf meinem IPad Mini läuft das Fhemweb jetzt wieder top...

Klasse und vielen Dank!

Zitat von: tpm88 am 20 November 2014, 19:38:54
Und noch eine - eigentlich off topic - Bitte:

Könnte man bei der WebApp (phone und tablet) den hässlichen weissen Balken am unteren Rand fixen?

Super, vielen Dank!

Der weiße Balken gehört eigentlich nicht weg, sondern nach oben. Dort wo die Uhr ist. Habe auch das Problem beim ios6 style.

Zitat von: holzwurm83 am 20 November 2014, 23:40:07
Der weiße Balken gehört eigentlich nicht weg, sondern nach oben. Dort wo die Uhr ist. Habe auch das Problem beim ios6 style.

Beim Dark Style ist ein weißer Balken oben wie unten häßlich. Mich stört eigentlich nicht, daß Uhr, Akkuanzeige etc. den FHEM Screen oben überlagern. Derzeit verschenkt der Balken auch einfach kostbaren Platz auf dem Display...

Hauptsache der Balken ist weg...

Bei mir klappts jetzt auch wieser mit meinem iPad ohne ewig langes warten, einzig was ich noch immer habe ist dieses
"connection lost, trying a reconnect every 5 seconds"... Aber damit kann ich leben.

Das mag auch einfach am raspi liegen...

Gruß
Jens

das liegt schon einmal nicht am Raspi, das hab ich auch auf meinem weitaus potenteren Mac Mini Server, stört aber auch nicht wirklich...

Greetz
Eldrik

das flackern das ich oben erwähnt habe tritt scheinbar immer dann auf wenn es einen svg plot auf der seite gibt und es passiert mit safari unter os x 10.10 und os x 10.8.

Dank an Rudolf König für die Anpassung an IOS8, es geht jetzt perfekt - schnell und stabil.

Andre: ich habe nur 10.9, ich sehe aber kein flackern, bzw. ich weiss nicht, was ich machen soll um es zu reproduzieren. Kannst du das am fhem.cfg.demo beschreiben?

sehen kannst du es auf dem movie oben.

ich versuche es mal nachzustellen mit der demo

sehen kannst du es auf dem movie oben.
Urgh. Und wie soll ich das debuggen?
Und wieso meinst du, dass es mit SVG zu tun hat?
Und was hat das mit dem betreff zu tun?
Fragen ueber fragen :)

ZitatUrgh. Und wie soll ich das debuggen?

es zu sehen ist doch schon mal ein anfang. aber das es scheinbar bei sonst niemandem passiert ist zumindest seltsam.

ZitatUnd wieso meinst du, dass es mit SVG zu tun hat?

es war mir bis eben nur auf seiten mit plots aufgefallen. es passiert aber auf fast allen meinen seiten und auf denen es nicht
direkt beim seitenaufbau passiert lässt es sich durch mehrfaches reload provozieren.

ZitatUnd was hat das mit dem betreff zu tun?

es hat in dem augenblick angefangen in dem ich die fhemweb version mit dem fix für iOS installiert habe. wenn ich auf die version davor zurück gehe ist es wieder weg.

und leider noch keine guten antworten :(

Zitates hat in dem augenblick angefangen in dem ich die fhemweb version mit dem fix für iOS installiert habe.

Dann sollte es mit gesetzten closeConn zusammenhaengen.
Kannst du das Attribut bitte entfernen? closeConn ist per default fuer iOS an und sonst aus.

das hatte ich auch vermutet aber closeConn ist nicht gesetzt und auch ein explizites setzen auf 0 bringt keine verbesserung.

ich habe jetzt noch etwa weiter probiert und dabei folgendes festgestelt:

- auch komplettes abschalten des TcpServer_Close in FW_closeConn hilft nicht.

- das zappeln ist weg oder nicht mehr sichtbar wenn nach einem reload 01_FHEMWEB.pm alle icons weg sind

- es scheint mit png icons zusammen zu hängen. nicht wie anfangs vermutet mit svg
  die seiten die nicht zappeln haben keine png icons

- rereadicons funktioniert nach einem reload 01_FHEMWEB.pm nicht, erst wenn ein mal der iconPath neu gesetzt wird

wenn ich default aus dem iconPath entferne und so die png icons deaktiviere ist das zappeln weg.

den rereadicons bug oben hattest du gesehen ?

Ja, ist in der TODO Liste etwas weiter unten.

Ich meine das eigentliche Problem gefunden zu haben: Safari sendet mehrere Anfragen ueber die gleiche Verbindung an FHEM, und das bevor FHEM auf die Idee kommt, mit dem Antworten anzufangen. FHEMWEB kam damit nicht zurecht, hat pro "sysread" nur die erste Anfrage bearbeitet, die anderen hat er vergessen. Safari wartete 'ne Weile (gefuehlt "ewig"), und hat es dann erneut probiert.

Das habe ich jetzt gefixt, und auf einem iPad mit iOS 8.3 erfolgreich getestet.

Den workaround mit closeConn habe ich hiermit entfernt.
Wenn es zu Problemen fuehrt, bitte hier melden.

Das klingt sehr vielversprechend. Juchu.
Mit viel Glück ist dann auch mein Problem hier (http://forum.fhem.de/index.php/topic,34507.0.html) ja dann auch behoben.

Danke fürs committen. Meine Probleme sind nun alle verschwunden.

Meine Probleme sind wieder da. Habe auf der Testinstallation vor drei Tagen ein Update gemacht und es "hängt" wieder. Mit der operationellen Version von Mitte Mai ist alles ok.

Welcher Browser/Client OS?
Hast du vorher closeConn explizit gesetzt?

Hallo Rudi,

sorry, hätte ich ja auch gleich dazu schreiben können:
iOS 8.3, getestet mit den Browsern Safari und Atom.
Vorher hatte ich closeConn bei FHEMWEB für Phone und Tablet gesetzt und damit hatte ich keine Probleme.
Ich benutze den iOS7 Style.

Jetzt ist das Verhalten etwa so: Beim ersten Aufruf (wenn der Browser länger "zu" war oder das iPad länger aus) kommt die Startseite sofort. Wenn ich nun ein beliebiges Menü anwähle, "hängt" der Browser und es kommt über Minuten nix mehr. Interessanterweise nutzt hier auch ein Reload nichts. Dies hatte vor der Einführung von closeConn aber meistens für das Laden der Seite gesorgt.

Gibts es irgendwelche Daten/Loggings, die ich dir machen kann? Wie kann ich helfen?

Mit "attr WEB verbose 5" den Vorgang protokollieren. Am besten vorher auch "attr global mseclog" aktivieren.

Ich habe zwei potentielle Fehler entfernt, bitte mit 01_FHEMWEB.pm Version 8788 nochmal testen.

Zitat von: rudolfkoenig am 21 Juni 2015, 08:28:07
Ich habe zwei potentielle Fehler entfernt, bitte mit 01_FHEMWEB.pm Version 8788 nochmal testen.

Sorry dass ich noch nix geloggt hatte. Zuviel um die Ohren.
Habe gerade die 8788 eingespielt und alles flutscht und lädt flüssig ohne "Hänger".
Vielen Dank und einen schönen Sonntag!   :D