LoxBerry: Statistik Plugin - Diskussion

[svethi]

Hihi, ich glaube nicht, dass Dir die XML was bringt. Das steht da nicht anders drin als in Deinem auskommentierten Beispiel in der bin/import.pl
bis auf V2 bei dem bei mir Inf steht. Warum auch immer. Vielleicht weil ich am Anfang keinen Leistungsgeber dran hatte.

Die Zeile oben ist aus dem rrd dump. Steht halt bei jedem Wert NaN drin, da er mit dem float nichts anzufangen wusste.
Importlog siehts so aus:

2017-01-30 18:43:14 INFO: =============== 6/2014 === STARTED XML processing ===============================
2017-01-30 18:43:20 INFO: Interpolation started to fill up missing values - Raw data: 722
2017-01-30 18:43:20 DEBUG: Last month data: 2014-06-30 23:55:00 Value: 1473.084
2017-01-30 18:44:26 INFO: Interpolation finished - Added data: 16847, Data count now 17569
2017-01-30 18:44:40 INFO: --> 2000 Datapoints prepared for RRD update ...
2017-01-30 18:44:40 ERROR: Error processing rrds::update: /dev/shm/stats4loximport/0001.rrd: not a simple unsigned integer: '1618.500'
2017-01-30 18:44:43 INFO: --> 4000 Datapoints prepared for RRD update ...
2017-01-30 18:44:43 ERROR: Error processing rrds::update: /dev/shm/stats4loximport/0001.rrd: not a simple unsigned integer: '1618.500'
2017-01-30 18:44:47 INFO: --> 6000 Datapoints prepared for RRD update ...
2017-01-30 18:44:47 ERROR: Error processing rrds::update: /dev/shm/stats4loximport/0001.rrd: not a simple unsigned integer: '1618.500'
2017-01-30 18:44:51 INFO: --> 8000 Datapoints prepared for RRD update ...
2017-01-30 18:44:51 ERROR: Error processing rrds::update: /dev/shm/stats4loximport/0001.rrd: not a simple unsigned integer: '1618.500'
2017-01-30 18:44:54 INFO: --> 8928 Datapoints prepared for RRD update ...
2017-01-30 18:44:54 ERROR: Error processing rrds::update: /dev/shm/stats4loximport/0001.rrd: not a simple unsigned integer: '1618.500'
2017-01-30 18:44:54 INFO: 8928 datapoints updated in 100 seconds.
2017-01-30 18:44:54 INFO: =============== 6/2014 === FINISHED =============================================

[Christian Fenzl]

Your code might be intermittently inserting floats for COUNTER, DERIVE or ABSOLUTE datasource types. Only integers are permitted on those datasource types.

[Christian Fenzl]

gut zu wissen - und dann auch zu fixen :-)
Jetzt muss ich mir die Stats-Definition also auch noch vorher anschauen ;-)

[svethi]

Was hast Du denn da für Daten wenn das bei Dir geht? Die in Deinem Beispiel sehen doch genauso aus.
Der Zähler hat keinen Tr sondern bekommt einen Wert zum dazuaddieren übermittelt.

[Christian Fenzl]

svethi Ich hab jetzt die Anpassung mit den Integern an Michael gepusht - wie ich ihn kenne, merged er am Morgen noch vor dem Zähneputzen ;-)
Ich habe auch Michael's fetch.pl angepasst, weil das bei den fortlaufenden Polls das gleiche Problem ist.
Dann müsstest du aber wirklich was sehen, sonst müssen wir in die nächste Runde mit Debugging! :-)

[Prof.Mobilux]

Stimmt - ist gemergt :-)

[Christian Fenzl]

Kurz zur Zusammenfassung des Import-Problems:
Der Import geht jetzt, es war das FLOAT-Problem. FLOAT's lassen sich nur mittels DCOUNTER-DS-Type importieren, den es erst am RRDTool v1.50 gibt (Raspbian liefert v1.48 mit).

Jetzt gibt's ein neues Problem mit den Werten, das sich meines Erachtens nur in der Graphengine lösen lässt:
Die Delta-DS-Typen COUNTER und DCOUNTER normalisieren den Wert auf "Value pro Sekunde".
Beispiel:
Sekunde 100 wurde 12 kW importiert/gefetched.
Sekunde 301 wurde 14 kW importiert/gefetched.
RRDTool rechnet nun
(301-100)=201
(14-12)=2
(2/201)=0,00995 kW/Sekunde.
Für dieses Intervall (201) wird der Durchschnitt 0,00995 gespeichert.

Ein Chart für Werte pro Stunde muss jetzt selbst alle Durchschnittswerte der Stunde mal 3600 rechnen, um auf kWh zu kommen.
Ein Chart für Werte pro Tag muss alle Durchschnittswerte des Tages mal 3600*24 rechnen, um auf die KW des Tages zu kommen.
Ich mache in die DS-Definition für den Verbrauchszähler jetzt auch einen GAUGE-Zeile hinein, um zur Sicherheit trotzdem auch den ermittelten Absolutwert abzuspeichern. So kann ggf. auch die Graph-Engine das Delta berechnen.

Lg, Christian

[Christian Fenzl]

PS:
Korrekterweise müsste die Graphengine für eine Stunde rechnen:
Das Dataset enthält den Epoch-Timestamp time[x] und den Value[x], beides von einer Stunde.
Result += value[x] * (time[x]-time[x-1])

