erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[HCS]

Das Problem, dass nach einem FHEM restart der ws nicht geöffnet werden konnte (ws could not open port 2121), hatte ich auch mal, solange bis ich den Server (cubie) neu gestartet habe, dann war wieder gut.

[herrmannj]

schau ich mir an - wir hatten das schon mal (fhainz?) auf 'nem apple server. Ist nichts wildes - soll aber nicht sein. Evtl startet fhem wg schneller cpu schon wieder durch bevor der ws ganz down ist.

vg
jörg

[bgewehr]

@HCS meinst Du, Du könntest im SVCI GIT die verschiedenen Versionen des Treibers zur Auswahl hinterlegen? Io_fhem102.js, io_fhem108.js usw? Sicher auch für die Fehleranalyse hilfreich!

Ich habe immer noch keine Lösung mit 1.08 und den swipe Events meiner Smartphone Pages (siehe mein multipage Git), da würde ich gern wählen können. Vielleicht gibt es ja noch andere, die ähnliche Themen haben.

Btw: bisher war bei mir bei weitem die schnellste Lösung mit 102 und tiefen delegates! Alles jetzt dauert Sekunden länger als diese Kombi!

[HCS]

@HCS meinst Du, Du könntest im SVCI GIT die verschiedenen Versionen des Treibers zur Auswahl hinterlegen? Io_fhem102.js, io_fhem108.js usw

Generell schon, aber sobald Jörg mit den charts so weit ist, werden die nur mit 1.08 aufwärts gehen.

Btw: bisher war bei mir bei weitem die schnellste Lösung mit 102 und tiefen delegates! Alles jetzt dauert Sekunden länger als diese Kombi!

Das ist interessant. Bei mir ist die 1.08 genauso schnell.

Da sollten wir eher dahinter kommen, warum die bei Dir langsamer ist, als die 1.02 mit tiefergelegten.

[bgewehr]

Was kann ich tun?
Die swipe Events funktionieren am Desktop chrome und ie, aber nicht am Mobile Safari mit 108.

Zeitmessung und debugging ist ja am Desktop kein Problem, aber wie mache ich die Ursachensuche am iPhone?

[fhainz]

schau ich mir an - wir hatten das schon mal (fhainz?) auf 'nem apple server. Ist nichts wildes - soll aber nicht sein. Evtl startet fhem wg schneller cpu schon wieder durch bevor der ws ganz down ist.

das neustart Problem hab ich leider immer noch derzeit erledigt den neustart noch ein notify, das fronthem löscht und anschließend FHEM neustartet seinen dienst.

edit:
ich hab auch schonmal FHEM auf einem 2. mac installiert. auch hier war nach dem fronthem define schluss mit normalen neustarten.

Hin und wieder quittert fronthem mit diesen meldungen den dienst. Hab aber noch nicht nachgeforscht was das sein könnte.

Code Auswählen Erweitern

2015.03.28 16:02:30.352 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/31_fronthemDevice.pm line 465.
2015.03.28 16:02:30.352 3: ENIGMA2 set wzReceiver record
2015.03.28 16:05:59.644 1: fronthem: thread ws closed for unknown reason

[HCS]

@bgewehr: wg. Speed: wenn Du willst, kannst Du die 1.08 mal mit den tiefergelegten probieren, ob die damit schneller ist.
Dazu müsstest Du das (ab Zeile 193):

Code Auswählen Erweitern

// -----------------------------------------------------------------------------
  // Try to call the update handler of a widget
  // -----------------------------------------------------------------------------
  callUpdateHandler: function(item, values) {
    var cachedWidget = io.action[$(item).attr('data-widget')];
    if(cachedWidget) {
      cachedWidget.handler.call(item, 'update', values);
    }
    else {
      $(item).trigger('update', values);
   }
  },

so umbauen:

Code Auswählen Erweitern

// -----------------------------------------------------------------------------
  // Try to call the update handler of a widget
  // -----------------------------------------------------------------------------
  callUpdateHandler: function(item, values) {
    $(item).trigger('update', values);
  },

Dauert es eigentlich lang, bis das erste GAD aktualisiert wird oder von GAD zu GAD lang?
Ist die 1.02 mit den tiefergelegten auf allen Deinen Geräten schneller?

