Neues Charting / Plotting - GUI Redesign?

[Puschel74]

Hallo,

nicht das ich wüsste.

Aber du kannst ja (so wie ich auch) fhem installieren und per fhem2fhem verbinden.
Dann kannst du auch das Frontend nutzen und hast eben fhem als "Unterbau".

Autocreate ausschalten (resp. keinen CUx etc definieren) und die beiden Installationen kommen sich nichtmal in die Quere.
(Und du hast noch eine fhem-Installation um diverse Dinge zu testen).

Grüße

[Johannes]

Update:

Die erste Highcharts Integration ist da.
Es gibt nun einen neuen Reiter auf der linken Seite namens "Highcharts".
Dort kann man wie gewohnt einen Chart zusammenstellen. Allerdings sind die meisten Optionen noch deaktiviert (speichern, averaging, etc.).
Zoomen lassen sich die Charts ebenfalls durch aufzeihen eines Bereichs mit der Maus.
Ich bitte euch, Highcharts zu testen in Sachen Performance und Bedienbarkeit und Rückmeldung zu geben.
Ich überlege, die ExtJS Charts komplett zu streichen und durch Highcharts zu ersetzen, wenn es keine Gegenstimmen gibt.
Aber auch eine dauerhafte hybride Lösung ist denkbar.
Also: Diskussion erwünscht!

Code Auswählen Erweitern

update thirdparty http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend frontend


Grüße,
Johannes

[ThorstenH]

Hallo,

ich finde die Highcharts optisch etwas ansprechender. Was die Performance angeht: kann ich wahrscheinlich erst sagen, wenn ich so ca. 6 Kurven anlege. Dann habe ich einen direkten Vergleich mit extjs. Auf den ersten Blick, fühlen sich die Highcharts flotter an.

Andere Frage:
Wer versorgt eigentlich den Browser mit den notwendigen Daten? Worauf ich hinaus will: ich habe diverse Latenzen in der Kommunikation zwischen fhem und dem HMLAN Device. DBLog zum Beispiel blockiert offensichtlich irgendwie die restliche fhem Verarbeitung. Was passiert, wenn der Browser 10 Sekunden lang Daten empfängt? Ist das dann ähnlich wie bei DBLog, dass die fhem Verarbeitung in dieser Zeit beeinträchtigt wird?

Grüße
Thorsten

[Johannes]

Hi,

Wer versorgt eigentlich den Browser mit den notwendigen Daten?

DbLog

DBLog zum Beispiel blockiert offensichtlich irgendwie die restliche fhem Verarbeitung. Was passiert, wenn der Browser 10 Sekunden lang Daten empfängt? Ist das dann ähnlich wie bei DBLog, dass die fhem Verarbeitung in dieser Zeit beeinträchtigt wird?

Ist mir bisher nicht aufgefallen, dass das der Fall wäre. Muss aber nichts heißen, da ich aktuell nur 3 Sensoren empfange und vielleicht auch einfach nur "Glück" habe bisher.
Ich habe aber für das Charting Frontend DbLog so abgeändert, das für alle Charting Anfragen eine eigene DB-Connection verwendet wird, so das für das Logging in DbLog eine eigene Verbindung bleibt und sich beide nicht gegenseitig stören sollten.
Das ganze kann aber durchaus auch abhängig von der verwendeten Datenbank sein, Für SQLite ist der Threading Mode bei der Kompilierung relevant:
http://www.sqlite.org/threadsafe.html

Wie sich FHEM allgemein in Sachen Multithreading verhält müsstest du an anderer Stelle erfragen

[ThorstenH]

Ich meinte mit versorgen, welcher Prozess/Thread die Daten aufbereitet und an den Browser schickt. Falls es der fhem main thread ist, kann fhem währenddessen nichts anderes mehr bearbeiten. Eine eigene Datenbankverbindung ist gut, bedeutet normalerweise aber nicht, dass auch ein eigener Thread verwendet wird und würde zum gleichen Resultat führen. Haben ein paar Clients gleichzeitig Browser offen und fordern Charts an, so würde das das ganze noch verschlimmern.

Da ich seitdem ich DBLog und Frontend benutze Probleme den HMLAN Lebenszeichen habe, frage ich hier danach.

EDIT: ich benutze MySQL

[Zwer2k]

Hallo Johannes,

die Highcharts sind auf jeden Fall schneller, aber auch bei denen ist ohne Server-seitigen Generalisierung irgendwann Schluss. Bei MAX-Thermostaten mit 250-300 Messungen pro Tag kann eine Woche noch dargestellt werden, ein Monat aber nicht mehr.
Kann es sein, dass "alten" Charts nur wegen den schattierten Linien langsamer sind?

