config files in fhem editieren

[justme1968]

warum die beschränkung auf eine?

die config files könne vom modul ja auch als liste oder regex angegeben werden

[rudolfkoenig]

die config files könne vom modul ja auch als liste oder regex angegeben werden

Stimmt, meine anderen Einwaende (keine Alternativdateien editierbar, es muss ein Modul dafuer geben) bleiben aber bestehen.
Aber: ich brauche das nicht, es ist erstmal ein Dienst fuer alexa.
D.h. wenn du darauf bestehst, kriegst Du es so. Bitte bestaetigen.

[justme1968]

ja. es muss ein modul dafür geben

ich würde aus dem alexa modul alexa-fhem.conf und alexa-fhem.conf.previous melden. d.h. das aktuelle config file und eine potentiell vorhandene sicherheitskopie der vorherigen version. d.h. aktuelle und vorherige version.

[PatrickR]

Hallo zusammen!

Mir wäre ehrlich gesagt wohl dabei, wenn es nicht für jede zu editierende Datei zwingend ein Modul geben müsste. Die Ablage in dem neuen Verzeichnis sollte ausreichen. Wir sollten nicht aus den Augen verlieren, dass FHEM maximale Freiheiten für den Nutzer (d. h. nicht nur für den Modulentwickler) bietet. Dazu gehört auch, eigene Konfigurationsdateien mit FHEM-Bezug im Dateisystem abzulegen und an zentraler Stelle editieren zu wollen.

Patrick

[justme1968]

dann würde ich dafür eine option im fhemweb vorschlagen um eigene files in die liste mit aufzunehmen. wenn man tatsächlich alles möchte trägt man da halt .* ein.

maximale freiheit heiss nicht es maximal einfach zu machen etwas kaputt zu machen. nicht alle files sollen vom anwender editiert werden.

[betateilchen]

@Rudi: ich glaube wir reden aneinander vorbei. Den Kram mit "karl.august" sollst Du doch gar nicht mit einbauen

@alle anderen: Mein vorgeschlagener patch bietet doch genau das, was Ihr haben wollt. Irgendwie verstehe ich gerade nicht, worüber hier diskutiert wird.

Ich versuche heute abend noch einmal, die Idee hinter meinem Vorschlag klarzumachen.

[betateilchen]

Schritt 1: Rudi implementiert den angehängten patch und muss sich danach nicht mehr weiter darum kümmern. In dem Patch sind auch karl august und Konsorten nicht mehr enthalten.



Danach funktioniert folgendes:

ich würde aus dem alexa modul alexa-fhem.conf und alexa-fhem.conf.previous melden.

dazu trägst Du in Deiner alexa_Initialize() folgendes ein:

Code Auswählen Erweitern


$FW_customConfFiles{'alexa-fhem.conf'}   = "0";
$FW_customConfFiles{'alexa-fhem.conf.previous'}   = "0";


und schon werden diese beiden Dateien in FHEMWEB zum Editieren angeboten, vorausgesetzt, die Dateien existieren im ./conf Verzeichnis.

die config files könne vom modul ja auch als liste oder regex angegeben werden

siehe oben - Du kannst beliebig viele Dateien in die Liste eintragen.
Und auch Dein Wunsch nach der regexp würde bereits funktionieren. Anstatt die beiden Dateien einzeln zu registrieren, könntest Du auch nur folgendes angeben:

Code Auswählen Erweitern


$FW_customConfFiles{'alexa-fhem\.conf.*'}   = "0";


Kommen wir zum nächsten Wunsch...

Mir wäre ehrlich gesagt wohl dabei, wenn es nicht für jede zu editierende Datei zwingend ein Modul geben müsste.

Das ist nicht notwendig und würde für mich auch wenig Sinn machen.

Dazu gehört auch, eigene Konfigurationsdateien mit FHEM-Bezug im Dateisystem abzulegen und an zentraler Stelle editieren zu wollen.

Auch das geht bereits. Du kannst eine beliebige Datei in das Verzeichnis ./conf legen und musst nur dafür sorgen, dass sie FHEMWEB bekannt gemacht wird, z.B. über einen Eintrag in der myUtils_Initialize() Deiner 99_myUtils.pm

Bei mir habe ich die Konfigurationsdatei für DbLog in das Verzeichnis gelegt und die Datei in der 99_myUtils.pm an FHEMWEB registriert mit

Code Auswählen Erweitern


$FW_customConfFiles{'myDbLog.conf'}   = "0";


Das Modul 93_DbLog.pm könnte beispielsweise auch die im DEF eines dblog-devices genannte Konfigurationsdatei automatisch bei FHEMWEB registrieren, um sie zum Editieren anzubieten.

Und auch das hier

und man dann auch jedes modul über sein config file informieren kann.

Das funktioniert schon lange, das habe ich bereits gestern hier im Thread beschrieben und Rudi hat das heute auch nochmal bestätigt. Du musst in der NotifyFN() Deines Moduls nur auf global:FILEWRITE triggern und prüfen, ob dabei eine "Deiner" Dateien geschrieben wurde.



Hoffentlich wird jetzt klarer, dass ich versucht habe, alle Wünsche zu berücksichtigen.

[CoolTux]

So habe ich es mir vorgestellt. Dann weiß ich jetzt auch endlich wie ich meine templisten editieren kann. Danke Dir Udo.

[justme1968]

