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

karl0123 · 09 Januar 2015, 08:13:04

Dauert es bei euch auch so lange, bis alle gads geladen sind (etwa 6-7 Sekunden im Gigabit-LAN)? Erst dann kann man die Seite scrollen und interagieren. Auch mit Pagecache gibt es diesen "Block", in dem man nicht mit der VISU interagieren kann. Ich gebe zu, ich habe viele gads im Menü aber ich verstehe nicht woher dieser "Block" kommt!?

herrmannj · 09 Januar 2015, 10:30:17

Zitat von: bgewehr am 09 Januar 2015, 08:08:26
Und noch was: ich habe auch schon alle Seiten auf Ajaxload umgestellt, weil sonst die Darstellung von der Web-App in den Browser wechselt. Trotzdem der Fehler...

Ich habe am ws geändert, kann also durchaus sein. Wundert mich weil ich da echt auch Stresstests gemacht hab, mit 4 Geräten gleichzeitig, 256Zeichen lange GAD VALS mit schneller Freuqenz, WLAN weg, an, weg .. argh!

Nur doof isses weil ich das nicht reproduzieren kann.

Triitt das genauso im laufenden Betrieb oder (nur?) beim Seitenwechsel auf ?
Tritt das bei allen Seiten auf oder nur bei langen/vollen (?), kleinen/leeren (?), bestimmte inhalte ? <- hierzu hätte ich einen Verdacht, das wäre aber schräg ...
Welcher client ? (typ, browser, os, version)

Wenn die Abbrüche statt finden, geht der client auf disconnect ?
Stellt mal bitte log von fronthem auf verbose 5 und provoziert das mal. (log sichern !)

Bevor jemand fragt: ignorieren und einfach wieder alles zurück ändern ist der falsche Weg, da wurden bugs beseitig, bspw konnte, durch einen vololen puffer, ein Gerät das andere lahmlegen ..

vg
jörg

hyper2910 · 09 Januar 2015, 10:45:12

Zitat von: marvin78 am 09 Januar 2015, 07:46:33
Weil die es im Verzeichnis kein SVG mit dem Namen gibt. Du musst, so wie ich es verstanden habe, die PNGs nehmen um verschiedene Farben zu benutzen.

Danke Marvin, das war es!

herrmannj · 09 Januar 2015, 10:52:37

Ich war eben dann auch etwas unpräzise:

Ihr müsstet im log (bei Fehler) finden (wenn mein Verdacht stimmt)
(bla) force disconnect for (blub)

und die Schnittmenge wäre: ihr habt alle drei eine sehr umfangreiche fronthem cfg (viele GAD definiert).

Gegencheck: fhem beenden, die fronthem (Mutter) cfg temporär wo anders hin schieben, fhem starten (fronthem erstellt eine leere cfg). Testweise nur einige GAD definieren (10? 20? plus minus) -> Fehler tritt nicht auf.

Mögt ihr das mal checken ? (wenn mgl, wäre cool, damit ich in der richtigen Ecke unterwegs bin)

Danke und Grüße
jörg

herrmannj · 09 Januar 2015, 11:15:35

Zitat von: karl0123 am 09 Januar 2015, 08:13:04
Dauert es bei euch auch so lange, bis alle gads geladen sind (etwa 6-7 Sekunden im Gigabit-LAN)? Erst dann kann man die Seite scrollen und interagieren. Auch mit Pagecache gibt es diesen "Block", in dem man nicht mit der VISU interagieren kann. Ich gebe zu, ich habe viele gads im Menü aber ich verstehe nicht woher dieser "Block" kommt!?

Bei mir nicht - ich befürchte aber das ich auch nur einen Bruchteil Deiner GAD im Einsatz habe. Tablet oder NB ?

vg
Jörg

karl0123 · 09 Januar 2015, 11:21:50

Rechner, Tablet, Notebook und Handy. Wobei es im LAN schon etwas schneller geht.

