Ich habe in FHEM als Style F18 Ausgewählt. Dort habe ich auf der linken Seite das Menü erweitert
http://fhem3:8083/fhem?cmd=style%20edit%2099_myUtils.pm
Damit konnte ich durch Klick die Datei direkt anzeigen. Das funktioniert nun seit einigen Tagen / Wochen nicht mehr.
Ich weiß nicht genau, seit wann das so ist. Woran könnte das liegen?
FHEM ist auf dem neuesten Stand.
Der Fehler tritt auch an anderen Stellen auf, zum Beispiel wenn ich Gplotfile anzeigen klicke, dann kann das File nicht angezeigt werden.
Als Meldung erscheint dann jedesmal: Error on reading from database!
Nutze ich jedoch den Menüpunkt EditFiles, wird die MyUtils nach Klick in der Dateiliste angezeigt. Bei Gplotfile habe ich noch keine Lösung. Im Anschluss funktioniert auch wieder die Menüerweiterung.
Woran kann das liegen oder was kann ich dagegen tun?
Danke im Voraus.
Ich meine configDB rausgehoert zu haben, und deswegen muss ich an https://forum.fhem.de/index.php?topic=142235.msg1347781#msg1347781 denken.
Danke, ich geh da mal hin mit meinem Problem.
Bleibe hier, damit Du Antwort da bekommst, wo Du die Frage gestellt hast.
Einfach den Link verwenden, der unter "Edit files" bei der jeweiligen Datei angezeigt wird, wenn man die Maus draufstellt (logischerweise ohne den fwcsrf-Teil)
Siehe nächster Beitrag.
Das Thema "gplot" könnte ein anderes Problem sein.
Übrigens vermute ich, dass der Link nach einem FHEM Neustart auch nicht funktionieren würde, wenn man mit fhem.cfg arbeitet, weil der neu eingeführte hash mit den Dateinamen erst befüllt wird, wenn man zum ersten Mal auf "Edit files" klickt.
Das erklärt auch diesen Hinweis:
Zitat von: Invers am 15 September 2025, 10:07:11Nutze ich jedoch den Menüpunkt EditFiles, wird die MyUtils nach Klick in der Dateiliste angezeigt.
...
Im Anschluss funktioniert auch wieder die Menüerweiterung.
Edit: gerade verifiziert. Solche Links
funktionieren sowohl mit fhem.cfg als auch mit configDB erst, nachdem einmal "Edit files" geklickt wurde.
Ich habe die myUtils nicht in der Configdb abgelegt, nur so ein Hinweis zur Sicherheit.
Sollte ich das eigentlich machen? auch gplot habe ich nicht drinnen. Ich konnte nirgends sehen, ob mal alle Dateien in die DB aufnehmen sollte. Aber das wäre ein anderes Thema.
Ob Du die 99_myUtils.pm in die configDB importierst oder nicht, bleibt Dir überlassen. Es hat eben den Vorteil, dass die Datei bei einem neu aufgesetzten FHEM automatisch wieder zur Verfügung steht, weil sie in der Datenbank gespeichert ist.
Bei den gplot Dateien hast Du keine Wahl, Du musst Dich aber auch nicht darum kümmern.
Bei Anwendern, die configDB nutzen, arbeitet das Modul 98_SVG.pm automatisch mit configDB zusammen, die gplot Dateien werden aus der Datenbank gelesen und beim Bearbeiten auch automatisch wieder in die Datenbank gespeichert.
Das von Dir beschriebene Problem mit Deinem Link hat aber erstmal nichts mit configDB zu tun.
Es handelt sich um ein Problem von/in 01_FHEMWEB.pm, das mit den Änderungen, die Rudi Mitte August eingebaut hat, zusammenhängt.
Zu Deinem Problem mit den gplot Dateien habe ich eine Frage: Hast Du in Deiner FHEMWEB Instanz das Attribut "showUsedFiles" gesetzt? Wenn ja, lösche bitte das Attribut und teste dann nochmal.
Danke für die Klarstellung.
Das Attribut war gestzt. Habs gelöscht, aber es gibt keine Änderung. Ich habe aber nicht neu gestartet. Sollte ich?
Ein Neustart sollte nicht notwendig sein.
Bei mir ist es reproduzierbar so, dass bei gelöschtem Attribut das Bearbeiten von gplot Dateien über ,,Edit files" wieder funktioniert.
(Zur Klarstellung: das Attribut kann nur Auswirkungen auf das Thema gplot haben, nicht auf Deine myUtils)
Ich hab verstanden. Ich habe die SVG geöffnet. Dann kann man da alle möglichen Einstellungen machen und auch unten bei den Internals GPLOTFILE auf den Dateinamen klicken. genau das geht nicht. In der Liste der Dateien funktioniert es sowieso. Da funktioniert ja auch myUtils.
Gerade getestet: bei mir sind gplot-Dateien, die nicht als readonly gekennzeichnet sind, in den Internals klickbar und werden zum Bearbeiten geöffnet. Aber nur, wenn zuvor schon einmal "Edit files" aufgerufen wurde.
Auch hier ist die Ursache, dass der neu eingeführte hash für die Dateinamen vorher nicht gefüllt ist.
OK, besten Dank nochmals. Dann warte ich mal ab, ob und wann es eine Korrektur gibt.
Zitat von: rudolfkoenig am 15 September 2025, 11:57:47Ich meine configDB rausgehoert zu haben, und deswegen muss ich an ... denken.
Von configDB werden die hier beschriebenen Probleme nicht verursacht.
Das muss in FHEMWEB korrigiert werden.
Hi, ich wollte mich nur noch einmal in Erinnerung bringen. Das Problem besteht leider noch immer. Ist eine Lösung in Sichtweite, oder ist kein Fix geplant, oder erst in weiter Ferne?
Schönen Sonntag noch.
Zitat von: Invers am 12 Oktober 2025, 17:33:43Das Problem
Welches der vielen Probleme, die Du hier im Thread aufgezählt hast, meinst Du jetzt konkret?
Grundsätzlich gab es vor gut 3 Wochen mehrere fixes an FHEMWEB, um die Reihenfolgeprobleme mit den Dateinamen zu lösen. Und diese fixes funktionieren auch grundsätzlich.
OK, aber bei mir funktioniert es nicht.
Anzeige in der Adresszeile vom Browswer:
http://fhem3:8083/fhem?cmd=style%20edit%2099_myUtils.pm
FHEM meldet: 99_myUtils.pm is not in the editFileList
Nach Klick auf edit Files Browser: http://fhem3:8083/fhem?cmd=style%20list und
anschliessendem Klick auf meinen Link myUtils : http://fhem3:8083/fhem?cmd=style%20edit%2099_myUtils.pm
funktioniert die Anzeige wieder bis zum FHEM Neustart, also myUtils wird durch den Link sofort geöffnet.
Welche Infos werden zur Lösungsfindung oder Ursachenforschung benötigt?
Tag,
ich hatte das gestern Morgen mal probiert, bin dann aber abgeschweift.
Jedenfalls funktioniert es bei mir, wenn ich den CSRF-Token mit an die URL hänge.
Gruß schwatter
Die Fehlermeldung
Zitat von: Invers am 13 Oktober 2025, 07:55:2099_myUtils.pm is not in the editFileList
hat aber m.E. nichts mit CSRF-Token zu tun.
Hallo,
ich habe mir den Code des Moduls 02_FHEMWEB.pm angesehen und auch getestet. Mein Verständnis ist, dass die Fileliste erst beim erstmaligen Aufruf von EditFiles geladen wird. Das Laden eines FhemWeb reicht wohl nicht aus.
Grüße Jörg
ZitatMein Verständnis ist, dass die Fileliste erst beim erstmaligen Aufruf von EditFiles geladen wird. Das Laden eines FhemWeb reicht wohl nicht aus.
Es gab eine FHEMWEB Version, wo das genau so der Fall war.
In der aktuellen Version wird die Liste direkt vor dem Anzeigen der Datei erstellt, falls Edit Files vorher nicht aufgerufen wurde.
Die Pruefung, ob die Datei existiert (mit "$fileName is not in the editFileList") erfolgt danach.
Hallo Rudi,
hm, wenn ich Fhem neu starte, aktuelle 02_FHEMWEB.pm, dann kann ich über einen http Link nicht z.B. die 99_myUtils.pm anzeigen lassen. Habe das jetzt mehrmals versucht. Erst nach EditFiles funktioniert es.
Grüße Jörg
Wie schaut dein http Link aus?
Zitat von: rudolfkoenig am 13 Oktober 2025, 15:43:07Wie schaut dein http Link aus?
Hallo Rudi,
ich habe zum Testen einfach den Link den FhemWeb geniert genommen:
http://192.168.0.30:8083/fhem?cmd=style%20edit%2099_myUtils.pm&fwcsrf=300168192
Grüße Jörg
Zitat von: betateilchen am 13 Oktober 2025, 16:21:46Offtopic: Auch wenn Du das noch 10 Mal hinschreibst: es gibt keine 02_FHEMWEB.pm
Ist ja gut. Dann 01_FHEMWEB.pm. Zahlen Demenz.
Grüße Jörg
Um beim Thema zu bleiben: Ich kann das nachvollziehen mit der Meldung 99_myUtils.pm is not in the editFileList
Die kommt, wenn man keinen oder einen festen csrfToken festlegt.
Falls ich csrfToken auf 300168192 setze, dann kann ich
http://localhost:8083/fhem?cmd=style%20edit%2099_myUtils.pm&fwcsrf=300168192
problemlos aufrufen, auch dann, wenn ich nach einem FHEM Neustart keine andere Seite in FHEMWEB aufgerufen habe.
Mit csrfToken none geht das auch (dann ist es egal, was fuer fwcsrf Parameter im URL steht).
Ohne csrfToken kriege ich im Browser eine Fehlermeldung: HTTP Error 400 (Bad Request).
@Rudi: hast Du das auch mit einem Menüeintrag in der Navigation links probiert
attr web menuEntries test,cmd=style%20edit%2099_myUtils.pm
und dann nach einem FHEM Neustart den Link links angeklickt?
Ja, danke Dir. Genauso kann man es nachstellen.
Zitat von: rudolfkoenig am 13 Oktober 2025, 19:14:38Falls ich csrfToken auf 300168192 setze, dann kann ich
http://localhost:8083/fhem?cmd=style%20edit%2099_myUtils.pm&fwcsrf=300168192
problemlos aufrufen, auch dann, wenn ich nach einem FHEM Neustart keine andere Seite in FHEMWEB aufgerufen habe.
Mit csrfToken none geht das auch (dann ist es egal, was fuer fwcsrf Parameter im URL steht).
Ohne csrfToken kriege ich im Browser eine Fehlermeldung: HTTP Error 400 (Bad Request).
Auch von einem anderen Rechner wie localhost?
Nachvollziehen kann man es auch bei der Demo-Installation von CoolTux.
Hab eine 99_myUtils.pm angelegt, csrfToken none angegeben und einen restart gemacht.
https://demo-fhem.cooltux.net/fhem?cmd=style%20edit%2099_myUtils.pm
Der gezeigte test-Menüeintrag ist auch angelegt und gibt auch die Meldung zurück.
Danke, habs gefixed und eingecheckt.
Meine Testkonfiguration hatte keinen Logfile Eintrag, mit Logfile war die Pruefung kaputt.
Bestätigung: Funktioniert wieder einwandfrei.
Vielen Dank für die Hilfe und Unterstützung.