LoxBerry: Statistik Plugin - Diskussion

[Christian Fenzl]

svethi So, hab's umgebaut (den Port weggesplittet), und wenn der Benutzer echt einen Hostnamen drin steht hat, mach ich ihm zuliebe gleich noch einen DNS-Lookup ;-/
Ist bei mir aktuell, und ein Pull-Request bei Michael.
Wie man sieht, es kommt ohne Tests auf anderen Umgebungen nicht aus. Dank dir!

lg, Christian

[svethi]

Dafür sind wir ja da. :-) Finde auch immer Fehler bei Loxone. Da muss ich mich nur immer für das Finden der Fehler rechtfertigen ;-)

[Christian Fenzl]

*gg*

[Christian Fenzl]

Prof.Mobilux Hi Michael,
wie schaut denn bei dir in Stats4Lox derzeit der Plan aus?
Ich bin an Stats4Lox gerade "arbeitslos". Du hast die Indexes kurz beschrieben - hast du schon einen konkreten Plan, erstmal für einen Baum?

Ich schildere stichwortartig, was ich mir vorstellen könnte:

• Die RRDs und die Graphen sollten grundsätzlich entkoppelt sein (d.h. 1 RRD != 1 Graph).
• Per Default legen wir aber 1 Graph pro RRD an.
• Die Graph-Definition (wie auch immer die dann ausschaut) kann mehrere RRDs enthalten.
• Die Graphs können den bestehenden Räumen und Kategorien zugeordnet werden. Jeder Graph kann _mehreren_ Räumen/Kategorien zugeordnet werden.
• Navigiert wird dann - wie gewohnt - über Räume und Kategorien (hätt ich mal vorgeschlagen)
• Jeder Graph kann einzeln direkt per URL aufgerufen, oder ganze Graph-Galerien per Index (inkl. Räume/Kategorien) annavigiert werden.
• Wenn es mehrere Engines gibt, muss die per URL auswählbar bleiben (um z.B. am PC und am Mobiltelefon mit anderer Engine zu arbeiten).
• Was mir persönlich sehr wichtig ist, dass man eine Index-Seite mit mehreren Graphen auch halbwegs bildfüllend am Handy anschauen kann ohne Zoom-Verrenkungen :-)

Optimal wäre auch, wenn alles, was für die Erstellung einer Graphikengine relevant ist, gleich in die Stats4Lox.pm kommt, sodass jeder auf die globalen Einstellungen von Indexen, Graphen usw. Zugriff hat. Die Navigation sollte am besten noch Stats4Lox-Basis sein, auf die mehrere Engines zugreifen/nutzen können.
Im Prinzip muss es wahrscheinlich so konzipiert sein, dass die Navigation jeweils die Graphengine wie ein Sub mit Parametern aufruft, und eine Grafik wird ausgespuckt. Aber ich hab echt keine Idee, wie das konzeptionell mit JavaScirpt, AJAX und Callback-Funktionen gehen kann.

Wenn du mit den anderen Sachen, die du gerade baust, fertig bist, sag Bescheid. Ich werd mich mal mit dem GPIO-Plugin mit den LoxBerry::Modulen spielen, damit's mal ein Demo-Plugin gibt, mit dem man die in Trockenübung erstellten Module überhaupt mal probieren kann :-)

lg, Christian

[Prof.Mobilux]

wie schaut denn bei dir in Stats4Lox derzeit der Plan aus?
Ich bin an Stats4Lox gerade "arbeitslos". Du hast die Indexes kurz beschrieben - hast du schon einen konkreten Plan, erstmal für einen Baum?

Ich wollte mich jetzt an die erste Grafikengine machen - habe aber ehrlich gesagt noch nicht angefangen. eisenkarl hat sich ja leider nicht gemeldet. Danach wollte ich mich dann an die nächste LoxBerry-Version machen und das Statistik-Plugin von meiner Seite erst einmal ruhen lassen.

[*]Die RRDs und die Graphen sollten grundsätzlich entkoppelt sein (d.h. 1 RRD != 1 Graph).[*]Per Default legen wir aber 1 Graph pro RRD an.[*]Die Graph-Definition (wie auch immer die dann ausschaut) kann mehrere RRDs enthalten.

