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

HCS · 10 März 2015, 23:05:40

Wenn die Werte alle 1,5ms von fronthem kommen und der treiber 2ms für das widget braucht, dann bleibt aber keine Luft, oder?
Die Oberfläche kann doch nur aktualisieren, wenn sie mit dem widget durch ist und noch kein neuer Wert von fronthem ansteht.

herrmannj · 10 März 2015, 23:08:09

Code Auswählen

Ämm - nach was?
Das war auf karls post, war überschnitten ...
Vergleich war das von Bernd angepasste (da wo die delegates näher am DOM Element liegen) vs POC driver. Beim ersten sind wir auf ø16ms gekommen beim POC auf ø2ms (plus minus)

vg
jörg

HCS · 10 März 2015, 23:17:26

OK.

Kannst ja mal die Messung scharf machen und schauen, was Du für Werte hast. Ist ein alert, dass man auch auf tablets und so messen kann.

Sinnvollerweise sollte man auf einer page messen, die basic.values oder floats hat, dass man nicht durch widgets, die lange Verarbeitungszeiten haben, Werte erhält, die nicht mit meinen vergeichbar sind.
In den OK Zeilen steht auch was für ein widget es ist, das sieht man schön, welche schnell und welche langsam sind.

Wenn ich das bei mir so anschaue, dann stelle ich fest, dass fronthem bei mir deutlich langsamer liefert, als die widgets aktualisieren.
Vielleicht merke ich deswegen kaum was vom blockieren.

herrmannj · 10 März 2015, 23:19:57

Zitat von: HCS am 10 März 2015, 23:05:40
Wenn die Werte alle 1,5ms von fronthem kommen und der treiber 2ms für das widget braucht, dann bleibt aber keine Luft, oder?
Die Oberfläche kann doch nur aktualisieren, wenn sie mit dem widget durch ist und noch kein neuer Wert von fronthem ansteht.

Ja, wobei genau dieser seltene und wünschenswerte Fall ja genau dafür sorgt das nach gerade mal 2 sek 1000 GAD auf dem Schirm untergebracht sind. Im Bereich von 2 Sekunden sind mMn auch keine Beeinträchtigungen im Sinn von "ich muss ewig warten bis ich was machen kann". Das laden der Seite an sich braucht ja schon in etwa in diesem Bereich.

Wenn Du jetzt 1ms per timeout dazunimmst sind das in den 99% der anderen Fälle plus 33% bis die 1000 GAD auf dem Schirm sind. Deswegen würde ich da Abstand von nehmen (kostet mAn viel mehr als es bringt)

btw, die 1.5ms muss man auch erst mal schaffen. Du siehst ja das ich die internals "ganz unten" abgreife und da brauchen die 4ms. Im "richtigen Leben" kommen da noch die Zuordnung von GAD zu device via cfg, die Abfrage der permissions, der converter usw dazu.

Ausserdem bremst der ws mit Bandbreite und overhead nochmal mechanisch.

Bei Karl liegt die Ursache vmtl wo anders.

vg
jörg

HCS · 10 März 2015, 23:28:47

Da muss ich mal drüber schlafen und wir bräuchten noch ein paar mehr Tester um einen Eindruck zu bekommen, wie der Treiber generell so läuft.

Ich würde es aber nicht so generell ablehnen. Ob man 2 Sekunden nichts tun kann oder responsive ist und dafür erst nach 3 Sekunden alle Werte dran stehen, ist schon eine Überlegung wert.

Notfalls wird es konfigurierbar, dann kann es jeder einstellen, wie er es möchte.

herrmannj · 11 März 2015, 00:29:19

ZitatIch würde es aber nicht so generell ablehnen. Ob man 2 Sekunden nichts tun kann oder responsive ist und dafür erst nach 3 Sekunden alle Werte dran stehen, ist schon eine Überlegung wert.

Ja, hast Du auch wieder recht. Ich bezweifle nur das Antwort (timeout) und Frage (karl) zusammenpassen. Wenn wir die Ursache kennen wird die Weg zwingend logisch sein.

btw: schlafen ist ein guter Plan.

bis morgen
Jörg

cruser1800 · 11 März 2015, 10:07:41

Zitathmm, komisch. Was denn für "Grafiken" eigentlich.

Sorry habe mich falsch ausgedrückt, sind nartürlich die Plots gemeint.

Mein Test habe ich auch nur mit der neuen widget.js gemacht! Werde heute Abend noch mal mit einem cleaninstall die Tests durchführen.

VG Lutz

avg123-de · 11 März 2015, 12:32:03

Hallo zusammen,