Jurij

[Puschel74]

Hallo,

Sorry das ich mich hier als "Unwissender" auch zu Wort melde aber bei

ein Monat aber nicht mehr

einem Monatschart wähle ich eher den AVG_Day-Wert aus und nichtmehr jeden Wert - das seh ich sowieso nicht am Bildschirm (egal wie groß aber bezahlbar).
Zur Not auch noch den AVG_Hour wobei das schon eher grenzwertig ist (bei einem Monatschart) - für mich!

Grüße

[Johannes]

Update:

Ich habe nochmal intensiv nach Performance Problemen gesucht in den ExtJS Charts - und auch welche gefunden.
Der Großteil der Zeit wird wie zu erwarten war beim Rendering des Charts verbracht, Seitaufbau, Datenabruf und Parsen sind schnell genug.
Am Rendering habe ich jetzt einige Optimierungen vrogenommen, so dass die ExtJS Charts deutlich schneller sein sollten.
Feedback erwünscht.

Weiteres:

Hallo Johannes,
Hier noch paar Punkte / Wünsche:
- Geschwindigkeit allgemein. Wenn ich Ein Tag mit ca. 300 Messpunkten darstellen will, reagieren die Charts unangenehm langsam.
- Deviceliste nur einmal laden für alle Y-Axen. Bei mir dauert es ca. 10 Sek. beim Anklicken von "Select Device".
- "Add another Y-Axis" benötigt man nur einmal -> zu "Show Chart", "Save Chart" Buttons verlegen.
- "Delete Y-Axis" Button hinzufügen.

Jurij

Ist alles erledigt, auch die Baseline Buttons wurden ausgelagert in die untere Zeile.
Ausserdem werden Pflichfelder rot umkringelt, wenn man sie leer lässt. Sollte eine Hilfe sein, wenn man sich wundert, warum der Chart keine Ergebnisse liefert.

Hallo,
nun hab ich auch mal wieder eine Frage ...
Geht (bzw. ginge) es evtl. anstelle (oder zusätzlich? evtl. zu unübersichtlich) den Device-Namen anzuzeigen?

Ist erledigt, auf den Achsen und in der Legend werden jetzt sowohl Device als auch der Wert gelistet. Ausserdem wird die Schriftgröße der Achsenbeschriftung in Abhängigkeit von der Textlänge dargestellt. Perfekt ist es aber sicher noch nicht...

Hallo Johannes,
die Highcharts sind auf jeden Fall schneller, aber auch bei denen ist ohne Server-seitigen Generalisierung irgendwann Schluss. Bei MAX-Thermostaten mit 250-300 Messungen pro Tag kann eine Woche noch dargestellt werden, ein Monat aber nicht mehr.
Kann es sein, dass "alten" Charts nur wegen den schattierten Linien langsamer sind?
Jurij

Ich habe auch gemerkt, dass Highcharts früher oder später auch ein Limit erreicht.
Mit den oben genannten Performanceoptimierungen kann ich im Chrome derzeit relativ entspannt einen ganzen Monat mit jeweils 300 Meswerten / Tag in den Ext-Charts darstellen (dauert etwa 10-15 Sekunden). Probier mal das Update!

Hallo,
Sorry das ich mich hier als "Unwissender" auch zu Wort melde aber bei
einem Monatschart wähle ich eher den AVG_Day-Wert aus und nichtmehr jeden Wert - das seh ich sowieso nicht am Bildschirm (egal wie groß aber bezahlbar).
Zur Not auch noch den AVG_Hour wobei das schon eher grenzwertig ist (bei einem Monatschart) - für mich!

Da muss ich absolut zustimmen. Knapp 10.000 einzelne Messwerte auf einer Breite von 10-20 cm darzustellen ist einfach sinnfrei und belastet den Browser ungemein.
Für solche Fälle bitte wenn es geht Averaging nutzen.

Ich werden ausserdem mal ein Infofenster einbauen, sobald man mehr als 10.000 Messwerte abfragt, dass einen dann darauf hinweist, dass man Averaging nutzen sollte und sich sonst erstmal Kaffee kochen kann..

Update wie üblich:

Code Auswählen Erweitern


update thirdparty http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend frontend


Grüße,
Johannes

[Puschel74]

Hallo