Sehe ich auch so. Pro Graph sollte man mehrere RRDs (=Werte) auswählen können. Ich hatte zunächst auch gedacht gleich einen Graph pro RRD anzulegen, bin mir aber nicht mehr sicher ob das so sinnvoll ist. Drauf gekommen bin ich bei der Visualisierung meines Energieverbrauchs. Da ist eine Auflistung Zeit/Wert irgendwie sinnlos... Man müsste dann schauen aus welchem Baustein der Wert kommt und anhand dessen dann entsprechende Voreinstellungen für den Graph wählen.

Das könnte man aber auch in den zweiten Schritt schieben. Das Anlegen eines Default-Graphen wäre ja vermutlich auch noch eine Funktion in addstat.cgi.

[*]Die Graphs können den bestehenden Räumen und Kategorien zugeordnet werden. Jeder Graph kann _mehreren_ Räumen/Kategorien zugeordnet werden.[*]Navigiert wird dann - wie gewohnt - über Räume und Kategorien (hätt ich mal vorgeschlagen)[*]Jeder Graph kann einzeln direkt per URL aufgerufen, oder ganze Graph-Galerien per Index (inkl. Räume/Kategorien) annavigiert werden.

Mehrere Räume/Kategorien: Daran hatte ich noch nicht gedacht. Aber ja: Sinnvoll! Was meinst Du genau mit Navigieren? zur Navigation hatte ich vor die Index-Seiten zu nehmen. Im Plugin hätte ich die Graphen einfach aufgelistet (so wie die Datenbanken auch auf der ersten Seite). Ich war bisher davon ausgegangen, dass man sich die Graphen nur über die Visu anschaut... Wenn man natürlich am PC die Graphen anschauen möchte ist das nicht sehr übersichtlich - das stimmt.

[*]Wenn es mehrere Engines gibt, muss die per URL auswählbar bleiben (um z.B. am PC und am Mobiltelefon mit anderer Engine zu arbeiten).

Im Moment habe ich im Kopf, dass man jeden Graphen, den man haben möchte, anlegen muss. So wie das auch in FHEM gemacht werden muss:




Wenn ich dann die URL des Graphen aufrufe (über seine ID) werden alle Einstellungen aus der angelegten Konfiguration genommen. Alle Optionen (oder die meisten) sollen aber per URL-Parameter übberschreibbar sein. So könnte man dann auch später den Graphen per URL wieder anpassen.

Ein Wechsel der Engine wird aber vermutlich schwierig, da unterschiedliche Engines ja unterschiedliche Fähigkeiten haben werden. Angenommen ich nehme bei HighCharts ein Diagramm-Typ, den es in der zweiten engine nicht gibt. Da wird es dann schwierig...

[*]Was mir persönlich sehr wichtig ist, dass man eine Index-Seite mit mehreren Graphen auch halbwegs bildfüllend am Handy anschauen kann ohne Zoom-Verrenkungen :-)

Das ist etwas was ich nicht so dringend brauche ;-) Hatte bisher im Kopf die Indexseite als Tabelle aufzubauen und dann aber die Spalten per URL-Parameter sowie die Vorschaubildgröße anpassen zu können. Das wird aber vermutlich nicht ausreichen...

Optimal wäre auch, wenn alles, was für die Erstellung einer Graphikengine relevant ist, gleich in die Stats4Lox.pm kommt, sodass jeder auf die globalen Einstellungen von Indexen, Graphen usw. Zugriff hat. Die Navigation sollte am besten noch Stats4Lox-Basis sein, auf die mehrere Engines zugreifen/nutzen können.
Im Prinzip muss es wahrscheinlich so konzipiert sein, dass die Navigation jeweils die Graphengine wie ein Sub mit Parametern aufruft, und eine Grafik wird ausgespuckt. Aber ich hab echt keine Idee, wie das konzeptionell mit JavaScirpt, AJAX und Callback-Funktionen gehen kann.

Ich werde mal mit einer "addgraph.cgi" anfangen. Mal sehen wie das funktionieren kann. Die Navigation, Indexes usw. können wir dann im zweiten Schritt drumherumbauen. Vielleicht magst Du das auch übernehmen - da scheinst Du Dir mehr Gedanken gemacht zu haben als ich :-) Ich habe da nicht so einen großen Bedarf - ich rufe die Trends nur übers iPAD ab und gut ist. Da brauch' ich nicht so viel :-)

Aber ich denke man kann mit der Navigation und den Indexseiten erst anfangen, wenn man mal grundlegend ein paar Trends anlegen kann.

