SVG Plots mit Spline Interpolation

Begonnen von eki, 19 Januar 2015, 14:05:33

Vorheriges Thema - Nächstes Thema

eki

Hallo zusammen,

bei GNUPLOT gibt es ja die Möglichkeit Kurven zu glätten. Das funktioniert offensichtlich bei SVG Plots bisher nicht (zumindest habe ich im 98_SVG.pm nichts dergleichen gefunden).
Da ich aber einige Plots mit wenigen Messpunkten (Wetterdaten aus dem Internet) habe, die mir nicht sehr gefallen haben, habe ich einen Versuch gemacht, das 98_SVG.pm entsprechend zu ändern. Jetzt wird der Parameter "smooth csplines" aus den Plotfiles entsprechend berücksichtigt (bisher nicht ganz genau so wie bei GNUPLOT, sieht aber optisch für mich besser aus und die Kurven werden auch ganz ordentlich angenähert). Als Beispiel habe ich ein paar Plots mit und ohne das Smoothing angehängt.

Falls Interesse besteht, könnte ich das 98_SVG.pm bereitstellen. Zusätzlich braucht man noch eine Änderung an den entsprechenden *svg_style.css files (dort muss man zusätzlich zu "polygon.." auch noch die entsprechenden Einstellungen für "path.." einfügen).

Gruss
Kurt Eckert

rudolfkoenig


eki

Bitteschön.

Da ich Perl und auch SVG Novize bin, hoffe ich, dass ich nichts Grobes übersehen habe, wäre ganz gut, wenn ein Profi sich das noch mal anschaut :-/.

Die von mir genutzte Basisversion von 98_SVG.pm müsste OK sein (habe ich gestern noch einmal gecheckt, falls also seit gestern nichts an 98_SVG.pm geändert wurde sollte nichts verloren gehen).

Gruss
Kurt

rudolfkoenig

Ich habe zwar auch viele kleine Probleme mit dem "Patch" wie DOS Format, Tabs, %f statt %d, mAn unnoetig geaenderte Zeilen, keine Plot-Editor-Unterstuetzung, keine Doku.

Das grosse Problem ist aber, dass es nicht moeglich ist, erst Linien ohne und dann welche mit spline zu definieren. Das gleiche Problem gibts zwar auch bei lw/ls/etc, allerdings ist das weniger gravierend.

Ich tendiere dazu, die .gnuplot-Kompatibilitaet hier zu brechen, das wuerde auch das Plot-Editor-Problem einfacher machen.

eki

Anmerkungen zu den kleinen Problemen:
%f geht leider nicht anders, da ich Zwischenwerte berechne und wenn ich die runde, kommt Käse bei den Plots heraus.
Zum Plot Editor und zur Doku könnte ich mich noch mal versuchen.
Die anderen Punkte liegen wahrscheinlich daran das das mein erster Versuch ist, sorry.

Das große Problem verstehe ich allerdings nicht so ganz. Soweit ich das sehe, kann man in einem Plot eine linear interpolierte Linie und eine Spline Linie mischen. Zwischen verschiedenen Plots geht das sowieso (zumindest hat das bei mir geklappt). Ich verwende sogar innerhalb einer Linie interpolierte und nichtinterpolierte Teile (z. B. bei den geschlossenen Linien werden die senkrechten Verbindungsstriche nicht interpoliert).

rudolfkoenig

Zitatwenn ich die runde, kommt Käse bei den Plots heraus.
Glaube ich nicht. Das SVG ist so skaliert, dass man fuer die Koordinaten ganze Zahlen verwenden kann, damit die uebertragenen Daten klein sind.

Das "grosse Problem" hat mit dem .gplot "Parser" in SVG_digestConf zu tun, der nicht in der Lage ist bei einem nicht gesetzten Parameter "undef" oder sowas ins Array ($conf{lSmooth}[$idx]) zu schreiben.

rudolfkoenig

ZitatDie anderen Punkte liegen wahrscheinlich daran das das mein erster Versuch ist, sorry.

Meine Bemerkungen waren weder boese gemeint, noch zum Abschrecken gedacht.
Aber wenn ich das nie sage...

oliverk


Egal wie, aber machen !!!  ::)  8)  ::)

Das trägt auf jeden Fall dazu bei, dass die Akzeptanz bei allen Betrachtern deutlich steigt. Auch wenn diese Kurven ja mathematisch nicht den wirklichen Verlauf darstellen.
Kurven sind immer besser als Ecken und Kanten. Sicherlich für jede Grafik, aber wenn es eine Option im Editor ist, dann wäre es für viele Graphen eine tolle Sache.

Oliver

Fhem: 5.7 auf RaspPi / Fhem: 5.7 auf Cubie
ca. 80 net4home Buskomponenten
zum Spielen diverse FS20, HomeMatic, EnOcean, hue Geräte, Fritz!Box 7490, Fritz!Dect 200, netatmo, eve

eki

