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

[herrmannj]

2 neue post während ich geschrieben habe

Aber bleibt ja, schaut Euch doch in der console mal an wo die Zeiten verbraten werden - generell ist das ein sv Thema. Wenn da was ist müssen wir zusammen schauen ob wir da für die sv Jungs (und dür uns  ) was tun können.

vg
jörg

[HCS]

Zumindest der Domotiga Treiber hat alle Elemente im DOM bei init aktualisiert (so sah es zumindest in der Console aus) und nicht nur die auf der Seite. Das können dann schnell mal 500 werden.

Das macht weder der Domotiga noch der FHEM-Treiber so.
Beispiel Domotiga page 1 geladen:

Code Auswählen Erweitern

[io.domotiga] sending data: {"cmd":"monitor","items":["quick_dummy","XXumlGad","hcs.data.counter","MAX_LivingRoom_actual","MAX_LivingRoom_wanted","MAX_LivingRoom_comfort","MAX_LivingRoom_night","MAX_LivingRoom_frost","MAX_LivingRoom_state","Temperature_Outside.temperature","Temperature_Outside.humidity","Temperature_LivingRoom.temperature"]}

11 GADs bei fronthem angefragt und genau die 11 liefert fronthem.

Beispiel Domotiga page 2 geladen:

Code Auswählen Erweitern

[io.domotiga] sending data: {"cmd":"monitor","items":["Temperature_Outside.temperature","Temperature_Outside.humidity","Temperature_Outside.battery","Temperature_OutsideNorth.temperature","Temperature_LivingRoom.temperature","Temperature_LivingRoom.humidity","Temperature_LivingRoom.battery","Temperature_GroundFloor.temperature","Temperature_GroundFloor.humidity","Temperature_GroundFloor.battery","Temperature_Penthouse.temperature","Temperature_Cellar_Hobby.temperature","Temperature_Cellar_Hobby.humidity","Temperature_Cellar_Hobby.battery","Temperature_Cellar_Storage.temperature","Temperature_Cellar_Storage.humidity","Temperature_Cellar_Storage.battery","Temperature_Mobile1.temperature","Temperature_Mobile1.humidity","Temperature_Mobile1.battery","Temperature_Mobile2.temperature","Temperature_Mobile2.humidity","Temperature_Mobile2.battery","HCSValues.BurnerTemperatureWanted","HCSValues.BurnerTemperature","HCSValues.BurnerOffCommand","HCSValues.BurnerIsOn","HCSValues.WaterTemperatureWanted","HCSValues.WaterTemperature","HCSValues.WaterOffCommand","HCSValues.WaterIsOn","HCSValues.HeatTemperatureWanted","HCSValues.HeatTemperature","HCSValues.HeatOffCommand","HCSValues.HeatIsOn","HCSValues.PenthouseTemperatureWanted","HCSValues.PenthouseTemperature","HCSValues.PenthouseOffCommand","HCSValues.PenthouseIsOn","HCSValues.HeatBackwardTemperature1Temperature","HCSValues.HeatBackwardTemperature2Temperature","LevelBarnEast.liters","LevelBarnEast.temperature","LevelBarnEast.voltage","hcs.data.oilconsumption.level","hcs.data.oilconsumption.3","hcs.data.oilconsumption.2","hcs.data.oilconsumption.1","System.cpu_freq","System.cpu_temp","System.ac_voltage","System.ac_current","System.battery_voltage","System.battery_capacity","System.time"]}

51 GADs bei fronthem angefragt und genau die 51 liefert fronthem.


Beispiel fhem-driver page 1 geladen:

Code Auswählen Erweitern

2015-02-09 20:49:24.846 io_fhem.min.js:101 [io.fhem]: FHEM GADs:11, Own GADs:1, FHEM Series:0, Own Series:0
2015-02-09 20:49:24.875 io_fhem.min.js:101 [io.fhem]: item updated: quick_dummy val: 333
2015-02-09 20:49:24.880 io_fhem.min.js:101 [io.fhem]: item updated: XXumlGad val: Ölkännchen
2015-02-09 20:49:24.893 io_fhem.min.js:101 [io.fhem]: item updated: MAX_LivingRoom_actual val: 20.0
2015-02-09 20:49:24.902 io_fhem.min.js:101 [io.fhem]: item updated: MAX_LivingRoom_wanted val: 20.0
2015-02-09 20:49:24.907 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.temperature val: 1.6
2015-02-09 20:49:24.912 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.humidity val: 85.9
2015-02-09 20:49:24.921 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_LivingRoom.temperature val: 19.2
2015-02-09 20:49:26.984 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.temperature val: 1.6
2015-02-09 20:49:27.007 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.humidity val: 85.9


