Diagram - RRA direkt adressieren?

[MicHau]

Das Backend ist eigentlich relativ simpel, nur erwartet die CV die Daten als json. Das kann bislang nur die gepatchte rrdtool Version des Wiregates. Ich hatte damals aktuelle rrdtools für x86 und arm gebaut die den Patch enthielten.
Makkis Totschlagargument war die Geschwindigkeit und damit hat er auch recht. Die aktuellen rrdtool Versionen sind langsamer. Sein Patch/Featurerequest wurde von T.Oettinger nicht übernommen.

Bezog sich das Argument Geschwindigkeit auf die Erzeugung des Outputs oder auf die Übertragung des Ergebnisses?

Ich denke, dass man das CV-Plugin mit ziemlicher Sicherheit auch ohne weiteres auf ein anderes Input-Format als JSON ändern könnte. Die Beschränkung auf RRD ist vermutlich sowieso nicht gerade sinnvoll, da man ja eventuell auch aus anderen Datenquellen Zeitreihen erhalten könnte.

[JuMi2006]

Die Geschwindigkeit bezog sich auf das Erzeugen der Datenreihen von rrdtool. Das hab ich selbst auf Unterschiedlicher Hardware nachstellen können. Ein Diagramm mit mehreren Datenreihen dauert schon eine Weile länger. Das WireGate mit seiner uralt rrdtool Version und der schwachen CPU ist sicherlich schneller als mein 1.6GHz Atom mit 2GB RAM. Mich stört es nicht so.

[tger977]

OK, verstanden.
Allerdings habe ich einige Befürchtungen bezüglich der Performance. Aber wie immer geht Probieren über Studieren.

Ich würd es auch ausprobieren / testen falls Du es umsetzen kannst

Bessere Idee hab ich leider keine.

[MicHau]

Ich würd es auch ausprobieren / testen falls Du es umsetzen kannst

Na dann, los geht's: Open Automation / Code / Commit [r2314]

Tatsächlich dürfte es kaum Geschwindigkeitsnachteile mit sich bringen, denn das Werte-Array wird sowieso schon komplett durchlaufen, die zusätzliche Berechnungszeile sollte also nicht sonderlich ins Gewicht fallen.

Das neue Attribut offset wird in Sekunden angegeben. Die folgende Definition verschiebt alle Zeitstempel um 10 Minuten nach vorne.

<rrd offset="-600" ...>...

[MicHau]

Die Geschwindigkeit bezog sich auf das Erzeugen der Datenreihen von rrdtool. Das hab ich selbst auf Unterschiedlicher Hardware nachstellen können. Ein Diagramm mit mehreren Datenreihen dauert schon eine Weile länger. Das WireGate mit seiner uralt rrdtool Version und der schwachen CPU ist sicherlich schneller als mein 1.6GHz Atom mit 2GB RAM. Mich stört es nicht so.

Kann man nicht mit rrdtool xport --json (siehe RRDtool - rrdxport) das gleiche Ergebnis erzielen? Das habe ich gerade in der Dokumentation gefunden. Da diese Option aber noch nicht auf dem Wiregate verfügbar ist, kann ich es nicht selbst ausprobieren.

[tger977]

Das neue Attribut offset wird in Sekunden angegeben. Die folgende Definition verschiebt alle Zeitstempel um 10 Minuten nach vorne.

<rrd offset="-600" ...>...

Wie kann man die negativen Werte im Editor eingeben? Dieser erwartet immer Integer (ansonsten kommt ne Fehlermeldung) und damit geht derzeit nur Verschieben in die Zukunft.

Wenn ich direkt im xml editiere geht es aber schon mal, d.h. der Code von Dir scheint schon mal i.O. Auf die Laufzeit sehe ich keinen spürbaren Einfluß.

Jetzt macht das mit den rrd Spielereien langsam richtig Spaß! Danke!

[MicHau]

Wie kann man die negativen Werte im Editor eingeben? Dieser erwartet immer Integer (ansonsten kommt ne Fehlermeldung) und damit geht derzeit nur Verschieben in die Zukunft.

