hallo rudi,
würdest du einen patch entgegen nehmen der es ermöglich eine nicht kontinuierliche (bzw. mehrere getrennte) linie(n) zu zeichnen?
meine idee wäre in den plot daten auch leerzeilen zu erlauben und dann jeweils ein neues polyline segment zu beginnen.
die anwendung dafür wäre keine durchgehende kurve mehr zu zeichnen wenn für eine bestimmte zeit keine sensor daten vorhanden sind. ein zweite anwendung wäre das komplette koordinaten system für etwas in dieser art: http://smartvisu.de/docu/2.7/index.php?page=plot/widget_plot.temprose (http://smartvisu.de/docu/2.7/index.php?page=plot/widget_plot.temprose) auf einen rutsch zu zeichen.
für letzteres würde ich am liebsten auch noch eine art 'plotanweisung' erlauben mit der es möglich wäre zwischen den reinen daten punkten auch format anweisungen für linienfarben und label unterzubringen.
für die gplotfiles würde ich gerne auch ein xrange erlauben um auf der x-achse etwas anderes als zeiten zu erlauben.
die syntax für die plotdaten die ich mir vorstellen könnte wäre etwa so:
2014-11-17_01:00:00 -10
2014-11-18_00:00:01 -10
2014-11-17_01:00:00 10
2014-11-18_00:00:01 10
#zwei Linien auf einmal
2014-11-17_01:00:00 -10
2014-11-18_00:00:01 -10
;color: red
2014-11-17_10:00:00 0
2014-11-17_20:00:01 0
;color blue
2014-11-17_30:00:00 10
2014-11-17_40:00:01 10
#eine linie mit drei unterschiedlich gefärbten segmenten
:2 4
:3 5
;label 5 5 leftalign "text"
:4 2
:4 8
:3 1
#explizite Angabe von x und y koordinate statt datum und wert und ein label "text" links ausgerichtet an (5,5)
gruss
andre
Label: von mir aus.
Farbe: bin dagegen, habe aber nix gegen style-wechsel.
Unterbrechung: wie soll das erkannt werden?
X-Achse: habe am meisten Probleme damit, wenn, dann als eine Funktion, die sich moeglichst frueh aus SVG_render verabschiedet. Ist de-facto dann ein zweites "Widget" im gleichen Modul.
Wuesste gerne, wie man das alles als nicht-logproxy user konfigurieren soll, am besten im SVG-Editor. :)
Btw. auf http://sen.se sieht man auch nette Alternativen.
Zitat von: rudolfkoenig am 17 November 2014, 14:40:56
Wuesste gerne, wie man das alles als nicht-logproxy user konfigurieren soll, am besten im SVG-Editor. :)
Ich auch. Und vor allen Dingen, wie man Anfängern, die hier im Forum mit Fragen aufschlagen, verständlich erklären soll, was im SVG Editor funktioniert und was warum nicht - selbst die mehr als 2 y-Achsen sind ja schon ein Problem, vor allem wenn man einen solchen Plot im SVG Editor aufruft, sind hinterher die zusätzlichen Achsen verschwunden...
natürlich soll jedes für den endanwender sinnvolle feature auch per gui/editor verfügbar sein.
die oben vorgeschlagenen features sind aber (fast) alle nicht direkt für den endanwender gedacht, für diesen nicht sichtbar und gehören daher nicht in den svg editor sondern jede dieser möglichkeiten würde nur von (speziellen) modulen genutzt um über die zurückgegebenen daten zeilen den plot zu beeinflussen.
das erkennen der unterbrechungen würde ich natürlich im logProxy modul einbauen. da habe ich die möglichkeit einen entsprechenden parameter (wenn unterbrechung > x dann neu anfangen) mit auf zu nehmen. für FileLog und DbLog könnte ich mir vorstellen das über ein attribut zu steuern falls daran interesse besteht. das man als nicht logProxy user ein logProxy feature nicht nutzen kann sehe ich nicht als problematisch an :)
ich fände es schöner die features mit in diesem (oder einem neuen) plot modul und nicht in einem zweiten zusätzlichen zu haben. der verdoppelte code würde in keinem verhältnis zur eigentlichen erweiterung stehen. es geht ja 'nur' um die beschriftung der x-achse.
für das oben angehängte beispiel bin ich mir tatsächlich noch nicht sicher ob ein solches diagram nicht besser in einem eigenen 'widget' aufgehoben ist. die überlappung mit SVG wäre hier minimal. aber sogar hier gibt es dinge wie plotfork oder plotEmbed die immer wieder nachgezogen werden müssten. wenn es darum geht ein xrange und xtics im plot file zu unterstützen würde ich das aber nicht in einem extra modul sehen.
ich glaube übrigens immer noch das logProxy für die anwender einfacher zu verwenden wäre wenn das normale SVG modul die column spec zeilen für unterschiedliche devices auslesen würde. dann könnte man das redundante #logProxy am anfang jeder zeile sparen. aber das ist eine andere geschichte :)
aber zurück zu der x-achse: du hast vorgeschlagen es in eine eigene funktion zu stecken. wie wäre es wenn man aus den folgenden vier fällen: automatische y-achse, y-achse mit ytics und yrange, automatische x-achse mit datum, x-achse mit xtics und xrange jeweils eine eigene funktion die nur die achse zeichnet macht und in SVG_render aufruft statt den code für alles in einem langen bandwurm zu haben? eventuell wäre die x-achse mit datum dann sogar 'nur noch' ein sonderfall der allgemeinen x-achse.
für die möglichkeit etwas anderes als zeiten auf der x-achse zu haben habe ich auch direkt schon feedback bekommen. im THZ modul wird gerade über einen ziemlichen hack/umweg so etwas eingebaut. das könnte man sich sparen wenn das SVG modul das einfach kann.
die zusätzlichen y-achsen gehören eigentlich in den editor bzw. sollten zumindest nicht verschwinden wenn man ihn verwendet. das würde ich aber eher als problem beim editor ansehen und nicht als grund die zusätzlichen y-achsen zu verbieten. die waren schon immer möglich. auch bevor es den editor gab.
weil bestimmte dinge mit dem ploteditor (noch?) nicht funktionieren sollte das nicht bedeut das diese features entfernt oder keine neuen mehr einbaut.
noch zwei oder drei probleme mit dem ploteditor (und wie der platz dort zur zeit genutzt wird) findet sich übrigens hier: http://forum.fhem.de/index.php/topic,27666.0.html (http://forum.fhem.de/index.php/topic,27666.0.html) und dem dort verlinkten thread.
ein plot wie im anhang ist mit etwa 15 zeilen änderung am SVG modul möglich. das sind ein paar zeilen für die unterbrechung und ein paar zeilen um die x achse auszublenden. diese änderung wäre also minimal. (natürlich zuzüglich des codes um dem eigentlichen plot daten zu erzeugen. aber der steckt ja nicht im SVG modul).
dazu kommen würde der code um für die x-achse etwas anderes als die zeit einzublenden.
gruss
andre
@andre: ich habe keine Einwaende, auch das Mischen der #FileLog/#logProxy Zeilen koennen wir in SVG.pm einbauen, wenn dir ein rueckwaertskompatibler Weg einfaellt. Z.Zt. fischt SVG.pm die Zeilen mit dem Typ des Lieferanten (FileLog/logProxy) aus der .gplot Datei, und befragt den Lieferanten (get) mit diesen Parametern. Der Lieferant kommt aus der SVG-Definition.
Apropos: ich habe gestern ein "Show preprocessed input" Knopf im Plot-Editor eingebaut, da ich es beim debuggen eines Plot-Fehlers einfacher haben wollte.
Mit DbLog.pm habe ich nichts am Hut :)
Zitat von: rudolfkoenig am 17 November 2014, 18:18:15
Apropos: ich habe gestern ein "Show preprocessed input" Knopf im Plot-Editor eingebaut, da ich es beim debuggen eines Plot-Fehlers einfacher haben wollte.
Toll... aber hätte man das nicht in einem separaten Fenster oder Tab ausgeben können, anstatt den aktuellen Inhalt des Browsers zu ersetzen?
Jenachdem wie man "haette" definiert. Nach meiner Definition nicht.
äöü macht nur Probleme :)
Dell hat mit seiner Werbung mich jahrelang daran erinnert, was alles schiefgehen kann.
anbei ein erste version für einen patch der die oben angesprochenen punkte umsetzt:
- xtics und xrange analog zu ytics und yrange
wenn beide nicht gesetzt sind ist alles wie bisher.
die zoom und pan buttons haben keine auswirkung auf den plot sobald die x achse etwas anderes als die zeit darstellt
- das berechnen der schrittweite für die tics auf der y-achse habe ich in eine sub gesteckt und auch für die x-achse verwendet
- im string der aus einer plot funktion zurück geben wird sind jetzt zusätzlich zu den zeilen mit datum und wert sowie den # zeilen die auf die nächste achse springen folgende specials möglich:
- ;
die aktuelle polyline wird beendet und eine neues segment angefangen - ;c [0|1]
das implizite schliessen der polyline wird aus- bzw. eingeschaltet. muss vor dem ersten daten punk des betreffenden segments kommen. - ;ls <style>
linestyle wird auf <style> umgeschaltet - ;m <x> <y> [<anchor> <mein text>]
es wird eine markierung mit optionalem text an die stelle x,y gezeichnet - ;t <x> <y> <anchor> <mein text>
es wird ein label an die stelle x,y gezeichnen - ;p <x> <y>
es wird ein punkt x,y zum plot hinzugefügt
- bei den specials m,t und p muss <x> in 'echten' x kordinaten sein wenn xrange gesetzt ist, ansonsten wie gehabt als SVG timestamp
- die optimierung aus dem anderen thread bei vielen punkten an gleicher x/zeit position ist auch mit drin
anbei noch mal ein beispiel was dann aus einem modul oder einer plot funktion möglich ist:
#logProxy Polar::[11,15,21,14,16]
#logProxy Polar::[11,15,21,14,16]
#logProxy Polar::[14,16,23,24,21]
#logProxy Polar::["Wohnzimmer","Bad","Kinder","Küche","Flur"]
plot "<IN>" using 1:2 axes x1y1 title 'Ist' ls l0 lw 1 with lines,\
plot "<IN>" using 1:2 axes x1y1 notitle ls l0 lw 1 with points,\
plot "<IN>" using 1:2 axes x1y1 title 'Soll' ls l1fill lw 1 with lines,\
plot "<IN>" using 1:2 axes x1y1 notitle ls l2 lw 1 with lines,\
die arrays in dem beispiel werden dann im 'echtbetrieb' aus einem stück perl code zurückgeliefert.
wenn du mit einem patch dieser art einverstanden bist würde mir als nächstes die abhängige darstellung zweier messgrößen vornehmen und die markierung von fehlenden messwerten vornehmen. dazu sollen dann (fast) keine änderungen am SVG modul mehr nötig sein.
Habe folgende Probleme:
- PERL WARNING: Use of uninitialized value $lTitle[0] in substitution iterator at ./FHEM/98_SVG.pm line 976.
- Undefined subroutine &main::getSteps called at ./FHEM/98_SVG.pm line 1421.
- bitte auf Spaltenbreite 80 umstellen
Sonst (== kein Problem): das Verarbeiten eines Jahreslogs mit 271 tausend Werten / 7 Linien (siehe Anhang) dauert 3.52 Sekunden (SVG) + 10.7s (FileLog). Die "alte" SVG Version benoetigt 3.42s, ist also 3% schneller bzw. im Gesamt-Wert 0.7%, mAn irrelevant. Auf dem Client habe ich aber keinen Unterschied beim Rendern gemerkt, war beides gefuehlt so ca 0.2s auf dem Desktop bzw. 1s auf dem Telefon. Wo ist die neue $ymin/$ymax Optimierung sinnvoll?
- die perl warnung in zeile 976 bekomme ich nicht. das scheint von der perl version abzuhängen. ich vermute das passiert in einer zeile in der notitle gesetzt ist? kannst du mal schauen ob die meldung so weg ist:$pTemp = $plot; $i = 0; $pTemp =~ s/title( '([^']*)')?/$lTitle[$i++]=(defined($2):$2?"")/gse;wenn das nicht hilft muss man das title/notitle attribut anders aus dem config file holen.
- das muss natürlich auch SVG_getSteps statt getSteps heissen. hatte ich im letzen moment noch umbenannt. reload findest das nicht weil die alte definition auch noch da ist.
- du meinst aber nur für meinen neuen code oder :) ?
klick mal auf eines der label so das parent.svg_labelselect aufgerufen wird. beim aus und einblenden solltest du einen massiven unterschied sehen (das ist der satz aus dem anderen thread der etwas verunglückt ist)
ich habe hier ein für ein device logs der letzten drei monate mit zusammen 250000 zeilen in zwei linien und es macht sich beim ein und ausblenden mit etwa faktor 3-4 bemerkbar. wenn du es nicht siehst ist dein log zu klein :)
es sollte auch sichtbar sein wenn man sich die datenmenge anschaut die zum browser geht. wir können aber den optimierung teil vom rest trennen und nicht alles im selben patch machen.
Ich habe dein Patch angepasst, und eingecheckt.
danke