Welchen Einfluss der Treiber beim mobile safari auf swipe haben kann, ist mir momentan völlig unklar.
Funktioniert die page ansonsten auf dem mobile safari wie sie soll?
Da war doch irgendwo ein git, in dem Du das hast und ich mal schauen kann, wie Du das eigentlich implementiert hast?

[bumbumb]

Hallo,

leider klappt es mit dem Calendar nicht.

die Dateien habe ich gemaes Anleitung in die Ordner kopiert.
http://forum.fhem.de/index.php/topic,33231.msg277847.html#msg277847

Auf der index.html seite kommt aber nichts, einfach nichts.
was kann es sein.

[bgewehr]

1) wenn Du willst, kannst Du die 1.08 mal mit den tiefergelegten probieren, ob die damit schneller ist. Dazu müsstest Du das so umbauen...

2) Dauert es eigentlich lang, bis das erste GAD aktualisiert wird oder von GAD zu GAD lang?

3) Ist die 1.02 mit den tiefergelegten auf allen Deinen Geräten schneller?

4) Welchen Einfluss der Treiber beim mobile safari auf swipe haben kann, ist mir momentan völlig unklar.

5) Funktioniert die page ansonsten auf dem mobile safari wie sie soll?

6) Da war doch irgendwo ein git, in dem Du das hast und ich mal schauen kann, wie Du das eigentlich implementiert hast?

1) mache ich morgen

2) das wechseln der Seite dauert bei 108 bis 2s länger als bei 102. wenn eine Seite einmal geladen ist, dauert es einige Zeit < 2s, dann kommen rasch alle Gads. Mit 102 und Tiefen delegates und Cache dauerte alles einmal 1,5s und dann war keine Verzögerung mehr spürbar

3) muss ich morgen mal systematisch analysieren, bisher Haupterkenntnisse auf dem iPhone 6 und einem iPad Air

4) Die swipe Events scheinen einfach nicht zu zünden, sobald der 108 Treiber verwendet wird.

5) Ja, die erste Seite lädt wie gewohnt, ich kann aber nicht auf die anderen Seiten wischen. Prinzipiell könnte auch ein Ladefehler bei einer der Folgeseiten passieren, der einen js Fehler verursacht, der den weiteren Ablauf stört. Kann ich aber auf dem iPhone nicht debuggen...

6) http://github.com/bgewehr - es ist das multipage Git. Ist so nicht lauffähig, weil die Widgets bei mir im widgets Folder liegen und nicht im pages Folder. Schau Dir die Struktur mal an, ich lade in der index.html alle Seiten und navigiere dann mit #wohnzimmer oder per swipe Events aus der Visu.js lief SUPERflott mit 102 und tief und Cache.

[bumbumb]

Warum wird mein kalender nicht angezeigt

[HCS]

@bgewehr: schau mal das an: http://appletoolbox.com/2014/05/use-web-inspector-debug-mobile-safari/
remote debugging eines mobile safari vom mac aus.
Ich kann es nicht probieren, habe einen mac aber kein i***
Ich hoffe, bei Dir ist es nicht genau umgekehrt.

Ich baue mal in den Treiber noch ein globales exception handling zum Testen ein, das exceptions so gut es geht fängt und als alert ausgibt.

[marvin78]

@HCS: Ich kann bgewehrs Beitrag zur Geschwindigkeit der Treiber bestätigen. Auf dem schnellen Laptop sieht der 1.08 sehr schnell aus und hier ist es auch empirisch belegbar, dass er schneller ist, als 1.02 und tief liegende delegates. Die Zeiten kann ich auf anderen Devices in etwa so bestätigen (je nach Anzahl der gads). Auf den langsameren Devices (auf denen auch keine Console möglich ist) ist jedoch die Sache mit den tief liegenden delegates sichtbar schneller. Bei mir handelt es sich nicht im i... Devices sondern um Nexus 5 und aktuelle Samsung Tablets. Das hier ist keinerlei Kritik, nur eine Bestätigung von bgewehrs Beobachtung.

Ich sehe das doch richtig, dass auch tief liegende Widgets als Fallback bedient werden, oder? Leider muss sich dann aber auf den Seiten jeweils mindestens auch ein Widget mit einem document.delegate befinden (es muss mindestens eines gefunden werden), sonst bricht das Laden ab (Fehler in der Console habe ich leider nicht parat, habe ich hier aber schon einmal gepostet).

[HCS]