das klingt wunderbar. sehr schön.

test folgt sobald ich dazu komme.

[betateilchen]

Gerade habe ich grade festgestellt, dass ich mir die file2path Auflösung nochmal vornehmen muss. Momentan kann ich ausschließlich die Dateien im conf Verzeichnis editieren, offenbar funktioniert das doch nicht so elegant, wie ich mir das gestern ausgedacht und nachträglich geändert habe



Edit: so klappts, und so hatte ich das ja gestern auch zuerst implementiert.

Code Auswählen Erweitern


FW_fileNameToPath($)
{
  my $name = shift;

  my @f = sort keys %FW_customConfFiles;
  return "$FW_confdir/$name" if ( map { $name =~ $_ } @f );

...


[betateilchen]

Wer testen möchte, findet eine entsprechend gepatchte 01_FHEMWEB.pm unter ./contrib/betateilchen im SVN.

Einen Nachtrag habe ich noch zum Thema "eigene Dateien ohne zugehöriges Modul". Der vorgeschlagene Weg, diese Dateien in der myUtils_Initialize() zu registrieren, war kein guter Tipp. Die 99_myUtils.pm wird sehr viel früher geladen als die 01_FHEMWEB.pm, deshalb gibt es den entsprechenden hash zum Eintragen zu diesem Zeitpunkt noch gar nicht.

Besser wäre, solche modulunabhängigen conf-Dateien in einer Funktion der 99_myUtils.pm zu registrieren, die erst ausgeführt wird, wenn der FHEM Start ausgeführt ist, z.B. per notify auf global:INITIALIZED

Ein ähnliches Problem könnte auftreten, wenn in einer FHEM Installation ein Modul versucht, Dateien zu registrieren, bevor das Modul 01_FHEMWEB geladen ist. Das sollte zwar selten vorkommen, ist aber nicht auszuschließen.

[rudolfkoenig]

Ich bin zwar von der Loesung, dass andere Module FHEMWEB-Variablen aendern, nicht sehr angetan, aber ich finde das Nutzen/Kosten fuer weiter zu diskutieren nicht ausreichend, insofern habe ich den Patch eingecheckt.

Bemerkungen:
- patch hat was von "patch unexpectedly ends in middle of line" gemeldet, bitte pruefen, ob nicht was schiefgegangen ist.
- ich habe die Aenderung aus dem vorletzten Beitrag auch eingebaut.
- ich habe die Ueberschrift in "Config files for external Programs" geaendert.
- ein Abschnitt wird nicht angezeigt, falls kein Inhalt da ist (der Abschnitt ist fuer 99% der FHEM-Benutzer sinnlos, da leer).

[betateilchen]

Ich bin zwar von der Loesung, dass andere Module FHEMWEB-Variablen aendern, nicht sehr angetan,

ich auch nicht, insbsondere aufgrund der oben erwähnten Reihenfolge-Problematik beim Laden der Module.
Die einfachste Lösung zur Lösung des Reihenfolgeproblems wäre, den hash in fhem.pl zu definieren anstatt in FHEMWEB.

- ein Abschnitt wird nicht angezeigt, falls kein Inhalt da ist (der Abschnitt ist fuer 99% der FHEM-Benutzer sinnlos, da leer).

Das stand noch auf meiner ToDo Liste. Danke, dass Du mir die Arbeit abgenommen hast

Jetzt müsste man nur noch dafür sorgen, dass das Verzeichnis ./conf in FHEM mit ausgeliefert wird und prüfen, ob das Verzeichnis auch bei einem backup berücksichtigt wird.

[betateilchen]

Bemerkungen:
- patch hat was von "patch unexpectedly ends in middle of line" gemeldet, bitte pruefen, ob nicht was schiefgegangen ist.

Scheint alles gutgegangen zu sein.

Ich bin zwar von der Loesung, dass andere Module FHEMWEB-Variablen aendern, nicht sehr angetan,

Spräche aus Deiner Sicht etwas dagegen, anstatt %FW_customConfFiles in FHEMWEB den bereits vorhandenen %data aus fhem.pl dafür zu verwenden? Ich würde dann meine Implementierung nochmal auf $data{confFiles} umbauen und einen entsprechenden patch liefern. Jetzt wäre noch ein Zeitpunkt, wo man das relativ problemlos umstricken könnte, wenn die Funktionalität erstmal etabliert ist, wäre eine Änderung schwierig.

Die Verwendung von %data würde auch das Reihenfolgeproblem lösen.

insofern habe ich den Patch eingecheckt.

Danke für Deine Unterstützung.

[rudolfkoenig]

Spräche aus Deiner Sicht etwas dagegen, anstatt %FW_customConfFiles in FHEMWEB den bereits vorhandenen %data aus fhem.pl dafür zu verwenden?

Nein, ich finde %data auch besser.

Jetzt müsste man nur noch dafür sorgen, dass das Verzeichnis ./conf in FHEM mit ausgeliefert wird [...]

Warum? Ich meine das kann auch von den Modulen/Personen, die es verwenden wollen, angelegt werden.
Habe sonst die Befuerchtung, dass es fuer eine Ablage von fhem.cfg benutzt wird.

und prüfen, ob das Verzeichnis auch bei einem backup berücksichtigt wird.

Backup fuegt automatisch alle Verzeichnisse aus modpath hinzu, bis auf dem Backup-Verzeichnis selbst.