configdb crasht FHEM

Begonnen von Prof. Dr. Peter Henning, 02 Februar 2023, 07:15:50

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

#30
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

betateilchen

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

Wernieman

Hast Du mal geprüft, ob eventuell "Sonderzeichen" im Ordnernamen sind? Also auf Shellebene geprüft?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

betateilchen

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

Prof. Dr. Peter Henning

#34
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

Prof. Dr. Peter Henning

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

betateilchen

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

Prof. Dr. Peter Henning

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

rudolfkoenig

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.

betateilchen


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

Prof. Dr. Peter Henning

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

betateilchen

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

Prof. Dr. Peter Henning

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

rudolfkoenig

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.

Prof. Dr. Peter Henning

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