Diagram - RRA direkt adressieren?

[MicHau]

Nun würde ich dieses gern in der CV anzeigen. Dazu müsste man aber den RRA-Namen mit übergeben können. Die URL sieht dann beipsielhaft wie folgt aus:
http://wiregateXYZ/graph.pl?--start=...:ds0=load.rrd:midterm:AVERAGE;LINE1:ds0%23FF0000:load.rrd;

Könnte dies jemand mit genug Kenntnis einbauen? Oder ist der Aufwand größer als es mir jetzt erscheint?

Wenn mir jemand sagt, wie ich das in den oben beschriebenen serverseitigen Aufruf als Parameter (siehe #13: https://knx-user-forum.de/449773-post13.html) übergeben muss, kann ich das gerne übernehmen. Allerdings behandele ich die Serverseite, wie im vorherigen Post beschrieben, als Blackbox, daher kann ich da selbst nicht weiterhelfen.

[JuMi2006]

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.

Da ich darauf keinen Bock hatte hatte ich einfach die rrdfetch.cgi geändert: https://knx-user-forum.de/cometvisu/...tml#post316204

Alles was rrdtool fetch kann, kann damit auch die CV, wenn man will. Die bash Funktionen kann ja mal jemand auf Geschwindigkeit optimieren.

[tger977]

Und zwar würde ich gern einen Graph anzeigen lassen, der mir die Durchschnittstemperatur eines Tages bzw Woche/Monat anzeigt.

Die Datenbasis liefert ein WG-Temperatursensor, also ein Standard-WG-RRD. Die Frage ist nun: geht das mit den standardmäßig erstellen RRDs und deren RRA-Einstellungen? Wenn nicht, wie kann ich das existierende RRD anpassen/erweitern? Oder ist es eher sinnvoll ein separates RRD zu erstellen (und periodisch mit Werten zu füllen)? Wenn ja, mit welchen Parametern?

Hallo Micha,

die Standardeinstellungen im WG liefern Auflösungen von 5min für Zeitbereich von 7,5Tagen, 25min für 35Tage, 75min für 150Tage und 900min für 15 Jahre. Frag mich nun bitte nicht warum die Auflösungen so gemacht wurden. Ich hätte die Auflösungen auch anders gewählt (z.B. 5min, 1h, 24h und 1 Woche). Das geht, dazu müsste man aber alle RRD neu anlegen und ggf. die Daten aufwändig in die neuen RRD übertragen. Man kann das aber individuell in den Einstellungen des WG ändern oder selbst die RRD anlegen.

Ich habe mal ein xls gemacht (in dem sind die Standardparameter des WG als Anfangswerte enthalten) in dem man zumindest rausbekommt welche Resolution man in dem neuen Parameter eintragen muß um genau die Werte eines RRA zu bekommen. Dazu muß man mit folgendem Befehl im rrd Verzeichnis

rrdtool info 28.99FF5A040000_temp.rrd

sich die Werte step, RRA Index, PDP_per_row und rows rauslesen (grün hinterlegte Eingabefelder) und dort eintragen. Man bekommt dann die Resolution und den möglichen Zeitbereich der RRA heraus.

Dann einfach die gewünschte Resolution eines RRA in der CV eintragen und es sollte funktionieren.

Wenn man eine andere Resolution haben möchte sollte das das rrdtool auch intern umrechnen können, man sollte nur beachten daß man ein Vielfaches einer vorhandenn Resolution verwendet. Das Ganze habe ich aber noch nicht wirklich ausprobiert.

Gruß
Andi

[tger977]

Also für mich sieht es nicht so gut aus. Die Tageswerte sind um einen Tag verschoben würde ich sagen. Ist irgendwann mal geplant von der speziell gepatchten rrdtool Version weg zu gehen? Ich hatte die rrdfetch.cgi schonmal soweit verändert dass sie mit jeder rrdtool Version läuft.

Das ist leider ein prinzipielles "Problem". Das Tool speichert immer die Werte der Vergangenheit ab, d.h. bei den 15min Werten bekommt man immer den Wert der letzten 15min, bei den Stunden immer den letzten Wert der letzten Stunde, d.h.mit Zeitstempel von z.B. 9 Uhr bekommt man im 15min RRA den Wert von 8:45 bis 9:00 und im Stunden RRA bekommt man eben den Wert von 8:00 bis 9:00. Wollte man das korrigieren müsste man die x-Achsen Wertzuweisung entsprechend verschieben.

[tger977]

Ich hätte passend zur aktuellen Diskussion doch auch noch einen Feature-Wunsch. Ich würde gern den Namen des RRA direkt angeben können.

das geht heute schon und war auch vorher schon im Plugin möglich. Hier handelt es sich um untershciedliche Datasets (DS). Diese kann man direkt im Plugin unter dem Attribut datasourceIndex eintragen. Alledings muß man hier nicht die Namen angeben sondern den Index. In dem Fall wäre 0 = shortterm, 1=midterm, 2=longterm.

Zusätzlich kann man nun auch über das Resolution Attribut die Auflösung der Werte beeinflussen...

Gruß
Andi

[tger977]

Schritt 2 ist auch erledigt: Open Automation / Code / Commit [r2312]
[/CODE]

Danke! hab ich doch glatt heute morgen übersehen. Problem bei mir ist daß die Editierbox für das Diagram Plugin nun leider so lange geworden ist, daß Sie unten abgeschnitten wird und die neuen Parameter nicht sichtbar waren. Da es keine Scrollfunktion in dem Attributbereich gibt (warum eigentlich?!) muß man um die neuen Attribute zu sehen leider die Bildauflösung über CRTL + Mausrad deutlich reduzieren.

Ansonsten scheint mir das Ganze prima und wie gewünscht zu funktionieren!

Gruß
Andi

[tger977]

Zufälligerweise bin ich auf der Suche nach einer ähnlichen Funktionalität. Und zwar würde ich gern einen Graph anzeigen lassen, der mir die Durchschnittstemperatur eines Tages bzw Woche/Monat anzeigt.

Die Datenbasis liefert ein WG-Temperatursensor, also ein Standard-WG-RRD.

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.

Allerdings ist zu beachten wie oben schon geschrieben daß die Werte in die Vergangheit zeigen also subjektiv "verschoben" aussehen!

@MicHau: Wenn man da nun noch eine x-Offset um die Resolution [sec] einbauen könnte wäre das perfekt!

[MicHau]

Problem bei mir ist daß die Editierbox für das Diagram Plugin nun leider so lange geworden ist, daß Sie unten abgeschnitten wird und die neuen Parameter nicht sichtbar waren. Da es keine Scrollfunktion in dem Attributbereich gibt (warum eigentlich?!)

Ich bin in Sachen Editor leider überfragt. Vielleicht kann jemand anderes hier helfen.

[mivola]

@tger977 & MicHau: vielen Dank für die Arbeit und die Erklärungen! Funktioniert echt prima. Da fallen mir direkt noch ein paar weitere Spielerein ein ... :-)

