Tablet UI -Icons mal da , mal nicht

Begonnen von rasti, 23 Januar 2016, 21:13:19

Vorheriges Thema - Nächstes Thema

setstate

Problem: device='' sollte nie an FHEM gesendet werden. Das versuche ich eigentlich zu vermeiden. Muss ich mir nochmal anschauen.

zap

Also ich habe diese Effekte immer noch. Auch bei mir klappt das erste Laden so gut wie nie. Es fehlen Readings und / oder Bilder. Nach einigen Versuchen mit Apache und dem Verzicht auf  Pagetabs vermute ich die Ursache eher in der Performance meiner Kombination FHEM/Raspi. Erstens ist der Raspi (aktuelle Generation) eine lahme Gurke und zweitens kommt dann noch FHEM als Perl-Interpreterlösung dazu (auch nicht gerade ein Geschwindigkeitsrausch).

Bin am überlegen, ob ich nicht auf potentere Hardware wechsle.

2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

dadoc

Zwischenbericht: Nach der Umstellung auf Apache läuft bislang (vier Tage intensives Testen) alles absolut reibungslos. Ich habe wieder auf Pagetab und include umgestellt, dennoch sind bislang sämtliche Probleme mit dem Nicht-Laden von Icons und dem Nicht-Aktualisieren von Werten auf dem iPad (4) ausgeblieben (auf dem Desktop lief es schon vorher wieder rund).
Möglicherweise ist der fhem Webserver in Verbindung mit dem iOS-Safari ja mit komplexeren ftui-Seiten doch etwas überfordert.
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

dadoc

Zitat von: Depechem am 06 Februar 2016, 16:36:35
jetzt läuft es!
musste per ssh die 000-default.conf komplett löschen und komplett neu anlegen. Inhalt ist nur:
DocumentRoot /opt/fhem/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /opt/fhem/www/>

Damit dürfte der Apache eigentlich nicht starten, denn es fehlt am Ende
</Directory>
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

zap

Zitat von: dadoc am 19 Februar 2016, 13:16:08
Zwischenbericht: Nach der Umstellung auf Apache läuft bislang (vier Tage intensives Testen) alles absolut reibungslos. Ich habe wieder auf Pagetab und include umgestellt, dennoch sind bislang sämtliche Probleme mit dem Nicht-Laden von Icons und dem Nicht-Aktualisieren von Werten auf dem iPad (4) ausgeblieben (auf dem Desktop lief es schon vorher wieder rund).
Möglicherweise ist der fhem Webserver in Verbindung mit dem iOS-Safari ja mit komplexeren ftui-Seiten doch etwas überfordert.

Nutzt Du auch einen Raspi? Ich entwickle/Teste auf einem MacBook und iMac mit Safari, Chrome und Firefox. Die Probleme habe ich bei jedem Browser. Daher die Vermutung, dass es (zumindest bei mir) am lahmen Raspi liegt.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

dadoc

Ja, auch Raspi (s. Signatur). Ich kann nur von W10-Desktop-Browsern sprechen, auf dem Mac habe ich es noch nicht ausprobiert.
Allerdings ist Safari ja schon recht speziell. Auf dem iPad habe ich z.B. das Phänomen, dass ftui seit einiger Zeit beim Aufruf in Safari nur das Hintergunrdbild und das leere Menü-Widget lädt. Wenn ich aus dieser verkrüppelten Seite dann aber eine Web App mache (zum Home-Bildschirm hinzufügen), dann funktioniert es perfekt. Im iOS Chrome gibt es dieses Problem nicht; Früher trat das in dieser Form nicht auf, und ich habe kein iOS-Update gemacht. Ist aber auch reproduzierbar, wenn ich alte Versionen meines ftui einspiele, die früher im Safari - mit den bekannten Problemchen - geladen wurden.
Weiterer Unterschied zwischen iOS-Safari und anderen Browsern: Externe Webseiten im iframe-Widget werden nicht mehr geladen; auf dem Desktop dagegen schon.
Irgendwas ist halt immer, sonst wär ja nix ;)
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

ekur

@zap und dadoc
Ich habe von einem Raspi B+ auf den Raspi 2B (vierkerner) gewechselt, da mir die Perfomance zu schnarchig war und fhem oftmals einfror wegen ein paar angeschlossener 1-Wire Sensoren und HM Komponenten wenn diese gleichzeitig mit dem Wettermodul gearbeitet haben. Graphikaufrufe waren ebenfalls ein Problem, hier konnte der Aufruf eines größeren Zeitraumes auch den Raspi lahmlegen.

Mit dem aktuellen Raspi habe ich keine Performanceproblem, zumal ich zeitaufwendige Sachen (Wetterupdate, 1-Wiresensoren) in einer zweiten FHEM-Instanz laufen lasse und mit FHEM2FHEM nur noch die Werte übergebe die ich wirklich auswerten will. Durch die zwei Instanzen und den Mehrkerner wird meine Steuerungsinstanz dann nicht mehr geblockt. Ich bereue die 35 Euro Anschaffungskosten nicht.

By the way, ich habe als Anzeige ein Samsung Tab 2 auf Cyanogenmod mit dem Firefox als Webbrowser am laufen (WebViewControl funktioniert nicht und für den FF gibt es ein schönes Fullscreen Addon das alles ausser der Webseite ausblendet), in allen html-Dateien die Metadateien, kein pagetab und es sind immer alle Symbole und widgets da, refresh am Tab ca 5 Sekunden bedingt durch WLAN, am festen PC (Ubuntu+Firefox) ca 1 bis 2 Sekunden.
Chrome funktioniert bei mir weder auf dem Android noch auf Ubuntu sauber.