Beispiel fhem-driver page 2 geladen:

Code Auswählen Erweitern

2015-02-09 20:55:22.128io_fhem.min.js:101 [io.fhem]: FHEM GADs:51, Own GADs:4, FHEM Series:0, Own Series:0
2015-02-09 20:55:22.295io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.temperature val: 1.6
2015-02-09 20:55:22.309io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.humidity val: 85.9
usw. usw. 51 GADs

Und was die vielen Gads auf einer Seite angeht: Die hat man sehr schnell, wenn man auch gads im Menü hat. Bei 10 Gads auf einer Seite ist das Blockieren auch schon deutlich spür- und sichtbar (in der Konsole). Bei 40-50 dann fast unerträglich.

Dann muss bei Dir ein anderes Problem vorliegen.

Die Seite mit den 11 GADs lädt bei mir auf dem Tablet und dem Telefon (auf dem Laptop sowiso) verzugsfrei
Die Seite mit den 51 GADs lädt fast verzugsfrei und kaum merklichem blockierend.

Eine Test-Seite mit 300 GADS:
Hat auf dem Laptop knapp 2 Sekunden benötigt, auf dem Tablet und dem Handy zw. 5 und 6 Sekunden, vom Menü-Klick bis zum vollständigen Ergebnis.

Code Auswählen Erweitern

2015-02-09 21:00:41.302io_fhem.min.js:101 [io.fhem]: FHEM GADs:299, Own GADs:1, FHEM Series:0, Own Series:0
2015-02-09 21:00:41.378io_fhem.min.js:101 [io.fhem]: item updated: XtraDummy001 val: 2015-02-09T21:04:49
2015-02-09 21:00:41.403io_fhem.min.js:101 [io.fhem]: item updated: XtraDummy002 val: 2015-02-09T21:04:49
.
.
.
2015-02-09 21:00:43.060io_fhem.min.js:101 [io.fhem]: item updated: XtraDummy298 val: 2015-02-09T21:04:49
2015-02-09 21:00:43.067io_fhem.min.js:101 [io.fhem]: item updated: XtraDummy299 val: 2015-02-09T21:04:49


Jedoch ist die Ladezeit der Seite bei mir zu vernachlässigen und das auch ohne Pagecache. Die ist fast sofort da.

Könnte es sein, dass Dein FHEM, warum auch immer, extrem langsam liefert?
Oder Dein Browser extrem lansam auf dem DOM ist.
Schwer zu sagen, aber was Du beschreibst, klingt für mich um Kategorien langsamer als meine Ergebnisse.

[Jojo11]

Bisher finde ich es echt noch ok. Könnte aber schneller laufen

schöne Grüße
Jo

[bgewehr]

Ich nutze noch kein Tablet, sondern im Moment nur das iPhone. Jeder Aufruf ist dabei ein initial load und schön langsam. Da ich beim Zurückblättern auf die Home Seite keine Gads mehr aktualisiert bekomme, ist sogar innerhalb einer Session mehrfach ein Full reload erforderlich. Mich nervts schon ein wenig, dass ich so lange warten muss, bis ich die Garage aufmachen kann...

[karl0123]

Das Problem ist da. Das lässt sich nicht weg diskutieren. Ich weiß sehr genau was ich tue und kenne meinen Server und mein System sehr gut. Da gibt es kein anderes Problem, als das langsame init und das Blockieren der gads. Und selbst wenn ich das für das Handy (Nexus 5 mit sehr schnellem W-Lan) auf das nötigste reduziere (Seiten ohne unsichtbares Menü), ist die Wartezeit schon deutlich spürbar. "Hangelt" man sich parallel durch das "normal" FHEMWEB, macht das deutlich mehr Spaß und da geht mir aktuell tatsächlich die Performance vor Aussehen.

Es macht für mich auch gerade wenig Sinn, das ganze am PC zu analysieren (habe ich hier ja auch alles schon einmal gepostet), wenn es doch die Probleme an Tablets und Handys (mit Quad-CPUs und schnellem Wlan) gibt. Am PC merkt man es auch es ist aber ok. Da würde ich SmartVisu aber gar nicht einsetzen wollen.

P.S.: 10 Sekunden sind vielleicht etwas übertrieben aber selbst 4-5 sind für so ein Frontend zu viel. FHEMWEB lädt in deutlich unter 1 Sekunde