Schau mal bitte in der neuesten Version, das war offenbar ein Fehler im Editor, der nur positive Werte für Integer erlaubt hat.

[tger977]

jup, jetzt tuts!

Nochmal herzlichen Dank für die schnelle unkomplizierte Hilfe! Für mich hat das Diagram Plugin jetzt einen deutlichen Mehrnutzen!

Denke damit kann man das Thema jetzt erstmal als einsatzreif abhaken!

Einzig die Doku muss man da ggf. mal nachziehen und etwas aufpeppen, da warte ich aber noch auf eine Entscheidung wie es mit der Doku der CV weitergeht...

Gruß
Andi

[Chris M.]

Auf welche Entscheidung wartest Du da?
Mir fällt momentan nichts ein, was da offen wäre...

Zum Thema:
Wenn das jetzt alles so passt (bitte von vielen Testen!), dann kann ich mir vorstellen zeitnah ein neues Release raus zu bringen

[tger977]

War da nicht mal die Diskussion das die CV Doku auch auf einen confluence Server umziehen soll auf den auch die WG Doku kommt? Oder bringe ich da jetzt was durcheinander? Falls sich nichts ändern wird müsste ich vielleicht doch noch über einen Schreibzugriff auf die heutige CV Dokuplattform nachdenken... Wer / wie kann man den bekommen?

[Chris M.]

Das mit Confluence war höchstens mal eine Gedankenspielerei.
Ziel ist es die Einstiegshürde zur Doku so gering wie möglich zu halten, so dass möglichst viele mitmachen können. Das System folgt daraus - und nach allem was *ich* aktuell sehe, ist's das MediaWiki. Aber sobald es da Neuigkeiten gibt, kann man das natürlich wieder neu bewerten.

Schreib-Zugriff auf's MediaWiki: IIRC einfach mit einem anderen Account anmelden und den Nutzernamen Makki, Swiss oder mir (wobei ich dann nicht wirklich weiter weiß...) zum Freischalten schicken.

[JuMi2006]

Ich hab das jetzt mal mit XPORT --JSON ausprobiert.

time rrdtool xport --json --start now-24h --end now DEF:xx=/var/www/rrd/WP_1-8-1_5.rrd:value:AVERAGE XPORT:xx:"test"
{ about: 'RRDtool xport JSON output',
  meta: {
    start: 1420581300,
    step: 300,
    end: 1420581300,
    legend: [
      'test'
          ]
     },
  data: [
    [ 0.0000000000e+00 ],
    [ 0.0000000000e+00 ],
    [ 2.0000000000e-01 ],
    [ 1.0000000000e-01 ],
    [ 2.0000000000e-01 ],
    [ 1.0000000000e-01 ],
    [ 2.0000000000e-01 ],
    [ 1.0000000000e-01 ],
    [ 2.0000000000e-01 ],
    [ 1.0000000000e-01 ],
    [ 2.0000000000e-01 ],
    [ null  ]
  ]
}

real	0m0.060s
user	0m0.000s
sys	0m0.020s

time rrdtool fetch /var/www/rrd/WP_1-8-1_5.rrd AVERAGE -s-24h
                          value

1420581300: 0,0000000000e+00
1420581600: 0,0000000000e+00
1420581900: 2,0000000000e-01
1420582200: 1,0000000000e-01
1420582500: 2,0000000000e-01
1420582800: 1,0000000000e-01
1420583100: 2,0000000000e-01
1420583400: 1,0000000000e-01
1420583700: 2,0000000000e-01
1420584000: 1,0000000000e-01
1420584300: 2,0000000000e-01
1420667700: -nan

real	0m0.039s
user	0m0.004s
sys	0m0.016s

rrdtool -v
RRDtool 1.4.7  Copyright 1997-2012 by Tobias Oetiker <tobi@oetiker.ch>
               Compiled Aug  2 2012 07:45:32

