config files in fhem editieren

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

Vorheriges Thema - Nächstes Thema

justme1968

wie bekommt man am besten die möglichkeit ein config file in fhem zu editieren?

problem: für alexa-fhem ist ein (minimales) config file nötig das unter umständen vom anwender noch etwas angepasst werden muss.

eigentlich gibt es in fhem schon fast alles um das relativ komfortabel zu lösen, leider scheitert es an ein paar 'kleinigkeiten':
- das file muss in .../FHEM liegen
- es gibt keine möglichkeit .json als extension zu vergeben damit codemirror schön funktioniert

zusätzlich: wo sollte so ein config file liegen? aktuell schreibe ich es dorthin wo auch das fhem config file liegt, wenn fhem dort nicht schreiben darf landet es dort wo das statefile landet.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

CoolTux

Ich denke mal da wo auch fhem.cfg liegt ist es gut aufgehoben. Die configdb Config liegt ja z.B. auch da.
Aber eventuell sollten wir überlegen ein Verzeichnis zu benennen wo alle Dateien rein dürfen die über FHEMWEB editiert werden dürfen. Ich vermisse es meine Heizprofile einfach über FHEMWEB zu editieren. Die Herausforderung ist das diese in einer configdb liegen.
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

betateilchen

Zitat von: CoolTux am 05 Januar 2019, 20:56:25
Die Herausforderung ist das diese in einer configdb liegen.

Es ist völlig egal, ob die Dateien in configdb oder im Dateisystem liegt. Solange FHEM in der Lage ist, die Dateiendung zu "kennen" und damit zu wissen, in welchem Pfad die Datei liegt, arbeiten FileRead() und FileWrite(), die für das Bearbeiten per "Edit files" verwendet werden, völlig transparent.

Ein Unterverzeichnis, in dem Konfigurationsdateien liegen, per "Edit files" verfügbar zu machen, fände ich auch eine grundsätzlich sinnvolle Idee.

Das Thema ".json Files für codemirror" ist davon weitgehend unabhängig zu betrachten.
-----------------------
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: CoolTux am 05 Januar 2019, 20:56:25
Ich denke mal da wo auch fhem.cfg liegt ist es gut aufgehoben.

Nein.

Zitat von: CoolTux am 05 Januar 2019, 20:56:25
Die configdb Config liegt ja z.B. auch da.

Das ist ein Ausnahmefall, den ich seinerzeit ausführlich mit Rudi diskutiert hatte.
Die Konfigurationsdatei zur configDB muss zu einem sehr frühen Zeitpunkt gelesen werden, zu dem es noch keinerlei Attribute (z.B. moddir) gibt. Zu diesem Zeitpunkt kann fhem.pl deshalb nur Dateien im gleichen Verzeichnis finden, in dem sich auch fhem.pl selbst befindet. Das ist der gleiche Grund, warum auch configDB.pm in diesem Pfad liegt. Das ist besonders deshalb wichtig, damit das Ganze auch auf Systemen funktioniert, die eine grundsätzlich andere Verzeichnisstruktur verwenden, wie z.B. NAS Systeme.

Für Konfigurationsdateien, die während des Systemstarts von FHEM für einzelne Modultypen bzw. devices benötigt werden, stehen dann schon die globalen Attribute und damit eine "bekannte" Verzeichnisstruktur bereit. Solche config-Dateien können deshalb "irgendwo" liegen, solange der Pfad per Attribut oder sonstwie bekanntgemacht ist.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

Zitat von: betateilchen am 05 Januar 2019, 21:20:49
Das Thema ".json Files für codemirror" ist davon weitgehend unabhängig zu betrachten.

ja. aber...

files mit der endung .json werden nicht automatisch gefunden, wenn man editFileList verwendet überschritt man alle defaults.

ein addToEditFileList und removeFromEditFileList könnte hier helfen. wenn bei den so hinzugefügten files die prüfung auf .../FHEM entfällt wäre vermutlich der sofware teil erledigt.

oder ein $hash->{editFileList} das man im modul setzen kann.

statt beliebige pfade könnte man zusätzlich zu .../FHEM auch noch .../fhem/config erlauben und per attribut in global konfigurierbar machen. so wie logdir
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

CoolTux

