SVG: Plot mit Steps sollte jetzt enden

[Dr. Boris Neubert]

Ein Plot, bei dem ich eine Messreihe mit Plot-Type = steps plotte, impliziert, dass der Messwert seit der letzten Messung konstant ist und sich erst mit der nächsten Messung ggf. ändert. Daher sollte m.E. im SVG-Plot immer noch eine horizontale Linie vom letzten Messpunkt bis zum aktuellen Zeitpunkt gezogen werden (ggf. mit dem Muster gefüllt), aber keine vertikale Linie am aktuellen Zeitpunkt. Würde das SVG-Modul so geändert, könnte man beispielsweise in Plots, die zwei Zustände (an/aus, nass/trocken) auf der Zeitachse  plotten, den aktuellen Zustand sehen. Aktuell zeigt der Plot am Ende immer aus/trocken (Einstellung: endPlotNow).

Oder gibt es eine einfache Möglichkeit (ohne logProxy), das Gewünschte zu erreichen? Anwendungsfälle: Zustand von Schaltern, Bodenfeuchtesensoren, Anwesenheitsmeldern.

[betateilchen]

Oder gibt es eine einfache Möglichkeit (ohne logProxy), das Gewünschte zu erreichen?

Für Werte, bei denen ich das wirklich so haben möchte, wird per addLog alle drei Minuten der aktuelle Wert ins Log geschrieben. Das reicht mir als "Ungenauigkeit" völlig aus.

[rudolfkoenig]

[...]impliziert, dass der Messwert seit der letzten Messung konstant ist und sich erst mit der nächsten Messung ggf. ändert.

Nicht unbedingt, ich benutze diese Darstellung fuer die Anzeige von Menge pro Zeiteinheit ("Regen pro Stunde", "Gasverbrauch am Tag", etc).
Wenn der Regenmesser nichts meldet, heisst es nicht, dass es immer noch regnet, eher das Gegenteil.

Daher sollte m.E. im SVG-Plot immer noch eine horizontale Linie vom letzten Messpunkt bis zum aktuellen Zeitpunkt gezogen werden (ggf. mit dem Muster gefüllt)

Das Fuellen mit dem Muster macht die Sache komplizierter, da man dafuer einen zweiten Polygon braucht, diesmal ohne Rand.
Vmtl. will man das Feature fuer alle 3 Varianten (step/histep/fstep) haben...
Ich kann sie einbauen, wenn noch jemand dafuer stimmt.
Und sinnvolle Namen dafuer vorschlaegt

[Dr. Boris Neubert]

@betateilchen: addLog ist ein Workaround, der in deinem Beispiel 3 Minuten nach dem letzten Umschalten greift. Abgesehen davon, dass ein Event geloggt wird, das nicht war, wäre das vermutlich die einfachste Lösung für die von mir gewünschte Darstellung im aktuellen System.

@Rudi:

Beim Regenmesser würde man doch eher fsteps verwenden? Die Regenmenge wird aufintegriert und der übertragene und geplottete Wert bezieht sich auf den Zeitraum BIS jetzt. Bei steps bezieht sich der Wert auf den Zeitraum AB jetzt.

Bei fsteps und histeps würde man die von mir vorgeschlagene Darstellung für steps nicht haben wollen.

Das Füllen ist der Clou: beim Bodenfeuchtesensor habe ich zwei Messreihen: 0=trocken,1=nass und 1=trocken,0=nass. Die Erste plotte ich mit steps in blau-gefüllt, die Zweite mit steps in rot-gefüllt, und sehe so Nass- und Trockenzeiten blau und rot hinterlegt im Plot.

BTW: Polygon mit/ohne Rand: der Ploteditor erlaubt keine Linienstärke 0. Lässt sich aber in der .gplot-Datei eintragen und funktioniert mit l?fill auch gut.

[betateilchen]

@Boris: bei addLog wird kein Bezug zu einem event hergestellt. Man kann damit sogar Werte ins Log schreiben (und in SVG darstellen) zu denen es gar kein existierendes device oder reading gibt. Das ist manchmal sehr praktisch.

[betateilchen]

Vmtl. will man das Feature fuer alle 3 Varianten (step/histep/fstep) haben...
Ich kann sie einbauen, wenn noch jemand dafuer stimmt.
Und sinnvolle Namen dafuer vorschlaegt

Bitte nicht noch mehr Einträge in die dropdown Liste. Da ist es jetzt schon voll und die Auswahlmöglichkeiten sind in FHEM nirgends verständlich dokumentiert. Ein Verweis auf gnuplot ist auch wenig hilfreich.

[Dr. Boris Neubert]