Usage: rrdtool [options] command command_options
Valid commands: create, update, updatev, graph, graphv,  dump, restore,
		last, lastupdate, first, info, fetch, tune,
		resize, xport, flushcached

RRDtool is distributed under the Terms of the GNU General
Public License Version 2. (www.gnu.org/copyleft/gpl.html)

For more information read the RRD manpages

Also ich sehe da keinen Vorteil, evtl. frisst die folgende Verarbeitung in der rrdfetch.cgi aber den ein oder anderen Vorteil wieder auf. Der Versuch steht noch aus. Aber im Moment fehlt dafür Zeit. Schön wäre es trotzdem sich von der gepatchten rrdtool-Version lösen zu können.

[JuMi2006]

Ein letzter Versuch für heute, die cgi-Zeit:

time QUERY_STRING="rrd=WP_1-8-1_5.rrd&ds=AVERAGE&start=end-24hour&end=now&res=60" ./rrdfetch
Content-Type: application/json
Content-Encoding: gzip

gzip: compressed data not written to a terminal. Use -f to force compression.
For help, type: gzip -h

real	0m0.735s
user	0m0.160s
sys	0m0.136s

[mivola]

so eben mal selbst ausprobiert: Geht nun ganz einfach aus dem Standard RRD in dem man beim RRD Teil des Temperatursensors einfach in die Resolution 86400 einträgt (die ist ein Vielfaches von 300s)! Man kann dann z.B. das rrd child einfach kopieren und nochmal eine Linie in die Grafik einfügen mit Standard resolution, dann sieht man den vergleich.

So, das habe ich nun mal ausprobiert (heutiger SVN-Stand). Leider nur mit mäßigem Erfolg: bei resolution=86400 sind die Schritte nicht wie erwartet 24h sondern nur 15h lang.
Hier ein paar Infos zum rrd:

root@wiregate:/var/www/visu-svn.neu/config# rrdtool info /var/www/rrd/26.E0AF30010000_temp.rrd
filename = "/var/www/rrd/26.E0AF30010000_temp.rrd"
rrd_version = "0003"
step = 300
last_update = 1421310018
ds[value].type = "GAUGE"
ds[value].minimal_heartbeat = 900
ds[value].min = -5,5000000000e+01
ds[value].max = 2,5500000000e+05
ds[value].last_ds = "3.96875"
ds[value].value = 7,2786370969e+01
ds[value].unknown_sec = 0
rra[0].cf = "AVERAGE"
rra[0].rows = 2160
rra[0].cur_row = 1993
rra[0].pdp_per_row = 1
rra[0].xff = 5,0000000000e-01
rra[0].cdp_prep[0].value = NaN
rra[0].cdp_prep[0].unknown_datapoints = 0
rra[1].cf = "AVERAGE"
rra[1].rows = 2016
rra[1].cur_row = 875
rra[1].pdp_per_row = 5
rra[1].xff = 5,0000000000e-01
rra[1].cdp_prep[0].value = 0,0000000000e+00
rra[1].cdp_prep[0].unknown_datapoints = 0

Hier der Code der CV:

<diagram_info series="day" period="7" refresh="300" format="%.1f °C" tooltip="true">
          <layout colspan="3"/>
          <label><icon name="temp_outside"/>gestern</label>
          <axis unit=" °C"/>
          <rrd color="red" label="24h" resolution="86400">26.E0AF30010000_temp</rrd>
          <rrd color="blue" label="Temp">26.E0AF30010000_temp</rrd>
          <address transform="DPT:9.001" mode="read">5/4/125</address>
</diagram_info>

Anbei ein Screenshot der Visu. Ich habe auch bissl mit dem resolution-Parameter gespielt, aber leider ohne Erfolg.

Jmd eine Idee?

VG
Micha

[Hauke]

Die RRD-Infos sind aber von dem Original-RRD, nicht von dem mit der geänderten Auflösung, oder?

step = 300
rra[0].pdp_per_row = 1

Das passt irgendwie nicht so ganz zu den erwähnten 86400...