Auffällig ist eben, wenn man sich die Konsole ansieht, dass die Seite zuerst geladen wird (auch wenn sie aus dem Cache kommt - dabnn sieht sie fertig aus), dann dauert es einen Augenblick und dann werden die Gads aktualisiert (Sichtbar in der Konsole). Erst danach kann man schalten, scrollen etc. Browser sind Firefox, Chrome und Dolphin.

Und ja, ich habe sehr viele gads. Aber ich denke nicht, dass es überdurchschnittlich viele für eine Hausautomation sind (etwa 230). Zudem kann ich dieses Verhalten bei anderen Anwendungen, die mit websockets arbeiten nicht wirklich beobachten.

Ich denke eben, dass gerade die Verwendung der Websockets dazu führen sollte, dass diese nicht blockierend wirken und die Aktualisierung im Hintergrund stattfinden sollte. Deshalb wundert mich das.

herrmannj · 09 Januar 2015, 11:29:46

Zitat von: karl0123 am 09 Januar 2015, 11:21:50
Rechner, Tablet, Notebook und Handy. Wobei es im LAN schon etwas schneller geht.

Auffällig ist eben, wenn man sich die Konsole ansieht, dass die Seite zuerst geladen wird (auch wenn sie aus dem Cache kommt - dabnn sieht sie fertig aus), dann dauert es einen Augenblick und dann werden die Gads aktualisiert (Sichtbar in der Konsole). Erst danach kann man schalten, scrollen etc. Browser sind Firefox, Chrome und Dolphin.

Und ja, ich habe sehr viele gads. Aber ich denke nicht, dass es überdurchschnittlich viele für eine Hausautomation sind (etwa 230). Zudem kann ich dieses Verhalten bei anderen Anwendungen, die mit websockets arbeiten nicht wirklich beobachten.

Ich denke eben, dass gerade die Verwendung der Websockets dazu führen sollte, dass diese nicht blockierend wirken und die Aktualisierung im Hintergrund stattfinden sollte. Deshalb wundert mich das.

Ja, das stimmt schon. Da spielt aber die Programmierung von sv eine Rolle, das ist halt so programmiert das es sich genau so so verhält. Das wäre meine nächste Frage gewesen mal in der console zu schauen. fronthem bringt die Daten schnell genug rüber aber sv aktualisiert teils gemächlich.

Ich weiß nicht ob man da optimieren kann, müsste man in sv machen. Sag mal, wenn Du so viele GAD hast, hast Du das update von gestern installiert oder bist Du mit der allerersten Version unterwegs ?

vg
Jörg

karl0123 · 09 Januar 2015, 11:34:47

Update von gestern ist drauf, ja. Diese Abbrüche, von denen hier die Rede war habe ich nur auf dem recht langsamen Handy und in Firefox Mobile auf dem Tablet. In Chrome läuft auf allen Geräten alles einwandfrei.

herrmannj · 09 Januar 2015, 11:35:01

btw, bei mir siehts so aus (Anhang). 500ms dom, 600ms Rest.

Im firbug kannste doch sehr gut sehen wo die Zeiten bleiben.

vg
jörg

herrmannj · 09 Januar 2015, 11:37:51

Zitat von: karl0123 am 09 Januar 2015, 11:34:47
Update von gestern ist drauf, ja. Diese Abbrüche, von denen hier die Rede war habe ich nur auf dem recht langsamen Handy und in Firefox Mobile auf dem Tablet. In Chrome läuft auf allen Geräten alles einwandfrei.

ok, Danke. Würde meinen Verdacht bestätigen, aber mal schauen was die Jungs liefern. Kann man heil machen. Muss ich sogar

vg
jörg

karl0123 · 09 Januar 2015, 11:42:39

