Für einige Geräteprofile (EEP) des EnOcean-Moduls würde ich gerne spezielle GPLOT-Definitionen erstellen und als Standard-Plots für die Anwender bereitstellen. Die Dateien sollen entsprechend benannt werden: EnO_xx-xx-xx, EnO_xx-x-xx_<nr> bzw. EnO_<Profil>. Ist es möglich und üblich, diese in das SVN-Verzeichnis ./fhem/www/gplot einzustellen und damit zu verteilen?
Ja, das ist leider üblich und müllt mir regelmäßig das Verzeichnis zu, was dazu führt, dass die Liste unter "Edit files" extrem unübersichtlich wird. Dort will ich eigentlich nur die gplot-Files sehen, die ich auch benutze. Dafür wünsche ich mir schon lange eine praktikablere Lösung.
Unüblich ist allerdings, danach zu fragen, ob man das tun soll, bevor man es tut... 8)
@Klaus: ja, das ist die Stelle dafuer.
@betateilchen: waerst du mit einem Regexp-Filter fuer die angezeigte Liste zufrieden?
betateilchen, bei mir habe ich das über "attr global exclude_from_update .*\.gplot$" eigtl. recht zufriedenstellend gelöst.
Gruß
Claudiu
@rapster: so habe ich das auch gelöst. Das löst aber zum einen nicht das Anzeige"problem" und man muss bei jeder neuen Installation erstmal alle vorhandenen Dateien löschen und das Attribut setzen.
@Rudi: Ich wäre mit einer Lösung zufrieden, die mir nur die gplot Dateien anzeigt, die auch in der fhem Installation bereits verwendet werden. Einen passenden Algorithmus, diese Dateien zu ermitteln, habe ich scihon bei der configDB-Migration (da müssen verwendete gplot-Dateien in die configDB umgelagert werden) eingebaut. Da kann ich gerne testen, ob sich dieser Algorithmus in FHEMWEB einbauen läßt und schlage dann einen patch vor. Einverstanden?
Generell stelle ich den Sinn der Bereitstellung von vorgefertigten gplot Dateien allerdings ohnehin in Frage. Ja, ich weiss, dass autocreate sie voraussetzt.
In meinen fhem Installationen wird kein einziges der vorgefertigten Files verwendet. Denn mit dem integrierten gplot-Editor funktioniert das Erstellen eines bedarfsgerechten gplot-Files viel schneller als das anpassen irgendwelcher Vorlagen, von denen ihr Entwickler glaubt, dass sie jemandem anderes nützen. Aus dieser Erkenntnis heraus gibt es auch keine gplot-Dateien für die von mir erstellten Wettermodule.
Hier die (bei mir erfolgreich getestete) notwendige minimale Änderung:
Patch entfernt, da noch nicht 100% funktionsfähig.
Daraus ergeben sich zwei zu klärende Fragen:
- Das Entscheidungskriterium. Mein Vorschlag: per Attribut "showUsedFiles" steuerbar.(vielleicht macht irgendwann irgendjemand den js/css Bereich in "Edit files" ebenfalls übersichtlich, dann kann das Attribut wiederverwendet werden)
- Die verwendete Funktion defInfo() (http://forum.fhem.de/index.php/topic,26395) befindet sich derzeit in der Standardauslieferung in 99_Utils.pm. Man sollte überlegen, die Funktion in die fhem.pl zu verlagern, damit das Laden der 01_FHEMWEB.pm nicht daran scheitert, dass ein User (versehentlich oder absichtlich) die 99_Utils.pm verändert/beschädigt hat.
Nachtrag zu Punkt 2: Sobald die Funktion defInfo() nach fhem.pl wandert, kann ich die inhaltlich identische Funktion _cfgDB_findDef() aus configDB.pm ausbauen und auf den "Standard" zurückgreifen. Die Funktion liegt derzeit nur deshalb in configDB.pm, um nicht von der Utils.pm abhängig zu sein.
*** STOP ***
der o.g. Patch funktioniert noch nicht korrekt im Zusammenspiel mit configDB. Da muss ich nochmal ran :)
jetzt aber...
Index: 01_FHEMWEB.pm
===================================================================
--- 01_FHEMWEB.pm (revision 9478)
+++ 01_FHEMWEB.pm (working copy)
@@ -166,6 +166,7 @@
reverseLogs:0,1
roomIcons
sortRooms
+ showUsedFiles:0,1
sslVersion
smallscreen:unused
smallscreenCommands:0,1
@@ -1783,8 +1784,17 @@
FW_displayFileList("Own modules and helper files",
FW_fileList("$MW_dir/^(.*sh|[0-9][0-9].*Util.*pm|.*cfg|.*holiday".
"|myUtilsTemplate.pm|.*layout)\$"));
- FW_displayFileList("gplot files",
- FW_fileList("$FW_gplotdir/^.*gplot\$"));
+ if (AttrVal($FW_wname,'showUsedFiles',0)) {
+ # show only used gplot files
+ my @usedFiles = defInfo('TYPE=SVG','GPLOTFILE');
+ @usedFiles = map { "$_.gplot" } @usedFiles;
+ @usedFiles = map { "$_.configDB" } @usedFiles if configDBUsed();
+ FW_displayFileList("gplot files", @usedFiles);
+ } else {
+ # show all gplot files
+ FW_displayFileList("gplot files",
+ FW_fileList("$FW_gplotdir/^.*gplot\$"));
+ }
FW_displayFileList("styles",
FW_fileList("$FW_cssdir/^.*(css|svg)\$"));
FW_pO $end;
Zitatjetzt aber...
...fehlt noch die Doku :)
Ich habe etwas nachgedacht, und bin der Ansicht, dass dieser Patch weder dir, noch anderen hilft.
Dir nicht, weil du die .gplots gar nicht sehen willst, da du den SVG-Editor verwendest. Anderen, die .gplot Dateien als Beispiel zum abschreiben brauchen auch nicht, weil sie die anderen dann gar nicht sehen.
Mir schwebt eher ein Attribut vor (im Beispiel der default-Wert):
attr FHEMWEB editFileList\
Own modules and helper files:$MW_dir:^(.*sh|[0-9][0-9].*Util.*pm|.*cfg|.*holiday|myUtilsTemplate.pm|.*layout)$\
gplot files:$FW_gplotdir:^.*gplot$\
styles:$FW_cssdir:^.*(css|svg)$Wenn dein Patch dir reicht, dann kann ich das auch uebernehmen.
Zitat von: rudolfkoenig am 20 Oktober 2015, 15:35:05
...fehlt noch die Doku :)
Naja, darüber kann man doch reden :)
Zitat von: rudolfkoenig am 20 Oktober 2015, 15:35:05
Ich habe etwas nachgedacht, und bin der Ansicht, dass dieser Patch weder dir, noch anderen hilft.
Dir nicht, weil du die .gplots gar nicht sehen willst, da du den SVG-Editor verwendest.
Das stimmt so nicht ganz. Ich brauche die Liste der gplot Dateien sehr wohl unter "Edit files", zumindest solange wie ich im SVG-Editor noch nicht alles bearbeiten kann (und von diesem Zustand sind wir noch Lichtjahre entfernt). Denn bis zu diesem Zeitpunkt muss ich gplot Dateien immer wieder mit dem integrierten Texteditor manuell bearbeiten.
Nur mal zwei Beispiele, was alles NICHT geht:
- sinnvolles arbeiten mit mehr als zwei y-Achsen
- einfügen von Funktionen zur Wertemanipulation beim Plotten aus DbLog
Insofern hilt mir "mein" Patch durchaus sehr viel weiter. Und die Doku zum neuen Attribut (ist showUsedFiles ok?) reiche ich Dir gerne nach.
Zitat von: betateilchen am 20 Oktober 2015, 19:49:45
- einfügen von Funktionen zur Wertemanipulation beim Plotten aus DbLog
Das funktioniert doch?
ich habe im SVG Editor noch nie eine Eingabemöglichkeit für Funktionen gesehen, wenn ich Werte aus DbLog verwende.
(http://up.picr.de/23460300ys.jpg)
Wenn du "attr <dblog> DbLogType History" setzt, sieht der Ploteditor wie im angehängten Bild aus und du kannst die function mit angeben.
EDIT: Allerdings 'hübsch' ist evtl. was anderes, aber praktisch ist es ;)
Habe beide Aenderungen (showUsedFiles & editFileList) eingecheckt.
Super, danke :)
Hast Du Dir auch darüber schon eine Meinung gebildet?
Zitat von: betateilchen am 17 Oktober 2015, 13:50:13
Die verwendete Funktion defInfo() befindet sich derzeit in der Standardauslieferung in 99_Utils.pm. Man sollte überlegen, die Funktion in die fhem.pl zu verlagern, damit das Laden der 01_FHEMWEB.pm nicht daran scheitert, dass ein User (versehentlich oder absichtlich) die 99_Utils.pm verändert/beschädigt hat.
Tut das Not, dass man im SVN Log momentan nur noch EnOcean GPLOT Commits sieht???
Kann man das nicht mit einem Commit lösen?
@Klaus: ich bin zunehmend der Ansicht, dass es keine gute Idee ist, fuer jeden der 100+ (oder 200+?) EnOcean Profile eine separate .gplot Datei anzulegen. Könnte man diese bitte nicht dynamisch generieren? Dann waere eine Unterstuetzung von DbLog auch einfacher zu realisieren bzw. zu pflegen. Idealerweise sollten alle Module das tun...
Zitat von: Markus Bloch am 25 Oktober 2015, 09:42:07
Tut das Not, dass man im SVN Log momentan nur noch EnOcean GPLOT Commits sieht???
Danke. Ich hatte mir die Frage nicht getraut 8)
Zitat von: rudolfkoenig am 25 Oktober 2015, 10:12:29
@Klaus: ich bin zunehmend der Ansicht, dass es keine gute Idee ist, fuer jeden der 100+ (oder 200+?) EnOcean Profile eine separate .gplot Datei anzulegen. Könnte man diese bitte nicht dynamisch generieren? Dann waere eine Unterstuetzung von DbLog auch einfacher zu realisieren bzw. zu pflegen. Idealerweise sollten alle Module das tun...
Im Augenblick scheint es doch wohl die Standardmethode zu sein, die Plots so zu definieren. Falls es zukünftig eine allgemein nutzbare Alternative geben würde, könnte das sicher für das EnOcean-Modul bei der Vielzahl der Profile auch nützlich sein.
P.S.: Ich bin mit den Definitionen (anzahlmäßig) im Wesentlichen durch!
ZitatDie verwendete Funktion defInfo() befindet sich derzeit in der Standardauslieferung in 99_Utils.pm. Man sollte überlegen, die Funktion in die fhem.pl zu verlagern, damit das Laden der 01_FHEMWEB.pm nicht daran scheitert, dass ein User (versehentlich oder absichtlich) die 99_Utils.pm verändert/beschädigt hat
Ich habs ueberlegt, und ich bin der Ansicht, dass das kein hinreichender Grund ist. Erstens sind in Utils noch viele andere "lebenswichtige" Funktionen (z.Bsp. min,max,time_str2num,SVG_time_to_sec), weiterhin muesste dann auch die Doku weiterwandern.
Ok.
Zitat von: rudolfkoenig am 21 Oktober 2015, 10:41:21
Habe beide Aenderungen (showUsedFiles & editFileList) eingecheckt.
traumhaft wäre, wenn das jetzt noch irgendwie in Kombination funktionieren würde...
Dann könnte ich mir den css Teil komplett ausblenden und in den gplot files nur die sehen, die ich auch brauche.
Aktuell habe ich Wahl zwischen Pest und Cholera: Entweder ich blende die css Liste aus, dann sehe ich erstmal eine Million EON-.gplot Dateien. Oder umgekehrt.
Nachtrag vom 30.10.
Ein neuer Test heute in aller Ruhe hat gezeigt, dass die Kombination doch wie gewünscht funktioniert. Vermutlich war eine falsche Angabe in meinem editFileList Attribut die Ursache, warum das beim ersten Versuch nicht geklappt hat.