Das meinte ich. Einfach ein ganzes Verzeichnis erlauben. Alle Dateien die darunter liegen dürfen von FHEMWEB editiert werden. Und somit ginge dann auch configdb wie Udo bereits angemerkt hat.
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

rudolfkoenig

Kann bitte jemand einen konkreten Vorschlag machen, ich kenne die Rahmenbedingungen nicht.

betateilchen

Zitat von: CoolTux am 05 Januar 2019, 21:34:55
Das meinte ich. Einfach ein ganzes Verzeichnis erlauben. Alle Dateien die darunter liegen dürfen von FHEMWEB editiert werden.

Zitat von: justme1968 am 05 Januar 2019, 21:31:57
statt beliebige pfade könnte man zusätzlich zu .../FHEM auch noch .../fhem/config erlauben und per attribut in global konfigurierbar machen. so wie logdir

Das Ganze ist nicht ganz so trivial wie es aussieht. Dazu müsste vermutlich ein Großteil der Logik für editFiles geändert werden.

Zitat von: justme1968 am 05 Januar 2019, 21:31:57
ja. aber...

files mit der endung .json werden nicht automatisch gefunden, wenn man editFileList verwendet überschritt man alle defaults.

Das ist schon klar. Das würde ja anderen Dateieendungen auch nicht anders ergehen. Das reine Hinzufügen einer Dateiendung, um diese als editierbar zu finden, wäre überhaupt kein Problem, solange dieser Dateityp in einem bereits bekannten Verzeichnis, z.B. ./FHEM liegt. Solche Erweiterungen wurden in der Vergangenheit ja auch schon vorgenommen.

Zitat von: rudolfkoenig am 05 Januar 2019, 21:38:54
Kann bitte jemand einen konkreten Vorschlag machen, ich kenne die Rahmenbedingungen nicht.

Auf meinen nächsten Bahnfahrten werde ich mal darüber nachdenken. Da ich bei der Entwicklung von configDB lange Zeit damit zugebracht habe, die Logik von "Edit files" zu verstehen um sie auch für configDB nutzbar zu machen, weiß ich zumindest, wie da intern grundsätzlich gearbeitet wird.

Die Diskussion über die Erweiterung dieser Funktion führen wir jetzt auch nicht zum ersten Mal. Gebt mir ein paar Tage Zeit.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

@rudfi: kurz nochmal die problemstellung aus meiner sicht:

- ein modul möchte ein oder mehrere files irgendwo im fhem verzeichnisbaum speichern
- die files müssen tatsächlich im filesystem liegen da andere externe prozesse darauf zugreifen müssen
- manche dieser files sollen vom endanwender über edit files editierter sein
- andere nicht, und sind idealer weise auch nicht 'abgreifbar'
- es wäre schön wenn diese files in der fhem backup routine mit berücksichtig werden

fragen:
- wo sollen die files genau liegen?
   vorschlag: ein neues verzeichnis unterhalb von .../fhem. pfad über global auffindbar
- sind Unterverzeichnisse erlaubt wenn ein modul mehr als ein file ablegen will?
- wie wird edit files informiert welche files mit angezeigt werden sollen?
  vorschlag: über eine add/remove routine und/oder über $hash->{editFiles}
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

betateilchen

Zitat von: justme1968 am 06 Januar 2019, 11:59:21
- die files müssen tatsächlich im filesystem liegen da andere externe prozesse darauf zugreifen müssen

Eine Datei zwingend im Dateisystem abzulegen, wird von FileRead() und FileWrite() grundsätzlich schon unterstützt.
Aber woher weiß der externe Prozess, wo er die Dateien suchen soll, wenn der Pfad über ein globales Attribut in FHEM beliebige verändert werden kann?

Zitat von: justme1968 am 06 Januar 2019, 11:59:21
- manche dieser files sollen vom endanwender über edit files editierter sein
- andere nicht, und sind idealer weise auch nicht 'abgreifbar'

Das ließe sich vermutlich über unterschiedliche Dateiendungen steuern.

Zitat von: justme1968 am 06 Januar 2019, 11:59:21
- es wäre schön wenn diese files in der fhem backup routine mit berücksichtig werden

Wenn sich die Dateien innerhalb der FHEM Verzeichnisstruktur befinden, sollte das kein Problem sein.

Zitat von: justme1968 am 06 Januar 2019, 11:59:21
- wo sollen die files genau liegen?
   vorschlag: ein neues verzeichnis unterhalb von .../fhem. pfad über global auffindbar
