Hallo zusammen,
ich möchte eine Jahresplot von Monatswerten (als "bars") meiner Photovoltaikanlage erstellen. Da mich die monatlichen Werte interessieren, möchte ich diese Werte als Text im Plot darstellen.
Gibt es hierzu ein Lösung?
Viele Grüße
Frank
Ich verstehe die Frage nicht.
Monatsdaten als bars war nie ein Problem (siehe Anhang), die Daten muessen nur vorliegen, z.Bsp. indem man sie mit average, statistics, oder direkt im Modul berechnet.
Dafuer habe ich keine Loesung.
Zitat von: rudolfkoenig am 14 August 2020, 13:04:02
Dafuer habe ich keine Loesung.
kein Problem ;). Wäre dies denn ein Vorschlag für eine kommende Version?
Vorschlagen kann man vieles, meine Motivation daran zu arbeiten ist aber z.Zt. begrenzt.
Zitat von: rudolfkoenig am 14 August 2020, 13:44:07
Vorschlagen kann man vieles, meine Motivation daran zu arbeiten ist aber z.Zt. begrenzt.
Dann stelle ich eine Kerze ins Fenster und hoffe mal auf die Zukunft ;) ::)
Ich ergänze meinen Wunschzettel:
Toll wäre es auch, wenn man mit der Maus über die dargestellte Kurve geht, dass dann der Wert angezeigt wird, auf den die Maus gerade zeigt.
Wenn man auf die Kurve klickt, dann wird der Wert jetzt schon angezeigt.
Alternativ waehlt man im Menu (Rechte Maustaste auf der Legende) "Display Plot Values".
Achtung: Die Werte werden interpoliert, sind also nicht immer genau.
Wuensche zu formulieren ist schoen und gut, hilft aber selten, weil ich meine TODO-Liste schon recht gut selber fuellen kann.
@Bastel-Frank:
Im Hintergrund wird gnuplot verwendet. Ich fand die Idee ganz nett und habe mal kurz recherchiert, wie man das ggf. machen könnte. Leider hatte ich schon auf der gnuplot-Seite keinen Treffer. Also falls du was findest: tell us...
Ansonsten helfen mir in der Regel schon Hilfslinien weiter, um mich wenigstens etwas hinsichtlich der Größenordnung zu orientieren. Wie das geht, steht ebenfalls in der gnuplot-Doku, und da hätte ich ggf. auch Beispiele anzubieten.
ZitatIm Hintergrund wird gnuplot verwendet
Das war sicher der Fall vor 12 Jahren, danach wurde das Rendern in perl (98_SVG.pm) nachimplementiert. Um die Benutzer zu schonen, habe ich das Format der Konfiguration (.gplot Dateien) mehr oder weniger behalten, was vmtl. verwirrend ist. Seit (gefuehlt) 10 Jahren wird das Rendern via gnuplot nicht mehr gepflegt. Wenn es funktioniert, schoen, wenn nicht, auch :)
Ah, Danke für die Klarstellung, das war mir in der Tat nicht klar; ich habe mich allerdings bei meinen letzten "Übungen" mit der Syntaxt teils gewundert, wie bestimmte Einstellungen wirken - oder eben nicht -. (ging vorrangig um mehrere y-Achsen-Beschriftungen links/rechts usw., bestimmte Einstellungen sind auch schlicht wirkungslos, ich weiß nur nicht mehr, welche...).
(OT: Bin jüngst aus gegebenen Anlaß über die Doku zum Thema Plotten im Quick-Start gestolpert und irgendwie nicht mehr so glücklich darüber, wie da auf den gplot-Editor verwiesen/verlinkt wird; wenn ich mal "lustig" bin, gehe ich da nochmal drüber, mache zum SVG-Wiki-Artikel dann eine kleine Einführung, in der dann diese allgemeine Funktionsweise erläutert ist, verweise auf die vielen Beispiele, die man unter "edit files" finden kann und mach' und dazu eine englische Übersetzung; das erscheint mir zwischenzeitlich zeitgemäßer als das alte Howto mit dem Editor?)
Zitat von: Beta-User am 14 August 2020, 14:55:38
wenn ich mal "lustig" bin, gehe ich da nochmal drüber...
Hmm, also, Zwischenstand dazu:
Eine kurze Ergänzung habe ich jetzt in https://wiki.fhem.de/wiki/SVG#Hintergr.C3.BCnde reingebastelt.
Irritierenderweise ist und war der englische Artikel https://wiki.fhem.de/wiki/Creating_Plots qualitativ deutlich besser und manches könnte man auch übersetzt nach SVG rübernehmen... (Müßte mich damit aber erst mal noch etwas intensiver befassen.) Habe daher dort auch ein paar Kleinigkeiten geändert, der kann m.E. eigentlich jetzt weiter so stehen bleiben (und aus dem Quick-Start/en verlinkt).
Allerdings bin ich nicht sicher, ob das alles noch so zutrifft, was da steht, z.B.
ZitatAll data used in a plot come from one (!) file. It is currently not possible to mix data from several files. So make sure that the regular expression of the FileLog object catches everything which you need in one plot
entspricht nicht meinen eigenen Erfahrungen (man muß nur die Datenquelle entsprechend hart vercoden, oder?)...
Dem Gefühl nach würde ich jetzt dazu tendieren, im (d-) Quick-Start auf SVG zu verlinken statt auf https://wiki.fhem.de/wiki/Plots_erzeugen, so ganz rund ist das ganze allerdings irgendwie auch noch nicht...
(Ich mache bei Gelegenheit dann ggf. nochmal einen Thread im Wiki-Bereich dazu auf).
ZitatIrritierenderweise ist und war der englische Artikel https://wiki.fhem.de/wiki/Creating_Plots qualitativ deutlich besser und manches könnte man auch übersetzt nach SVG rübernehmen...
Dieser Artikel ist damals (2013) mit meiner Hilfe entstanden (sprich, ich habe Generix geduldig alles gefragte erklaert, und er hat einen Wiki Artikel geschrieben). Seitdem wurde im SVG Modul vieles ein- bzw. umgebaut, aber der Beitrag von Generix war eine "Eintagsfliege", und der Artikel seitdem nicht ausreichend angepasst.
Hmmm,
ok, habe jetzt erst kurz in die history geschaut, aber sowas in der Art schon vermutet. Ich werde mir dann erlauben, etwas "freier" mit dem Content umzugehen, muß aber wie gesagt erst mal selbst checken, was davon eigentlich noch gilt usw.
Ansonsten ist die Struktur des Artikels sehr gut, vermutlich werde ich das als Basis nehmen, um den SVG-Artikel umzubauen (an das Thema gplot-Editor will ich nicht so recht ran, das Ding ist "besonders" zweischneidig, da einerseits für Anfänger hilfreich, andererseits erzeugt es eben immer "hartcodierte" Ergebnisse, was ich als sehr unschön empfinde....
[OT]
Ich habe mir ein paar Mal den FHEM-Server komplett blockiert (nicht FHEM selbst, aber in der Folge war mysql laut top minutenlang auf 200% Last, ist ein dual-core-System) bei meinen Versuchen, generalisierte gplot-Templates zu erzeugen. Ich bin dem noch nicht vollständig auf den Grund gegangen, glaube aber, dass die Ursache (oder besser der Anlaß) darin lag, dass die plotreplace-Attribute nicht vollständig waren, es also mehr zu ersetzende Device:Reading-Zeilen gab als ersetzende Angaben im plotreplace-Attribut. (Noch) K.A., wie sich das bei FileLog verhalten würde, ich nehme aber an: unauffällig...
Das ist jetzt nicht mehr das Problem, weil ich dann einfach alles auf "none" gesetzt habe (und damit unnötigen Einträge in der Legende erhalte), aber irgendwie gibt es da gefühlt "room for improvement". Falls Interesse besteht, liefere ich gerne Details dazu; dem Gefühl nach sollte man a) erforderliche Angaben aus den gplot-files ggf. auf einen "ignoriere das"-Wert setzen (none?) und b) im Folgenden dann auch solche Zeilen sowohl in der Auswertung wie auch in der eigentlichen plot-Anweisung rausfischen (ich habe noch nicht in den Code gesehen, ob und wie das ggf. ginge).
(eigentlich würde ich gerne auch ein paar generalisierte Muster-.gplot für z.B. das 3-phasige Messen oder den Thermostat mit Außentemperatur oä. einpflegen und ggf. auch andere Beitragende zu dem Thema bitten, mal über "ihre" gpolt-Definitionen kritisch drüberzusehen, aber wenn/solange das solche Haken hat (bzw. ich noch nicht so recht weiß, welche Hinweise man dazu geben müßte), ist das noch zu unausgegohren).
eigentlich würde ich gerne auch ein paar generalisierte Muster-.gplot für z.B. das 3-phasige Messen oder den Thermostat mit Außentemperatur oä. einpflegen
Das finde ich deswegen amuesant, weil ich auch damit angefangen habe: einige Module erzeugen jetzt noch per autocreate SVGs mit dem passenden Template, autocreate bietet eine Schnittstelle dafuer an.
Ich empfand irgendwannmal den Aufwand, diese Templates anzupassen (auch wegen den Fragen von Generix) hoch, bzw. fuer "einfache" Benutzer unzumutbar, deswegen habe ich mit dem PlotEditor angefangen.
Vermutlich gibt es keine Loesung, was jedem Recht ist.
Ja, man merkt dieser Ecke von FHEM an, dass da viele vieles angefangen haben... (ich habe CUL_HM-Thermostate und fand das lange sehr gut, was autocreate da "veranstaltet"; irgendwann habe ich allerdings dann mit dem "hilfreichen" Editor die Außentemperatur (aus einer anderen Logfile ;) ) dazugebastelt und dummerweise damit einen ganzen Haufen individueller Definitionen generiert; erst beim Aufräumen dieses suboptimalen Zustands bin ich dann über plotreplace "gestolpert", was dann Anlaß für den "neuen Artikel" (SVG) war und auch für mindestens einen anderen wieder so interessant, dass der sehr aktiv dazu beigetragen hat).
Im Prinzip denke ich, dass plotreplace ein sehr mächtiges Werkzeug ist, das vieles vereinfachen _könnte_. Es fehlt allerdings irgendwie der integrierende Ansatz, und es wäre vermutlich wichtig, eine gewisse "kritische" Masse an gplot-Files zu haben, damit die User das feature überhaupt wahrnehmen und damit weiterarbeiten können. Anders gesagt: es gibt da viele Detaillösungen, aber warum braucht es fht.gplot und hm-rt.gplot (und einen Wandthermostat?) und ggf. nochmal was für EnOcean und dann noch (EnOcean) motion, motion+brightness, ... und dasselbe nochmal für ZWave, ... (?)?
"Eigentlich" sollte man z.B. für jede Variante eines Klimagerätes (und unterschiedslos für FileLog oder DBLog?) mit einem oder zwei "Master-gplot" auskommen können (mit und ohne Fenster-kontakt, z.B.), dann vergibt man (via attrTemplate?) das "eine" Attribut und "fertig ist die Laube" (und das Ergebnis ggf. nachvollziehbarer). Würde halt erfordern, dass im Modul-Code ignoriert wird, was "nicht vorhanden" ist.
Dazu ggf. noch ein paar wenige sinnstiftende logProxy-Beispiele? (Ich habe das noch nicht im Einsatz, aber irgendwann will ich ggf. meine statistics-Werte ohne komplexe Datenbankabfragen historisch vergleichen können).
(Das ist nicht die wichtigste Ecke, es war nur grade Gelegenheit, meine Gedanken etwas auszuführen).