Zitat von: rudolfkoenig am 19 Januar 2015, 16:16:00
Glaube ich nicht. Das SVG ist so skaliert, dass man fuer die Koordinaten ganze Zahlen verwenden kann, damit die uebertragenen Daten klein sind.
Möglicherweise hast Du teilweise recht, ich habe zuerst alles mit %d probiert, dabei kam Käse heraus. Danach habe ich allerdings alle outputs, die was mit "path" zu tun haben auf %f umgestellt. Das war wahrscheinlich zu viel. Was vermutlich auf %f bleiben muss ist die Zeile:
"$ret .=  sprintf(" %f,%f", ($lx+$x1)/2, ($ly+$y1)/2);"
der Rest kann möglicherweise auf %d geändert werden. Ich test mal und melde mich dann (morgen) wieder.

Zitat von: rudolfkoenig am 19 Januar 2015, 16:16:00
Das "grosse Problem" hat mit dem .gplot "Parser" in SVG_digestConf zu tun, der nicht in der Lage ist bei einem nicht gesetzten Parameter "undef" oder sowas ins Array ($conf{lSmooth}[$idx]) zu schreiben.
OK, jetzt hab ich's verstanden.

Zitat von: rudolfkoenig am 19 Januar 2015, 16:16:00
Meine Bemerkungen waren weder boese gemeint, noch zum Abschrecken gedacht.
Aber wenn ich das nie sage...
Ich hab's auch nicht böse aufgefasst und abschrecken lasse ich mich auch nicht, dazu ist FHEM viel zu spannend.

rudolfkoenig

- lines von <polyline> auf <path> umgestellt. Hat auch eine Anpassung von svg.js nachgezogen, wg. "Display plot values".

- mit <path> waren die weiteren Typen cubic, cubicSmooth, quadratic, quadraticSmooth einzufuehren trivial, diese entsprechen den SVG <path> Optionen C, S, Q und T. Das ist zwar nicht .gnuplot compatibel, dafuer waren die Aenderungen fuer den PlotEditor und fuer die Darstellung minimal. quadraticSmooth ist sehr "haarig", wenn jemand es "kaemmen" kann/will, bitte erst mit fhem.cfg.demo testen, und dann hier melden.

- meine 5 verlorengegangenen Linientypen (l0_dot,l1_dot,l0fill_stripe,l1fill_stripe,l0fill_gyr) restauriert. Das ist in svg_style.css definiert, fuer dark muesste es nachgezogen werden

eki

ich habe mir Deine Version mal angeschaut und getestet, hier meine Anmerkungen

Leider fürchte ich, dass das nicht so einfach geht wie Du es jetzt eingebaut hast. Die Interpolationsmethoden bei "path" scheinen leider unterschiedlich zu arbeiten. Grundsätzlich braucht man immer Datenpunkte und Stützwerte, die festlegen wie die Kurve durch die Datenwerte geplottet wird. Bei quadraticSmooth, also der Option "T" werden einfach immer die vorherigen und nächsten Punkte in der Reihe als Stützwerte genommen. Wenn man das jetzt einfach genauso macht wie bei der Linie, kommen recht eigenartige Ergebnisse heraus. Daher habe ich in meinem Vorschlag als Datenpunkte nicht die egentlichen Input Datenpunkte verwendet,  sondern immer die Mittelwerte zwischen zwei Datenpunkten (daher die Zeile mit ($lx+$x1)/2 und %f). Dadurch läuft die Kurve dann zwar nicht mehr genau durch die Datenpunkte, aber sie nähert sich ganz gut einem Verlauf an, wie ich ihn erwarten würde. Wenn man will, dass man die Datenpunkte trifft, muss man die Stützpunkte komplizierter berechnen, dann muss man nämlich darauf achten, dass die Steigungen im Vergleich zum vorherigen Punkt passen (die Mathematik dazu müsste ich mir aber auch noch mal anschauen).
Für die anderen Interpolationsmethoden muss man z.T. die Stützwerte zusätzlich zu den Datenpunkten angeben, hier wird wohl nicht einfach der vorherige und nächste Punkt verwendet. In diesem Fall kommen also zusätzliche Werte in die Liste, die man auch entsprechend ausrechnen muss.

Alles mit path zu machen (auch die Linien) macht den Code natürlich einfacher und macht Sinn, habe ich mich nur nicht von vorne herein getraut.

Wenn Du willst, kann ich das noch einmal genauer anschauen, und einen auf Deiner Version basierenden Vorschlag machen (ohne Tabs und mit Unix LF ;-). Wir werden aber um getrennte Behandlung der verschiedenen Interpolationsfälle nicht herum kommen fürchte ich.

rudolfkoenig

Einverstanden. Du darfst die haarige Linie gerne kaemmen :)

eki

