Ich habe wie immer im Januar den neuen Müllkalender eingelesen, und als Datei /opt/fhem/muell.ics in die configdb importiert. Nachdem das dennoch nicht richtig funktionierte, habe ich mit
configdb filelist nachgesehen: Außer der Datei /opt/fhem/muell.ics behauptet configdb auch noch eine Datei muell.ics zu enthalten, die - folgerichtig - die Daten aus dem letzten Jahr enthält und bei der Anforderung aus dem Müllkalender als erstes gelesen wird. Kann also nicht gehen...
Also habe ich zuerst den Befehl
configdb filedelete muell.ics abgesetzt. Daraufhin teilt mir configdb brav mit, dass es die Datei /opt/fhem/muell.ics gelöscht habe - die ich ja gar nicht löschen wollte. Also noch einmal
configdb filedelete muell.ics. Daraufhin teilt mir configdb mit
ZitatFile /opt/fhem/muell.ics not found in database.
Allerdings ergibt
configdb fileshow muell.ics sehr wohl den Inhalt der veralteten Datei.
Hier stimmt also etwas nicht - wie werde ich die obsolete Datei wieder los?Dann habe ich verschiedene Varianten des Dateinamen muell.ics ausprobiert. Alle ohne Erfolg, bis ich dann
configdb filedelete 'muell.ics' eingegeben habe. Daraufhin hat sich
FHEM ins Nirvana verabschiedet. Fehlermeldung:
Zitat2023.02.02 06:57:49 1: PERL WARNING: DBD::SQLite::db do failed: near "muell": syntax error at configDB.pm line 1340.
DBD::SQLite::db do failed: near "muell": syntax error at configDB.pm line 1340.
LG
pah
Moin Peter,
der reißerische Thread-Titel
Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 07:15:50
configdb crasht FHEM
ärgert mich gerade maßlos.
- Wenn Dein Rottweiler ein kleines Kätzchen frißt und daran erstickt, ist auch nicht das kleine Kätzchen schuld, sondern der Hund, weil er etwas getan hat, das er nicht tun sollte. Genau so ist das hier:
Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 07:15:50
bis ich dann configdb filedelete 'muell.ics' eingegeben habe
Du hast etwas getan, was man nicht tun sollte. Es steht nirgends, dass man den Dateinamen in dem Befehl in Anführungszeichen setzen soll :)
- Der Titel hat überhaupt nichts mit dem eigentlichen Problem zu tun, für das Du eine Lösung suchst. Dein Problem ist ja nicht der von Dir provozierte FHEM Absturz, sondern dass Du eine Datei nicht löschen kannst.
Kommen wir zu Deiner Frage:
Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 07:15:50
und als Datei /opt/fhem/muell.ics in die configdb importiert.
...
Nachdem das dennoch nicht richtig funktionierte
...
Außer der Datei /opt/fhem/muell.ics behauptet configdb auch noch eine Datei muell.ics zu enthalten, die - folgerichtig - die Daten aus dem letzten Jahr enthält und bei der Anforderung aus dem Müllkalender als erstes gelesen wird. Kann also nicht gehen...
Wenn die Datei im Vorjahr muell.ics hieß und Du die neue Datei dieses Jahr als /opt/fhem/muell.ics importiert hast, sind das für configDB zwei unterschiedliche Dateien. Hier wird nämlich nicht mit Pfaden im Sinne eines Dateisystems gearbeitet, sondern der angegebene Name inklusive Pfad identifiziert die abgespeicherte Datei eindeutig.
Dateien OHNE Pfadangabe können zwar in die Datenbank importiert werden, solche Dateien können aber mit configdb filedelete nicht gelöscht werden. Beides ist so beabsichtigt, auf die Hintergründe und Notwendigkeiten dafür will ich jetzt nicht eingehen.
Wenn Dein Müllkalender nach einer Datei muell.ics (ohne Pfadangabe) sucht, dann importiere doch die ics Datei einfach aus dem Verzeichnis /opt/fhem mittels
configdb fileimport muell.icsin die Datenbank, dann wird die vorherige Datei durch die neue ersetzt.
Alternativ kannst Du die Datei als /opt/fhem/muell.ics importieren, dann musst Du halt in Deinem Müllkalender die Datei dort auch genau so angeben.
Eine Datei ohne Pfadangabe kannst Du nur auf Datenbankebene außerhalb FHEM aus der configDB löschen.
Habe gerade nochmal in meinem code nachgeschaut.
Zitat von: betateilchen am 02 Februar 2023, 08:38:19
Dateien OHNE Pfadangabe können zwar in die Datenbank importiert werden
Mach mal bitte ein "configdb filelist" - mich interessieren nur die Zeilen, die muell.ics enthalten.
Eigentlich kann eine Datei vom Benutzer gar nicht ohne Pfadangabe importiert werden.
Wenn Du beispielsweise "configdb fileimport muell.ics" eingibst, wird der Dateiname automatisch um den in global definierten modpath ergänzt. In der Datenbank wird die Datei dann als ./muell.ics abgelegt. Das ist genau aus dem Grund so implementiert, damit die Datei auch vom Benutzer wieder mit "configdb filedelete ./muell.ics" gelöscht werden kann.
Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 07:15:50
Dann habe ich verschiedene Varianten des Dateinamen muell.ics ausprobiert. Alle ohne Erfolg, bis ich dann configdb filedelete 'muell.ics' eingegeben habe. Daraufhin hat sich FHEM ins Nirvana verabschiedet.
Sollte ab dem morgigen Update nicht mehr passieren.
https://forum.fhem.de/index.php/topic,131996.0.html
Lieber Udo,
den "Ärger" kannst Du bitte, in aller Freundschaft, wieder runterfahren. Auch wenn das nirgendwo steht, müssen wir bei FHEM immer vom DAU, dem dümmsten anzunehmenden User ausgehen. Und der sollte nicht durch einen einfachen FHEM-Befehl sein System zum Absturz bringen können, und schon gar nicht mit einer Fehlermeldung "Syntaxfehler". Wenn das beim nächsten Update gefixt ist, prima.
Betreffend configdb filelist:
ZitatFiles found in database:
------------------------------------------------------------
/home/fhem/fhemlogs/LightScenes.save
... diverse weitere Dateien mit Pfadangabe
/opt/fhem/www/gplot/well.gplot
441327ce3704eee20587a97ab5b996de.fhem.save
... diverse weitere save-Files
9d55dcecde2d6c66906f411f3b86608d.fhem.save
AlarmFILE
TESTFILE
YAAHMFILE
babbleFILE
muell.ics
Also, wie Du siehst: mehrere Files OHNE Pfadangabe. AlarmFILE, YAAHMFILE, babbleFILE sind Konfiurationsdateien für meine Module und fühlen sich in der configdb sehr wohl - aber hineingeschrieben habe _ich_ sie nicht, und löschbar sind sie auch nicht. Und muell.ics _ohne_ "./", auch nicht löschbar.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 15:10:03
müssen wir bei FHEM immer vom DAU, dem dümmsten anzunehmenden User ausgehen.
Und der sollte nicht durch einen einfachen FHEM-Befehl sein System zum Absturz bringen können, und schon gar nicht mit einer Fehlermeldung "Syntaxfehler".
Bei einem "Prof. Dr." gehe nicht von einem "dümmsten anzunehmenden User" aus. Und von allen anderen Usern ist in den vergangenen fast 9 Jahren, seit es configDB gibt, noch nie jemand auf die Idee gekommen, den Dateinamen in Anführungszeichen zu setzen. Wahrscheinlich bist Du einfach überqualifiziert und alle anderen waren zu dumm, auf diese Idee zu kommen.
Davon abgesehen, ist die Fehlermeldung aus der Datenbankschicht (außerhalb FHEM!), die auf den Syntaxfehler hinweist, völlig korrekt.
Zitat von: Prof. Dr. Peter Henning am 02 Februar 2023, 15:10:03
Betreffend configdb filelist:
Also, wie Du siehst: mehrere Files OHNE Pfadangabe. AlarmFILE, YAAHMFILE, babbleFILE sind Konfiurationsdateien für meine Module und fühlen sich in der configdb sehr wohl
- aber hineingeschrieben habe _ich_ sie nicht, und löschbar sind sie auch nicht. Und muell.ics _ohne_ "./", auch nicht löschbar.
Das ist aber eher ein Problem der Module, die diese Dateien angelegt haben und damit arbeiten. Beispiel aus 95_Alarm.pm, Zeile 509:
my $error = FileWrite("AlarmFILE",$jhash0);Würden diese (alles Deine?) Module beim Anlegen der Dateien korrekt das globale Attribut modpath berücksichtigen und verwenden, gäbe es das Problem nicht.
Zugegeben: Dieses Problem tritt in dieser Form erstmalig auf. Aber man kommt beim besten Willen nicht darauf, dass ein Entwickler eine Konfigurationsdatei einfach ohne eine Pfadangabe (./ würde ausreichen!) IRGENDWOHIN schreibt - schon gar nicht ins root-Verzeichnis von FHEM (bezogen auf ein Dateisystem). Vor vier Jahren (https://forum.fhem.de/index.php/topic,95375.0.html) (Januar 2019) wurde im Developmentbereich das Thema "Ablage von Konfigurationsdateien" diskutiert und dabei auch ein Konfigurationsverzeichnis ./conf definiert, das dafür verwendet werden kann. Das schafft sogar die Möglichkeit, die dort abgelegten Dateien über "Edit files" bearbeitbar zu machen. Die Verantwortung, das Verzeichnis zu verwenden bzw. dieses Verzeichnis anzulegen, wenn es noch nicht vorhanden ist, liegt beim Modulautor, der dort seine Konfigurationsdateien ablegen möchte.
-
Zitat von: betateilchen am 02 Februar 2023, 16:46:08
Das ist aber eher ein Problem der Module, die diese Dateien angelegt haben und damit arbeiten.
Nun habe ich mal FHEM durchforstet.
Es gibt genau drei Module, die dieses Problem verursachen,
weil sie mit einem Dateinamen ohne Pfadangabe arbeiten:
95_Alarm.pm in Zeile 509
95_Babble.pm in Zeile 459
95_YAAHM.pm in Zeile 1030
Die Datei "muell.ics" ist vermutlich auf einem anderen Weg in die Datenbank gekommen, vielleicht in einer 99_myUtils.pm?
Erst einmal danke für den Hinweis, wie ich das Ding wieder loswerde - das war mir wichtig.
Zweitens:
ZitatVor vier Jahren (Januar 2019) wurde im Developmentbereich...
mag ja sein. Aber alle diese Module sind deutlich älter. Und da wir keinen Lesezwang haben, war diese Diskussion bei mir nicht auf dem Schirm. Wenn ich mich recht erinnere, war ich 2019 vollauf damit beschäftigt, neue Forschungsaktivitäten im KI-Bereich hochzufahren, die seitdem einen erheblichen Teil meiner Zeit beanspruchen. Ist aber ein guter Hinweis, ich werde alle drei entsprechenden Module so umbauen.
Drittens:
ZitatBei einem "Prof. Dr." gehe nicht von einem "dümmsten anzunehmenden User" aus.
Andersherum. Ich war mal Chef des Test-Teams einer Tochtergesellschaft der Deutschen Börse AG und habe da gelernt, systematische DAU-Tests durchzuführen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 03 Februar 2023, 05:38:44
Ist aber ein guter Hinweis, ich werde alle drei entsprechenden Module so umbauen.
Für den Anfang würde als Sofortmaßnahme reichen, jeweils das aktuelle Verzeichnis als Pfad mit anzugeben:
my $error = FileWrite("./AlarmFILE",$jhash0);An den Stellen, an denen das File gelesen wird, muss das natürlich auch so angepasst werden.
Ich habe mal mit einem einfachen grep gesucht - aber bisher kein Modul gefunden, das ein "conf"-Directory testet und ggf. erzeugt... War wohl 2019 doch nicht so dringend.
LG
pah
Edit: Ich habe das gerade in Babble, YAAHM und Alarm eingebaut.
Dringend? Habe ich nie behauptet. Aber nützlich. Es gibt aber durchaus Module außerhalb des offiziellen FHEM Kosmos, und da hilft Dir auch Dein grep nicht weiter. Bei mir gibt es aktuell vier Module, die mit ./conf arbeiten und das funktioniert super.
Vermutlich wissen einfach zu wenige Entwickler überhaupt von dem bunten Strauß an Möglichkeiten, die tief im Inneren von FHEM inzwischen verborgen schlummern. Wenn ich mir anschaue, welche Klimmzüge manche Module machen, um eigene Dateien zu verwalten, könnte es mancher Entwickler sehr viel leichter haben, wenn man auf solche Mechanismen zurückgreifen würde. Oft ist es hilfreich, ab und zu mal in die fhem.pl zu schauen, um zu verstehen, wofür es alles fertige Funktionen gibt. Genauso wäre es an manchen Stellen hilfreich, wenn die Kollegen die Funktionen FileWrite() etc. "richtig" verwenden würden, damit sie auch den Zweck erfüllen, zu dem sie ursprünglich erschaffen wurden. Aber diese Diskussion gehört eigentlich nicht in diesen Thread, zumal Du es ja prinzipiell richtig machst (abgesehen vom Dateinamen ohne Pfad).
Das ./conf Verzeichnis und das Problem in Deinen drei Modulen haben nicht zwingend etwas miteinander zu tun.
Es würde schon reichen, wenn Du in Deinen Modulen beim Schreiben und Lesen der Datei den in FHEM global definierten modpath vor den Dateinamen setzen würdest.
ZitatEs würde schon reichen,
Halbe Sachen mache ich nicht.
ZitatVermutlich wissen einfach zu wenige Entwickler
Stimmt. Aber ich habe weder die Zeit, allen Threads zu folgen, noch, die fhem.pl zu studieren. Die Sache mit dem ./conf hätte m.E. auch unter Ankündigungen erscheinen sollen. Und wir sollten so etwas wie einen "Developer Alert" einrichten, der solche Dinge zumindest einem eingeschränkten Personenkreis bekannt macht.
LG
pah
Das mit dem Lesen und schreiben in ./conf klappt prima - aber bisher kriege ich keine der Dateien im 01_FHEMWEB zum Editieren angezeigt, obwohl ich a.) sie in $data{confFiles} eingetragen habe und b.) sie auch explizit in der editFileList des Frontends habe und c.) diverse Endungen des Dateinamens ausprobiert habe.
LG
pah
Moin Peter,
zu a) in meiner 99_myUtils.pm habe ich testweise folgendes eingetragen: $data{confFiles}{'myUtils.conf'} = '0';
Danach wird mir die Datei myUtils.conf zu Editieren angeboten, sofern die Datei existiert. Siehe angehängten Screenshot
zu b) für meinen Test in a) habe ich eine Installation verwendet, die kein Attribut editFileList besitzt. Für die Anzeige der Konfigurationsdateien müssen diese nicht extra angegeben werden.
Falls Du das Attribut editFileList selbst gesetzt hast, sollte der Eintrag für die Konfigurationsdateien so aussehen
"Config files for external programs:\$FW_confdir:^".FW_confFiles(1)."\$\n"
zu c) die Endungen der Dateien haben keinen Einfluss. Es wird exakt der Dateiname verwendet, der in $data{confFiles} angegeben wird.
Hab ich alles brav gemacht:
{Dumper($data{confFiles})} ergibt
Zitat$VAR1 = {
'demo.conf' => '0',
'YAAHMFILE' => '0'
};
ls -l /opt/fhem/conf
ergibt
Zitattotal 28
-rw-r--r-- 1 fhem dialout 292 Feb 4 10:28 Alarm.conf
-rw-r--r-- 1 fhem dialout 292 Feb 3 20:13 AlarmFILE
-rw-r--r-- 1 fhem dialout 4 Feb 4 10:22 demo.conf
-rw-r--r-- 1 fhem dialout 5078 Feb 4 10:28 YAAHM.cfg
-rw-r--r-- 1 fhem dialout 5062 Feb 5 00:00 YAAHMFILE
Und die entsprechende Zeile im Attribut editFileList lautet bei mir
Configuration files:$FW_confdir:^(.*conf|.*cnf|.*FILE|.*txt)$Ergbnis: Keine Anzeige der existierenden und registrierten Dateien wird zum Editieren angezeigt. Versucht auf zwei verschiedenen Systemen, erstens einem meiner Hauptsysteme und zweitens auf einem Minimalsystem mit RaspBerry Pi und fast keinen Devices und ohne editFileList Attribut. In beiden Fällen ist die Version von 01_FHEMWEB aktuell. :'(
LG
pah
Was ich gerade nicht verstehe: wenn Du mit configDB arbeitest und Du in Deinem Modul wie bisher mit FileWrtite() arbeitest, sollten diese Dateien eigentlich automatisch in der Datenbank landen, nicht im Dateisystem.
Dem Mechanismus zum Auflisten der Dateien ist das aber egal.
Was liefert
{FW_confFiles(1)}
Zitat von: Prof. Dr. Peter Henning am 05 Februar 2023, 07:11:26
Und die entsprechende Zeile im Attribut editFileList lautet bei mir
Configuration files:$FW_confdir:^(.*conf|.*cnf|.*FILE|.*txt)$
Der Eintrag funktioniert zumindest problemlos, wenn ich den bei mir einbaue. Siehe Screenshot.
Wenn
- die Dateinamen in %data korrekt stehen
- die Dateien in ./conf vorhanden sind
- die Angabe in editFileList korrekt ist
und trotzdem der Abschnitt nicht unter "Edit Files" auftaucht, fällt mir als einzige Ursache nur noch ein, dass FHEM in dem Verzeichnis keine Dateien findet. Hat eventuell das Verzeichnis selbst irgendein Rechteproblem, sodaß FHEM dort einfach nicht nachschauen kann, welche Dateien da liegen?
Versuch doch mal, eine in ./conf liegende Datei in die configDB zu importieren und schau nach, ob diese Datei dann zum Editieren angeboten wird.
Zum ersten Post oben: Weil ich die Dateien mit
FileWrite({FileName => $filename,ForceType => "file"},$json); explizit ins Dateisystem, nicht in die configDB schreibe. Um erstmal ein Problem weniger zu haben. Außerdem ist auf dem einfachen RPi-Testsystem keine configDB da, sondern eine schön traditionelle fhem.cfg.
{FW_confFiles(1)} liefert
Zitat(YAAHMFILE|demo.conf)
Zum zweiten Post: Keine Änderung.
Ich werde gleich nach dem Frühstück mal sehen, ob ich das in der 01_FHEMWEB.pm irgendwie verfolgen kann.
LG
pah
Warum machst Du Dir das Leben unnötig schwer? Da habe ich Dich wohl weiter oben zu früh für die korrekte Verwendung von FileWrite() gelobt...
Lass das mit dem ForceType bitte weg und benutze FileWrite() genau so wie vorher,
Wenn auf dem FHEM keine configDB verwendet wird, landen die Dateien automatisch im Dateisystem.
Genau dafür wurden diese File...() Funktionen ja geschaffen: damit sich ein Entwickler keine Gedanken über die Fallunterscheidung machen muss.
Testweise kannst Du in 01_FHEMWEB.pm in der Funktion FW_displayFileList() eine Debug Meldung einbauen, um das Problem weiter zu analysieren.
sub
FW_displayFileList($@)
{
my ($heading,@files)= @_;
++ Debug "dFL $heading ".join("|",@files);
Damit sollten auf jeden Fall Debug Ausgaben erzeugt werden, wenn Du im Frontend in den Bereich Edit Files wechselst.
ZitatWarum machst Du Dir das Leben unnötig schwer?
Wieso schwer? Wenn man - und das kannst Du einem, den auf dem Gebiet NLP aktiv forscht, nicht verwehren - z.B. das babbleFILE mit einem externen Werkzeug bearbeiten will, führt daran kein Weg vorbei.
LG
pah
Das mit dem "Leben schwer machen" bezog sich hierauf:
Zitat von: Prof. Dr. Peter Henning am 05 Februar 2023, 09:59:56
Außerdem ist auf dem einfachen RPi-Testsystem keine configDB da, sondern eine schön traditionelle fhem.cfg.
Das alleine wäre kein Grund, mit ForceType zu arbeiten.
Aber wie schon gesagt - dem Mechanismus zum Auflisten von Konfigurationsdateien ist es egal, ob die Datei im Dateisystem liegt oder in der Datenbank.
Skype geht heute morgen nicht, ich muss gleich arbeiten...
Ich habe es jetzt zumindest eingegrenzt. 01_FHEMWEB steigt hier aus
Zitatsub
FW_fileList($;$)
{
my ($fname,$mtime) = @_;
my $logdir = Logdir();
$fname =~ s/%L/$logdir/g; #Forum #89744
$fname =~ m,^(.*)/([^/]*)$,; # Split into dir and file
my ($dir,$re) = ($1, $2);
Debug "===========> fL dir=$dir, re=$re";
return $fname if(!$re);
$re =~ s/%./[A-Za-z0-9]*/g; # logfile magic (%Y, etc)
my @ret;
Debug "==========> fL before opendir $dir";
return @ret if(!opendir(DH, $dir));
Debug "==========> fL opendir $dir succesfull";
while(my $f = readdir(DH)) {
next if($f !~ m,^$re$, || $f eq "98_FhemTestUtils.pm" ||
$f eq "99_Utils.pm");
push(@ret, $f);
}
closedir(DH);
return sort { (CORE::stat("$dir/$a"))[9] <=> (CORE::stat("$dir/$b"))[9] }
@ret if($mtime);
@ret = cfgDB_FW_fileList($dir,$re,@ret) if (configDBUsed());
return sort @ret;
}
Darüber hinaus habe ich auch noch eine weitere Datei zum Editieren in die editFileList eingebaut, mit Namen phonebook.txt. Und das klappt prima, wird mir zum Editieren angeboten.
Die Ausgabe in Log ist
Zitat
DEBUG>=============> t=Helper files, v=/opt/fhem/FHEM, re=^(.*sh|[0-9][0-9].*Util.*pm|.*cfg|.*holiday|.*sh)$
2023.02.05 11:01:23 1: DEBUG>===========> fL dir=/opt/fhem/FHEM, re=^(.*sh|[0-9][0-9].*Util.*pm|.*cfg|.*holiday|.*sh)$
2023.02.05 11:01:23 1: DEBUG>==========> fL before opendir /opt/fhem/FHEM
2023.02.05 11:01:23 1: DEBUG>==========> fL opendir /opt/fhem/FHEM succesfull
2023.02.05 11:01:23 1: DEBUG>===========> filelist=99_BabbleUtils.pm,99_HeatingUtils.pm,99_LightUtils.pm,99_PlotUtils.pm,99_RemoteUtils.pm,99_RollUtils.pm,99_SecUtils.pm,99_TimeUtils.pm,99_myUtils.pm,calendar.cfg,ebus_hz.cfg,ebus_solar.cfg,ebus_ww.cfg,holiday,holiday/Ferien.holiday.configDB
2023.02.05 11:01:23 1: DEBUG>=============> t=Configuration files, v=/opt/fhem/conf, re=^(.*conf|.*cnf|.*FILE|.*txt)$
2023.02.05 11:01:23 1: DEBUG>===========> fL dir=/opt/fhem/conf, re=^(.*conf|.*cnf|.*FILE|.*txt)$
2023.02.05 11:01:23 1: DEBUG>==========> fL before opendir /opt/fhem/conf
2023.02.05 11:01:23 1: DEBUG>===========> filelist=
2023.02.05 11:01:23 1: DEBUG>=============> t=Phonebook, v=/opt/fhem/FHEM, re=^phonebook.txt$
2023.02.05 11:01:23 1: DEBUG>===========> fL dir=/opt/fhem/FHEM, re=^phonebook.txt$
2023.02.05 11:01:23 1: DEBUG>==========> fL before opendir /opt/fhem/FHEM
2023.02.05 11:01:23 1: DEBUG>==========> fL opendir /opt/fhem/FHEM succesfull
2023.02.05 11:01:23 1: DEBUG>===========> filelist=phonebook.txt
So, und jetzt sag mir einer, was da los ist. Das Verzeichnis /opt/fhem/config hat als owner fhem:dialout, und als Rechte habe ich 755, 775 und 777 ausprobiert. Leicht irre finde ich, dass FileWrite und FileRead damit gut zurecht kommen - aber opendir nicht.
LG
pah
Zitat von: betateilchen am 05 Februar 2023, 09:25:01
fällt mir als einzige Ursache nur noch ein, dass FHEM in dem Verzeichnis keine Dateien findet. Hat eventuell das Verzeichnis selbst irgendein Rechteproblem, sodaß FHEM dort einfach nicht nachschauen kann, welche Dateien da liegen?
Da war meine Vermutung mit dem Rechteproblem doch gar nicht so falsch.
Ein ähnliches Problem hatte ich irgendwann, als ich versucht hatte, ein Verzeichnis aus FHEM mit make_path() aus File::Path anzulegen.
Wie hast Du denn (aus Deinem Modul heraus?) das Verzeichnis ./conf angelegt?
(mit schlechtem Gewissen, weil ich eigentlich wirklich die Klausur korrigieren muss...) Beispielsweise so.
my $error = mkdir $filedir;
if( $error != 1){
Log3 $name,1,"[Alarm_save] configuration directory $filedir could not be created, return code=$error";
Und ich habe es gerade eben auch nochmal mit einem manuell angelegten Verzeichnis probiert.
Irre. => Gelöst
LG
pah
Lass Dich nicht bei der Arbeit stören, ich sammle hier noch ein paar Ergebnisse meiner weiteren Tests.
Deine Art der Fehlerbehandlung hat natürlich den Effekt, dass jetzt immer eine Fehlermeldung im Log ausgegeben wird, da ein Verzeichnis ja nur einmal angelegt werden kann.
Bei mir habe ich jetzt das ./conf Verzeichnis wieder gelöscht und in meine 99_myUtils.pm folgendes eingebaut:
sub test{
use File::Path qw(make_path);
my $pathname = AttrVal('global','modpath','.').'/conf';
my @result = make_path($pathname, { verbose => 1, chmod => 0755, owner => 'fhem', group => 'dialout'});
my $ret = "make_path result:\n".join("\n",@result);
my $filename = $pathname."/myUtils.conf";
my $err = FileWrite({ FileName => $filename, ForceType => "file"},"test");
$err = $err?$err:"ok";
$ret .= "\n\nFileWrite result: $err";
$err = opendir(DH, $pathname) ? "ok" : "error";
$ret .= "\n\nopendir result: $err";
while(my $f = readdir(DH)) {
$ret .= "\nfound :$f";
}
closedir(DH);
$ret .= "\n\nFW_fileList result:\n";
@result = FW_fileList("$pathname/.*conf");
$ret .= join("\n",@result);
return $ret;
}
Ein Aufruf der Funktion liefert hier folgendes Ergebnis:
make_path result:
./conf
FileWrite result: ok
opendir result: ok
found :.
found :..
found :myUtils.conf
FW_fileList result:
myUtils.conf
myUtils.conf.configDB
Anschließend wird die Datei unter Edit Files angezeigt (sogar zweimal, einmal aus dem Dateisystem und einmal die Version in der Datenbank, das ist aber für den Test unbedeutend)
Mit dem Wert 0644 in make_path hat das Ganze nicht funktioniert, da gab es einen Fehler beim FileWrite.
ZitatDeine Art der Fehlerbehandlung hat natürlich den Effekt, dass jetzt immer eine Fehlermeldung im Log ausgegeben wird, da ein Verzeichnis ja nur einmal angelegt werden kann.
Äh, nö. Das war nur ein Schnipsel aus dem Code, natürlich schaue ich vorher, ob das Verzeichnis existiert:
#-- check existence of config directory
my $filedir = $attr{global}{modpath}."/conf";
if (-d $filedir) {
Log3 $name,1,"[Alarm_save] configuration directory $filedir found";
}elsif (-e "$filedir") {
Log3 $name,1,"[Alarm_save] $filedir found, but is not a directory";
return 1;
}else {
my $error = mkdir $filedir;
if( $error != 1){
Log3 $name,1,"[Alarm_save] configuration directory $filedir could not be created, return code=$error";
return 1;
}
Log3 $name,1,"[Alarm_save] configuration directory $filedir created";
}(brauchte mal eine Sekunde Pause vom Korrigieren...)
LG
pah
Auch wenn ich mkdir für sowas nicht mag (es arbeitet im Unterschied zu make_path nicht rekursiv), habe ich meinen o.g. Test jetzt nochmal mit mkdir ausgeführt.
Auch hier war das Ergebnis erfolgreich.
Warum es bei Dir nicht funktioniert - da bin ich gerade etwas ratlos.
Kann es sein, das der benutzte Style einen Einfluss hat?
Zitat von: Jamo am 05 Februar 2023, 18:41:28
Kann es sein, das der benutzte Style einen Einfluss hat?
Das würde mich sehr wundern.
bright, dark, f11, f18, iOS6, iOS7, iOS12 - alle getestet, in allen werden mir die Dateien zum Bearbeiten angeboten.
Eigentlich sollte ein Moderator diesen Thread mal auftrennen.
Das Problem mit den Konfigurationsdateien hat ja schon lange nichts mehr mit dem ursprünglichen Theman und dem Titel zu tun.
ZitatKann es sein, das der benutzte Style einen Einfluss hat?
Ausgeschlossen, denn es ist ja klar, dass das kein Anzeigeproblem ist. Sondern dass opendir bei diesem Verzeichnis aussteigt.
Ich habe jetzt in eine Testversion von 01_FHEMWEB nach dem opendir eine Ausgabe von $! eingebaut. Fehlermeldung lautet: "No such file or directory"
Brat mir einer einen Storch... => Gelöst.
LG
pah
Die Meldung kenne ich von der Betriebssystemebene...
Da kommt bei einem "rm ./conf" keine Fehlermeldung, dass es sich um ein directory handelt.
Irgendwas geht beim Anlegen des Verzeichnisses durch perl offenbar (manchmal?) schief - aber ich habe noch nicht verstanden, was genau.
Leider hatte Rudi es seinerzeit abgelehnt, das Verzeichnis einfach mit FHEM auszuliefern, was vieles einfacher gemacht hätte.
Hast Du mal meinen Codeschnipsel aus der 99_myUtils.pm oben ausprobiert?
Damit funktioniert das Anlegen des Verzeichnisses und das opendir bei mir fehlerfrei.
Hast Du mal geprüft, ob eventuell "Sonderzeichen" im Ordnernamen sind? Also auf Shellebene geprüft?
In ./conf sind m.W. keine Sonderzeichen enthalten.
Zitat von: Wernieman am 06 Februar 2023, 13:24:22
Also auf Shellebene geprüft?
Zitat von: betateilchen am 06 Februar 2023, 13:14:04
Die Meldung kenne ich von der Betriebssystemebene...
So, scheint gelöst. Auf den beiden genannten Systemen habe ich einen kompletten Neustart vorgenommen - und siehe da, plötzlich funktioniert alles. Ich stehe vor einem Rätsel, das ist mir aber egal, solange es geht. Kann m.E. höchstens sein, dass irgendein non-printable charakter mir da einen Streich gespielt hat - peinlich, auf einen Neustart hätte ich gestern selbst kommen können.
Allen Mit-Postern danke ich für die Unterstützung, ibs. Udo.
LG
pah
Also, ganz sauber ist die Implementation in FHEMWEB noch nicht.
Man kann nämlich in /opt/fhem/conf eine beliebige Datei einfügen und dafür sorgen, dass diese durch eine entsprechende Zeile im editFileList-Attribut auch zum Editieren angeboten wird. Allerdings kann man sie eben nicht editieren: Da sie nicht in %data{confFiles} steht, gibt es beim Klick auf den Dateinamen die Meldung, diese Datei würde nicht gefunden.
LG
pah
Naja, sowohl das manuelle Einfügen einer Datei in ./conf als auch die Bearbeitung des editFileList Attributes sind schon "Spezialfälle", von deren Existenz man überhaupt wissen und deren Funktionsweise man verstanden haben muss. Und wenn man das hat, kommt man auch darauf, dass man das "Problem" dadurch lösen kann, indem man eine solche selbstgestrickte Datei im _Initialize() seiner eigenen 99_myUtils.pm in $data{confFiles} einträgt.
Und ich bin mir auch nicht sicher, was der "richtige" Weg wäre?
- Dateien, die in ./conf abgelegt sind, auch dann im Frontend editierbar machen, wenn sie nicht in %data stehen?
- Dateien, die in ./conf abgelegt sind, nicht im Frontend anzeigen, wenn sie nicht in %data stehen?
Das soll die Projektleitung entscheiden...
Ich wünsche mir auch eine Guideline, ob ./conf wirklich nur für "Externe Programme" sein soll, wie es die Überschrift suggeriert. Oder wo wir, um eine gewisse Ordnung einzuhalten, solche Sachen wie "Lightscene.save", "Ferien.ics", "muellkalender.holiday" für existeriende Module ablegen.
Nicht, dass ich ein Freund von Guidelines wäre - aber etwas Ordnung ist gefragt.
LG
pah
Die Anforderung fuer das Verzeichnis ist hier beschrieben: https://forum.fhem.de/index.php/topic,95375.msg882334.html#msg882334
Wenn das fuer Benutzerdateien erweitert werden soll, dann muss ich was machen: ist das hiermit gewuenscht/bestellt?
Die Ursache meiner Zurueckhaltung ist, dass FHEMWEB nicht mit dem Pfad arbeiten will, sondern Dateien mit bestimmter Endung einem Verzeichnis zuordnet. Aus heutiger Sicht ist das Kaese, aber weil es nach und nach gewachsen ist, ist es nicht aufgefallen. Das Verfahren hat "leider" auch Vorteile, deswegen ist ein kompatibler Umbau nicht unbedingt trivial.
- Die Anforderung für ein Konfigurationsverzeichnis stammt aus 2019
- Selbst diejenigen, die das damals haben wollten, benutzen es bis heute nicht
- Peter ist nun der erste Entwickler, der den Mechanismus in offiziellen Modulen benutzt
- Die derzeit implementierte Lösung ist für das nutzbar, was seinerzeit gewünscht wurde
Über einen Umbau oder eine Erweiterung dieser Möglichkeit sollten wir nachdenken, wenn wirklich entsprechende Anforderungen bestehen.
Voreilige Schnellschüsse an dieser Stelle nützen niemandem und stiften mehr Verwirrung als dass sie nützen.
Zitat von: rudolfkoenig am 07 Februar 2023, 13:05:14
Die Ursache meiner Zurueckhaltung ist, dass FHEMWEB nicht mit dem Pfad arbeiten will, sondern Dateien mit bestimmter Endung einem Verzeichnis zuordnet.
Bei ./conf ist genau das eben nicht der Fall, da spielt die Endung keine Rolle (weil ich die Endungs-Abhängigkeit 2019 schon Käse fand...). Hauptsache, die Datei ist als confFile in %data eingetragen.
Zitat von: rudolfkoenig am 07 Februar 2023, 13:05:14
Wenn das fuer Benutzerdateien erweitert werden soll, dann muss ich was machen: ist das hiermit gewuenscht/bestellt?
Von mir nicht.
Na ja, noch habe ich die drei Module nicht eingecheckt. In allen drei Fällen handelt es sich JSON-Dateien, die aber bewusst nicht die Endung .json tragen. Und die mehr oder weniger komplizierte interne Konfiguration der Module darstellen und absichern. Zumindest bei Babble ist das ein ziemlich großer Hash mit semantischen Informationen, YAAHm liegt so in der Mitte und für Alarm ist das eher trivial.
Also, wohin sollen sie ? Ich bin für Vorschläge offen.
LG
pah
Jetzt verstehe ich überhaupt nicht mehr, was Du eigentlich willst und worüber wir hier die letzten Tage diskutiert haben...
Eigentlich ging es ursprünglich nur darum, dass Du Deine Dateien nicht als "ALARMbla" abspeichern solltest, sondern als "modpath/ALARMbla"
Alles andere hatte doch problemlos funktioniert.
Ich bin raus.
Mach mal langsam - wir haben ja länger an dem Verzeichnis ./conf herumdiskutiert, es wäre schade, wenn diese Arbeit und Deine Unterstützung für nix wären. Ich habe aber nicht den Eindruck, dass Rudi mit der Lösung konform geht.
LG
pah
ZitatIch habe aber nicht den Eindruck, dass Rudi mit der Lösung konform geht.
Wodurch ist dieser Eindruck entstanden?
Ich wollte nur wissen, ob ich was aendern soll, nicht dass ich nachher beschimpft werde.
Das ist aber oben nicht deutlich geworden. Gut, also bleibt es so: Die Konfigurationsdaten für Alarm, YAAHm und Babble liegen ab dem nächsten Release im Verzeichnis ./conf. Wann ich das offiziell einchecke, kann ichnochnicht sagen- ich muss mir noch eine automatische Migrationslösung ausdenken.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 08 Februar 2023, 08:54:06
ich muss mir noch eine automatische Migrationslösung ausdenken.
Vielleicht so?
- FileRead("ALARM.conf") ausführen
- im Fehlerfall => alles ok, es existiert kein altes conf-File oder wurde schon migriert
- im Erfolgsfall => Datei vorhanden, dann mit FileWrite("./conf/ALARM.conf") an den neuen Ort schreiben und mit FileDelete("ALARM.pm") am ursprünglichen Ort löschen
(Und in einer späteren Version diesen Mechanismus dann ausbauen, weil man irgendwann annimmt, dass alle bestehenden Installationen migriert haben.)
Lese hier auch schon eine ganze Weile mit (der Thread läuft seit einiger Zeit unter völlig falscher Flagge).
Wäre es nicht sinnvoll, eine Art API-Kommando "readConfigFile()" (Übergabe Dateiname bzw. Dateiname und alter Pfad+Dateiname) (bzw. "saveConfigFile()") einzubauen, das zum einen ggf. anstehende Verschiebungen macht, und/oder den Import nach configDB etc. (und ggf. den Hash entspechend erweitert)?
Hintergrund: Die Migration in Richtung configDB ist im laufenden Betrieb zumindest manchmal ein Problem (siehe unsere Diskussion (übrigens nach 2019!) zu lightScene), und für Verschiebe-Umbauten z.B. in RHASSPY oder msDialog fehlt mir grade die Lust, ebenso, "Übergangscode" einzubauen (und irgendwann wieder rauszunehmen). Aber diese zentrale Funktionalität des Verzeichnisses an sich zu nutzen, fände ich auch sinnvoll...