@Boris: bei addLog wird kein Bezug zu einem event hergestellt. Man kann damit sogar Werte ins Log schreiben (und in SVG darstellen) zu denen es gar kein existierendes device oder reading gibt. Das ist manchmal sehr praktisch.

Ja, das habe ich auch so verstanden. Der Purist in mir nimmt daran Anstoß, aber der Pragmatiker sagt: das ist eine Möglichkeit, die Darstellung einfach mit akzeptabler Unschärfe hinzubekommen.

[Dr. Boris Neubert]

Vmtl. will man das Feature fuer alle 3 Varianten (step/histep/fstep) haben...
Ich kann sie einbauen, wenn noch jemand dafuer stimmt.
Und sinnvolle Namen dafuer vorschlaegt

Bitte nicht noch mehr Einträge in die dropdown Liste. Da ist es jetzt schon voll und die Auswahlmöglichkeiten sind in FHEM nirgends verständlich dokumentiert. Ein Verweis auf gnuplot ist auch wenig hilfreich.

Meiner Meinung nach braucht es keine weiteren Plot-Typen sondern nur die Änderung bei steps. Das bricht allerdings die Abwärtskompatibilität. Oder zwingt zum richtigen Gebrauch von steps, fsteps und histeps (es sei denn, meine Argumentation, wie diese Plot-Typen zu interpretieren sind, ist fehlerhaft).

Ja, der Plot-Editor ist eine Herausforderung... Und ich habe noch ein paar Wünsche mehr in Sachen Bedienbarkeit und Wiederverwendbarkeit von .gplot-Dateien. Vielleicht mache ich noch ein Wunschkonzert-Thema auf.

[betateilchen]

Ja, der Plot-Editor ist eine Herausforderung...

Für mein Empfinden ist der komplett überflüssig, weil vieles ohnehin nicht mehr zeitgemäß ist oder erst gar nicht funktioniert (z.B. mehr als 2 y-Achsen)

Vielleicht wäre es sinnvoller, den Editor komplett auszubauen und stattdessen ein bisschen Aufwand in eine verständliche Dokumentation der Syntax von gplot-Dateien zu stecken.

Dann ließe sich sicher auch Dein Wunschkonzert einfacher realisieren, dem ich mich ggf. anschließe und auch noch die eine oder andere Idee dazu hätte.

[Gisbert]

@Boris: bei addLog wird kein Bezug zu einem event hergestellt. Man kann damit sogar Werte ins Log schreiben (und in SVG darstellen) zu denen es gar kein existierendes device oder reading gibt. Das ist manchmal sehr praktisch.

Hallo betateilchen,
das klingt interessant, und ich nutze auch addLog, allerdings war mir neu, dass es dafür keines Devices und Readings bedarf. Kannst du näher erläutern, am besten mit einem Beispiel oder einem Link, falls es dort ein Beispiel gibt?

Viele Grüße Gisbert

[xenos1984]

Meiner Meinung nach braucht es keine weiteren Plot-Typen sondern nur die Änderung bei steps. Das bricht allerdings die Abwärtskompatibilität. Oder zwingt zum richtigen Gebrauch von steps, fsteps und histeps (es sei denn, meine Argumentation, wie diese Plot-Typen zu interpretieren sind, ist fehlerhaft).

+1. Ich verstehe die verschiedenen Linien-Typen genau wie Boris:

• steps: Der Wert gilt ab dem gemeldeten Zeitpunkt, so lange, bis ein neuer Wert gemeldet wird. Nach dem letzten gemeldeten Wert gilt dieser weiterhin.
• fsteps: Der Wert gilt bis zum gemeldeten Zeitpunkt. Nach dem letzten gemeldeten Wert sind keine aktuellen Daten vorhanden.
• histeps: Der Wert gilt für ein bestimmtes Zeitintervall, das sich um den Meldezeitpunkt erstreckt.

Ich nutze z.B. steps für Sensoren, die nur dann etwas melden, wenn sich der Wert ändert (z.B. event-on-change-reading) und würde es daher auch logischer finden, wenn im Plot eine Linie vom letzten Messwert horizontal bis zum jetzigen Zeitpunkt durchgezogen würde.

Der Fall eines Regensensors, der die Regenmenge bis jetzt meldet, klingt für mich auch eher nach einem Anwendungsfall für fsteps. Da erscheint es mir logisch, wenn der Plot beim letzten Messwert endet.

Vielleicht wäre es sinnvoller, den Editor komplett auszubauen und stattdessen ein bisschen Aufwand in eine verständliche Dokumentation der Syntax von gplot-Dateien zu stecken.

+1.