So, ich habe mich gestern abend noch einmal mit dem Thema beschäftigt. Die 4 Varianten, die in "path" möglich sind ("C" "S" "Q" "T"), sind mathematisch immer Bezier Kurven. Die ersten beiden und die letzten beiden sind jeweils nur Varianten der gleichen grundsätzlichen Methode (bei den ersten beiden zwei Kontrollpunkte pro Segment, bei den zweiten beiden ein Kontrollpunkt pro Segment) siehe auch https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths.
Der Trick ist eine sinnvolle Festlegung der Kontrollpunkte. Dazu habe ich einen Algorithmus gefunden (https://www.particleincell.com/2012/bezier-splines/), der ganz ordentlich zu funktionieren scheint. Allerdings ist dazu ein bisschen Rumrechnerei notwendig, macht die Plots eventuell etwas langsamer. Unten Beispiele, wie die Kurven dann aussehen würden.
Eine zusätzliche Möglichkeit wäre das, was ich, wie vorher beschrieben, zuerst gemacht hatte (also als Punkte nicht die Datenpunkte sondern die Mitte dazwischen zu nehmen und die "T" Variante). Dann wäre kein großer Rechenaufwand notwendig. Auch hier ein Beispiel Bild unten.

Bitte gebt mir mal kurz Bescheid was Ihr denkt, dann kann ich mich ans Implementieren in Perl machen (bisher habe ich nur mit JS herumprobiert, weil das für mich einfacher und schneller ist).

Das Thema %f ist übrigens kein Problem, wenn man die gerechneten Werte zum Schluss kaufmännisch auf Ganzzahlen rundet.

Gruss
Kurt

rudolfkoenig

Ich wuerde die aufwendige Berechnung nur bei den Splines anwenden, wer Spline waehlt, der hat entweder nur wenige Punkte, oder muss die erhoehte Rechenzeit in Kauf nehmen.

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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.

Zitatist 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
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Fritzi

#16
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
FHEM 5.6 auf RaspberryPi2 mit Busware CUL culfw V1.61
CUL_HM     : HM-CC-RT-DN,HM-LC-SW1-FM,HM-LC-Sw1PBU-FM,HM-SEC-SC,HM-Sen-MDIR-O-2,HM-TC-IT-WM-W-EU
FBDECT      : Dect200
HUEDevice  : LCT001,LCT003

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

#18
@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.
FHEM 5.6 auf RaspberryPi2 mit Busware CUL culfw V1.61
CUL_HM     : HM-CC-RT-DN,HM-LC-SW1-FM,HM-LC-Sw1PBU-FM,HM-SEC-SC,HM-Sen-MDIR-O-2,HM-TC-IT-WM-W-EU
FBDECT      : Dect200
HUEDevice  : LCT001,LCT003

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?
FHEM 5.6 auf RaspberryPi2 mit Busware CUL culfw V1.61
CUL_HM     : HM-CC-RT-DN,HM-LC-SW1-FM,HM-LC-Sw1PBU-FM,HM-SEC-SC,HM-Sen-MDIR-O-2,HM-TC-IT-WM-W-EU
FBDECT      : Dect200
HUEDevice  : LCT001,LCT003

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...
FHEM 5.6 auf RaspberryPi2 mit Busware CUL culfw V1.61
CUL_HM     : HM-CC-RT-DN,HM-LC-SW1-FM,HM-LC-Sw1PBU-FM,HM-SEC-SC,HM-Sen-MDIR-O-2,HM-TC-IT-WM-W-EU
FBDECT      : Dect200
HUEDevice  : LCT001,LCT003

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

#26
anbei zwei logProxy beispiele für die demo:

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

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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):

#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.

frank

danke für dieses grossartige feature. macht sehr schöne plots.  :)

kleines manko: das über- und unterschwingen aus dem automatisch generierten plotbereich. aber lieber so, als dass der plotbereich bei minus-X prozent begint.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Mr.Heat

Das ist leider aber täglich im Plot, womit quasi alle Kurven sch** aussehen...jedes mal, wenn kurz aufeinander mehrere Punkte zu finden sind.

Ich meine, eine Interpolation wie diese Splines bei der mehrere Werte für einen Zeitpunkt entstehen können, ist nicht gerade gut geeignet.
Gibt es da denn keine Alternative? So ist das zur Glättung der Temperatur nicht wirklich schön.

eki

Das Verhalten wundert mich bei Deinen Punkten. Das sieht mir eher danach aus, dass Du noch die 98_SVG.pm von vorher hast, dort kam es zu solchen Effekten. Bitte mal prüfen wann Du das letzte Update gemacht hast. Falls es tatsächlich die Version von heute Morgen ist, könntest Du Dein Datenfile und plotfdef posten?

Mr.Heat

#33
Hallo,

ja, fhem ist up-to-date. "update" bringt "nothing to do...". Heute morgen wurde die 98_SVG.pm aktualisiert. Ich benutze logproxy.
Das Wochenprofil evtl. entfernen aus dem gplot, da das nicht aus dem log übernommen wird....


in der FHEM.cfg:

define AAAAMA_weblink SVG lp:max_temp_MA:CURRENT
attr AAAAMA_weblink label "$data{currval3}°C ($data{currval1}°C), Max $data{max3}°C, Min $data{min3}°C"
attr AAAAMA_weblink plotsize 700,200


