[gelöst] iPad 2 Safari stürzt seit letztem Update ab

[tante ju]

Speicherleck wäre auch meine Vermutung, eventuell getriggert durch irgendwas anderes.

Allerdings trat das ganze im Dezember, bevor ich alles aktualisierte, nicht auf. Da lief das iPad klaglos durch, also sogar besser als Dein Android.
Wenn es im iCab wenigstens funktionieren würde, aber da scheitert es ja schon an der Basisdarstellung.

[setstate]

Aber hast du diese Woche nochmal aktualisiert? Wir haben noch eine Stelle optimiert, wo vorher zu viele "online" Event behandelt wurden.

[tante ju]

Aber hast du diese Woche nochmal aktualisiert? Wir haben noch eine Stelle optimiert, wo vorher zu viele "online" Event behandelt wurden.

Ja, und danach ging es schlechter. Die Anzahl der Online-Sessions war es nicht. Das hatte ich schon auf dem RPi geprüft.
Deswegen habe ich zur Zeit den Patch "ausgebaut".

[tomster]

Mein iPad 1 ist auch eine mittlere/schwere Katastrophe mit dem FTUI. 10 Reloads = 1-2 Mal eine vernünftige Darstellung mit der Startseite.
Gridster passt noch, Label-Widgets (verzögert) / Thermostat (sofort) auch. Alles andere (Switch, Symbol, Pagetab-Icons) wird eigentlich NIE angezeigt. Spinner mit "nach unten" verschobenem "+", aber (meistens) ohne Wert. Weniger data-templates machen es besser, aber gut ist was Anderes.

Seit dem Update habe ich aber sogar Probleme auf dem PC. Ist quasi wie auf dem iPad: x-Mal Relaods bis zu einer vernünftigen Darstellung...

[roman1528]

Seit dem Update habe ich aber sogar Probleme auf dem PC. Ist quasi wie auf dem iPad: x-Mal Relaods bis zu einer vernünftigen Darstellung...

Moin. Jetzt möchte ich mich hier auch mal einmischen. Alte Äpfel soll man entsorgen 

Wenn du so arge Probleme hast sollten wir mal deinen Code durchgehen. Da kann irgendwas ganz gewaltig nicht passen. Weil gerade auf meinem PC habe ich gar keine Probleme mehr.

Ich habe z.B. ein Problem mit Icons so gelöst, dass wenn ich ein data-icons array habe, zusätzlich nochmal data-icon mit angegeben habe. Hier war es nämlich manchmal der Fall, dass die Icons auch nicht richtig bzw. gar nicht geladen wurden. Auch bei PageTab wenn dieses ein data-device hat (z.B. für warn un co.).

Wie gesagt... Code mal richtig aufräumen und ggf. deine alten Äpfel mal Jailbraken und mit einer aktuelleren Version versehen... Damit auch neuere Browserversionen geladen werden können und die JavaScriptUnterstützung ein Update bekommt.

Grüße^^

[tomster]

Ich hatte auf dem PC bislang eigentlich NIE Probleme. Bis zum heute getätigten Update...

Und mein FHEM/FTUI ist gerade 4 Tage alt. Ich hab mich eben wegen der Probleme auf dem iPad1 langsam an möglliche "Bugs" herangetastet und from scratch losgelegt. Eigentlich ist mit meinen Versuchen (weniger data-templates, nur fa-Icons, etc.) die Sache immer besser geworden. Bis zum heutigen/gestrigen Update...

Alte Äpfel haben mich zwar eh noch nie interessiert, aber einem geschenkten Barsch, schaut man nicht an den...
Ach halt, Schimmel waren's ja ;-.)

[zap]

Ich habe ebenfalls Probleme mit Tablet UI und Safari. Diese äußern sich so:

- Die Hintergrundfarbe eines Grids wechselt nach ca. 1 Sekunde auf Weiß, und zwar nur bei Knob-, Volume- und Thermostat Widgets
- Einige Widgets werden erst nach mehrfachem Reload angezeigt

Da das mal funktioniert hat und ich die entsprechenden Seiten nicht geändert habe, kann es nur an einem Safari-Update oder an einem Tablet-UI Update liegen. Leider weiß ich nicht mehr, was ich zuletzt aktualisiert habe. Jedenfalls treten die Probleme mit aktuellem Safari und aktuellem MacOS sowie IOS auf.

Mit Chrome ist alles gut. Insofern habe ich zumindest einen Workaround.

[tante ju]

Ich habe gestern Abend auf dem Apache SSI aktiviert und die Seite für das iPad auf SSI umgestellt. Es kommen also auf dem iPad gar keine data-template mehr an.

Darüber hinaus habe ich DbLog etwas besser getunt, was dem Antwortverhalten des RPi richtig gut getan hat.

Ergebnis: Seitenaufbau auf dem iPad 1 richtig schnell. Symbole sind sowieso immer da, seit ich den Apache nutze. Antwortverhalten super und Last auf dem RPi tief unten im grünen Bereich.
Also WebApp antippen und binnen weniger Sekunden ist alles da und bedienbar.