Das hier ist keinerlei Kritik, nur eine Bestätigung von bgewehrs Beobachtung.

Logisch, fundierte Aussagen zum aktuellen Zustand sind nie Kritik.

Bei mir handelt es sich nicht im i... Devices sondern um Nexus 5 und aktuelle Samsung Tablets.

Ein Nexus 5 habe ich auch, auf dem finde ich es von der Geschwindigkeit her ganz OK. Aber das ist natürlich auch persönliches Empfinden.
Wenn wir irgendwo noch speed rausholen können, macht es Sinn, es zu versuchen.

Auf den langsameren Devices (auf denen auch keine Console möglich ist) ist jedoch die Sache mit den tief liegenden delegates sichtbar schneller

Schau mal in Zeile 650, da kann man definieren, für wie viele GADs eine Zeitmessung durchgeführt werden soll und in Zeile 670 die Messung scharf machen. Das gibt die ermittelten Zeiten als alert aus, geht also auch auf dem Nexus.
Die min.js nicht vergessen.

Ich sehe das doch richtig, dass auch tief liegende Widgets als Fallback bedient werden, oder? Leider muss sich dann aber auf den Seiten jeweils mindestens auch ein Widget mit einem document.delegate befinden (es muss mindestens eines gefunden werden), sonst bricht das Laden ab (Fehler in der Console habe ich leider nicht parat, habe ich hier aber schon einmal gepostet).

Ich glaube, dass das der Fehler war, wenn mindestens ein tiefergelegtes dabei war. Das hier ist ja gerade anders herum.
Da muss ich mir mal eine Testseite mit nur tiefergelegten bauen und debuggen, wo es klemmt.

Ich mache gerade einen größeren Umbau im Treiber, da das bisher übernommene Update-Konzept von SV in Verbindung mit fronthem eigentlich doppelt aktualisiert hat. Es werden erst alle GADs aktualisiert, für die ein Wert im Cache ist, und dann mit Monitor die Daten von fronthem angefragt. fronthem liefert dann alle Werte für die GADs als Initialbefüllung, was dann sowieso alle GADs aktualisiert, somit ist die erste Aktualisierungs-Runde eigentlich recht nutzlos und verschwendete Zeit.

Evtl. gebe ich heute noch einen Treiber raus, um diese neue Update-Strategie von euch testen zu lassen, ob das generell bei allen so hinhaut.

[bgewehr]

@bgewehr: wg. Speed: wenn Du willst, kannst Du die 1.08 mal mit den tiefergelegten probieren, ob die damit schneller ist.
Dazu müsstest Du das (ab Zeile 193):

Code Auswählen Erweitern

// -----------------------------------------------------------------------------
  // Try to call the update handler of a widget
  // -----------------------------------------------------------------------------
  callUpdateHandler: function(item, values) {
    var cachedWidget = io.action[$(item).attr('data-widget')];
    if(cachedWidget) {
      cachedWidget.handler.call(item, 'update', values);
    }
    else {
      $(item).trigger('update', values);
   }
  },

so umbauen:

Code Auswählen Erweitern

// -----------------------------------------------------------------------------
  // Try to call the update handler of a widget
  // -----------------------------------------------------------------------------
  callUpdateHandler: function(item, values) {
    $(item).trigger('update', values);
  },

Habe ich so gemacht, erstmal ohne Änderungen an den Widgets ausprobiert. Ergebnis:

- Hauptseite lädt, gefühlt genauso schnell wie vorher
- EINE Navigation ist nun möglich, also entweder eine Seite durch antippen öffnen oder swipeleft für wetter, tel und Cal
- Nach dem swiperight (zurück zu #index) ist die Navigation tot, kein tippen, kein wischen

Mit Treiber 102 alles wieder normal.

[HCS]

- Hauptseite lädt, gefühlt genauso schnell wie vorher

Was das zu erwartende Ergebnis ist.

- EINE Navigation ist nun möglich, also entweder eine Seite durch antippen öffnen oder swipeleft für wetter, tel und Cal

Seltsam.
Wie bekomme ich denn stressfrei Deine Installation ans Laufen?
Hast Du eine Chance, das remote zu debuggen (siehe weiter oben)?

- Nach dem swiperight (zurück zu #index) ist die Navigation tot, kein tippen, kein wischen

Ich habe immer noch keine Idee. Aber kann ja noch kommen...