gplot und log im Anhang.


LG

frank

ich nutze auch logproxy und filelog gemischt in einem svg. keine probleme. allerdings ist logproxy dabei nicht in der definition des svg enthalten, sondern ein x-beliebiges filelog. daraus nutze ich nicht mal daten.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

eki

ich hatte mir ja schon gedacht, dass das, so wie es jetzt ist, im Zusammenhang mit logProxy (also den von mir erwähnten "specials" im Code) Probleme machen könnte. Z.B werden die Pfade ja im Fall von logProxy unter Umständen in mehrere Pfade aufgeteilt (siehe # new line segment after newline im Code). Spätestens da geht mein bisheriger Ansatz schief, soweit ich das jetzt überblicke.

Ich habe aber eine Idee, wie man das Lösen kann. wird aber sicher ein bisschen dauern.

eki

Ich habe jetzt eine neue Version von 98_SVG.pm angehängt.

Das Vorgehen müsste jetzt, soweit ich sehe, auch für logProxy und für die ausgelassenen Werte mit gleichem x-Werte beim Jahresplot passen.
Außerdem habe ich die Option quadraticSmooth eingefügt. Dort wird jetzt die Variante mit den Zwischenwerten verwendet, die nicht durch die Messpunte geht, aber dafür keine Überschwinger etc. produziert.

Bei mir sehen die Plots gut aus, allerdings habe ich das mit dem logProxy aus den Daten von Mr.Heat nicht hinbekommen. Da kommt bei mir immer:
2015.01.23 09:20:55 3: AAAAMA_weblink: space is not allowed in logProxy definition:... (obwohl in der Plot Definition ganz sicher keine spaces sind). Der Plot bleibt bis auf eine gerade Linie auf der x-Achse leer.

Also bitte mal bei jemandem testen, der eine funktionsfähige logProxy Umgebung hat.

Mr.Heat

#37
Hallo,

vielen Dank für deine Mühe. Leider hat es nichts gebracht, weder die Version von heute morgen aus dem Update, noch deine Angehängte:

im Anhang wieder das selbe von heute.


EDIT: @eki: hast du denn ein Logproxy-Device angelegt? Mit
define lp logProxy
?

LG

frank

die neue option quadraticsmooth sieht sehr gut aus. kein über- und unterschwingen mehr. das angehängte beispiel wird über eine logproxy-func erzeugt. ein kleiner schönheitsfehler ist die behandlung am ende des plots. wahrscheinlich 0 statt 87.5. hier mal die letzten 3 punkte des plots.

2015-01-29_18:00:00 100
2015-01-29_21:00:00 87.5
2015-01-29_23:59:59 87.5


@mr.heat
hast du mal versucht die definition des svg ohne das logproxy-device zu machen?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Mr.Heat

Hallo,

mit Filelog sieht es nicht so extrem aus, mehr wie gestern (siehe Anhang weiter oben). Bei schnellen Temperaturwechseln gibt es diese Rückschwünge der Kurve immernoch. Könnte aber sein, dass das an der nun unterschiedlichen Datenbasis liegt (logProxy macht ja z.B. Werte ans Ende, damit der Plot weitergeht).
Das ist wirklich schade, ich würde das so gerne benutzen....

LG MS

justme1968

auch mit der angehängten version geht das spinnennetz diagramm nicht.

in der js console sehe ich das hier:[Error] Error: Problem parsing d=" 170,117 199,139 187,176 152,176 140,139 170,117" (SVG_showLog, line 99)
[Error] Error: Problem parsing d=" 170,84 170,84 170,84 228,129 205,202 134,202 111,129 170,84" (SVG_showLog, line 101)
[Error] Error: Problem parsing d=" 170,51 170,51 170,51 257,119 223,229 116,229 82,119 170,51" (SVG_showLog, line 102)
[Error] Error: Problem parsing d=" 170,51 170,150 170,150 257,119" (SVG_showLog, line 104)
[Error] Error: Problem parsing d=" 170,150 223,229" (SVG_showLog, line 105)
[Error] Error: Problem parsing d=" 170,150 116,229" (SVG_showLog, line 106)
[Error] Error: Problem parsing d=" 170,150 82,119" (SVG_showLog, line 107)
[Error] Error: Problem parsing d=" 170,104 216,133 211,210 126,213 109,128 170,104" (SVG_showLog, line 108)
[Error] Error: Problem parsing d=" 170,114 213,134 207,205 144,187 123,133 170,114" (SVG_showLog, line 115)


wenn ich im quelltext das d= durch ein points= ersetze sind zwar die warnung weg aber die linien sind immer noch nicht zu sehen. in der version gestern hatte ich dann eine endlosschleife. die ist heute weg.

mir ist noch nicht ganz klar warum die interpolationsgeschichten auch dann einen einfluss haben wenn das feature gar nicht aktivert ist.

mein beispiel oben sollte direkt per copy&paste funktionieren.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

#41
edit: wenn ich die svg js files auch aktualisiere geht auch der sonnenauf- und -untergangs plot nicht mehr.

unten noch mal screenshots wie es aktuell ausschaut und wie es eigentlich sein sollte.

gruss
  andre

und noch mal. edit: der schwarze sonnen plot lag an einem fehlenden iconPath. wenn ich den setzte schaut er wieder korrekt aus.

nur das spinnennetzdiagramm geht noch nicht.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Mr.Heat

Auch mit quadraticSmooth sind die Ergebnisse nicht so toll, wenn auch etwas besser.

liegt das vielleicht an der ungleichmäßigen Datenbasis? Da die MAX-Thermostaten die Temperatur nur Sporadisch melden, kann es sein, dass über Stunden kein Wert übermittelt wird, und dann plötzlich (weil Ventiländerungen) alle paar Sekunden. Ließe sich denn nicht eine Interpolationsmöglichkeit finden, die das besser macht?

LG

frank

@mr.heat

mit den temperaturdaten aus deinem logfile sieht das bei mir so aus (quadraticsmooth)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

eki

@Mr. Heat: kannst Du mir Dein ohne logProxy angepasstes glot file schicken, Deine Daten habe ich ja noch von gestern, dann kann ich mal schauen.

@andre: Dass das auch Auswirkungen darauf hat, wenn gar keine Glättung eingeschaltet ist, liegt daran, dass die Umstellung generell von "polyline" auf "path" gemacht wurde. Es werden also SVG "paths" benutzt anstatt des "polyline" typs. Dass Deine Sonnenaufgang und Untergangs Bilder nicht mehr gehen, liegt wahrscheinlich daran dass Du nicht alle css files angepasst hast. In allen *svg_style.css files (oder zumindest in denen deren Stil Du nutzt) muss ein zusätzlicher Eintrag für path erfolgen. Sollte also so:

path { stroke:black; fill:none; }
.border  { strikte:black; fill:url(#gr_bg); }
.vgrid   { stroke:gray;  stroke-dasharray:2,6; }
.hgrid   { stroke:gray;  stroke-dasharray:2,6; }
.pasted  { stroke:black; stroke-dasharray:1,1; }

polyline { stroke:black; fill:none; }
.border { stroke:black; fill:url(#gr_bg);}
.vgrid { stroke:gray; stroke-dasharray:2,6;}
.hgrid { stroke:gray; stroke-dasharray:2,6;}
.pasted { stroke:black; stroke-dasharray:1,1;}


oder so ähnlich aussehen. Die Seiteneffekte müssen aber natürlich noch repariert werden ;-).

justme1968

hatte es inzwischen oben editiert. das problem mit dem sonnen plot war ein fehlender iconPath.

momentan macht nur das spinnennetz diagramm noch probleme.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Mr.Heat

#46
@eki: gplot im Anhang.

Definition:
Zitat
define AAAAMA_weblink SVG FileLog_MA_Thermostat_Fenster:max_temp_MATEST:CURRENT
attr AAAAMA_weblink label "$data{currval3}°C ($data{currval1}°C), Max $data{max3}°C, Min $data{min3}°C"
attr AAAAMA_weblink plotsize 700,200

frank

Zitat von: Mr.Heat am 23 Januar 2015, 11:50:47
Hallo,

mit Filelog sieht es nicht so extrem aus, mehr wie gestern (siehe Anhang weiter oben). Bei schnellen Temperaturwechseln gibt es diese Rückschwünge der Kurve immernoch. Könnte aber sein, dass das an der nun unterschiedlichen Datenbasis liegt (logProxy macht ja z.B. Werte ans Ende, damit der Plot weitergeht).
Das ist wirklich schade, ich würde das so gerne benutzen....

LG MS

ich nutze trotzdem logproxy, obwohl in der definition filelog angegeben ist. im ploteditor gibt es ja ein neues selectfeld, in dem du logproxy als source wählen kannst. mein beispiel mit deinen daten nutzt genau deine gplot defintionen, nur die definition von svg ist anders. "lp" ist mein logproxy device. hier noch das gplot zu dem plot:

# Created by FHEM/98_SVG.pm, 2015-01-23 12:14:20
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid y2tics
set ylabel "Humidity"
set y2label "Temperature"

#FileLog_myProPlant 4:MA_Thermostat_Fenster.temperature\x3a::
#lp FileLog:FileLog_myProPlant,predict,extend=60*60*24:4:MA_Thermostat_Fenster.temperature\x3a:0:

plot "<IN>" using 1:2 axes x1y2 title 'test Tist' ls l1 lw 1 with points,\
     "<IN>" using 1:2 axes x1y2 title 'test2' ls l0 lw 2 with quadraticSmooth
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Mr.Heat

Mit dem Ploteditor stehe ich auf Kriegsfuß, weil der nie das macht was ich will :D ich erzeuge deshalb die gplots immer manuell.

Ich bin mir nicht sicher, dass mir das irgendwie helfen würde... Auch mit FileLog alleine ist die Darstellung nicht gut. Auch bin ich mir nicht sicher, ob das Zufall ist dass das geht, oder ob das so gewollt ist? Konnte aus der Commandref zu lp so nicht rauslesen, dass man das SVG ohne Logproxy definieren dürfte...ist natürlich nett, man hätte sich die Änderung in der fhem.conf sparen können :)

LG

frank

ZitatKonnte aus der Commandref zu lp so nicht rauslesen, dass man das SVG ohne Logproxy definieren dürfte...ist natürlich nett, man hätte sich die Änderung in der fhem.conf sparen können
es gab ja auch änderungen an svg. dort können jetzt unterschiedliche datenquellen gemischt werden. logproxy, unterschiedliche filelog, dblog und sogar fhem logfile. danach ist die definition der datenquelle in der svg definition von der logik gesehen eigentlich überflüssig.

ZitatIch bin mir nicht sicher, dass mir das irgendwie helfen würde... Auch mit FileLog alleine ist die Darstellung nicht gut.
warum bekomme ich mit deinen daten und gplot-konfigs andere plots? hast du schon mal "update force" gemacht. du kannst doch auch weiterhin deine gplots manuell erstellen. das kann ja nicht der grund sein.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

define AAAAMA_weblink SVG lp:max_temp_MA:CURRENT
dein logproxymodul hat hiernach den namen lp, wie bei mir.

dann musst du in deiner gplot auch folgendes eintragen:
#lp FileLog:FileLog_MA_Thermostat_Fenster,predict,extend=60*60*24:4:MA_Thermostat_Fenster.temperature\x3a:0:

du schreibst aber den namen des moduls in dein gplot:
#logProxy FileLog:FileLog_MA_Thermostat_Fenster,predict,extend=60*60*24:4:MA_Thermostat_Fenster.temperature\x3a:0:

also ersetze "logProxy" durch "lp". dann sollte es funktionieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Mr.Heat

#51
Das steht aber in http://www.fhemwiki.de/wiki/LogProxy ganz eindeutig anders.

Trotzdem werde ich es probieren...

EDIT: ändert nichts, funktioniert aber auch.

@frank: sehr komisch, dass die bei dir anders aussehen? Kannst du mir mal mit meinen Daten und gplot nen Screenshot anhängen? ich werde mal ein update force machen und dann berichten.

eki

Hallo,

@Mr. Heat: Ich habe jetzt mal ein bisschen mit Deinen Daten rumprobiert. Leider scheint das Verhalten ein Problem des Algorithmus zu sein. Wenn die Abstände zwischen den Punkten sehr unterschiedlich sind, dann kommt es bei den Bezier Kurven offensichtlich zu diesem Effekt. Bei dem quadraticSmooth Algorithmus ist das nicht ganz so schlimm.

Beseitigen könnte man das nur, in dem man die Reihenfolge irgendwie gleichmäßiger macht, oder indem man einen anderen Algorithmus findet (z.B. immer nur Abschnitte für die Berechnung der Kontrollpunkte verwendet, dann können aber andere Effekte auftreten z.B. Eckige Übergänge). An den Punkten selber sollte man meiner Ansicht nach im Plot nichts herumpfuschen sondern die Datenbasis irgendwie anpassen.

Tut mir leid, da weiß ich im Moment auch keine wirklich gute Lösung.

Mr.Heat

Habe mit dem Programm GNUplot direkt rumgespielt, ob das wirklich nicht gehen kann.
Ergebnis im Anhang: mit Befehl
plot 'data.txt' using 1:4 axes x1y1 lw 3 with points, 'data.txt' using 1:4 axes x1y1 smooth csplines lw 3 with lines

Es handelt sich um die Ist-Temperatur-Daten von heute wie aus den letzten Diagrammen. So will ich da eigentlich auch in FHEM haben.... :(

rudolfkoenig

Mit gnuplot herumzuspielen hilft nur dann, wenn man im FHEM statt SVG gnuplot verwendet (geht ja). Die mit diesem Patch im SVG verwendeten Kurven werden direkt vom SVG angeboten, und es waere sehr ineffizient, gnuplot Splines in FHEM/SVG nachimplementieren zu wollen.

Wer mit Splines schon herumgespielt hat weiss, dass es unmoeglich ist Splines zu finden, die fuer alle Stuetzpunkten-Kombinationen gut ausschauen, gnuplot optimiert wohl fuer andere Zwecke als SVG.

eki

Ich habe ja nicht gesagt, dass es grundsätzlich nicht geht. Es geht nur mit dem Ansatz den wir hier verwenden Grundsätzlich nicht.

Nur zur Erklärung:
- Ich verwende eine Glättungsfunktion die direkt in SVG beinhaltet ist, und die kann nur Bezier Kurven (quadratisch, also mit einem Kontrollpunkt, oder kubisch also mit 2 Kontrollpunkte).
- Wie der genaue Kurvenverlauf ist, hängt von den Kontrollpunten ab. Je nachdem wie die Kontrollpunkte liegen, verzieht es die Kurve (in den beiden Links von mir am Anfang des Threads kann man da Details nachschauen).
- Man kann die Kontrollpunkte automatisch berechnen lassen, wie ich das in dem Patch tue (ist letzendlich Lösung eines linearen Gleichungssystems)
- Einen anderen Algorithmus für die Berechnung der Kontrollpunkte kenne ich leider nicht (vielleicht habe ich irgendwann mal Lust weiter zu suchen, jetzt geht das aber zeitlich nicht)
- Gnuplot verwendet mehr verschiedene Kurven (z.B. Splines) die z.T. rechenaufwändiger sind.

eki

Mit der angehängten Version funktioniert jetzt auch das Spinnennetz (zumindest bei mir gings, bitte prüfen). Außerdem wird der letzte Punkt jetzt richtig gesetzt.

Mr.Heat

#57
Zitat von: rudolfkoenig am 23 Januar 2015, 15:04:37
Wer mit Splines schon herumgespielt hat weiss, dass es unmoeglich ist Splines zu finden, die fuer alle Stuetzpunkten-Kombinationen gut ausschauen, gnuplot optimiert wohl fuer andere Zwecke als SVG.
Das mag ja sein, aber jede Lösung die für einen Zeitpunkt mehrere Werte rechnet muss ja offensichtlich falsch sein. Eventuell wird das in gnuplot verhindert, wenn die x-Achse auf time eingestellt ist? Man sollte mal die smooth csplines in den sourcen von gplot anschauen... bin nur nicht daheim :)

Sind das keinr Funktionen, den der Algorithmus ausspuckt? Eie kann es dann solche komischn Schwünge in x-Richtung überhaupt geben?

justme1968

mit dieser version sind meine plots wieder schwarz. kann es sein das die nicht auf der aktuellen svn version basiert sondern einer älteren?

ich glaube rudi hatte noch mal was bezüglich der styles repariert.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

eki

Ich habe jetzt die letzten Änderungen von Rudi eingefügt. Ist also jetzt identische mit der Version im SVN plus meine Änderungen von heute.

justme1968

schaut gut aus.

auch die achsen gehen wieder.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Mr.Heat

Hallo,

ich weiß nicht, was ich sonst helfen kann, um eine bessere Glättung zu bekommen, deshalb bin ich mal so frei und hänge den (garnicht so großen) Sourcecodeteil an, in dem gnuplot (erfolgreich) csplines aus meinen Daten rechnet; es ist von https://github.com/gnuplot/gnuplot/blob/master/src/contour.c#L1041.

Wenn jemand in diesem Thema drin ist, kann er vielleicht ohne größeren Aufwand da rauslesen, was dort anders gemacht wird? Wenn es nicht hilft, muss ich mich halt damit abfinden, eckige Kurven zu haben und auf die hübsche Glättung zu verzichten =)

LG

eki

Einen Algorithmus zu finden, der uns so etwas wie in Deinem Bild berechnet, sollte nicht so schwer sein. Das hilft hier aber leider nichts.
Wenn wir das Gnuplot mäßig machen würden, dann müssten wir auf dem Server relativ viele nahe beieinander liegende Punkte rechnen, die einen schönen weichen Verlauf der Kurve ergäben. Clientseitig würden dann nur Linien geplottet (mit dem Nachteil, dass Serverseitig viel gerechnet werden muss und jede Menge Daten zu übertragen wären).
Mein Ansatz war daher, wir nutzen die in SVG enthaltene Interpolationsmethode (nutzt leider keine Splines sonder Bezier Kurven). Der Vorteil ist, wir müssen auf dem Server nur für die eigentlichen Messpunkte auf schlaue Weise die Kontrollpunkte rechnen und auch nur die übertragen. Den Rest macht dann der Client im Browser.
Die Methode von Gnuplot irgendwie zu analysieren bringt also nicht viel, das das mathematisch wenig mit meinem Ansatz zu tun hat.
Offensichtlich ist die von mir gefundene und implementierte Methode bei nicht gleichmäßiger Verteilung der Punkte auf der x-Achse nicht so richtig schlau. Ich mache mir noch einmal ein paar Gedanken, das kann aber schon ein wenig dauern. Falls mir noch was schlaueres einfällt, melde ich mich.

rudolfkoenig

Ich habe die logproxy Demos von andre ins fhem.cfg.demo mit kleinen aenderungen uebernommen, und nach laengerem nachdenken und experimentieren das cubic/quadratic an einen fiktiven "predicted" Linie in dem vorhandenen Plot demonstriert.

Dabei ist mir aufgefallen, dass bei quadraticSmooth:
- die Linie am Schluss immer zu Null gebogen wird
- bei Daten mit vielen Punkten es genauso "haarig" ist, wie ohne eine spezielle Behandlung, siehe screenshot. Lohnt sich diese spezielle Behandlung trotzdem?

Ich habe die letzte Version der SVG eingecheckt, aber
- den letzten split im SVG_render (was mAn zu teuer ist) durch ein regexp ersetzt
- falls die Quelle nur ein Datenpunkt sendet, die Ausgabe geloescht, sonst kriegt man eine Fehlermeldung.

eki

#64
Das mit dem letzten Punkt bei quadraticSmooth war noch ein Fehler.
In Zeile 1907 muss stehen:
      $ret .= sprintf(" %d,%d", $x1, $y1) if(($lt eq "T") && defined($x1));
      anstatt
      $ret .= sprintf(" %d,%d", $x1, $y+$h) if(($lt eq "T") && defined($x1));

Was meinst Du mit "spezielle Behandlung"?.

Kannst Du mir die Daten zu Deinem Bild posten?

rudolfkoenig

ZitatWas meinst Du mit "spezielle Behandlung"?.
Na SVG_calcControlPoints() & co.

ZitatKannst Du mir die Daten zu Deinem Bild posten?
Ist Teil der fhem.cfg.demo, siehe auch
Zitatsvn co https://svn.code.sf.net/p/fhem/code/trunk/fhem

eki

Ich denke die spezielle Behandlung lohnt sich trotzdem, sonst ist es ja auch bei wenigen Punkten "haarig". Außerdem wird das SVG_calcControlPoints() bei quadraticSmooth ja gar nicht genutzt.

Eventuell könnte das Problem bei vielen Punkte und quadraticSmooth an der Rundung liegen. Wenn man die sprintf statements mit %.1f statt mit %d und ohne die int(...+0.5) Rundung verwendet sehen Plots mit vielen Punkte bei mir auf jeden fall besser aus.
Source ist angehängt

rudolfkoenig

Habe deine Aenderungen eingecheckt, aber das demo Plot bleibt haarig. Selbst nachdem ich bei der $x1/$y1 Berechnung das int entferne, und statt %0.1f das %f mit 6 Nachkommastellen verwende.

Ich wuerde es dabei belassen, man sieht ja sofort, dass es haarig wird, wird also keiner "betrogen".

eki

OK.
Mehr als %.1f macht keinen Sinn, da ja nur ein int durch zwei geteilt wird, und da kann es ja höchstens ein .5 nach dem Koma geben.

Hat Spaß gemacht, auch mal sebst in die Tiefen von fhem abzutauchen.

eki

Es hat mich doch nicht so ganz in Ruhe gelassen, dass die Plots in einigen Fällen "haarig" aussahen. Nach einiger Suche habe ich einen alternativen Ansatz gefunden, um die Kontrollpunkte zu berechnen. Ergibt zumindest bei mir mit "cubic" auch bei "anspruchsvoller Datenbasis" (z.B. aus dem fhem.cfg.demo) sehr gute Ergebnisse ("quadratic" funktioniert zwar auch besser, ist aber immer noch nicht optimal, "quadraticSmooth" habe ich erst mal so gelassen wie es war).
98_SVG.pm ist angehängt (Basis war die Version 7819 von heute Morgen).

rudolfkoenig


nccfast

Hallo eki,
ganz was anderes:
Wie nhast du deine Wettervorhersage von Seite 1 eingebaut?
Hast du evtl das cfg davon ...

willybauss

Hi,

ich bin mir nicht sicher, ob ich hier richtig bin ==> bitte nicht hauen  ;) ...

Ich habe grade festgestellt, dass die im SVG angezeigten Werte meiner Innentemperatur ('Display Plot Values' Funktion) alle einen Offset von 0,1° haben bezogen auf die Daten im Logfile, also

Logfile = 21,4°C
'Display Plot Values'  zeigt 21,5°C

Das ist reproduzierbar über längere Zeiträume. Der  'Display Plot Values' Wert ändert sich über der Zeit genau so wie der Wert im Logfile, behält dabei immer den Offset von 0,1° bei.

==> Bug or Feature?
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

rudolfkoenig

Bug, aber eins was vermutlich nicht einfach zu aendern ist.
Das SVG-Perl Modul berechnet/rundet die Daten soweit, dass es auf dem Bildschirm noch richtig angezeigt wird, damit man nicht ueberfluessige Nachkommastellen ueber die Leitung reisen. Das JavaScript im Browser versucht aus den Daten die Werte zurueckzurechnen.

willybauss

ok, verstehe.

Das führt mich aber zu einer anderen Frage: Im Header der Plots lasse ich mir ein paar Werte anzeigen, z.B. mit

attr Mythz_Plot2_HC1Offset_Integral label "HC1Soll-HC1Ist $data{currval1}K, Integralwert $data{currval2}"

Gelegentlich werden da etliche Nachkommastellen angezeigt, also z.B. 3,000000001 K.
Kann ich da was ändern, z.B. eine Rundung auf 1 Nachkommastelle?
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

rudolfkoenig

attr Mythz_Plot2_HC1Offset_Integral label sprintf("HC1Soll-HC1Ist %0.1fK, Integralwert %0.1f", $data{currval1}, $data{currval2})