- sind Unterverzeichnisse erlaubt wenn ein modul mehr als ein file ablegen will?

Es gibt jetzt schon mehrere Module, die eine Anforderung bezüglich eigener Zusatzdateien haben, z.B. RSS, InfoPanel, holiday.
Grundsätzlich bin ich auch für ein gemeinsames Config-Verzeichnis für diese Dateien, von einer weiteren Untergliederung in weitere Unterverzeichnisse halte ich allerdings wenig.

Zitat von: justme1968 am 06 Januar 2019, 11:59:21
- wie wird edit files informiert welche files mit angezeigt werden sollen?
  vorschlag: über eine add/remove routine und/oder über $hash->{editFiles}

Diese Aufgabe zu lösen, ist voraussichtlich der einfachste Teil der Aufgabe.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Risiko

Zitat von: CoolTux am 05 Januar 2019, 20:56:25
Ich vermisse es meine Heizprofile einfach über FHEMWEB zu editieren. Die Herausforderung ist das diese in einer configdb liegen.
Hallo,

die von FHEMWEB editierbaren Wochenprofile liegen bei mir (json-Datei vom Modul weekprofile) im Log-Verzeichnis.
Nicht gerade schön, aber ich wollte das Problem mit den Schreibrechten umgehen und ganz neu ist das Modul auch nicht.
Wenn es eine einheitliche Lösung gibt, schließe ich mich gerne an.

Risiko.

justme1968

Zitat von: betateilchen am 06 Januar 2019, 14:49:15
Aber woher weiß der externe Prozess, wo er die Dateien suchen soll, wenn der Pfad über ein globales Attribut in FHEM beliebige verändert werden kann?
in meinem fall wird der externe prozess aus dem fhem modul heraus gestartet.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

betateilchen

#12
Zitat von: betateilchen am 06 Januar 2019, 10:33:00
Auf meinen nächsten Bahnfahrten werde ich mal darüber nachdenken.

Grüße aus dem ICE 79 irgendwo in Niedersachsen  8)

Spräche irgendwas dagegen, den ohnehin schon vorhandenen Ordner ./FHEM/FhemUtils künftig für die Ablage von config Dateien zu verwenden? Das dort liegende Keyfile wird natürlich nicht zum Editieren angeboten.

Dieser Ordner hätte den Vorteil, dass er schon komplett in die FHEM Infrastruktur, zum Beispiel bezüglich backup, integriert ist.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

spontan würde ich sagen alles unter FHEM kommt per update und ist auch im svn.

die config files sollen nicht ins svn sondern sind benutzer spezifisch. eigentlich gehört das key file sich nicht dahin. und von hand editierte holiday files auch nicht. aber das hatten glaube ich schon mal.

ein mal ein ./conf verzeichnis anzulegen wäre eigentlich sauberer. wäre das für configdb ein problem?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

betateilchen

nö, für configDB ist das kein Problem.

Das mit FhemUtils war ja nur eine spontane Idee, als ich gerade über das Thema nachgedacht habe.

BTW: Der Mechanismus für die holiday Files wurde schon vor längerer Zeit umgestellt, da spielt dieser Ordner keine Rolle mehr.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Wohl nicht ganz so trivial. Nach dem Editieren wird leider nur Dateiname an FHEMWEB zurueckgeliefert, und FW_fileNameToPath entscheidet anhand Dateiendung, wo es hingehoert, mit moddir/FHEM/Dateiname, falls sonst nirgendwo passt.
Ideen?

betateilchen

Zitat von: rudolfkoenig am 18 Januar 2019, 18:39:14
Wohl nicht ganz so trivial.

Stimmt :)

Ich arbeite gerade an dem Thema. Bin in den nächsten Tagen noch öfters auf Langstrecken mit der Deutschen Bahn unterwegs...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#17
Die Bahnfahrt heute hat sich gelohnt - und sie ist noch nicht zu Ende.


  • FHEM bekommt ein neues Verzeichnis modpath/conf
  • Die Edit Files Seite bekommt einen neuen Bereich "Config files"
  • Die Namen der config Files stehen in einem neuen hash in FHEMWEB mit dem Namen %FW_customConfFiles

Die Bearbeitung der Dateien mit dem internen Editor ist ohne weitere Besonderheiten in die vorhandene Implementierung eingebunden.

