SVG Plots mit Spline Interpolation

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

Vorheriges Thema - Nächstes Thema

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.