Aber: Heute morgen war die Sitzung wieder abgesemmelt.
Also liegt es nicht an den data-templates oder am zähen Antwortverhalten von FHEM auf dem RPi. Nächster Schritt wäre dann so lange widgets aus der Seite zu nehmen, bis sie stabil bleibt. Das wird eine zähe Angelegenheit, da ich die nächsten Wochen viel unterwegs bin.

Ich habe ebenfalls Probleme mit Tablet UI und Safari. Diese äußern sich so:

- Die Hintergrundfarbe eines Grids wechselt nach ca. 1 Sekunde auf Weiß, und zwar nur bei Knob-, Volume- und Thermostat Widgets
- Einige Widgets werden erst nach mehrfachem Reload angezeigt

Da das mal funktioniert hat und ich die entsprechenden Seiten nicht geändert habe, kann es nur an einem Safari-Update oder an einem Tablet-UI Update liegen. Leider weiß ich nicht mehr, was ich zuletzt aktualisiert habe. Jedenfalls treten die Probleme mit aktuellem Safari und aktuellem MacOS sowie IOS auf.

Mit Chrome ist alles gut. Insofern habe ich zumindest einen Workaround.

So ein Problem mit den Farbwechseln hatte ich auch und konnte zwei Ursachen feststellen: (a) Fehler in der Seite und (b) Fehler in Widgets mit 0-Werten.

Zu (a): setstate hat es hier schon öfter erwähnt, daß solche Fehler sehr komische Effekte zur Folge haben können und das habe ich selbst auch erlebt. Ich hatte mir dann mal die kompletten Sourcen meiner Web-Seiten und Includes angeschaut und dann mit Bleistift und Papier alle <ul></ul>, <li></li> und <div></div> durchgezählt und tatsächlich ein überzähliges </div> gefunden. Das entfernt und danach war es besser.

Zu (b): Ich habe öfters festgestellt, daß Widgets Probleme mit dem Wert 0 haben, wenn dieser als set value verwendet wird. Dann kam es tatsächlich zu sehr komischen Effekten. Deswegen habe ich alles, was mit 0 ausgeschaltet wird, auf "off" umgestellt und keine Probleme mehr. Ich muß gestehen, den Bug nicht weiter verfolgt oder gemeldet zu haben und habe daher keine Ahnung, ob es immer noch drin ist.

Zu den mehrfach nötigen Reloads kann ich seit gestern Abend sagen: HTML über Apache ausliefern mit SSI, FHEM aufräumen, insbesondere bei DbLog und das ist kein Problem mehr.

[zap]

Ich habe gestern Abend auf dem Apache SSI aktiviert und die Seite für das iPad auf SSI umgestellt. Es kommen also auf dem iPad gar keine data-template mehr an.

In wie fern nutzt die Server Side Includes in Zusammenhang mit Tablet UI?

Darüber hinaus habe ich DbLog etwas besser getunt, was dem Antwortverhalten des RPi richtig gut getan hat.

Nutze ich nicht.

Zu (a): setstate hat es hier schon öfter erwähnt, daß solche Fehler sehr komische Effekte zur Folge haben können und das habe ich selbst auch erlebt. Ich hatte mir dann mal die kompletten Sourcen meiner Web-Seiten und Includes angeschaut und dann mit Bleistift und Papier alle <ul></ul>, <li></li> und <div></div> durchgezählt und tatsächlich ein überzähliges </div> gefunden. Das entfernt und danach war es besser.

Würde ich ausschließen. Habe den Farbwechsel Effekt auch auf einer abgespeckten Testseite, die nur den Tablet-UI Standardheader sowie ein Knob-Widget enthält (Wert ist immer >0).
Außerdem nutze ich einen Editor mit HTML-Syntaxcheck.

Trotzdem stelle ich heute Abend auf Apache um.

[roman1528]

Trotzdem stelle ich heute Abend auf Apache um.

Ich finde das so dermaßen dämlich einen extra Server laufen zu lassen!
FHEM bringt doch alles mit. Da sollte man Rudolf mal ein bisschen den Kopf streicheln damit er eine anständige Server-Source einbaut!

[zap]

Ich finde das so dermaßen dämlich einen extra Server laufen zu lassen!
FHEM bringt doch alles mit. Da sollte man Rudolf mal ein bisschen den Kopf streicheln damit er eine anständige Server-Source einbaut!

m.E. wäre es von Anfang an vernünftiger gewesen, auf einen etablierten Webserver zu setzen (sowohl für FHEM als auch für Tablet UI). Warum das Rad neu erfinden? Für Apache gibt es mod_perl, mit dem sich sehr gut PERL basierte Anwendungen abbilden lassen.

Server basierte Dienste mit einer Interpreter Sprache umsetzen ... kann man machen ...