Einen ersten Patch zur Begutachtung habe ich angehängt. die beiden Beispieleinträge in den hash müssen in der Produktversion natürlich rausgenommen werden.


  • Der Wert 0 im hash hat derzeit noch keine Bedeutung, ich habe einen hash zur Ablage gewählt, um die Möglichkeit zu haben, später ggf. noch weitere Aktionen mit diesen Konfigurationsdateien ausführen zu können, an die ich jetzt noch nicht gedacht habe.
  • Aus dem gleichen Grund (evtl. spätere Erweiterung) wurde die Erzeugung der regexp für die Dateiliste in eine eigene Funktion ausgelagert.
  • Die Implementierung ist bezüglich fhem.cfg und configDB völlig transparent. Bei mir liegt die Datei "karl.august" in der configDB und "demo.conf" im Dateisystem. FHEMWEB erkennt das wie bisher automatisch, lädt die Datei von der richtigen Quelle und speichert sie auch wieder an den richtigen Speicherort ab.

Im einfachsten Fall trägt ein Modul seine eigene Konfigurationsdatei(en) einfach in den genannten hash ein, um sie in der Liste anzuzeigen. Genau so einfach wird eine Konfigurationsdatei wieder aus der Liste gelöscht, wenn sie aus dem hash entfernt wird.

Achtung: Wer testen möchte, muss darauf achten, dass die in den hash eingetragene Datei auch tatsächlich existiert, sonst wird sie in der Liste nicht angezeigt. (Diese Prüfung kommt direkt aus FHEMWEB und hat mit der jetzigen Änderung nichts zu tun)


aktualisierter patch im weiteren Verlauf des Threads
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

An der Möglichkeit, in den hash direkt eine regexp einzutragen, arbeite ich noch. Insbesondere wenn ein Modul mehrere Konfigurationsdateien benutzt, die sich per regexp zusammenfassen lassen, wäre das ein schönes feature.

Anzeigen in der Liste geht schon, die Auflösung von file to path fehlt noch.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#19
Zitat von: betateilchen am 20 Januar 2019, 19:55:18
An der Möglichkeit, in den hash direkt eine regexp einzutragen, ...

Anzeigen in der Liste geht schon, die Auflösung von file to path fehlt noch.

funktioniert jetzt. Siehe screenshot

$FW_customConfFiles{'.*.xy'}   = "0";
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Jetzt fehlt nur noch die sinnvolle Bestueckung von FW_confFiles.
Nein, ich weiss nicht, was sinnvoll ist :)

betateilchen

#21
Wir sind auf jeden Fall für Erweiterungen vorbereitet  8)
Falls keine Erweiterungen kommen, umso besser.

Mein Hauptgedanke bei der Umsetzung war, erstmal möglichst wenig invasiv in FHEMWEB zu arbeiten und möglichst vieles zu verwenden, was an Funktionalität vorhanden und bewährt ist.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#22
Zitat von: rudolfkoenig am 20 Januar 2019, 20:14:10
Jetzt fehlt nur noch die sinnvolle Bestueckung von FW_confFiles.

Bevor jetzt jemand auf die Idee kommt "man könnte ja den Modulnamen eintragen, um das Modul über Änderungen an "seiner" Konfigurationsdatei zu informieren" - das funktioniert auch heute schon. Beispiele sind 02_RSS.pm und 55_InfoPanel.pm, die nach Änderungen an einer Layoutdatei im Editor diese Layoutdatei automatisch neu einlesen um sie zu verwenden.

Für jede Datei, die über den Editor geändert und gespeichert wird, wird ein event global:FILEWRITE <fileName> erzeugt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#23
Die Auflösung in file2path geht noch eleganter:

nein, doch nicht...
-----------------------
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 finde es ungluecklich, dass ich fuer jedes Projekt, was Konfigurationsdateien in diesem Ordner speichern will, FHEMWEB anpassen muss, alternativ faellt mir kein Regexp ein, was alle Projekte gluecklich macht und keine sonstigen FHEM Dateien matcht.
Wie waere es mit "alle Dateien" aus FW_confDir?


justme1968

ich denke die liste der konfiguration files sollte nicht fest sein sondern dynamisch aus den modul und device hashes zusammen gesucht werden. also z.b. alle $hash->{FW_configFiles} zusammen suchen. darüber hat man dann auch umgekehrt die zuordnung welches file zu welchem modul gehört
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