Naja. Wie ich das analysieren weiß ich schon. Ich habe ja oben geschrieben, was blockt. Ich sehe, wie die gads geladen werden und in der Konsole scrollen und wenn das fertig ist, kann ich wieder interagieren.Die Liste ist natürlich ziemlich lang. Nur verstehe ich nicht warum das laden der gads im Hintergrund blockierend wirkt. Dass es lange dauert kann ich nachvollziehen.

herrmannj · 09 Januar 2015, 11:44:41

Ich habe angefangen meine Uhr schöner (für mich) zumachen (dachte ich hätte langsam Zeit dazu - Pustekuchen

)

Da kommt noch (fhem) Wetter mit den meteo icons und ein Wecker dazu, dann leg ichs ins git.

vg
jörg

herrmannj · 09 Januar 2015, 11:53:48

Zitat von: karl0123 am 09 Januar 2015, 11:42:39
Naja. Wie ich das analysieren weiß ich schon. Ich habe ja oben geschrieben, was blockt. Ich sehe, wie die gads geladen werden und in der Konsole scrollen und wenn das fertig ist, kann ich wieder interagieren.Die Liste ist natürlich ziemlich lang. Nur verstehe ich nicht warum das laden der gads im Hintergrund blockierend wirkt. Dass es lange dauert kann ich nachvollziehen.

tschuldigung, sollte keine Bevormundung sein (sorry)

Das laden (sprich transport) der GAD geht schnell. SV nimmt sich aber eine interne loop, packt jeden einzeln an, aktualisiert und scheint da eher gemütlich vorzugehen. Solange steht die GUI. Wobei ich jetzt Deine 6-7 Sekunden auch echt lange dafür finde. Wenn ich mir den domotiga treiber vornehme finde ich evtl stellen wo man optimieren kann, dazu kann ich aber jetzt noch keine Aussagen machen.

Wenn da nichts geht könnte ich die GADs aus fronthem langsamer liefern. Das mag unlogisch klingen, aber: der sv treiber liest alle GADs die er bekommen kann (aus dem ws) auf einen Rutsch und dreht seine loop. Wenn ich langsamer liefere sind am Anfang schon Pausen (in sv) in denen die GUI aktiv werden kann. Diese tuning sollten wir aber später machen, es gibt aber Schrauben an denen ich drehen kann.

vg
jörg

karl0123 · 09 Januar 2015, 11:59:38

Das sollte hier keine Kritik an dir und deiner Arbeit sein. Ich dachte nur, ich erwähne es mal und frage, ob andere das auch beobachten und stelle fest, ob es an meiner Konfiguration liegt. Deine Beschreibung jedoch passt sehr gut auf das Verhalten. Die 6-7 Sekunden stimmen im Schnitt. Am langsamen Handy sind es sogar noch mehr. Am PC mit LAN etwas weniger (3-4).

Ich möchte auch auf keinen Fall Druck machen. Jedoch dachte ich, dass auch solche Dinge früh in der Entwicklung bekannt sein sollten.

Danke!!

BTW: In welchen JS Dateien macht SmartVisu diese Dinge?

Es werden doch immer nur die sichtbaren gads aktualisiert oder?

herrmannj · 09 Januar 2015, 12:09:31

Zitat von: karl0123 am 09 Januar 2015, 11:59:38
Ich möchte auch auf keinen Fall Druck machen. Jedoch dachte ich, dass auch solche Dinge früh in der Entwicklung bekannt sein sollten.

BTW: In welchen JS Dateien macht SmartVisu diese Dinge?

Es werden doch immer nur die sichtbaren gads aktualisiert oder?

Alles gut, das passt perfekt. Vielen Dank

zu 1: geht vom sv driver aus, danach macht aber das gesamte framework mit
zu 2: na..., it-depends-on ... da werden auch unsichtbare GADs angepackt (was auch gut ist). Die Zeit geht nur in geringem Maß fürs Neu-Zeichnen drauf. Das suchen der Elemente im DOM (von jquery via selector) braucht typischerweise viel Zeit.

vg
jörg