[Prof.Mobilux]

Auf das Probem "Wert pro Sekunde" bin ich auch schon gestoßen. RRDGraph bietet dazu CDEF an: http://oss.oetiker.ch/rrdtool/doc/rrdgraph_data.en.html Soetwas in der Art habe ich im Kopf - vielleicht beschränkt auf ein oder zwei Rechenoperationen und nicht "unendlich" viele wie bei RRDGraph.

Result += value[x] * (time[x]-time[x-1]) dann umzusetzen wird schon wieder schwieriger - zumindestens wenn man das auch irgendwie allgemeingültig in die Konfiguration bringen will. Weiß noch nicht wie ich das lösen kann.

[Christian Fenzl]

Beim FLOAT-Problem habe ich auch weiter recherchiert. Das mit dem Runden ist zwar für längerfristige Graphen egal, aber ein konkreter Einzelwert ist faktisch immer falsch.
Da der Verbrauchszähler kWh in Float liefert, bekomme ich beispielsweise nie den richtigen Wert der Stunde, wo die Waschmaschine gelaufen ist. Der Tageswert hingegen ist natürlich wieder richtig.

Zwei Ansätze habe ich im Kopf:
1. Ich nehme in dbsettings eine frei definierbare Vorberechnung des Wertes hinein. Z.B. steht dort drin "*1000", wird der Value mit 1000 multipliziert, oder "/100" dividiert den Value. Das nehme ich dann im Import und Fetch hinein. Die Rundung passiert nach der Berechnung.

2. Ich trickse apt aus (Pinning), nur RRD aus testing zu holen (v1.6.0). Die vorausgesetzten Libs (libc) scheinen jetzt schon zu passen, muss ich aber testen.

Besser gefällt mir Weg 2 - aber nur, wenn es funktioniert.

[Prof.Mobilux]

Weg 2 würde mir auch besser gefallen - oder selbst kompilieren und mitliefern.

[Christian Fenzl]

Prof.Mobilux
Wie geht's dir mit der Statistik?
Ich mach das Any-Plugin noch fertig ("Eigenbedarf"), dann würde ich mir mal das Versionsheben von rrdtool genauer anschauen.
Hast du schon was in Richtung Definitionsdateien Navigation oder Plots (auch halbfertig, egal)?

[Prof.Mobilux]

Christian Fenzl Leider bin ich noch nicht weiter - habe ehrlich gesagt die letzten Wochen nicht weiter um Plugin gebaut, bis auf dass ich etwas mit HighCharts gespielt habe....

Bei mir wird es in nächster Zeit beruflich sehr eng werden - ich überlege daher wie wir weiter machen (sollen). Eventuell macht es mehr Sinn wenn ich mich aus Stats4Lox vorerst zurückziehe und mich um die nächste Version des LoxBerry kümmere. Deine Libs haben ja eine sehr gute Basis und die Liste an offenen Punkten im Restsystem des LoxBerry wird dort langsam immer länger... Ich würde gerne auch die Pluginschnittstelle auf Version 2 heben inkl. Deinstall.sh usw.

Wenn wir das so angehen hättest Du "freie Bahn" hier ;-) Was denkt ihr?

[Christian Fenzl]

Ich würde sagen, wir lassen Stats4Lox ruhen, und helfen alle bei LoxBerry zusammen.
Es ist derzeit ja noch niemand auf die Statistik angewiesen.

Ich finde das spannender als allein zu programmieren. Es hat von den "Stammentwicklern" sicher niemand was dagegen, wenn du die Tasks etwas verteilst, und die QA ist viel besser.

[svethi]

Ich bin in der letzten Zeit auch zu nichts gekommen da ich einfach zu viel um die Ohren habe. Ich sehe das so wie Christian. Die Stats sind ja jetzt nicht lebensnotwendig und die Libs als festen Bestandteil würde ich schon begrüßen, dann müssen die nicht immer mit ausgeliefert werden.

[Prof.Mobilux]

Super, bin ich natürlich einverstanden! Ich mache mal einen neuen Thread für LoxBerry 0.3.0 auf.

[m0h]

Hallo, mich drückt noch das Statistik thema (SD Karte des MS ist jetzt auch kaputt). Ich arbeite gerade an einem python script mit dem ich bestimmte varialben über die Webservices auswerten kann und mir dann Diagramme statisch erzeugt werden (jpg). Diese werden für den Magic Mirror abgelegt und der lädt diese mit dem Picture-Viewer und zeigt sie im Spiegel an. Dann habe ich mir gedacht, ich entwickle dies weiter und schreibe mir die Werte in eine MySQL Datenbank und deaktiviere die Statistik am MS komplett.

Hat jemand Erfahrung wie eine zyklische Abfrage aller Eingänge (100) und Ausgänge den Miniserver belastet? Mir fällt es speziell bei vielen UDP pakenten auf, dass die CPU Auslastung in die höhe schnellt.

Wird an dem Statistik Tool noch gearbeitet?

[svethi]

Die Frage ist eher, wo läuft denn die MySQL Datenbank? Auf dem Rpi mit SD-Karte?

[m0h]

Hallo, ich hab ein QNAP, das wäre der Plan. Für RPI hätte ich mir eine externe SSD gedacht.

[svethi]

Okay ... war ja nur ne Frage :-)