LG,
Micha

[svethi]

Moin Ihr Beiden,

also mal ehrlich. Ich habe mich mit den hier auflaufenden Themen Graphen, RRD etc. noch nie befasst, doch das liest sich hier nach unheimlich viel Arbeit. Hut ab. Ich finde eher Fehler in bestehenden Dingen *g*
Sagt mal, was ich gestern noch gar nicht angesprochen habe ... bei mir gabs gestern auf Indexes und Graphen (oder wie es heißt) auch nach anlegen eines Wertes immer nur Error loading page. Ist das noch korrekt?
Christian Fenzl bei mir ging gestern nichts mehr ... werd es vllt heute mal testen. Wenn es bei Michael noch nicht gemerged ist, kann ich es ja von Dir holen.

[Christian Fenzl]

Jo, wenn man's richtig machen will (ich hoffe zumindest, dass das alles Sinn macht), ist da schon Komplexität drin.

Die Charts- und Indexes-Seiten gibt's noch nicht, das diskutieren wir gerade :-)
Auf der Statistiken-Seite links oben gibts "Quickcharts", da solltest du schon was sehen.

lg, Christian

[svethi]

Ja, wenn man auf das Graphicon neben dem Namen klickt, kommt ja auch der Graph für diesen Wert. Soweit sogut. Ja, habe ich mir ja schon gedacht, daher hatte ich gestern nichts gesagt. Wollte nur noch einmal sicherstellen, dass es da nicht bei mir noch mehr Probleme gibt :-)

[Christian Fenzl]

Wie du sagst, es braucht mal was, damit man mal sieht, wie man es verwenden kann :-)

Ich habe ein paar Screens angehängt, wie das mit Cacti (in diesem Fall CactiPhone, reduziertes UI extra fürs Mobiltelefon) ausschaut.
In Cacti muss jeder Graph einzeln definiert werden, und jeder Graph wird frei definierbar in einem Baum abgelegt, wo er dann angezeigt wird. Man hat immer mehrere Graphs am Schirm, so kann man auch direkt vergleichen.
Das ist sehr praktisch und übersichtlich, man kommt schnell zu Graphen im Baum.
Klick auf einen Graphen öffnet bei Cacti die Sicht auf die definierten rra's, das könnte bei uns die Einzelgrafik mit Manipulationsmöglichkeit (was die Engine hergibt) öffnen.

Das war, was ich mit "Navigation" meinte.

Mit den Infos, die wir schon haben (Raum/Kategorie), haben wir praktisch eine rudimentäre Navigation in der Hand.

Diese Navigation kann man später bauen. Evt. bei der Engine berücksichtigen, dass es sowas wie einen "Übersichtsmode" (nur Anzeige) und einen "Full Mode" (Anzeige+Interaktion) gibt.

Bin schon auf die Engine gespannt!

lg, Christian

[svethi]

Solltest mal ein iOS Update machen ... musste erst überlegen was das für'n Gerät ist *g*

[Christian Fenzl]

Das ist keine App, sondern eine Webanwendung erstellt mit iWebKit (sowas wie jquery, nur viel einfacher). Das verwendete Template ist schon älter, wie man sieht :-)

[Christian Fenzl]

Die Definition von FHEM finde ich gar nicht schlecht.
Hier mal auch ein Screenshot von Cacti, was man dort alles pro Graph und pro Datensatz definieren kann. Bei Cacti ist natürlich alles auf die RRD-Graph-Engine zugeschnitten. Es ist aber auch ein gutes Beispiel dafür, was da alles definiert sein könnte/müsste.

Mir gefällt Config::Simple sehr gut, wo man das alles ablegen könnte, und es gibt das gleiche für PHP (parse_ini_file). So wie in der general.cfg.
So in der Art

[GRAPH]
Title=Fußbodenheizung OG und UG
AutoScale=True
LogarithmicScale=False
UpperLimit=100
LowerLimit=0
NumberOfDatasets=3

[DATASET1]
Datasource=0001
Color=FF0000
Opacity=100
Type=line2
LegendText=OG Vorlauf
Order=1

[DATASET2]
Datasource=0012
Color=00FF00
Opacity=100
Type=line2
LegendText=UG Vorlauf
Order=2

[DATASET3]
# Feste, horizontale Linie bei 60
Datasource=
Color=AAAAAA
Opacity=100
Type=line1
LegendText=
Value=60
Order=3