Danke,
Micha

[MicHau]

@MicHau: Wenn man da nun noch eine x-Offset um die Resolution [sec] einbauen könnte wäre das perfekt!

Das ist mir nicht ganz klar. Wenn ich deine obigen Ausführungen richtig verstehe, wäre der Timestamp doch eigentlich korrekt. Bei 15 Minuten Auflösung gibt der Wert um 9 Uhr den errechneten Wert für 8:45 bis 9:00 wieder. Das wäre doch richtig. Wenn ich diesen Wert um 8:45 anzeigen würde, wäre das meines Erachtens falsch

[tger977]

Hallo Micha,

die Ideen für die netten Spielereien darfst Du gerne hier mit uns teilen

Gruß
Andi

[mivola]

die Ideen für die netten Spielereien darfst Du gerne hier mit uns teilen

Mach ich. Sobald diese einigermaßen vorzeigbar in der CV eingebunden sind :-)

[tger977]

Das ist mir nicht ganz klar. Wenn ich deine obigen Ausführungen richtig verstehe, wäre der Timestamp doch eigentlich korrekt. Bei 15 Minuten Auflösung gibt der Wert um 9 Uhr den errechneten Wert für 8:45 bis 9:00 wieder. Das wäre doch richtig. Wenn ich diesen Wert um 8:45 anzeigen würde, wäre das meines Erachtens falsch

