Hallo,
Ich habe ein iPad 2 (wirklich 2, kein Air oder so!) als Display an FHEM laufen. Die Seite mit FTUI lief auch lange gut. Nun habe ich einiges geändert und dabei auch FHEM und FTUI auf die neuesten Versionen aktualisiert (letzte Aktualisierung war im November oder so) und seitdem stürzt der Safari im iPad zyklisch nach einigen Stunden ab.
Habe schon alle Änderungen zurückgeführt, aber die Abstürze bleiben.
Da beim Neustart jeweils die Last auf dem RasPi sehr hoch getrieben wird, brauche ich dann immer mehrere Versuche die Seite (als WebApp) neu zu starten, bis auch wirklich alle Werte aktuell angezeigt werden.
Habe es schon mit dem iCab als alternativen Browser versucht, aber der stellt FTUI unvollständig oder fehlerhaft dar.
Irgendwelche Ideen?
Hallo,
was steckt den dahinter - wieso ist die Last beim Neustart so hoch ? Schon mal Chrome probiert oder gibt es das für IPad2 nicht ? Ich habe ein 4er und wenn Safari zickt, läuft es auf Chrome meistens. Was sagt das Log von fhem ?
Gruß Christoph
Im Log finde ich nichts auffälliges.
Die Last scheint von den vielen verschiedenen Sessions zu kommen, die die Widgets aufmachen. Ich meine im Debugger im Safari (auf dem Mac) eine lange Liste von Sessions gesehen zu haben.
Chrome scheint im App Store nicht für die alte IOS Version verfügbar zu sein.
Allerdings frage ich mich, warum es im iCab nicht läuft. Das ging früher. Wobei ich es auf einem neueren iPad (neues IOS und damit auch neues iCab) noch viel schlimmer ist. Im alten iCab kommen die Widgets, nur die Aktualisierung der Werte fällt aus. im neuen iCab kommt das Gradster und die Seitenstruktur ist zu sehen. Das war es dann aber auch, dann kommt nach ein paar Minuten der Zwangs-Reload, weil Seite nicht vollständig geladen.
Hmmm, könnte es sein das du auch dein IOS einem Update unterzogen hast ?
Bei der aktuellen Version ist da wohl ein Bug :-(
Autovervollständigen im Safari ( Einstellungen ) abstellen ,soll wohl helfen ...
Vielleicht ist das die gleiche Ursache, wie hier: http://forum.fhem.de/index.php/topic,48474.0.html
Ich habe eine Update mit der Optimierung gerade eingecheckt.
Zitat von: Aladin222 am 01 Februar 2016, 02:23:12
Hmmm, könnte es sein das du auch dein IOS einem Update unterzogen hast ?
Bei der aktuellen Version ist da wohl ein Bug :-(
Autovervollständigen im Safari ( Einstellungen ) abstellen ,soll wohl helfen ...
Nö, das ist es definitiv nicht. Beim iPad 2 gibt es seit Jahren kein Update mehr. Das läuft noch auf iOS 4 oder 5.
Zitat von: setstate am 01 Februar 2016, 08:51:57
Vielleicht ist das die gleiche Ursache, wie hier: http://forum.fhem.de/index.php/topic,48474.0.html
Ich habe eine Update mit der Optimierung gerade eingecheckt.
Das hatte ich auch erst vermutet und den Patch schonmal eingebaut, aber das hat dazu geführt, daß die Werte gar nicht mehr kommen.
Was ich heute feststellte: Wenn ich schnell mehrere Schaltvorgänge auslöse, dann scheint es abzustürzen und hat keinen der Vorgänge ausgelöst.
Hallo
ZitatNö, das ist es definitiv nicht. Beim iPad 2 gibt es seit Jahren kein Update mehr. Das läuft noch auf iOS 4 oder 5.
Da muss ich entschieden wiedersprechen.
Ich mache dasselbe ebenfalls auf dem iPad 2. Die Software habe ich auf dem neusten Stand. Aktuell ist dies iOS 9.2.1
Ich empfehle Dir mal die Softwareaktualisierung durchzuführen.
Grüsse
Conti
Zitat von: Conti am 01 Februar 2016, 21:21:36
Hallo
Da muss ich entschieden wiedersprechen.
Ich mache dasselbe ebenfalls auf dem iPad 2. Die Software habe ich auf dem neusten Stand. Aktuell ist dies iOS 9.2.1
Ich empfehle Dir mal die Softwareaktualisierung durchzuführen.
Grüsse
Conti
Wenn ich mich mal selbst zitierten dürfte:
Zitat von: tante ju am 31 Januar 2016, 23:40:31
[...] Ich habe ein iPad 2 (wirklich 2, kein Air oder so!) [...]
Hi Tante Ju,
also ich habe mal gesucht und das
Zitathttp://www.macerkopf.de/2015/11/09/ios-9-2-beschleunigt-aeltere-geraete/
gefunden. Die scheinen das IPad 2 tatsächlich noch zu unterstützen. Meine IPod der vorletzten Generation habe die leider aus unerfindlichen Gründen nicht mitgezogen obwohl der ja aus der gleichen Zeit stammt. Der hängt jetzt auf 6.x fest.
Gruß Christoph
Moin,
Für das iPad 2 gibt es iOS 9. Das 2 hat die gleiche CPU wie das iPad mini und das war bis vor kurzem noch zu kaufen, und wird daher von Apple noch in aktuellen iOS Versionen unterstützt.
Gruß FD
Hallo Tante Ju
ZitatWenn ich mich mal selbst zitierten dürfte:
Zitat von: tante ju am Gestern um 23:40:31
[...] Ich habe ein iPad 2 (wirklich 2, kein Air oder so!) [...]
Ich habe Dich sehr wohl verstanden. Genauso eines habe ich auch.
Bin an dem Morgen vor vielen vielen Jahren als es in der Schweiz zum ersten mal verkauft wurde, in der Schlange gestanden und habe das 5. das über den Ladentisch gieng ergattert 8)
Trotzdem fahre ich alle Updates und bin jetzt auf 9.2.1
Bisher macht FTUI auf Safari keine Probleme.
Conti
Ok, muß mich selbst korrigieren. Ist sogar noch iPad 1 mit iOS 5.1.1.
Die Jahre bringen einen durcheinander.
Also: Updaten ist nicht.
Este es parallel auf einem neuen iPad unter iOS 9 und wie gesagt, im iCab ist es da sogar schlimmer.
Wenns ein IPad 2 (und nicht 1) ist läuft das hoch bis zu den aktuellsten IOS 9er Updates. Soll/Muss OTA updaten, wenn nicht mal an einen Rechner mit ITunes klemmen.
Ok, nachdem wir jetzt geklärt haben, daß es iOS 5.1.1 ist und bleiben wird, hatte ich den Verdacht, daß es mit der teilweise langen Antwortzeit von FHEM zusammenhängen könnte.
Habe also ein komplett neues System aufgesetzt (die andere Speicherkarte hatte eh schon Fehler und machte Zicken) und auch gleich apache2 als Web-Server eingesetzt.
Die statischen Elemente sind jetzt sofort da. Widget-Inhalte kommen meist gut, leider nicht immer. Aber zumindest der Lastsprung ist weg. Genau genommen hat der Rai jetzt nur noch einen Bruchteil der CPU-Auslastung wie vorher (vorher so 0,9 - 1,00 und jetzt 0,1 - 0,4). Keinen blassen Schimmer, was da jetzt anders ist. Aber egal.
Trotzdem ist die WebApp im iPad nach Stunden abgestürzt.
Ich habe auf dem Rechner in der Konsole vom Safari festgestellt, daß alle data-templates unaufgelöst im Source stehen und ich die eigentlichen Inhalte nicht sehe. Sie scheinen also zur Laufzeit aufgelöst zu werden. Kann das bei dem alten iPad zu Problemen führen? Gibt es einen Weg, die includes serverseitig aufzulösen, so daß die Anzahl der File Gets reduziert wird?
Ansonsten sehe ich nur die Möglichkeit die Seite so lange um Elemente zu verkleinern, bis es stabil bleibt. Das wäre ein Task für Wochen, denn es stürzt ja immer erst nach Stunden ab (typisch nachts).
Auf meinem 99€ gebraucht Android Tablet habe ich auch einen Cronjob laufen, der aller 60 Sekunden nachschaut, ob FTUI noch läuft und ggf. nachstartet. Auch wird 4:00 Uhr pauschal das WVC neugestartet. Nur so erreiche ich den geforderten WAF. Ansonsten wäre aller 2-3 Tage das UI weg oder die Thermostate hätten keine Skala mehr. Ich schiebe das auf irgendwelche Speicherlecks in der JS-Engine.
Mein Code ist bestimmt alles andere als optimal, aber ich denke, JS ist so robust, dass nichts zu Absturz führen muss. Oder kennt jemand potentielle Stolperstellen, die so etwas verursachen können bei JS? Integer Überlauf, Object Dispose?
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.
Aber hast du diese Woche nochmal aktualisiert? Wir haben noch eine Stelle optimiert, wo vorher zu viele "online" Event behandelt wurden.
Zitat von: setstate am 03 Februar 2016, 23:29:58
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".
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...
Zitat von: tomster am 04 Februar 2016, 01:47:49
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 :P
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^^
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 ;-.)
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.
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.
Zitat von: zap am 04 Februar 2016, 07:49:01
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.
Zitat von: tante ju am 04 Februar 2016, 11:16:30
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?
Zitat
Darüber hinaus habe ich DbLog etwas besser getunt, was dem Antwortverhalten des RPi richtig gut getan hat.
Nutze ich nicht.
Zitat
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.
Zitat von: zap am 04 Februar 2016, 11:50:23
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!
Zitat von: roman1528 am 04 Februar 2016, 11:58:19
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 ...
(//)
Zitat von: zap am 04 Februar 2016, 13:14:47
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! :o
Ich will Apache... Für FHEM. Punkt. ;D ;D
Zitat von: zap am 04 Februar 2016, 11:50:23
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.
Zitat von: roman1528 am 04 Februar 2016, 11:58:19
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.
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
ZitatSeitenaufbau 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.
Zitataber 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...
Zitat von: tante ju am 04 Februar 2016, 14:07:53
Dem möchte ich mich nicht anschließen. FHEM ist genial, unbestritten.
Ja richtig!
Zitat von: tante ju am 04 Februar 2016, 14:07:53
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!
Zitat von: tomster am 04 Februar 2016, 14:18:57
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 tendenziell richtig gut. Und das hebt neben dem WAF auch den MAF...
Irgendwo hier gibt es schon eine Anleitung, wie man Apache installiert. Finde sie nur gerade nicht.
Also, auf jessie apache2 installieren und include aktivieren:
sudo apt-get install apache2
sudo a2enmod includeDann globale Config anpassen mit
sudo vi /etc/apache2/apache2.confSo ab Zeile 168 (im vi :168) ungefähr, dieses einfügen:
<Directory /opt/fhem/www/>
Options Indexes FollowSymLinks Includes
AllowOverride None
Require all granted
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
</Directory>
Speichern und raus (im vi :x). Jetzt für den virtuellen Host noch die Einstellung anpassen mit
sudo vi /etc/apache2/sites-enabled/000-default.confHier den alten DocumentRoot und Directory entfernen und dieses einfügen:
DocumentRoot /opt/fhem/www
<Directory /opt/fhem/www>
Options Indexes FollowSymLinks MultiViews Includes
AllowOverride None
Order allow,deny
allow from all
</Directory>
Alias /fhem /opt/fhem/www/
Jetzt noch den apache neu starten, damit alles aktiv wird:
sudo service apache2 restartDa die Web-Seiten (und java widgets) nun von einem anderen Server kommen als die Resultate der AJAX-Requests, muß CORS eingeschaltet werden und ein Port beim FHEM gesucht werden, der keine Authentisierung hat. Dafür gibt es viele Möglichkeiten. Das einfachste ist den WEB (Port 8083) zu nehmen, also in FHEM dann:
attr WEB CORS 1Jetzt zum Beispiel in /opt/fhem/www/tablet/ eine Datei index.shtml (mit s!) erstellen. Das kann eine Kopie der bekannten index.html sein. Im Header eine neue Zeile einfügen (wie auch meiner index.html, dann halt ohne SSI):
<meta name="fhemweb_url" content="http://192.168.0.1:8083/fhem">Das sorgt dafür, daß die Requests der Widgets an diese URL gerichtet werden. Deswegen muß Port 8083 mit dem übereinstimmen, bei dem in FHEM CORS aktiviert ist. Es gibt auch andere Wege CORS zu aktivieren, also jeder wie er mag.
Der Zugriff erfolgt jetzt über http://<server>/tablet/<datei>
Also ohne das /fhem in der URL und ohne Port.
Eine normale index.html würde zum Beispiel so aussehen:
<li data-row="1" data-col="1" data-sizex="2" data-sizey="1" data-template="inc_badtemp.html">
</li>In diesem Fall muß der Client die index.html laden und dann noch das data-template. Es sind zwei Zugriffe nötig. Je nach System und Browsereinstellungen kann sich das ganz schön summieren, bis im Browser alle Daten zusammen sind. Zusätzlich sind das alles TCP Zugriffe, die im Server (RPi hier) auch ein wenig was bewirken.
Mit SSI (Server Side Include) analysiert der Apache die Datei nach <!--# Signaturen und führt die Befehle aus. Das obige Beispiel könnte also so aussehen:
<li data-row="1" data-col="1" data-sizex="2" data-sizey="1">
<!--#include virtual="inc_badtemp.html" -->
</li>
Hier wird der Apache-Server den Inhalt der Datei einsetzen und an den Browser genau eine Datei ausliefern, was Latenz reduziert, da weniger TCP Sessions aufgebaut werden müssen.
Die Doku zu SSI kann man sich hier http://httpd.apache.org/docs/2.2/howto/ssi.html (http://httpd.apache.org/docs/2.2/howto/ssi.html) anschauen.
Es ist auch möglich, Ergebnisse einer Befehlsausführung einzubauen oder mit if/else/elif eine strukturierte Datei auszuliefern, was um Beispiel verwendet werden kann, um bestimmte Elemente nur für bestimmte Devices auszuliefern oder was immer einem einfällt.
Ich habe gerade mal nachgeschaut. Hätte ich auch eher drauf kommen können. Die Crashinfos vom iPad sagen ganz klar "Low Memory" und deswegen wurde der Safari gekillt.
Es ist also irgendwo ein Speicherleck, welches nach September oder so eingeführt wurde.
Vielen Dank für die Apache Anleitung.
Durch die SSIs hat sich das Thema Pagetab aber erst mal erledigt? Oder verwendest Du beides parallel?
Weitere Infos zu SSIs (sieht vielversprechend aus)
https://httpd.apache.org/docs/2.4/mod/mod_include.html
und hier:
https://httpd.apache.org/docs/2.4/howto/ssi.html
"Low Memory" -> das wird am Longpoll liegen. Dort wird jede neue Message nur hinten dran gehangen.
Das summiert sich dann bis ins Unendliche (outOfMemory). Früher habe ich Longpoll aller 60sekunden neu gestartet, jetzt läuft es durch.
Da muss ich mir noch was einfallen lassen. Im FHEMWEB ist dazu auch ein Workaround:
Zitat// reset the connection to avoid memory problems
if(FW_longpollOffset > 1024*1024 && FW_longpollOffset==input.length)
FW_longpoll();
Zitat von: zap am 05 Februar 2016, 11:00:25
Vielen Dank für die Apache Anleitung.
Durch die SSIs hat sich das Thema Pagetab aber erst mal erledigt? Oder verwendest Du beides parallel?
Bin mir nicht sicher, ob ich das richtig verstehe.
Pagetab ist ja zur Seiten-Umschaltung, SSI dafür den Browser und RPi TCP Stack zu entlasten, um möglichst viel in einem File zu liefern.
Was meinst Du mit "Pagetab erstmal erledigt" ?
Edit: Autokorrektur korrigiert
Zitat von: setstate am 05 Februar 2016, 12:48:05
"Low Memory" -> das wird am Longpoll liegen. Dort wird jede neue Message nur hinten dran gehangen.
Das summiert sich dann bis ins Unendliche (outOfMemory). Früher habe ich Longpoll aller 60sekunden neu gestartet, jetzt läuft es durch.
Da muss ich mir noch was einfallen lassen. Im FHEMWEB ist dazu auch ein Workaround:
Wenn "früher" auf meine Installation vor dem Dezember-Update zutrifft, dann kann das in der Tat der Grund sein. Kann man den Neustart des Longpoll parametrisierbar machen?
ich starte longpoll jetzt aller 1000 Zeilen neu. Sollte passen. Ich teste noch etwas und release das heute Abend.
Zitat von: setstate am 05 Februar 2016, 13:41:55
ich starte longpoll jetzt aller 1000 Zeilen neu. Sollte passen. Ich teste noch etwas und release das heute Abend.
Super. Werde mir von meiner Frau berichten lassen, ob das funktioniert hat. Bin die nächste Zeit viel unterwegs.
BTW: DU hast http://forum.fhem.de/index.php/topic,48758.0.html (http://forum.fhem.de/index.php/topic,48758.0.html) gesehen?
Zitat von: tante ju am 05 Februar 2016, 12:50:02
Bin mir nicht sicher, ob ich das richtig verstehe.
Pagetab ist ja zur Seiten-Umschaltung, SSI dafür den Browser und RPi TCP Stack zu entlasten, um möglichst viel in einem File zu liefern.
Was meinst Du mit "Pagetab erstmal erledigt" ?
Edit: Autokorrektur korrigiert
Mit Pagetab werden ja die "Unterseiten" per Template eingebunden. Bei SSI verstehe ich das so, dass jede Seite mit komplettem FTUI Header erstellt wird und die einzelnen Bereiche nicht per FTUI Template eingebunden werden sondern per SSI Include. Ob sich beide Mechanismen sinnvoll kombinieren lassen, muss ich mir mal anschauen ( wenn ich mal die Zeit finde, den Apache zu installieren )
Zitat von: setstate am 05 Februar 2016, 13:41:55
ich starte longpoll jetzt aller 1000 Zeilen neu. Sollte passen. Ich teste noch etwas und release das heute Abend.
Es hat was geholfen, läuft jetzt schon >12 Stunden. Super.
Hallo tante ju,
kannst Du bei dir auch das Verhalten feststellen, welches ich bei mir hatte.
Wenn man debug auf 1 stellt, kamen bei mir nach mehr als 1024 Zeilen immer schnell longpollrestarts.
siehe http://forum.fhem.de/index.php/topic,48818.0.html (http://forum.fhem.de/index.php/topic,48818.0.html).
Zitat von: MichaelT am 06 Februar 2016, 14:08:39
Hallo tante ju,
kannst Du bei dir auch das Verhalten feststellen, welches ich bei mir hatte.
Wenn man debug auf 1 stellt, kamen bei mir nach mehr als 1024 Zeilen immer schnell longpollrestarts.
siehe http://forum.fhem.de/index.php/topic,48818.0.html (http://forum.fhem.de/index.php/topic,48818.0.html).
Ich hatte was in der Art auf dem Laptop, aber (noch) nicht auf dem Tablet. Hab's beim Laptop auf meine Bastelei und den Cache geschoben.
Ok, mal warten
So, bin wieder zurück und Frau sagte, es lief alles durch. Das Problem scheint also gelöst.
Allerdings "hing" das Update just gestern Abend, als ich wiederkam. Es wurden keine aktuellen Werte angezeigt.
Mal sehen, ob sich das wiederholt. Bis dahin sehe ich das hier als gelöst an. Danke an alle.
Hi Tante Ju,
Zitat von: tante ju am 04 Februar 2016, 20:45:35
Das sorgt dafür, daß die Requests der Widgets an diese URL gerichtet werden. Deswegen muß Port 8083 mit dem übereinstimmen, bei dem in FHEM CORS aktiviert ist. Es gibt auch andere Wege CORS zu aktivieren, also jeder wie er mag.
Hast Du einen Tipp, wie man CORS aktivieren sollte, damit im iframe-Widget von Nesges (https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/iframe) externe Websites (z.B. TV-Programm von TV Spielfilm) auch unter iOS auf dem iPad geladen werden? Das ging bei mir bis vor Kurzem noch mit data-check-src auf die lokale IP des fhem-Raspi, jetzt nicht mehr. Auch das Einbinden von URLs aus dem Heimnetzwerk geht nicht mehr. Auf (Desktop-)Chrome und Safari geht es dagegen immer noch. Die einschlägigen Tipps, um CORS in Apache2 zu aktivieren, habe ich ausprobiert, ohne Erfolg.
Grüße
Martin
Zitat von: dadoc am 19 Februar 2016, 13:09:17
Hi Tante Ju,Hast Du einen Tipp, wie man CORS aktivieren sollte, damit im iframe-Widget von Nesges (https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/iframe) externe Websites (z.B. TV-Programm von TV Spielfilm) auch unter iOS auf dem iPad geladen werden? Das ging bei mir bis vor Kurzem noch mit data-check-src auf die lokale IP des fhem-Raspi, jetzt nicht mehr. Auch das Einbinden von URLs aus dem Heimnetzwerk geht nicht mehr. Auf (Desktop-)Chrome und Safari geht es dagegen immer noch. Die einschlägigen Tipps, um CORS in Apache2 zu aktivieren, habe ich ausprobiert, ohne Erfolg.
Das Widget verwende ich nicht, daher habe ich auch keine Idee, was da zu machen ist. Vor Ostern komme ich auch nicht dazu, daß zu testen.
Danke Tante Ju,
hat sich soeben dahin gehend erledigt, als dass ich die iframes einfach mal versuchsweise ganz normal (also ohne widget) eingebunden habe, nämlich etwa so:
<li data-row="2" data-col="1" data-sizex="12" data-sizey="40">
<div>
<iframe
src="http://192.168.123.123"
frameborder="0"
allowfullscreen>
</iframe>
</div>
</li>
Das geht bestens sowohl mit internen als auch mit externen URLs. Im Notebook-Firefox erscheint die Seite dann zwar in einer kleinen Box mit Scrollbalken; auf dem iPad-Safari (bzw. Webapp) aber skaliert sie automatisch zur vollen Breite.