Das könnte man dann auch leicht erweitern.
Jede Graph-Engine muss selbst einen "Wrapper" implementieren, was sie mit den bereitgestellten Settings anfängt.

lg, Christian

[svethi]

Dem Raspi1 qualmt der Kopf. Er importiert. Dauert wohl so seine Zeit *g*
Christian Fenzl dann hätte mein Patch bei einer Neuinstallation wohl auch funktioniert, denn genau dort hatte ich ja auch angesetzt

[svethi]

:heul: jetzt ist der nach Stunden endlich mit der ersten durch und zeigt die auch grün an, jetzt ist der Chart leer. Muss dazu gestehen, dass ich böse bin und eigentlich nur Verbrauchszähler habe :-) hab auch schon auf value-count umgeschaltet. Bringt nix.

[Prof.Mobilux]

Wenn ich mir die Screenshots und die CactiEngine von Christian Fenzl anschaue wird mir ganz schlecht - was haben wir da nur angefangen?!? Ich schätze an dem Ding programmieren wir noch wenn wir alle schon in Rente sind...

Die Navigation von Cacti finde ich cool - ich hatte an etwas viel einfacheres gedacht!. Ich wollte pro Chart einfach ein (fixes) Icon auf der Index-Seite verwenden, man klickt drauf und kommt zum eigentlichen Chart. Aber:



Die Navigation, die Christian Fenzl dort zeigt ist ja eine andere (wenn ich es richtig sehe). Wenn iich das auf uns übertrage wäre der Einstieg einer Index-Seite eine Auflistung aller Räume oder Kategorien. Dann klicke ich auf einen Raum/Kategorie und komme zu einer Miniaturansicht von allen Graphen, die dazu gehören. Der nächste Klick auf die Miniaturansicht öffnet dann den Graph mit Manupulationsmöglichkeiten bzw. je nach Engine einfach verschiedene Ansichten des Charts (wie oben bei Cacti). Das finde ich sehr cool!

Nur wird das eine Javascript-Orgie auf der Index-seite, wenn dort 10 Graphen per Javascript/Highchart als Übersicht gebaut werden sollen. Ich schätze mein iPad1 baut da ewig an der Seite :-) Das ist natürlich bei RRD einfacher gelöst mit den starren PNG-Graphen...

Config::Simple werde ich auch für die Definition nehmen. Meine jetzige Idee ist, dass pro Graph eine Config angelegt wird. Je nach Engine kann die Configdatei aber anders aussehen - also je nach dem, was die Engine für Optionen bietet. Im Header der Config-Datei muss daher fest fixiert sein, welche Engine verwendet wird. Anschließend muss es dann pro Engine einen Parser geben, der die Config-Datei auswertet.

[svethi]

Eines ist klar, wenn Du erst einmal in Rente bist, hast Du auch wieder mehr Zeit ;-). Nur ob ich das Debugging dann noch hinbekomme kann ich nicht sagen :-)

[Christian Fenzl]

svethi Zu deinem grünen aber leeren Import:
Ist es leer oder alles 0?
Kannst du mir ein Monats-XML schicken, um das mit meinen XMLs des Verbrauchszählers zu vergleichen. Und das Importlog. Weil meine Verbriahcszähler funktionieren.

lg, Christian

[svethi]

Christian Fenzl ich hab da mal reingesehen. Ist weder leer noch steht 0 drin. Steht NaN drin ;-) "Not a simple unsigned integer" beim Schreiben in die rrd.
Da ist wohl das Feld falsch angelegt ;-)

[Christian Fenzl]

Welches Feld, wo, was, falsch angelegt? Ich brauche mehr Detaaails :-)

[svethi]

Kenn ich mich mit Round Robin aus? Nö. Da kann ich ja auch gleich selber machen *g*
<!-- 2017-01-30 01:00:00 CET / 1485734400 --> <row><v>NaN</v></row>

Ich denke mal, dass das Feld wohl ebenso v heißt.

Im Log ist kein Feldnamen erwähnt.

[Christian Fenzl]

svethi
Sorry, ich steh grad völlig am Schlauch.
Wo steht das?
Schickst mir einfach das XML dieses Monats (Download-Pfad steht im Log) und das Log, und vielleicht auch gleich das RRD?
Einfach zippen per PM
lg, Christian