Nun ja, einerseits richtig aber andererseits ist das Diagramm so wie es nun ist auch "unschön" zu lesen wenn man mehrere Werte aus einem RRD mit verschiedenen Auflösungen darstellt.

Hier mal ein schönes, anschauliches Beispiel:

die roten Werte haben eine Resolution von 900 (15min) die grünen eine von 3600 (1 Stunde).

die ersten roten Werte (Wh für 15min) sind:
48 (9:00Uhr) , 176 (9:15h), 83, 56, 59 (10:00h)
der erste grüne Wert für 10:00 Uhr liefert als Ergebnis für die Stunde von 9 bis 10 Uhr 374Wh für eine Stunde (Achtung hier ist ein Scalefaktor von 4 mit drin um die Absolutwerte für eine Stunde zu bekommen, ohne Scalefaktor würde als Mittelwert hier 93,5Wh rauskommen). Dies bedeutet es wurden die Werte 176, 83, 56 und 59 (sprich die Werte von 9:15 bis einschliesslich 10 Uhr) aus dem roten RRD verwendet.

Grafisch interpretiert man nun aber daß dieser Wert (da er von 10 Uhr bis 11 Uhr als konstant mit 374Wh dargestellt wird) von 10 bis 11 Uhr galt. Es wäre deshalb (optisch) schöner wenn der grüne Wert von 374h von 9 bis 10 Uhr angezeigt würde.

Um dies zu erreichen müsste man nun die gemessenen Werte alle um ihre Resolution Zeit in die Vergangenheit setzen, sprich die Werte auf der x-Achse um die Resolution Zeit zurückrechnen.

Damit wäre dann im Beispiel ab 9 Uhr bis 10 Uhr folgende Werte dargestellt:
rot: 176, 83, 56 und 59
grün: 374
und es würden die Werte die jeweils "zusammengehören" auch im Diagramm direkt zusammenpassen.

Hoffe so wird es klarer was ich und wahrscheinlich auch JuMi meine.

[JuMi2006]

Das liegt auch an den unterschiedlichen Grafik Engines. Vergleicht das mal mit den Diagrammen aus dem Webmin vom WireGate.
Ich meine mich da an eine unterschiedliche Darstellung zu erinnern. Im Webmin steckt drraw dahinter, das kann man auch auf jedem anderen Webserver installieren und ist recht mächtig. Ich kann das mangels Hardware nicht rekonstruieren aber das Thema hatten wir schonmal. Ich meine im Zusammenhang mit der Einführung der gefüllten Plots.
Meine persönliche Meinung: Keine Darstellung ist besser als falsche Darstellung.

[MicHau]

Hoffe so wird es klarer was ich und wahrscheinlich auch JuMi meine.

OK, verstanden.

Leider wüsste ich jetzt keine andere Möglichkeit, als manuell den Timestamp sämtlicher zurückgelieferten Datenpunkte um einen bestimmten Wert (den ich frei definierbar in der Config angeben würde) zu korrigieren.

Ich denke, dass das ohne größeren Programmieraufwand machbar wäre. Allerdings habe ich einige Befürchtungen bezüglich der Performance. Aber wie immer geht Probieren über Studieren. Wem es zu langsam ist, der kann ja auf die Verwendung des Korrekturwertes verzichten.

Habt ihr einen anderen Vorschlag?