Hallo,
ich hoffe das ist hier richtig.
- ich habe gesucht (Forum, Suchmaschine), aber nichts gefunden, was auf mein Problem passt.
- in der CommandRef (en und de) und im Wiki steht nichts zu Unterordnern (auch eben nicht, dass es nicht geht)
Ich hatte vorgehabt, die LogFiles besser zu organisieren. Und zwar habe ich ein autocreate mit
- fileLog=./log/devices/%NAME/%Y-%m-%d.log
was dann im FileLog device zB so landen würde:
- logfile=./log/devices/MQTT2_zigbee_Tuya.Sens.TempHumid.Bad/%Y-%m-%d.log
Wenn ich das aber nun testweise versuche manuell anzulegen bringt mir FileLog den Fehler
ZitatCan't open ./log/devices/MQTT2_zigbee_Tuya.Sens.TempHumid.Bad/2021-09-12.log: No such file or directory
Erstelle ich manuell alle Ordner (mkdir -p devices/MQTT2_zigbee_Tuya.Sens.TempHumid.Bad) funktioniert es.
Daher gehe ich mal stark von aus, dass LogFile selber keine Ordner anlegt, oder ich mache etwas richtig falsch in fhem.
Eine Alternative wäre natürlich zB "./log/devices/%NAME-%Y-%m-%d.log", aber das ist nicht viel besser als vorher (nur vom fhem-log getrennt)
Der globale/fhemLog ist "./log/fhem/%Y-%m-%d.log". Da lege ich den Ordner einmal manuell an, und ist gut. Aber das ist ja nur die Ausnahme.
Module Info FileLog:
Version: 0.248490
Release Date: 2021-08-14
(kätzerische) Frage: wozu? ;)
Greifst du wirklich auf Dateisystem-Ebene auf die Logs zu?
Wozu?
Sie sind doch ganz einfach durch das FileLog-Device erreichbar und die kannst du ja ordnen: attr room z.B. :)
Gruß, Joachim
(dickköpfige) Antwort: weil ich das so möchte :P
Klar kann ich das in fhem auslesen. Wenn ich die Syntax nebenbei habe und alles in die kleine Command-Textbox bekomme (oder mit Notepad nebenher arbeite).
Aber was, wenn ich mehrere Dateien gleichzeitig haben will? zB alle zigbee-Geräte im Bad oder Schlafzimmer. Um zb zu sehen, ob es allgemeine Funkstörungen gab, oder ob es am einzelnen Gerät liegt (Position/Marke/etc).
Beispiel: ein einzelner Sensor hat gestern kurzzeitig spontan 6% Akku gehabt (statt >60%) warum weiß ich nicht.
Mit meiner Shell kann ich (durch Vorwissen) gut mit Wildcards und grep/awk arbeiten. Der Unterordner bietet einen "bekannten Trenner". Ich weiß ja nicht, ob ich in Zukunft Geräte habe, die vielleicht "komisch" benannt werden, mit Zahlen im Namen wie etwa Mehrfach-Schalter.
Außerdem lässt es sich so notfalls auch ohne laufendes fhem durchforsten.
Na ja, die Meldung war: Kann nicht da reinschreiben...
Ergo gibt es 3 Möglichkeiten:
1. Das directory gibt es nicht
2. Die Rechte zum Schreiben in das directory passen nicht
3. Die Datei gibt es, aber die Rechte auf die Datei passen nicht.
Wie du festgestellt hast, ist es 1. - das directory erstellt FHEM nämlich nicht implizit & automatisch, das muss der Anwender machen (unter Beachtung von 2.).
Und wo war jetzt die Frage?
Ähmm nicht ganz....
Die Meldung war "No such file or directory" - es kann also nur erstens sein. Bei 2 und 3 würde es a la "permission denied" heißen.
Ich weiß das, da ich viel rumprobiert hab, und es aufgetreten ist. (hab das in Docker laufen - daher sind Permission-Fehler nicht "unüblich")
Aber eine Frage? ich dachte es wäre offensichtlich, aber kein Problem:
Kann "jemand" das in LogFile (oder wo auch immer auf Dateien zugegriffen wird) einbauen, dass er auch Ordner erstellt? a la mkdir -p $(dirname $filePath)
Sowas in der Art kann Perl doch bestimmt auch.
(und dann aber auch so, dass mit einem autocreate möglich ist - falls ein Attribut verwendet werden sollte)
:o Da hast du nun auch wieder recht, die Meldung kommt ja aus der OS-Schicht....
Es sollte ohne weiteres gehen, aus FHEM heraus (z.B. mit '{qx()}' oder mit '"befehl"') auch Verzeichnisse anzulegen, wenn die Berechtigungen passen. Aber selbst wenn man das automatisieren wollte, wären es zwei Vorgänge, einmal das Anlegen (pro directory), und das Anlegen der darin befindlichen Datei, oder? (das erledigt ein "open" vermutlich implizit mit).
Du kannst Rudi gerne einen patch-Vorschlag zukommen lassen, aber ehrlich gesagt ist es m.E. ein Spezialfall, der besser durch den User zu lösen ist, als durch noch eine Option, die kaum einer braucht...
Eine Umsetzung dieses (Automatisierungs-)Wunsches würde der Wildcard-Logik von %L für die Verwendung des globalen Attributes logdir komplett zuwider laufen.
@Beta-User
qx und backticks sind mir bekannt. Aber ich wüsste gerade nicht, wo/wie ich mich ranhängen könnte (zB mit notify), damit man den Namen bekommt, noch bevor autocreate zuschlägt. das "global:defined" wird meines Wissens nach ja nur nach dem erfolgreichen erstellen ausgelöst (was ja durch o.g. Fehler nicht passieren würde).
(ich kann noch mit einem "übrigen" Schalter testen)
@betateilchen
Kannst du das bitte erläutern? Mehr als "wird durch global:logdir ersetzt" erschließt sich mir nicht. Das ist auch der einzige Satz, der dazu in der CommandRef steht (und im Wiki gar nichts). Und warum sollte das nicht funktionieren?
Na ja, was hindert dich daran, die FileLog-Erstellung durch autocreate zu unterbinden und dann auf DEFINED mit eigener Logik zu reagieren?
Ich habe in FileLog vor dem Anlegen der Datei restoreDir_mkDir() aufgerufen (und genauso in OpenLogfile von fhem.pl), ich gehe davon aus, dass es keine negativen Nebenwirkungen hat.
Auch wenn mir z.Zt. nichts einfaellt, wo man das wirklich benoetigen sollte.