(//)

[roman1528]

m.E. wäre es von Anfang an vernünftiger gewesen, auf einen etablierten Webserver zu setzen (sowohl für FHEM als auch für Tablet UI). Warum das Rad neu erfinden? Für Apache gibt es mod_perl, mit dem sich sehr gut PERL basierte Anwendungen abbilden lassen.

Server basierte Dienste mit einer Interpreter Sprache umsetzen ... kann man machen ...

Da spricht natürlich der Dev! 

Ich will Apache... Für FHEM. Punkt. 

[tante ju]

In wie fern nutzt die Server Side Includes in Zusammenhang mit Tablet UI?

Bin jetzt 10 Jahre aus dem Thema HTML und Webserver raus, aber für mich sah es so aus, als ob der Client jedes data-template gesondert auflöst und die Datei vom Client geholt wird. Das erhöht natürlich die Anzahl der TCP Sessions, die abgehandelt werden müssen. Mit SSI fügt der Server die Inhalte ein und der Client bekommt die ganze HTML Datei (ohne CSS und JS , klar) in einmal, was es dem "schwachen" iPad1 leichter machen sollte. Es war einen Versuch wert, ob diese Sessions die Ursache für die Abstürze sind. Sind sie nicht, aber der Aufwand war nicht so groß und der Gewinn an Geschwindigkeit beim Aufbau (ist ja nur ein einmal-Effekt) läßt mich dieses weiter verwenden. Frisst ja kein Brot.

Ich finde das so dermaßen dämlich einen extra Server laufen zu lassen!
FHEM bringt doch alles mit. Da sollte man Rudolf mal ein bisschen den Kopf streicheln damit er eine anständige Server-Source einbaut!

Dem möchte ich mich nicht anschließen. FHEM ist genial, unbestritten. Aber Perl ist jetzt nicht der Hort der Geschwindigkeit, wenn es um kurzlebige TCP Sessions geht. Da hat Apache für diesen Anwendungsfall ganz klar die Nase vorn. Ich sehe keinen Sinn darin, statische Web-Inhalte durch was anderes als einen darauf spezialisierten Web-Server ausliefern zu lassen. Ich habe vorher keinen Apache genommen, weil ich einfach zu faul war, mich da wieder einzulesen (siehe oben mit den 10 Jahren usw.). Aber da seit meinem Update Anfang des Jahres der WAF enorm gesunken ist, war es halt ein Versuch die Probleme zu beheben.
Das grundsätzliche Problem ist noch da, aber zumindest lädt es jetzt sofort, schnell und vollständig und dieses mehrmals starten und hoffen, daß dann alles da ist, ist weg. Damit kann ich (hoffentlich) den WAF wieder ein wenig anheben.

Darüber hinaus hast Du doch auch so andere spezialisierte Daemons, mit denen FHEM zusammen arbeitet. Mosquitto zum Beispiel, oder mochad oder hmland, oder aptitude zum flashen von AVRs ... Könnte man auch alles in FHEM mit Perl abbilden, aber ich glaube dem OS das Multitasking zu überlassen und bestimmte Sachen in spezielle Dienste auszulagern hilft und macht Sinn.

[tomster]

Och, Tante Ju, nachdem Du dich schon Mal so formidabel eingelesen hast, wie wär's damit dieses Wissen zu Teilen?
SSI war/ ist für mich bislang nur ein weiterer Ausdruck, den ich mit lediglich mit unfundiertem Halbwissen füllen konnte/ kann.
Auch wenn es nicht nach DER Lösung für das Lade-/ Anzeigeproblem zu sein scheint gefallen mir so Nebeneffekt wie

Seitenaufbau auf dem iPad 1 richtig schnell. Symbole sind sowieso immer da, seit ich den Apache nutze. Antwortverhalten super und Last auf dem RPi tief unten im grünen Bereich.

aber zumindest lädt es jetzt sofort, schnell und vollständig und dieses mehrmals starten und hoffen, daß dann alles da ist, ist weg.

tendenziell richtig gut. Und das hebt neben dem WAF auch den MAF...

[roman1528]

Dem möchte ich mich nicht anschließen. FHEM ist genial, unbestritten.

Ja richtig!

Aber Perl ist jetzt nicht der Hort der Geschwindigkeit, wenn es um kurzlebige TCP Sessions geht. Da hat Apache für diesen Anwendungsfall ganz klar die Nase vorn.

Du hast mich da glaube ich nicht recht verstanden... Warum nutzt FHEM nicht eine Apache Instanz oder Apache als Deamon für die ganzen WEB Geschichten?? Warum wird Apache nicht mit FHEM mit installiert inkl. aller nötigen Erweiterungen wie Perl?!
Dann haben wir (mehr oder weniger) wieder alles in einem.
Nur noch einen Webserver laufen zu lassen wenn man schon einen hat finde ich halt Sinnfrei (egal wieviel Brot irgendwer frisst)!

Deswegen: FHEM mit Apache! Fertig!