SVG Plots mit Spline Interpolation

[frank]

super feature, das hier entsteht. bei mir warten auch schon etliche kurven auf ein neues "design". 

da hier (fhem/svg) hauptsächlich daten in abhängigkeit der zeit geplottet werden, finde ich dein beispieldatensatz etwas unglücklich. die letzten 2 punkte scheinen den selben x-wert zu haben. wenn nicht den selben, dann doch zumindestens sehr nahe bei einander, im gegensatz zu den vorher liegenden. einer von beiden passt also nicht wirklich in diesen datensatz. bei diesem beispiel ist deine quadratcMid variante für mich die "realistischte" annäherung, da sie keine bereiche enthält, die der "zeit" vorauseilen.

mich würde interessieren, wie die kurven aussehen, wenn du den letzten punkt weiter nach rechts verschiebst. in der praxis handelt es sich wahrscheinlich häufiger um kurven mit ähnlichem x-abstand, oder vielfachem abstand, wenn daten verloren gegangen sind.

ist es nicht sinnvoll eine variante einzubauen die zumindest durch die tatsächlich vorhanden punkte geht? auch die interpolierte kurve sollte doch so viel wie möglich mit den tatsächlichen werten zu tun haben.

da könnte man ja fast eine philosophische diskussion beginnen. 

wenn es sich bei den datenpunkten zb um yahoo-wetterdaten für meinen standort handelt, sind die datenpunkte sicherlich auch nur interpoliert/berechnet, und haben mit den "tatsächlichen" temperaturen in meinem garten, an einer ganz bestimmten stelle, nicht wirklich etwas zu tun. also eher schätzwerte, die mal mehr und mal weniger mit der realität zu tun haben. da würde eine interpolation, die nicht durch die datenpunkte führt, insgesamt eventuell näher an der "wirklichkeit" liegen. wenn es sich sogar um wetter vorhersagewerte handelt, liegt die "realität" wahrscheinlich noch weiter entfernt.

auch bei "gemessenen" daten handelt es sich ja nicht wirklich um die "tatsächlichen" werte. messfehler, übertragungsfehler, systemfehler, bauteiltoleranzen, temperaturabhängigkeiten, fehler durch störquellen, ....

trotzdem würde ich es begrüssen, wenn man zb zwei varianten zu verfügung hätte. eine die durch die datenpunkte verläuft, und eine, die nicht zwangsläufig die datenpunkte enthalten muss. es gibt bestimmt unterschiedliche anwendungsfälle, wobei mal die eine oder die andere variante "bessere" ergebnisse erzielt.

gruss frank

[Fritzi]

Hab gerade mal wieder ein Update (ich sollte damit aufhören )angestossen und muss leider feststellen, dass es mir die Lines-Graphen zerschossen hat. Schaut mal hier...

Grüsse,
Fritzi

[rudolfkoenig]

@Fritzi:
Ich habe gerade saemtliche eingecheckte Styles geprueft -> bei mir funktioniert es.
Muss eine lokal modifizierte Version von ${styleprefix}svg_style.css sein.
Wurde heute schon mal gemeldet und erfolgreich diagnostiziert.

@frank:
du kannst davon ausgehen, dass gewoehnliche Linien durch die vorhandenen Punkte gehen werden.
Senkrechte Striche koennen sehr wohl zustandekommen, z.Bsp. falls man mit zoom ausreichend herumspielt.
Ich habe aber kein Problem damit, falls eine Kurve unter bestimmten Bedingungen nicht korrekt ist, keiner ist gezwungen, die Splines zu verwenden.

[Fritzi]

@rudi:

Mmmh... ich habe eigentlich keine lokalen style.css modifiziert.

P.S. die senkrechten Linien im oberen Graphen sind gewollt und signalisieren die Ereignisse, an denen das Licht angeschaltet wurde.

[Fritzi]

Hab gerade mal einen anderen Style probiert. Du hast zumindest Recht, was die Styles angeht. Der "Bright"-Style hat den Effekt jedenfalls nicht. Nur was tun, um dem iOS7-Style die richtige Darstellung beizubringen?

[Fritzi]

So, hab jetzt noch mehr Styles durchprobiert. Alle funktionieren, bis auf den ios7touchpad-style. Da kommt der o.g. Darstellungsfehler. Wie gesagt, nix modifiziert...

[eki]

Ich habe jetzt eine erste Version fertig (angehängt) (eher ein Zwischenstand bei dem ich aber doch mal bitten würde das bezüglich meines Ansatzes im Code zu prüfen). Zum Ergebnis siehe angehängten Beispielplot.

- Es gibt nur noch 2 Varianten cubic (mit "C" im "path") und quadratic (mit "Q" im path). Die Ergebnisse unterscheiden sich nicht sehr, die "Q" Variante hat etwas weichere Übergänge, macht manchmal aber auch Überschwinger. Die anderen beiden sind wie bereits gesagt aus meiner Sicht nur andere "Bedienung" der gleichen Mathematischen Variante. Die Variante, die die Messpunkte nicht trifft, fehlt zunächst, könnte aber relativ problemlos dazugefügt werden.

Außerdem habe ich einige Fragen zum Code bzw. offene Punkte:

- Es gibt sogenannte "specials" die nicht zum eigentlichen Graphen gehören, aber in den Zeilen des Inputs auftauchen. Außerdem werden, wenn sich am X Wert nichts ändert (keine Ahnung wann das passiert), Punkte übersprungen. Beide Fälle machen in dem von mir erstellten Zwischenstand wahrscheinlich Probleme. Um die Interpolation zu machen, muss mann für alle Punkte des Graphen die Kontrollpunkte berechnen, d.h. man muss den ganzen Graphen kennen, bevor man anfangen kann etwas ins SVG Bild zu schreiben. Im aktuellen Code gibt es aber kein array, das die Messpunkte enthält, sondern die Daten werden während des Durchlaufs in die SVG "paths" geschrieben. Vielleicht hat ja jemand einen Alternativvorschlag.