[HCS]

Das Problem ist da. Das lässt sich nicht weg diskutieren.

Ich diskutiere es auch nicht weg, ich arbeite daran.

Und selbst wenn ich das für das Handy (Nexus 5 mit sehr schnellem W-Lan) auf das nötigste reduziere (Seiten ohne unsichtbares Menü), ist die Wartezeit schon deutlich spürbar.

Das Telefon, von dem ich oben schrieb, ist mein Nexus 5.

Die Ladezeiten generell sind ein weiteres Thema. Aktuell versuche ich das non blocking hinzubekommen, dass es zumindest bedienbar ist, wärend es lädt.

[herrmannj]

Das Problem ist da. Das lässt sich nicht weg diskutieren.

Relativ, bei mir ist ist es ok. Das hilft Dir jetzt nichts, ist aber so.

Es macht für mich auch gerade wenig Sinn, das ganze am PC zu analysieren

Das sehe ich anders. Dir Frage ist doch: kann man das ändern ? Um das zu klären braucht man objektive Daten. Die skalieren doch vom PC zum Tablett.

Entweder Du nimmst das als gottgegeben und arrangierst Dich, oder wir schauen zusammen was man ändern kann (wohlgemerkt in sv). Dafür braucht es zu aller erst eine genaue Analyse was, wann, wo, wielange dauert.

vg
jörg

[bgewehr]

Das Problem ist da. FHEMWEB lädt in deutlich unter 1 Sekunde

Also ich stürze mich eben deshalb auf SmartVISU, weil fhemweb mich schon oft wegen blocking im Stich gelassen hat, es bei weitem nicht so gut aussieht und die Entwicklung in Richtung eines zeitgemäßen Frontends für Ästhetiker nicht mehr in Sichtweite war. Daher ist doch jetzt der ganze Schwung hier entstanden.

Sicher ist es so, dass man - wie in jeder Umgebung - mit den Ressourcen so umgehen muss, dass das Ergebnis passt. Ich habe auch schon HANA kriechen sehen...)

[herrmannj]

Ich habe auch schon HANA kriechen

Och, da könnte ich was gegen liefern 

[HCS]

Die GADs in fronthem initial zu sammeln ist aufgrund der event getriebenen Struktur nicht trivial, mMn wäre der AUfwand höher als der Nutzen.

Da ich nur den Nutzen kenne aber den Aufwand nicht, kann ich es schwer beurteilen.
Wenn das aber nicht möglich ist, dann wird es schwieriger.
Mal schauen, ob ich noch eine Idee dazu finde.

[marvin78]

Also ich stürze mich eben deshalb auf SmartVISU, weil fhemweb mich schon oft wegen blocking im Stich gelassen hat, es bei weitem nicht so gut aussieht und die Entwicklung in Richtung eines zeitgemäßen Frontends für Ästhetiker nicht mehr in Sichtweite war. Daher ist doch jetzt der ganze Schwung hier entstanden.

Naja. Performance geht immer vor Aussehen. Und in FHEMWEB blockt nichts so, wie das Nachladen der gads in SmartVisu. Ich will mich da nicht beschweren (ich beeindruckt von der Geschwindigkeit, wie sich das hier entwickelt), aber dass es aktuell noch ein klarer Showstopper ist, stimmt schon.

[herrmannj]

@hcs: ja smooth. Lass mal bitte strukturieren, ich seh schon, der Plan mit nach hinten schieben geht so nicht auf

Wir brauchen aber echt erst mal valide Daten.

Ich verstehe ad-hoc zB nicht warum eine initiale Sammellieferung von GADs schneller sein soll als der aktuelle event getriebene. Da sehe ich ein Zeichen das wir (ich) was nicht richtig einschätzen.

So wie ich das sehe wird die Zeit (20ms .. 40ms pro GAD) im DOM verbraten wenn jquery mit Hilfe der Selectoren (attr-val) das dazugehörige widget sucht. Da sollte es doch eigentlich keinen Unterschied geben.

Da es Deiner Beobachtung nach nicht so ist (gesammelt schneller) müssen wir mal alternative Theorien aufstellen.

Jquery lässt Interaktionen je erst zu wenn der das ready event durch ist. Wäre es vielleicht möglich das der initiale socket call das verzögert ? Dann könnte man den socket mit einem delay öffnen.

(Doof ist das ich kein setup habe um das nachzustellen - wie machst Du das eigentlich ?).