FHEM 5.8 auf Intel NUC, Visualisierung TabletUI auf Lenovo Tab10, Datenlogging MySQL
CUL_HM  HM-CC-RT-DN, HM-RC, HM-LC-BL1-FM, HM-PBI-4-FM, HM-SEC-SD, HM-SEC-SCo
ZWave
OWDevice:DS1420,DS18B20 an Intel NUC

CoolTux

Lässt Du die zweite FHEM Instanz auf dem selben Rechner laufen? Das interessiert mich wirklich sehr.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

ekur

Hallo CoolTux,

ja, auf dem gleichen Raspi. Du musst nur FHEM mit einer zweiten "fhem.cfg" (die natürlich anders heissen muss) starten. Die Verteilung auf die Kerne macht das BS selber (logisch). Im Anhang mal ein Screenshot von htop, hier sieht Du gut die zwei Instanzen, eine mit "fhem_ocx" gestartet. Und wie man sieht dümpelt er gerade vor sich hin (wenn ich einen graph aufrufe mit Daten von 14 Tagen, dann geht ein Kern mal auf 100%). Wenn das Ding nicht so eine grottig schlechte LAN/USB Anbindung hätte....




FHEM 5.8 auf Intel NUC, Visualisierung TabletUI auf Lenovo Tab10, Datenlogging MySQL
CUL_HM  HM-CC-RT-DN, HM-RC, HM-LC-BL1-FM, HM-PBI-4-FM, HM-SEC-SD, HM-SEC-SCo
ZWave
OWDevice:DS1420,DS18B20 an Intel NUC

zap

Zitat von: ekur am 22 Februar 2016, 11:32:09
@zap und dadoc
Ich habe von einem Raspi B+ auf den Raspi 2B (vierkerner) gewechselt, da mir die Perfomance zu schnarchig war und fhem oftmals einfror wegen ein paar angeschlossener 1-Wire Sensoren und HM Komponenten wenn diese gleichzeitig mit dem Wettermodul gearbeitet haben. Graphikaufrufe waren ebenfalls ein Problem, hier konnte der Aufruf eines größeren Zeitraumes auch den Raspi lahmlegen.

Ich habe ebenfalls einen Raspi 2B. 90% meiner Geräte sind Homematic Komponenten. Diese werden von der CCU2 gesteuert, d.h. FHEM hat keinen Stress damit. Die Schnittstelle zu FHEM bildet ein separater Prozess außerhalb von FHEM. Ich denke nicht, dass es hier Performance-Probleme gibt.

Ich glaube, die Probleme kommen eher von dem in Perl implementierten Webserver von FHEM. Apache brachte bei mir eine deutliche Verbesserung, d.h. die fehlenden Icons wurden weniger. Nun habe ich noch in den HTML-Header der FTUI Seiten ein paar Meta-Tags zur Vermeidung von Browser seitigem Caching eingefügt und seitdem scheint es zu laufen. Der Seitenaufbau ist aber trotzdem noch langsam, aber zumindest vollständig.

Habe aber noch einen alten MacMini rumstehen. Ich denke, ich werde mein FHEM darauf umziehen. Wenn da nur nicht der Aufwand wäre .... davor graut mir echt. Alleine bis alle notwendigen Perl-Module wieder installiert sind.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

CoolTux

Wenn Du Deinen Apache als Reserve Proxy eingerichtet hast, dann holt er sich die Daten ja doch wieder vom FHEMWEB. Oder wie hast Du das gemacht?
ich suche ja noch eine Möglichkeit das FTUI die Daten sich per telnet holt, aber ganz ohne php. Rein nur html.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

zap

Nein, kein Reverse Proxy. Einfach native Apache mit DocumentRoot auf /opt/fhem/www. So wie das in einem früheren Beitrag in diesem Thread beschrieben ist. Noch eine kleine Alias Direktive dazu, damit man sich die Änderung der HMTL-Dateien spart und fertig.

Zu Telnet: FTUI holt sich die Daten doch jetzt schon per Telnet (dachte ich zumindest).
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

CoolTux

Dachte ich auch. Aber wieso kann ich dann nicht ne IP und nen Port in der index.html angeben? Oder ist das im fhem-tablet-ui.js hart kodiert?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Ban-ya

Zitat von: dadoc am 08 Februar 2016, 12:02:43
  • Wenn das Problem auftritt, lädt meine index.html mit aktualisierten Readings (Wetter, Thermostaten usw.), aber ohne jegliche fa-Icons. Die kommen dann auch nach längerer Wartezeit nicht.
Martin
Bei mir ist es fast das Gleiche. Es erscheint für Sekundenbruchteile die Seite aber ohne Icons und dann wird die Seite komplett schwarz. Ein Reload bringt dann die komplette Seite so, wie es sein soll.
Das ist bei iOS unter Safarie und Firefox genauso wie unter OSX unter Safarie, Firefox und Chrome  >:(
Was soll ich nur tun? Ich habe schon alle Tips hier getestet und keine Besserung erreicht ...
Grüße vom (noch) hoffnungsvollen Uwe
Raspberry Pi2 B+, CC1101, FHEM 5.7, 7x HM-LC-Bl1PBU-FM, HM-Sec-SC-2 (opt), HM-Sec-SC-2 (reed), VU+ duo, VU+ solo2, IT-Dosen

zap

Wenn die schwarze Seite immer auftritt, könnte es auch ein HTML-Fehler (nicht geschlossener Tag) sein. Du solltest die HTML-Datei nochmal genau auf Syntax-Fehler prüfen.

Der in diesem Thread beschriebene Effekt äußert sich ja so, dass ab und zu Icons oder Readings nicht angezeigt werden.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)