config files in fhem editieren

Begonnen von justme1968, 05 Januar 2019, 20:39:56

Vorheriges Thema - Nächstes Thema

justme1968

warum die beschränkung auf eine?

die config files könne vom modul ja auch als liste oder regex angegeben werden
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Zitatdie 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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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:

Zitat von: justme1968 am 21 Januar 2019, 12:41:57
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:


$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.

Zitat von: justme1968 am 21 Januar 2019, 11:13:10
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:


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


Kommen wir zum nächsten Wunsch...

Zitat von: PatrickR am 21 Januar 2019, 13:16:50
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.

Zitat von: PatrickR am 21 Januar 2019, 13:16:50
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


$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

Zitat von: justme1968 am 21 Januar 2019, 10:59:45
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

CoolTux

So habe ich es mir vorgestellt. Dann weiß ich jetzt auch endlich wie ich meine templisten editieren kann. Danke Dir Udo.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

justme1968

das klingt wunderbar. sehr schön.

test folgt sobald ich dazu komme.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

betateilchen

#39
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.


FW_fileNameToPath($)
{
  my $name = shift;

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

...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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

#42
Zitat von: rudolfkoenig am 21 Januar 2019, 22:29:27
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.

Zitat von: rudolfkoenig am 21 Januar 2019, 22:29:27
- 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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: rudolfkoenig am 21 Januar 2019, 22:29:27
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.

Zitat von: rudolfkoenig am 21 Januar 2019, 22:29:27
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.

Zitat von: rudolfkoenig am 21 Januar 2019, 22:29:27
insofern habe ich den Patch eingecheckt.

Danke für Deine Unterstützung.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatSprä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.

ZitatJetzt 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.

Zitatund 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.