- Ich habe ganz schön mit array in subroutinen gekämpft, da ist perl ja nicht gerade "freundlich" mit den Programmierern, aber jetzt eine Variante gefunden (mit Referenzen), die klappt. Auch da bitte noch mal kritisch draufschauen.

Gruss
Kurt

[eki]

... sorry, falsche Datei, hier kommt die Richtige. Ich sollte, glaube ich, ins Bett gehen.

[rudolfkoenig]

Nach kurzen Tests mit den Daten in fhem.cfg.demo habe ich dein Patch unveraendert uebernommen (d.h. per update verfuegbar), auch weil er die bisherigen Linientypen mit grosser Wahrscheinlichkeit nicht beeinflusst.
Die Splines bringen mAn nur bei wenigen Stuetzpunkten schoenere Ergebnisse, bei vielen Punkten, insb. bei harten Kanten wie die Beispiele in fhem.cfg.demo sind sie mAn kontraproduktiv. Waerst du bereit dein Beispieldatensatz fuer fhem.cfg.demo bereitzustellen?

Zu den Fragen:
- die Specials kommen vom andre bzw. logProxy. logProxy kann den aktuellen Datensatz erweitern, kann aber auch weitere Texte oder "Stuetzlinien" hinzufuegen. Da im fhem.cfg.demo noch kein Beispiel dafuer gibt, kann ich nicht sagen, ob es Probleme verursacht.
- Die ueberspungene Punkte ist eine Optimierung fuer "Jahr-Zoom", um die uebertragene Datenmenge und die Client-Rechenzeit zu minimieren. Ich kann damit leben, diese Optimierung fuer Splines nicht durchzufuehren, da die Splines mAn nur bei wenigen Messpunkten sinnvoll sind.

[eki]

Eine Korrektur ist noch notwendig, sonst führt ein Datensatz mit weniger als zwei Werten zu einem fhem Absturz (den Fall hatte ich gestern Nacht als für den aktuellen Tag noch keine Wetterdaten da waren, kommt aber auch vor, wenn man ganz tief hinein zoomt).

Meine Testdaten kann ich natürlich bereitstellen (sind eh nur Wetterdaten von Yahoo). Was brauchst Du denn genau bezüglich fhem.cfg.demo?

[rudolfkoenig]

Habe die Aendrung eingecheckt.
Ich brauche Daten fuer 3 Tage, idealerweise fuer 11-13 August. Ich habe aber keine Skrupel, die Zeitstempel anzupassen.
Und gerne die .gplot-Datei dazu, sonst muss ich die Parameter raten.

[justme1968]

anbei zwei logProxy beispiele für die demo:

- ein plot der sonnenauf- und -untergangszeiten
- ein spinnennetzdiagramm von einer hand voll räumen

Code Auswählen Erweitern

define lp logProxy

define SVG_Sonne SVG lp:lp_sun:CURRENT
attr SVG_Sonne fixedrange year
attr SVG_Sonne room lp
attr SVG_Sonne title {"".logProxy_dec2hms($data{min1})." - ".logProxy_dec2hms($data{max1})." - ".logProxy_dec2hms($data{min2})." - ".logProxy_dec2hms($data{max2})}

define SVG_TempOverview SVG lp:lp_polar:CURRENT
attr SVG_TempOverview plotsize 340,300
attr SVG_TempOverview room lp

gruss
  andre

edit: das spinnennetzdiagramm geht mit der aktuellen SVG version nicht mehr alle linien fehlen.
        hier: http://forum.fhem.de/index.php/topic,29271.msg222157.html#msg222157 ist beschrieben was die specials genau machen und da ist auch ein screenshot wie es aussehen sollte.

[eki]

Hier die Daten und die gplot Dateien (ich nehme an, Du meinst August 2014).

Bezüglich des Spinnen-Netz Plots kann ich später noch mal schauen (geht nicht vom Büro aus).

[Mr.Heat]

Hallo,

bei cubic gibt es komische Effekte.... im Anhang mit "cubic" und "lines":

meine gplot (Ausschnitt):

Code Auswählen Erweitern


#logProxy FileLog:FileLog_MA_Thermostat_Fenster,predict,extend=60*60*24:4:MA_Thermostat_Fenster.desiredTemperature\x3a:0:$fld[3]=~"off"?0:$fld[3]
#logProxy Func:logProxy_WeekProfile2Plot("MA_Thermostat_Fenster",$from,$to)
#logProxy FileLog:FileLog_MA_Thermostat_Fenster,predict,extend=60*60*24:4:MA_Thermostat_Fenster.temperature\x3a:0:
#logProxy FileLog:FileLog_MA_Thermostat_Fenster,predict,extend=60*60*24:4:MA_Thermostat_Fenster.valveposition\x3a:0:

plot "<IN>" using 1:2 axes x1y2 title 'Soll' ls l2 lw 3 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'Wochenprofil' ls l2 lw 1 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'Ist' ls l1 lw 3 with cubic,\
     "<IN>" using 1:2 axes x1y1 title 'Ventil Fenster (%)' ls l3 lw 3 with steps


[rudolfkoenig]

Meiner Erfahrung nach kann sowas bei automatisch erzeugten Splines immer wieder passieren.