betateilchen

Zitat von: rudolfkoenig am 21 Januar 2019, 09:52:47
Ich finde es ungluecklich, dass ich fuer jedes Projekt, was Konfigurationsdateien in diesem Ordner speichern will, FHEMWEB anpassen muss,

Das verstehe ich nicht: "dass ich fuer jedes Projekt, was Konfigurationsdateien in diesem Ordner speichern will, FHEMWEB anpassen muss"

Wieso musst Du FHEMWEB anpassen? Die Liste ist doch komplett dynamisch und FHEMWEB muss sich um keine regexp kümmern.

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

rudolfkoenig

@justme1968: Wozu braucht man diese Zuordnung?
@betateilchen: Wenn ich deinen Patch, so wie er ist (mit karl.august & co), einchecke, gehe ich davon aus, dass nicht alle zufrieden sind.

justme1968

weil jedes modul selber sagen soll welche config files editierbar sein sollen und man dann auch jedes modul über sein config file informieren kann.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

rudolfkoenig

Zitatweil jedes modul selber sagen soll welche config files editierbar sein sollen
D.h. FW_confdir ist nicht noetig, und jedes Modul kann _eine_ Datei beliebig spezifizieren. Der Benutzer kann nicht alternative oder alte Konfigrationen anschauen, und fuer eine Konfigurationsdatei muss zwingend eine FHEM-Geraete-Instanz angelegt sein.
Ich bin immer noch fuer "FHEM/conf/*", ohne Modul-Mitwirkung :)

Zitatund man dann auch jedes modul über sein config file informieren kann.
Das gibt es jetzt schon per global:FILEWRITE.

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.

betateilchen

Zitat von: rudolfkoenig am 22 Januar 2019, 12:03:56
Nein, ich finde %data auch besser.

Ok, ich baue das heute Abend um und bereite einen patch vor.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#46
es ist zwar noch nicht Abend...

Die Registrierung einer Konfigurationsdatei erfolgt jetzt im zentralen hash %data in der Form:

$data{confFiles}{'demo.conf'} = '0';


Index: 01_FHEMWEB.pm
===================================================================
--- 01_FHEMWEB.pm       (revision 18379)
+++ 01_FHEMWEB.pm       (working copy)
@@ -15,6 +15,7 @@
sub FW_addContent(;$);
sub FW_addToWritebuffer($$@);
sub FW_answerCall($);
+sub FW_confFiles($);
sub FW_dev2image($;$);
sub FW_devState($$@);
sub FW_digestCgi($);
@@ -88,7 +89,6 @@
use vars qw(@FW_httpheader); # HTTP header, line by line
use vars qw(%FW_httpheader); # HTTP header, as hash
use vars qw($FW_userAgent); # user agent string
-use vars qw(%FW_customConfFiles);

$FW_formmethod = "post";

@@ -2244,7 +2244,7 @@
{
   my $name = shift;

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

   $attr{global}{configfile} =~ m,([^/]*)$,;
@@ -2266,9 +2266,12 @@
   }
}

-sub FW_confFiles() {
+sub FW_confFiles($) {
+   my ($param) = @_;
    # create and return regexp for editFileList
-   return "(".join ( "|" , sort keys %FW_customConfFiles ).")";
+   return "(".join ( "|" , sort keys %{$data{confFiles}} ).")" if $param == 1;
+   # create and return array with filenames
+   return sort keys %{$data{confFiles}} if $param == 2;
}

##################
@@ -2296,7 +2299,7 @@
     my $efl = AttrVal($FW_wname, 'editFileList',
       "Own modules and helper files:\$MW_dir:^(.*sh|[0-9][0-9].*Util.*pm|".
                         ".*cfg|.*\.holiday|myUtilsTemplate.pm|.*layout)\$\n".
-      "Config files for external Programs:\$FW_confdir:^".FW_confFiles."\$\n".
+      "Config files for external programs:\$FW_confdir:^".FW_confFiles(1)."\$\n".
       "Gplot files:\$FW_gplotdir:^.*gplot\$\n".
       "Style files:\$FW_cssdir:^.*(css|svg)\$");
     foreach my $l (split(/[\r\n]/, $efl)) {

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

rudolfkoenig