Ist erledigt, auf den Achsen und in der Legend werden jetzt sowohl Device als auch der Wert gelistet. Ausserdem wird die Schriftgröße der Achsenbeschriftung in Abhängigkeit von der Textlänge dargestellt. Perfekt ist es aber sicher noch nicht...

Genial. Danke Johannes.

Gleich mal ein Update laufen lassen.

Grüße

Edith: Update ist drüber - perfekt Johannes.
Endlich kann ich die Charts den Geräten zuordnen - DANKE

Edith2: Autsch - grad im Log von FHEM gesehen

2013.04.27 19:40:13 1: CustomGetFileFromURL http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend/www/frontend/lib/highcharts/ux/Highcharts/ErrorBarSerie.js: Select timeout/error:
2013.04.27 19:40:13 1: update skip 'ErrorBarSerie.js'. Size does not correspond to controlfile: 283 bytes download:  bytes

[Johannes]

So, habe nochmal ein Update mit kleineren Optimierungen bereitgestellt.
Charts werden schneller gezeichnet bei Größenänderungen, Bug in der Achsenbeschriftung wurde behoben (mehrfache Beschriftungen auf der rechten Achse wurden nicht aufgeräumt).

Edith2: Autsch - grad im Log von FHEM gesehen

2013.04.27 19:40:13 1: CustomGetFileFromURL http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend/www/frontend/lib/highcharts/ux/Highcharts/ErrorBarSerie.js: Select timeout/error:
2013.04.27 19:40:13 1: update skip 'ErrorBarSerie.js'. Size does not correspond to controlfile: 283 bytes download:  bytes

Kann ich nicht nachvollziehen, erstmal bitte einfach ignorieren.

Grüße,
Johannes

[Rince]

Holla Zack,

das funktioniert ja richtig gut :)
Habe es dank Puschels Anleitung im Wiki nun doch zum laufen gebracht. Herzlichen Dank für die tolle Anleitung Puschel, und vor allem dir Johannes herzlichen Dank für das coole Chart-Teil :)

Der erste Versuch gestern Abend scheiterte, mehr als ein "Waiting for Javascript to initialize" (?) kam nicht.

Habe jetzt grade nochmal das Frontend mit force neu geladen (sonst kam ein nothing to do), und siehe da, es gab nur noch 1 Fehler:

2013.04.29 17:26:55 3: update get http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend/www/frontend/lib/ext-4.2.0.663/images/grid/page-first-disabled.gif
2013.04.29 17:27:00 1: CustomGetFileFromURL http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend/www/frontend/lib/ext-4.2.0.663/images/grid/page-first-disabled.gif: Select timeout/error:
2013.04.29 17:27:00 1: update skip 'page-first-disabled.gif'. Size does not correspond to controlfile: 925 bytes download:  bytes

Das scheint aber die Funktionalität nicht weiter zu beeinträchtigen :)


Frage:
Wenn ich jetzt ein Device mit rename umbenenne, bekommt die Datenbank das mit?

Ich habe bis jetzt nur mit attr aliases vergeben, was aber in den Auswahlmenüs etwas unübersichtlich wird. Oder kann man das irgendwo so konfigurieren, dass das Alias angezeigt wird?





Edit:
Noch etwas anderes:
Habe mal versucht, auch meinen Fensterkontakt darzustellen.
Das funktioniert zwar, aber die Werte 0 und 1 sind jetzt in einem Diagramm, wo der Maximalwert gerade bei 63 liegt (Valveposition)nicht so unglaublich gut sichtbar.

Könnte man irgendwo einen Multiplikator mit angeben? (so z.B. x5)? Dann würde es etwas deutlicher werden. Und die dicken Punkte wenn er einen Messpunkt hat, sind in diesem Fall eher überflüssig. (Wobei das ist eher ein echt kosmetisches Problem)

[Johannes]

Hallo rince,

und siehe da, es gab nur noch 1 Fehler:

2013.04.29 17:26:55 3: update get http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend/www/frontend/lib/ext-4.2.0.663/images/grid/page-first-disabled.gif
2013.04.29 17:27:00 1: CustomGetFileFromURL http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend/www/frontend/lib/ext-4.2.0.663/images/grid/page-first-disabled.gif: Select timeout/error:
2013.04.29 17:27:00 1: update skip 'page-first-disabled.gif'. Size does not correspond to controlfile: 925 bytes download:  bytes

Das scheint aber die Funktionalität nicht weiter zu beeinträchtigen :)