vg
jörg

[HCS]

Dass wir kein Missverständnis haben. Das gesammelte Senden meinte ich nur initial, wenn Du auf monitor antwortest.
Da bin ich von ausgegangen, dass Du die readings gem. der in monitor gelieferten Liste einsammelst, kannst ja nicht warten, bis die mal per event irgendwann kommen.
Darum dachte ich, dass das kein großes Problem sein sollte. Aber ich kenne Deine Architektur nicht, drum lag ich wohl falsch.

Es ist auch nicht schneller, nur eben ohne Blockieren machbar. Die Zeit, die die Updates der widgets auf dem DOM brauchen ist ja eher unabänderlich (solange man nicht in SV weiter unten eingreift).
Ich muss mich mal da runter debuggen, um zu sehen, was da genau vor sich geht.

@all: das Ganze ist ein mühseliges Geschäft, das braucht wohl noch etwas Zeit.

Ich kenne ja die guten Server von karl0123 nicht, aber dass wir auf dem gleichen Endgerät so drastisch unterschiedleiche Ergebnisse haben, muss einen Grund haben, der es wert wäre, gefunden zu werden.

(Doof ist das ich kein setup habe um das nachzustellen - wie machst Du das eigentlich ?).

Ich versuche mal Dir meinen addon driver so zu bauen, dass Du es damit versuchen kannst.
Kann aber etwas dauern, muss erst mal die Zeit für finden.

Generell so:
eine page mit 299 basic.value

Code Auswählen Erweitern


  {{ basic.value("XtraDummy001", "XtraDummy001", "X") }}
.
.
.
  {{ basic.value("XtraDummy299", "XtraDummy299", "X") }}


Ich aktualisiere vom addon driver aus in einer schnöden Schleife 299 GADs mit "widget.update(item, val);"
Dabei ist das Telefon unbedienbar, bis die GADs durch sind.

Diese Variante hier schafft die Aktualisierung ohne dass die Seite blockiert.
Während bei den 300 basic.value aus "---" die Werte werden, kann ich die Seite bedienen, scrollen usw.
      var d = new Date();
      var val = "I-" + d.getSeconds();
      var i = 0, limit = 300, busy = false;
      var updater = setInterval(function() {
        if(!busy) {
          busy = true;
          var item = "XtraDummy" + ("000" + i).slice(-3);
          widget.update(item, val);
          if(++i == limit) {
            clearInterval(updater);
          }
          busy = false;
        }
      }, 2);
    }

Die paar hundert GADs mit ihren Werten sind schnell über die Leitung, schneller als jedes einzeln mit protokoll-overhead.
Und ab dann wären wir responsiv, während die 300 Werte innerhalb von 2-3 Sekunden nach und nach erscheinen.

[herrmannj]

verstehe, kann (muss) ich mir auch klöppeln.

Die untere Variante macht das ja eigentlich so wie ich das von der queue erwarten würde. Den overhead und auch die gesamte Datenmenge kann man bei 300 GAD (a 50byte ?) doch ignorieren. Das wären 15kb, normale jpegs haben das 10fache. ( plus x ... ). 3000ms für 300 GAD finde ich auch ok - das sind 10ms pro.

Hilft nichts, wir müssen das messen und untersuchen, alles andere ist wie blind mit der Schrotflinte in den Wald schießen und hoffen das der Hirsch umfällt.

vg
jörg

[HCS]

Der mit dem Hirsch ist gut 

Das ist die queue-Variante, die nichts geholfen hat. Aber möglicherweise habe ich das nicht so gemacht, dass es funktioniert?
Mit der jquery queue habe ich null Erfahrung.
Da es ja keinen Sinn macht, jedes GAD im DOM zu suchen und ihm eine queue für eine Aktion anzuhängen habe ich ein DOM Element erzeugt, an das ich die queue hänge.
Mal so grob rausgezogen aus meinem Test:

Code Auswählen Erweitern

    irgendwo im run:
    var self = this;
    this.q = $({});

    und dann die Aktualisierung:

    var d = new Date();
      var val = "Q-" + d.getSeconds();
      var ctr = 0;
      for (var i = 1; i < 300; i++) {
        this.q.queue("qt", function (next) {
          var item = "XtraDummy" + ("000" + ctr++).slice(-3);
          widget.update(item, val);
          if(self.q.queue("qt").length > 0) {
            next();
          }
        });
      }
      this.q.dequeue("qt");


Wie auch immer, morgen ist auch noch ein Tag ...