Hallo Rudi,
seit langem ärgere ich mich immer wieder darüber, dass der gplot Editor bei komplexen gplot-Dateien komplett versagt und diese Dateien regelmäßig "versehentlich" zerstört.
Mit "komplex" meine ich z.B. mehr als 2 y-Achsen, plotFunctions in Kombination mit DbLog usw. Diese Dateien können nur über "Edit files" korrekt bearbeitet werden.
Das Schreiben solcher Dateien wird ja schon dadurch ausgelöst, dass man nicht aufpaßt und durch Drücken von ENTER das Formular im gplot Editor abgeschickt und das gplot file geschrieben wird.
Um das zu verhindern, habe ich mir einen patch gebaut, der das Schreiben eines gplot Files aus dem gplot Editor verhindert, wenn es eine Zeile mit dem Inhalt "#readonly" enthält:
# Created by FHEM/98_SVG.pm, 2022-03-04 08:17:03
#readonly
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
...
Mein Bestreben war, die Änderungen in 98_SVG.pm möglichst gering zu halten.
Falls Du eine andere/bessere Idee hast, wie man das Feature umsetzen kann, gerne :)
Index: 98_SVG.pm
===================================================================
--- 98_SVG.pm (revision 25766)
+++ 98_SVG.pm (working copy)
@@ -59,6 +59,7 @@
Jan=>"Jan", Feb=>"Feb", Mar=>"Mrz", Apr=>"Apr", May=>"Mai", Jun=>"Jun",
Jul=>"Jul", Aug=>"Aug", Sep=>"Sep", Oct=>"Okt", Nov=>"Nov", Dec=>"Dez"
);
+my $gplotReadonly;
#####################################
sub
@@ -663,6 +664,14 @@
return if($FW_hiddenroom{detail});
return SVG_showData() if($FW_webArgs{showFileLogData});
+ if ($gplotReadonly) {
+ $FW_RET .=
+ '<div id="errmsg">'.
+ "gplot file marked as readonly: won't write!".
+ '</div>';
+ return 0;
+ }
+
if(!defined($FW_webArgs{par_0_0})) {
$FW_RET .=
'<div id="errmsg">'.
@@ -793,6 +802,7 @@
}
};
+ $gplotReadonly = 0;
foreach my $l (@svgplotfile) {
$l = "$l\n" unless $l =~ m/\n$/;
@@ -806,6 +816,8 @@
}
} elsif($l =~ "^plot" || $plot) {
$plot .= $l;
+ } elsif($l =~ "^#readonly") {
+ $gplotReadonly = 1;
} else {
push(@data, $l);
}
Ich wuerde das lieber als Attribut machen, dann gibt es gleich die Doku dazu.
Was dagegen?
Vorschlag: beide Ansätze kombinieren?
Hintergrund: Es gibt ja z.B. für Heizungs-Thermostate "Standard-gplot"-Files, die für alles mögliche taugen. Wenn der User die versehentlich überschreibt (ist mir früher auch schon passiert), ist das "doof".
Die Logik wäre: Attribut überschreibt die Vorgabe aus dem file.
Ach ja: Danke für den Vorschlag zu readonly!
Zitat von: rudolfkoenig am 04 März 2022, 12:20:03
Was dagegen?
Ja, denn ein gplot file besitzt keine Attribute und wird ggf. auch in mehreren devices verwendet.
Wo willst Du da ein Attribut setzen, um das gplot file selbst zu schützen?
Standardmäßig soll in einem von FHEM ausgelieferten gplot file überhaupt kein readonly gesetzt werden, weil es da normalerweise nicht notwendig ist bzw. sich diese Datei auch jederzeit problemlos wiederherstellen lässt.
Da ich aber nicht mit den standardmäßig gelieferten gplot arbeite, möchte ich zumindest die Möglichkeit haben, bestimmte (!) von mir erstellte gplot Dateien entsprechend zu schützen. Letzte Nacht habe ich gerade mal wieder zwei Stunden damit zugebracht, solche versehentlich verursachten Probleme zu beseitigen.
Edit:
Zitat von: rudolfkoenig am 04 März 2022, 12:20:03
dann gibt es gleich die Doku dazu.
Das Ansinnen ist löblich.
Aber: der Aufbau der gplot Dateien ist ohnehin nirgends wirklich nachvollziehbar beschrieben, das erschließt sich einem entweder durch trial-and-error oder indem man sich den Code von 98_SVG.pm vornimmt und die Bedeutung des Dateiinhaltes verinnerlicht.
ZitatJa, denn ein gplot file besitzt keine Attribute und wird ggf. auch in mehreren devices verwendet.
Falls mehrere SVGs die gleiche .gplot verwenden, wird im SVG Editor eine Warnung eingeblendet, diesen Fall sehe ich nicht, bzw. es wird sehr kompliziert.
ZitatWo willst Du da ein Attribut setzen, um das gplot file selbst zu schützen?
Ist wohl eine rhetorische Frage: in der SVG, was die Datei verwendet.
Allerdings ist das nicht naheliegend, weil der Benutzer die Datei direkt editiert, d.h das Attribut kann ich mir sparen.
Auf der anderen Seite sollten alle ausgelieferten .gplot Dateien sollten mit #readonly versehen werden, das wuerde immerhin die Aenderung ueber den PlotEditor vermeiden. Und das Faeture waere damit fuer die Datei-Editierer dokumentiert.
Zitat von: rudolfkoenig am 04 März 2022, 13:51:41
Falls mehrere SVGs die gleiche .gplot verwenden, wird im SVG Editor eine Warnung eingeblendet, diesen Fall sehe ich nicht, bzw. es wird sehr kompliziert.
Das hindert den gplot-Editor nicht daran, das file zu überschreiben. Was sich dann auf alle SVG devices auswirkt
Zitat von: rudolfkoenig am 04 März 2022, 13:51:41
Ist wohl eine rhetorische Frage: in der SVG, was die Datei verwendet.
Ja, schon. Aber wenn 5 SVG die gleiche Datei verwenden, muss auch in allen 5 SVG das Attribut gesetzt werden, damit es wirklich zuverlässig wirkt.
Zitat von: rudolfkoenig am 04 März 2022, 13:51:41
Auf der anderen Seite sollten alle ausgelieferten .gplot Dateien mit #readonly versehen werden,
das wuerde immerhin die Aenderung ueber den PlotEditor vermeiden.
Wenn Du das für sinnvoll hältst, gerne.
Gerade getestet: set <dev> copyGplotFile funktioniert mit meiner vorgeschlagenen Änderung nach wie vor problemlos. Das neue gplot File ist dann auch wieder readonly.
Zitat von: rudolfkoenig am 04 März 2022, 13:51:41
Und das Feature waere damit fuer die Datei-Editierer dokumentiert.
Na immerhin :)
Ich habe jetzt eine SVG.pm Version eingecheckt was eine readonly Anweisung in der .gplot File beruecksichtigt.
Ich habe aber statt #readonly den Weg ueber "set readonly" gewaehlt.
Vorteile: keine globale Variable, und der Patch ist deutlich kleiner. Nachteil: nicht gnuplot kompatibel.
Falls kein Veto kommt, dann wuerde ich alle eingecheckten .gplot Dateien mit dieser Zeile versehen.
Damit man diese Dateien anpassen kann, filtert "copyGplotFile" die "set readonly" Zeile.
Hallo Rudi,
danke für die Umsetzung. Die neue Version habe ich gerade getestet und zwei Anmerkungen.
- Wenn man im gplot-Editor jetzt nach Änderungen ENTER drückt (langjährige Angewohnheit, vermutlich nicht nur bei mir) wird FW_submit() für die Ausgabe der preprocessed data aufgerufen. Könnte man nicht stattdessen ein FW_submit() aufrufen, das einfach nichts tut oder nur die Meldung auf das readonly nochmal ausgibt? Ich glaube, das wäre besser verständlich. Bisher wurde in dem Fall immer FW_submit() mit "write gplot file" als default aufgerufen.
- bei "set <dev> copyGplotFile" wird ein readonly file nicht kopiert, wenn es "already unique" ist. Man müsste also zwingend erstmal das gplot file manuell bearbeiten. Bei selbst erstellten Dateien finde ich das ok, aber wenn sich nun alle von FHEM ausgelieferten gplot Dateien erstmal nicht mit FHEM Bordmitteln bearbeiten lassen, sind die (berechtigten) Beschwerden der Benutzer absehbar.
Ad 1: ich finde beide Varianten (meine und dein Vorschlag) komisch.
Richtig waere alle Felder auf readonly zu setzen, und das habe ich jetzt auch gemacht.
Return bringt aber weiterhin das "Show preprocessed input" Dialog :)
Ad 2: unique ist eine .gplot Datei dann, wenn es genauso heisst, wie das SVG. Das sollte im Fall der ausgelieferten Dateien kein Problem sein, wenn doch, dann muss man eine groessere Runde drehen.
Zitat von: rudolfkoenig am 05 März 2022, 13:03:12
Return bringt aber weiterhin das "Show preprocessed input" Dialog
Das halte ich persönlich für die schlechteste mögliche Lösung :(
Die zwischenzeitlich eingecheckte Lösung #25781 mit der Fehlermeldung als Rückgabewert fand ich erheblich besser.
Überlegung zur Logik: Wenn alle Felder im Editor readonly sind, braucht man auch die "prepocessed data" nicht mehr, weil man ohnehin nichts verändern kann, was sich auf die Ausgabe auswirken würde.(doch, die kann man u.U. trotzdem brauchen)
ZitatDas halte ich persönlich für die schlechteste mögliche Lösung :(
Gibt es dafuer auch eine Begruendung?
Dass die zwischenzeitlich eingecheckte Loesung dir gefaellt, leuchtet mir ein, entspricht ja auch deinem Vorschlag.
Mein Problem damit: dem Benutzer wird das Aendern der Konfiguration erlaubt, und beim Speichern mitgeteilt , dass Alles ueberfluessig war.
Zitat von: rudolfkoenig am 06 März 2022, 10:30:50
Gibt es dafuer auch eine Begruendung?
Dass die zwischenzeitlich eingecheckte Loesung dir gefaellt, leuchtet mir ein, entspricht ja auch deinem Vorschlag.
Da geht es nicht um "meinen Vorschlag" (so eitel bin ich nicht), sondern darum, dass man sich als Benutzer in der Vergangenheit angewöhnt hat, im Editor auch mal ENTER zu drücken. Bisher wurde dann gespeichert und man konnte weitermachen. Das "preprocessed input" Popup muss man erst manuell wieder schließen. Außerdem ist das Fenster in vielen Fällen einfach gar nicht erwünscht.
Zitat von: rudolfkoenig am 06 März 2022, 10:30:50
Mein Problem damit: dem Benutzer wird das Aendern der Konfiguration erlaubt, und beim Speichern mitgeteilt , dass Alles ueberfluessig war.
Das verstehe ich. Kannst Du die beiden Verhaltensänderungen nicht kombinieren? Du setzt die Felder auf readonly und falls jemand (gewohnheitsgemäß) ENTER drückt, kommt die Meldung trotzdem und verschwindet automatisch wieder. Meinetwegen kann das ENTER auch einfach "gar nichts" tun, ich brauche die Fehlermeldung nicht unbedingt. Aber ich will nicht durch ein unnötiges popup am Weiterarbeiten gehindert werden.
Zitat von: rudolfkoenig am 05 März 2022, 11:41:38
Falls kein Veto kommt, dann wuerde ich alle eingecheckten .gplot Dateien mit dieser Zeile versehen.
Soll ich Dir das abnehmen?
ZitatKannst Du die beiden Verhaltensänderungen nicht kombinieren?
Ok, einigen wir uns auf unentschieden :)
Habs gemacht.
ZitatSoll ich Dir das abnehmen?
Danke, nicht noetig, ein
sed -i -e '/^set terminal/i set readonly' *.gplothat mir die Arbeit schon abgenommen.
Danke.
Hallo in die Runde
Ob das jetzt so eine gute Idee war, die *.gplot mit dem Update alle auf readonly zu setzen, weiß ich nicht...
Gemerkt habe ich es freilich erst, als ich ein neues SVG einrichten wollte, und kläglich scheiterte:
In die Maske läßt sich schon nichts eintragen (1. Template-Eintrag ändern) geschweige denn läßt sich die Datei speichern (was ja noch logisch ist - folglich läßt sich aber dann auch nichts editieren) - Also erst einmal stundenlang das Dateisystem untersucht, schon an ein Hacking gedacht, dann einmal im Forum gesucht - und siehe da!
ME sollten die Templates und Vorlagen ohne dieses readonly daherkommen, damit man überhaupt etwas damit anfangen kann, bei besonderem Schutzbedarf kann man in eine ja ohnehin dann schon offene Datei dann manuell den Garant für's ewige Leben einsetzen.
Hat jemand eine Idee, wie ich diese readonly's wieder loswerde?
Danke im Voraus
ZitatHat jemand eine Idee, wie ich diese readonly's wieder loswerde?
Man clickt auf "set" neben dem voreingestellten copyGplotFile.
Zitat von: tryit am 23 März 2022, 19:46:06
ME sollten die Templates und Vorlagen ohne dieses readonly daherkommen, damit man überhaupt etwas damit anfangen kann
Abgesehen davon, dass template und Vorlage das gleich ist, geht es genau darum, diese Vorlagen als solche in ihrem Bestand zu sichern.
Um eine Vorlage für eigene Zwecke zu benutzen, ist set ... copyGplotFile eigentlich schon immer der dafür vorgesehene Weg. Diese Funktion wurde jetzt nicht neu eingeführt. In der Kopie der Datei ist das readonly nicht mehr vorhanden, somit kann der Anwender damit tun und lassen, was er möchte.
Ein liebes Danke an rudolfkoenig!
... darauf wäre ich im Leben nicht gekommen, weder aus der Commandref zu SVG "Set copyGplotFile" noch aus vorliegendem Thread. (War - und ist - für mich unlogisch, warum ich eine neu angelegte .gplot Datei nicht einfach speichern (Write .gplotfile) können sondern erst kopieren soll)
Ohne "readonly" hatte das Speichern bei mir immer funktioniert, ohne dass ich je eine Datei zerschossen hätte.
Aber mit dem "Set copyGplotFile" kann man ja gut leben.
Ergibt sich für mich die Anschlussfrage: Wie oder wo ist "die aktuell ausgewählte .gplot Datei" definiert?
@betateilchen:
Ich unterscheide zwischen gelieferten "Templates" und eigenen "Vorlagen", die ich nach Bedarf ganz oder teilweise meinen .gplot inkorporiere - und auch hier noch einmal: ich habe es noch nicht fertiggebracht, eine *.gplot zu zerschießen (mehrfach genutzte .gplot haben zusätzlich zu dem ohnehin vorhandenen Warnhinweis bei mir eine Namenspräambel, so dass ich gar nicht auf die Idee komme, diese im Editor zu öffnen.
ZitatOhne "readonly" hatte das Speichern bei mir immer funktioniert, ohne dass ich je eine Datei zerschossen hätte.
Zerschiessen ist Ansichtssache, aus meiner Sicht als Softwarelieferant ist das der Fall.
Dafuer repariert das naechste FHEM Update das Problem, was vermutlich der Benutzer als Zerschiessen wertet.
Zitat von: tryit am 23 März 2022, 22:53:19
unlogisch, warum ich eine neu angelegte .gplot Datei nicht einfach speichern (Write .gplotfile) können sondern erst kopieren soll
Wird eine "neue" gplot Datei mit FHEM Bordmitteln erzeugt, sollte diese nicht schreibgeschützt sein und kann sofort verwendet werden.
Zitat von: tryit am 23 März 2022, 22:53:19
Ergibt sich für mich die Anschlussfrage: Wie oder wo ist "die aktuell ausgewählte .gplot Datei" definiert?
Die gplot Datei, die für set ... copyGplotFile als Quelle verwendet wird, ist die Datei, die aktuell im gplot Editor geladen ist. Diese ergibt sich aus dem im DEF des SVG devices angegebenen Dateinamen.
Zitatdefine <name> SVG <logDevice>:<gplotfile>:<logfile>
Wird diese Datei mit set ... copyGplotFile kopiert, wird automatisch der Name der neuen Datei in das DEF des SVG device übernommen und im Editor angezeigt.
Das sind alles bewährte und durchdachte Mechanismen, die es schon ewig gibt, die aber die wenigsten Benutzer kennen, geschweige denn in der Vergangenheit genutzt haben.
Danke betateilchen!
Mit jeder Antwort erhellt sich mir die Struktur des Systems etwas mehr...
ZitatZitat
define <name> SVG <logDevice>:<gplotfile>:<logfile>
Wird diese Datei mit set ... copyGplotFile kopiert, wird automatisch der Name der neuen Datei in das DEF des SVG device übernommen und im Editor angezeigt.
Das sind alles bewährte und durchdachte Mechanismen, die es schon ewig gibt, die aber die wenigsten Benutzer kennen, geschweige denn in der Vergangenheit genutzt haben.
So habe ich schon immer meine SVG's angelegt! :-)
Zitat von: tryit am 24 März 2022, 13:51:26
So habe ich schon immer meine SVG's angelegt! :-)
So habe ich in all den vielen Jahren noch nie ein SVG angelegt.
Ich benutze immer den Link "Create SVG Plot from..." im Log-Device als Startpunkt :)