Das ist merkwürdig, ich bekomme keine dieser Meldungen. Ist ein Problem des Update Moduls, scheint auch irgendwie mit TImeouts zusammenzuhängen. Kann mir vorstellen, dass die "betroffene" Datei auch variiert wenn man den Befehl nochmal abschickt. Puschel hatte ja eine ganz andere Datei mit dem selben Problem. Solang das nur eine Gif Datei ist, ist das nicht weiter schlimm, aber bei *.js Dateien wird es dann doch fatal. Bitte im Auge behalten, ob der Fehler wiederkommt.

Frage:
Wenn ich jetzt ein Device mit rename umbenenne, bekommt die Datenbank das mit?

Nein, du hast dann in der DB zwei Devices, einmal der alte Name mit den Daten bis zur Umbenennung, und danach den neuen.
Du könntest aber direkt auf der Datenbank dann deinen alten Device Namen umbennenen in den neuen, dann passts wieder.
In etwa so:
UPDATE history SET DEVICE = "neuesdevice" where DEVICE = "altesdevice";

Oder kann man das irgendwo so konfigurieren, dass das Alias angezeigt wird?

Nein, aktuell nicht.

Noch etwas anderes:
Habe mal versucht, auch meinen Fensterkontakt darzustellen.
Das funktioniert zwar, aber die Werte 0 und 1 sind jetzt in einem Diagramm, wo der Maximalwert gerade bei 63 liegt (Valveposition)nicht so unglaublich gut sichtbar.
Könnte man irgendwo einen Multiplikator mit angeben? (so z.B. x5)? Dann würde es etwas deutlicher werden. Und die dicken Punkte wenn er einen Messpunkt hat, sind in diesem Fall eher überflüssig. (Wobei das ist eher ein echt kosmetisches Problem)

Lösung dazu: Packe deine Valveposition und den Fensterkontakt auf jeweils getrennte Achsen (left axis, right axis).
Damit solltest du an dein Ziel kommen.

Grüße,
Johannes

[Rince]

Danke für die Antwort.
Das ein Bild nicht übertragen wird, stört nicht. Gestern Nacht waren es ziemlich viele Dateien, deshalb hatte es nicht funktioniert. Wohl ein ähnliches Problem wie Puschel nehme ich an.

Das mit dem Umbenennen, das muss ich dann im Interface der Datenbank machen, ja?

Die Idee mit der zweiten y Achse, die ist cool :-)

Danke schön :-)

[Rince]

Nachtrag:
Das mit der 2. y-Achse geht besser, ist aber noch etwas vom Optimalzustand entfernt.
Lege ich den Kontakt auf die rechte Achse, werden die Werte von ganz unten bis ganz oben dargestellt.
=> ziemlich viele Striche

Mache ich es andersrum, rutschen die Temperaturwerte ganz kräftig ins obere Drittel der Anzeige.


Dürfte ich meinen Wunsch mit dem Multiplikator anders formulieren?

Wie wäre es, den Zahlenbereich für die beiden y-Achsen einstellen zu können?


Dann könnte man für die Temperatur einen Zahlenbereich von 0-40° vorgeben, was (in meinem Fall) die Werte abdecken sollte (bis jedenfalls die Sauna überwacht wird) und die Werte optisch schön mittig hält. Weiterhin könnte man dann die Valve-Achse von 0-100 gehen lassen, was auf einen Blick auch immer das richtige Verhältnis der Ventilöffnung sehen lässt.
So ist immer die maximale Öffnung (bei mir aktuell 63) ganz oben, was aber zunächst mal nicht erkennen lässt, dass da noch viel mehr Öffnung gehen würde.

Verstehst du, was ich meine?



Und eine andere Sache, aber wieder kosmetisch, kann man irgendwo den Schattenwurf der Linien ausstellen? Das wirkt unscharf.


Und noch eine Frage:
Ist es möglich eine Timerange von 24h und von 7 days zu definieren?



Vielen Dank,

Rince

[Johannes]

Wie wäre es, den Zahlenbereich für die beiden y-Achsen einstellen zu können?

Gute Idee, gefällt mir, wird beim nächsten Update eingebaut.

Und eine andere Sache, aber wieder kosmetisch, kann man irgendwo den Schattenwurf der Linien ausstellen? Das wirkt unscharf.

Im nächsten Update werden die Schatten komplett entfernt, war mir auch schon ein Dorn im Auge.

Und noch eine Frage:
Ist es möglich eine Timerange von 24h und von 7 days zu definieren?

Noch nicht. Du meinst eine Option wie "die letzten 24h ab genau jetzt" ?
Aktueller Tag, Woche etc. gibt es ja schon.