habe auch gerade versucht den neuen Driver zu testen, dabei ist mir aufgefallen, dass jetzt bei Verwendung des neuen Drivers unter IE keine GADs mehr geladen werden und ich keine Pages mehr aufrufen kann. Untern Chrome funktioniert das einwandfrei.
Habe ich vergessen, irgendetwas zu beachten bezüglich des IE oder ist das normal das dass jetzt nicht mehr unter IE läuft?

viele Grüße
Alexander

HCS · 11 März 2015, 12:47:23

Mit IE habe ich es nicht getestet. Muss mal schauen, ob ich einen habe und probieren.

Mir ist aber bei temprose schon aufgefallen, dass es Unterschiede zw. FF und Chrome gibt, für die ich einen Fix drin habe. Evtl ist das das gleiche Thema.
Wobei: Keine GADs geladen könnte ich mir vorstellen, keine Pages laden, da ist mir monetan unklar, welchen Einfluss der Treiber drauf haben sollte.
SV-Page-Cache mal ausgeschaltet und temp-Verzeichnis von SV geleert?
Was sagt die Konsole vom Browser? Errors?

Eine Frage drängt sich mir aber gerade auf: welche Browser werden "offiziell" unterstützt?

Generelles Vorgehen bei seltsamen Erscheinungen:
SV-Page-Cache ausschalten
SV-temp-Verzeichnis leeren
Browser neu starten
Konsole im Browser öffnen und nach Errors schauen

HCS · 11 März 2015, 12:51:35

Zitat von: herrmannj am 11 März 2015, 00:29:19
Ja, hast Du auch wieder recht. Ich bezweifle nur das Antwort (timeout) und Frage (karl) zusammenpassen.

Das halte ich für sehr denkbar. Die Frage ist, wie kommen wir dahinter, was bei karl so bremst.

@karl: kannst Du mal, wie oben beschrieben, die Messung im Treiber scharf machen und die Werte übermitteln. Am einfachsten eine HC vom alert.

avg123-de · 11 März 2015, 12:59:06

Zitat von: HCS am 11 März 2015, 12:47:23
Generelles Vorgehen bei seltsamen Erscheinungen:
SV-Page-Cache ausschalten
SV-temp-Verzeichnis leeren
Browser neu starten
Konsole im Browser öffnen und nach Errors schauen

Der Page-Cache ist bei mir derzeit immer ausgeschaltet, das SV-Temp-Verzeichnis habe ich gelöscht, den Browser neu gestartet und dann mit F12 im IE unter Konsole nach Fehlern geschaut, es werden mir dort keine angezeigt.

viele Grüße
Alexander

Badflex · 11 März 2015, 13:40:38

Hab mich schon gewundert warum er bei mir am Handy die Temperaturen nicht Anzeigt werden.
IE ist also schuld.

HCS · 11 März 2015, 16:19:39

Ja, stimmt, geht im IE nicht. Wobei es mich wundert, dass Du im Unterschied zu mir keinen Fehler in der Konsole bekommst.
Das Problem ist, dass der IE wohl new Event(... nicht unterstützt.

Allerdings komme ich da heute nicht mehr dazu.
Eilt aber auch nicht so sehr, nimm FF oder Chrome, da geht es.

fidel · 11 März 2015, 16:55:17

Zitat von: HCS am 11 März 2015, 12:47:23
Eine Frage drängt sich mir aber gerade auf: welche Browser werden "offiziell" unterstützt?

Laut der smartVISU page:
Firefox, Chrome, IE, Safari, iPhone, iPad, Android Phone or Android Tablet

Aber hast ja schon gefunden woran es liegt.

herrmannj · 11 März 2015, 18:07:08

Zitat von: HCS am 11 März 2015, 16:19:39
Ja, stimmt, geht im IE nicht. Wobei es mich wundert, dass Du im Unterschied zu mir keinen Fehler in der Konsole bekommst.
Das Problem ist, dass der IE wohl new Event(... nicht unterstützt.
Allerdings komme ich da heute nicht mehr dazu.
Eilt aber auch nicht so sehr, nimm FF oder Chrome, da geht es.

Den Teil mit "new Event" habe ich aus jquery abgespickt weil ich deren Erfahrung in Bezug auf Kompatibilität nutzen möchte (und an der Stelle ja das handling bzgl delegates "nachgebaut" habe). Die haben dort keine browser Weichen drin - könnte also auch was anderes sein.

Wenn es mit dem domotiga driver läuft können wird es hier lösen. Wenn nein dann liegt es in sv (jq, jqm .... ). Teste doch mal.

vg
jörg