Hallo zusammen,
ich finde keine Lösung zu meiner Frage, wie ich die Häufigkeit der Einträge eines FileLog-Devices beeinflussen kann.
Sprich, das Gerät, z.B. ein Raumsensor, sendet im Minutentakt einen aktualisierten Wert, welchen das FileLog-Dev auch prima mitloggt. Aber es wäre völlig ausreichend, wenn dieser Wert z.B. lediglich alle 60 Minuten in das Logfile geschrieben würde.
Das Attribut "event-min-intervall" passt hier nicht so richtig, da ich erstens das Gerät und weniger das FileLog damit beeinflusse und zweitens - falls ich es nutze - meine Echtzeitanzeige auf der Tablet UI auch nur noch alle 60 Minuten aktualisiert würde...
Gibts da einen Trick?
Im speziellen wüsste ich nichts, du könntest aber mit Event-on-change zumindest nur dann loggen, wenn der Wert sich ändert.
Gesendet von iPhone mit Tapatalk
Hm, was wäre mit einem Workaround ? Ich stecke in Linux / FHEM einfach nicht gut genug drin.
Ich stelle mir z.B. ein Dummy-Device vor, welches den Parameter - hier des eigentlichen Raumsensor-Device in einem frei konfigurierbaren Zyklus (= konkret alle 10 Minuten z.B.) abruft. Dieses Dummy-Device könnte ich dann alternativ per FileLog protokollieren und hätte "ab Werk" exakt alle 10 Minuten einen Protokolleintrag.
MMn. sollte man diese Art der "Verbesserung" der Datenbasis lassen. Das führt nur irgendwann zu Problemen, weil man das vergißt und irgendwann nicht mehr mit den Ausgangsdaten arbeitet.
Warum baust du keine Hysterese (threshold) in deine Events am Device ein und gut ist? Ich finde es ok, wenn dann viele Werte kommen, wenn sich auch (ernsthaft) was ändert. Kannst du immer noch mit min-interval ergänzen: https://wiki.fhem.de/wiki/Event-on-change-reading#Wechselwirkungen. So siehst du in Plots auch noch Zusammenhänge mit anderen Events (Fenster-offen), die sonst ggf. "verwaschen".
Tendenziell solltes du davon ausgehen, dass es für Standardprobleme auch bereits eine Lösung gibt und die Energie darauf verwenden, diese zu suchen, statt was neues eigenes zu bauen.
Just my2ct.
Beta-User
Du könntest auf dblog umstellen, da bist Du flexibler.
Ja wobei die Ausgangslage gut analysiert ist.
Geht leider nicht out of the Box und die Idee ist schon richtig. bisher hat keiner (ich schließe mich ein) die Zeit gefunden dass umzusetzen.
Was du machen kannst:
Erstelle einen Dummy.
Dort richtest du User Reading für die Werte ein die dich interessieren.
Dort die event-on... Und das loggen.
Dann hast du beides (das device mit hoher Auflösung und den Dummy zum loggen)
Zitat von: Beta-User am 16 Dezember 2019, 15:13:32
Tendenziell solltes du davon ausgehen, dass es für Standardprobleme auch bereits eine Lösung gibt und die Energie darauf verwenden, diese zu suchen, statt was neues eigenes zu bauen.
Das versuche ich. Meine simpelsten Problemchen sind sicherlich schon 100fach diskutiert und gelöst worden. Sehr viele Fragen konnte ich mir mit Hilfe der Suchfunktion schon selbst beantworten.
Allerdings ist dieses Forum so gigantisch groß und er Content letztlich sehr komplex, dass ich mit meinen beschränkten Fähigkeiten häufig die Zusammenhänge nicht mehr begreife. Das betrifft primär die Abwandlung von gefundenen Codeschnipseln z.B. :-\
Zitat von: Beta-User am 16 Dezember 2019, 15:13:32
MMn. sollte man diese Art der "Verbesserung" der Datenbasis lassen. Das führt nur irgendwann zu Problemen, weil man das vergißt und irgendwann nicht mehr mit den Ausgangsdaten arbeitet.
Das hatte ich anderweitig, ich glaube sogar auch von Dir, bereits gelesen. Deswegen möchte ich eigentlich vermeiden mit event-min-intervall im "echten" Sensor-Device etwas zu modifizieren, was ich in einem anderen FileLog-Device bräuchte. Daher dieser Thread :D
Zitat von: Beta-User am 16 Dezember 2019, 15:13:32
Warum baust du keine Hysterese (threshold) in deine Events am Device ein und gut ist? Ich finde es ok, wenn dann viele Werte kommen...
Der Hintergrund meiner Versuche ist es, die Schreibzugriffe auf die SD-Karte nach Möglichkeit zu reduzieren. Hier im Beispiel beim Raumtemperaturfühler benötige ich keine Protokollierung im 60-Sekunden Takt, da dies Protokoll lediglich Basis für ein Chart in Touch UI ist. Theoretisch würde es ausreichen alle 15 Minuten einen Eintrag dafür zu generieren.
Nur soll weiterhin der aktuelle Istwert des 1Wire Sensors minütlich aktualisiert ebenfalls in Touch UI dargestellt bleiben unabhängig vom Chart.
edit:
Hupsala, die weiteren Postings habe ich erst jetzt gesehen.
Okay, Dummy erstellen, user reading einrcihten und event-on konfigurieren.
Habe heute abend damit erstmal Grundlagen zu recherchieren :-)
schaun wir mal, wo ich rauskommen werde.
Das filelog auf die System SD Karte zu schreiben ist sehr gefährlich. Du solltest dafür einen separaten USB Stick oder ein nfs share auf einem NAS nutzen. Ich habe schon ohne filelog 2 SD Karten ,,verheizt" seitdem nutze Ich dblog auf einer externen mariadb und erstelle jede Nacht ein Backup des kompletten opt Verzeichnisses auf ein externes Share.
Gesendet von iPhone mit Tapatalk
Mein Kommentar war auch nicht negativ gemeint (sonst hätte ich den Link zu weiterführenden Infos weggelassen und nur rtfm gemurmelt...), das Problem (von der theoretischen Seite her) kann ich durchaus nachvollziehen (einschl. der Furcht vor SD-Karten-Schredderei, die mich selbst auch letztlich zu anderer Hardware getrieben hat...).
@Waldmensch:
Da hat Wernieman in dem anderen Thread aber auch was dazu geschrieben von wegen: Wenn sich der Stick weghängt, geht auch nichts mehr... Und ein NAS hat auch nicht jeder.
(Ich kann das alles nur bedingt verifizieren, aber im Ergebnis scheint es mir so zu sein, dass die Empfehlung für Leute, die "nur wegen ein bißchen Hausautomatisierung" nicht gleich eine komplette IT-Infrastruktur aufbauen wollen, wohl sein sollte: nimm was anderes wie einen Pi (irgendwas, das ein vernünftiges wear-leveling für seine Haupt-Datenträger kann)... oder mach jedenfalls häufig ein Backup und übe, das bei Bedarf dann auch schnell zu nutzen!)
@herrmannj:
Vielleicht sollte man Rudi vorschlagen, (inhaltlich) genau diese "event-on.."-Attribute auch bei FileLog-Geräten setzen zu können?
Ich bin allerdings insgesamt noch nicht überzeugt, ob das Grundproblem wirklich außerhalb der Theorie ernsthaft besteht. Entweder eine Änderung ist relevant, dann macht es mMn. tendenziell auch Sinn sie zu protokollieren (wenn überhaupt, aber das ist eine andere Frage), oder eben nicht. Damit ist die Anzeige - wo auch immer - immer noch genau genug, und ob ein Problem vorliegt (Sensor ausgefallen?) sollte man ggf. am timestamp erkennen können (ungeprüft, aber soweit ich das im Kopf habe).
Zitat von: Dracolein am 16 Dezember 2019, 15:27:24
Deswegen möchte ich eigentlich vermeiden mit event-min-intervall im "echten" Sensor-Device etwas zu modifizieren, was ich in einem anderen FileLog-Device bräuchte.
Sorry, aber das verstehe ich nicht. Du loggst doch hoffentlich nicht Daten doppelt? (Man kann mit SVG dann durchaus Daten aus mehreren LogFiles mischen und in einem Graphen darstellen!)
Wenn es so gemeint war, dass du die Echtdatenänderung brauchst, um darauf zu reagieren (mit was anderem als FileLog), ist es m.E. eher eine Frage der Festlegung der Hysterese. Meistens ist sowieso schon der Meßwert/bzw. der Sensor nicht kalibriert (aber genau genug), so dass auch entsprechende Grenzwertfestlegungen (z.B. für ein THRESHOLD-Device) eben "relativ" sind.
Zitat von: Waldmensch am 16 Dezember 2019, 15:54:01
Das filelog auf die System SD Karte zu schreiben ist sehr gefährlich. Du solltest dafür einen separaten USB Stick oder ein nfs share auf einem NAS nutzen. Ich habe schon ohne filelog 2 SD Karten ,,verheizt" seitdem nutze Ich dblog auf einer externen mariadb und erstelle jede Nacht ein Backup des kompletten opt Verzeichnisses auf ein externes Share.
Gesendet von iPhone mit Tapatalk
Deswegen diskutieren wir gerade parallel hier:
https://forum.fhem.de/index.php/topic,106343.0.html
8)
edit:
Zitat von: Beta-User am 16 Dezember 2019, 16:08:12
Sorry, aber das verstehe ich nicht. Du loggst doch hoffentlich nicht Daten doppelt? (Man kann mit SVG dann durchaus Daten aus mehreren LogFiles mischen und in einem Graphen darstellen!)
Also um es plastisch zu machen - mit der Bitte um Verständnis für mein Anfängerlevel:
Ich habe per GPIO4 einen 1Wire Temperatursensor angeschlossen und in FHEM eingebunden, welcher mir derzeit mittels Attribut "pollinginterval" alle 60 Sekunden einen Wert ausgibt. Selbigen Wert habe ich in meiner Touch UI als "aktuelle Raumtemperatur" dargestellt.
Nun war mein Wunsch, diese Temperatur grafisch über den Tag darzustellen in einem Chart, was prinzipiell auch schon gut funktioniert.
Allerdings halt mit der Thematik, dass es mir alle 60 Sekunden einen Wert ins Log schreibt.
Ein SVG-Chart habe ich dafür nie definiert in FHEM. Ich nutze ein FileLog und das FTUI-Modul "Chart" zur grafischen Darstellung.
Mein "Problem" besteht lediglich darin, weiterhin aktuelle Raumtemperaturen angezeigt zu bekommen, die nicht 10 oder 15 Minuten alt sind und gleichzeitig die FileLog-Einträge auf das nötigste zu reduzieren.
Ebend: Die Frage ist, was die aktuelle Raumtemperatur ist ;) .
Setzt du eine Hysterese von 0.2°C auf den Wert, ist er mMn. immer noch "aktuell", solange er sich innerhalb der Bandbreite bewegtt. Also sagen wir as Beispiel: Messung beginnt bei 22.0°C. Dann wird ggf. erst ein Event erzeugt, wenn 22.21°C sind (oder 21.7999°C). Mir reicht es zu wissen, dass es "um die 22°C" hat; wie lange das schon der Fall ist, ist mir eigentlich nicht so wichtig, solange es sich nicht wesentlich ändert, das ist mir "aktuell" genug... Dazu alle Stunde ein "Zwangsupdate", damit es keine Abrisse in plots gibt und leichter geprüft werden kann, dass der Sensor nicht "weg" ist.
Die DS18B20 haben übrigens auch eine Toleranz von 0.5°C (?), und sind zwar "genau", aber eben mit dieser "Normalverschiebung", die sich aus der Grundtoleranz ergibt (ich messe - über einen MySensors-Arduino - in der Regel sowieso nur 1/4 Grad genau, dann geht das auch wesentlich schneller). (Und GPIO-Nutzug am PI ist auch so ein Thema, das ich persönlich als nogo ansehe (schon klar, dass man auch darüber lange diskutieren kann)...)
ZitatIm speziellen wüsste ich nichts, du könntest aber mit Event-on-change zumindest nur dann loggen, wenn der Wert sich ändert.
Ist doch eigentlich ganz easy mit Bordmittelbn zu bewerkstelligen:
Ein statistics-Device, attr singularreadings setzen und einfach dann den
statTemperatureHourLastloggen :D
lg, Stefan
Zitat@herrmannj:
Vielleicht sollte man Rudi vorschlagen, (inhaltlich) genau diese "event-on.."-Attribute auch bei FileLog-Geräten setzen zu können?
Ja, wobei es auch fair wäre gleich den passenden Patch zu liefern... Zeitfrage halt ..
Zitat von: Icinger am 16 Dezember 2019, 16:51:15
Ist doch eigentlich ganz easy mit Bordmittelbn zu bewerkstelligen:
Ein statistics-Device, attr singularreadings setzen und einfach dann den
statTemperatureHourLast
loggen :D
lg, Stefan
Hi Stefan,
ich habe mir den Wiki Eintrag zum statistics Device durchgelesen und etwas herumprobiert, aber ich verstehe nicht ganz, was ich tue.
define StatistikDevice statistics 1wire_Temp1bringt mir ein statistics-Device und zusätzlich in meinem Raumsensor-Device, namentlich 1wire_Temp1, 3 neue Readings, dessen Bezeichnung (stat[...|day / ... month / year... oder so) mir komisch erscheinen. Zuletzt fehlt mir das Verständnis, wie ich einem erstellten Reading sage, was es denn überhaupt darstellen soll.
Nachdem ich das StatistikDevice zunächst wieder gelöscht hatte, waren die neu erstellen Readings im 1wire_Temp1 geblieben; ich löschte sie manuell erstmal wieder.
Zitat von: Beta-User am 16 Dezember 2019, 16:45:24
Ebend: Die Frage ist, was die aktuelle Raumtemperatur ist ;) .
Setzt du eine Hysterese von 0.2°C auf den Wert, ist er mMn. immer noch "aktuell", solange er sich innerhalb der Bandbreite bewegtt. Also sagen wir as Beispiel: Messung beginnt bei 22.0°C. Dann wird ggf. erst ein Event erzeugt, wenn 22.21°C sind (oder 21.7999°C). Mir reicht es zu wissen, dass es "um die 22°C" hat; wie lange das schon der Fall ist, ist mir eigentlich nicht so wichtig, solange es sich nicht wesentlich ändert, das ist mir "aktuell" genug... Dazu alle Stunde ein "Zwangsupdate", damit es keine Abrisse in plots gibt und leichter geprüft werden kann, dass der Sensor nicht "weg" ist.
Inhaltlich bin ich bei Dir, das würde völlig ausreichen. Selbst 0,5°C als Hysterese wären ausreichend, stimmt. Auch für diese Lösung fehlt mir das Verständnis für die technische Umsetzung in FHEM. Braucht es dazu das THRESHOLD-Modul oder lässt es sich mithilfe eines Attributs im Device lösen?
list 1wire_Temp1:
Internals:
DEF 28-0114504011aa
FUUID 5ddff6c1-f33f-4dec-8c3d-60f53c43981b8e6e
NAME 1wire_Temp1
NR 27
NTFY_ORDER 50-1wire_Temp1
STATE T: 24.25
TYPE GPIO4
OLDREADINGS:
READINGS:
2019-12-16 07:19:39 failures 0
2019-12-16 18:58:01 state T: 24.25
2019-12-16 18:58:01 temperature 24.25
fhem:
interfaces temperature
helper:
_98_statistics StatistikDevice
Attributes:
DbLogExclude .*
alias RaumtempEG
pollingInterval 300
room Homekit,Sensoren
Und ja, 24°C sind gerade richtig, ich habe den Kamin an 8). Der läuft "zu Glück" auch ohne Pearl- und FHEM-Kenntnisse ;D
So schwer ist das doch nicht, wenn man den Schlüsselworten folgt :o .
Versuch's mal mit
attr 1wire_Temp1 event-on-change-reading temperature:0.2
event-min-interval bekommst du selbst hin, oder?
@hermannj:
Bin selbst auf DBLog, von daher ist das mit LogFile nicht meine Baustelle, zumal Rudi gerne nachhakt, welches Problem denn mit einem patch gelöst werden soll. Hier m.E. mal wieder: keines...
Und das mit statistics kommt "in den Hinterkopf", das würde auch bei DBLog helfen.
(Irgendwie habe ich es immer geschafft, mich um das Ding rumzudrücken; vermutlich fehlt mir eine Art Musterlösung für ein paar Standardfälle (ich habe aber auch noch nicht intensiv danach gesucht).
Zitat von: Beta-User am 16 Dezember 2019, 19:41:26
So schwer ist das doch nicht, wenn man den Schlüsselworten folgt :o .
Versuch's mal mit
attr 1wire_Temp1 event-on-change-reading temperature:0.2
event-min-interval bekommst du selbst hin, oder?
Zitat von: Beta-User am 16 Dezember 2019, 19:41:26
So schwer ist das doch nicht
Für Euch Pro´s ist das killefitz, für mich Newbie ist das high-end. Aber primär deswegen, weil ich mit aller Macht versuchen will zu verstehen, was ich da mache. Copy & paste bringt mir nur kurzfristig Hilfe.
Vorab: danke für Deine Hilfe!
event-min-interval stellt keine Herausforderung dar, dessen Syntax und Funktion habe ich begriffen. Auch die Kombination beider Attribute ist eine rückwirkend logische Idee, die Du dargestellt hast.
Nochmal in Zusammenfassung für mich selbst:
mit event-on-change-reading temperature:0.2 prüft das System permanent, ob eine Abweichung von 0,2°C zum aktuellen Messwert vorliegt und schreibt erst bei Überschreiten selbiger den neuen Messwert in das Reading "temperature".
PollingIntervall 300 ergibt einen Mindest"abstand" von 5 Minuten zwischen zwei Sensorabfragen.
Gleichzeitig wird zusätzlich mittels "event-min-interval 3600" 1x stündlich ein Logeintrag unabhängig von obigem Attribut erzwungen.
D.h. mein Logfile wird mindestens 1 Eintrag pro Stunde, maximal 20 Einträge pro Stunde enthalten. Letzteres müsste voraussetzen, dass alle 5 Minuten der Messwert um mindestens 0,2°C im Vergleich zum vorherigen Wert abweicht.
Mit der Bitte um Bestätigung oder Korrektur 8)
Mein Bier ist leer, gibts dafür auch ein FHEM-Modul? ...
Fast: Die Hysterese ist die Abweichung zum vorherigen letzten Wert, der ein event ausgelöst hatte... Da können einige Aktualisierungen dazwischen sein ;) .
(Sonst würde bei schleichenden Änderungen zu spät/nie ein Event ausgelöst.)
(Und deine Darstellung entspricht fast dem, was jemand anderes in den im Wiki verlinkten Beiträgen als Zusammenfassung geschrieben hatte).
Der Punkt ist der: Bei keinem von uns ist das vom Himmel gefallen. Was mich etwas gewundert hatte, war, dass du offenkundig den Wiki-Artikel und die cref zu event-on... nicht schlicht mal angesehen zu haben scheinst. Damit (will sagen: mit diesem Eindruck, kann durchaus sein, dass das anders war, nur habe jedenfalls ich nichts davon gemerkt) machst du dir auf Dauer die Helfer kaputt...
Jedenfalls bei mir ist es so, dass ich viel gelesen und ausprobiert habe und darüber nachgedacht. Ist nicht immer der schnellste Weg, aber heute merke ich oft, das das hilfreich war (wenn auch mit einigen Umwegen).
Zitat von: Beta-User am 16 Dezember 2019, 20:18:11
Was mich etwas gewundert hatte, war, dass du offenkundig den Wiki-Artikel und die cref zu event-on... nicht schlicht mal angesehen zu haben scheinst. Damit (will sagen: mit diesem Eindruck, kann durchaus sein, dass das anders war, nur habe jedenfalls ich nichts davon gemerkt) machst du dir auf Dauer die Helfer kaputt...
Dem möchte ich der Vollständigkeit halber klar widersprechen :) da ich mehrere Versuche erfolglos getestet hatte. Es lag letztlich an meiner falschen Syntax. Ich hatte aus dem Wiki-Beispiel die eckigen Klammern übernommen UND bei der Temperatur anstelle eines Punktes ein Komma (0,2) verwendet.
Die Tipperei hier kostet mich mehr Zeit, als einzelne Versuche mit try&error, soviel zu meiner Verteidigung. ;)
Nochmals Danke und mit der Bitte um Nachsicht.
Kein Ding... ;D
Was wichtiges gelernt: Eckige Klammern stehen für optionale Angaben, sind dann wegzulassen, wenn man die Option nutzt.
Und das mit dem Punkt wird dir auf andere Weise noch mehrfach über den Weg laufen ;D ;D ;D .
@dracolein ... !!! Achtung !!!
Diese, deine Aussage
Zitat
Gleichzeitig wird zusätzlich mittels "event-min-interval 3600" 1x stündlich ein Logeintrag unabhängig von obigem Attribut erzwungen.
ist grundlegend falsch.
Das Attribut event-min-interval erzwingt nichts !! sondern vielmehr ... ich zitiere:
Zitat
Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind
Das heißt es können auch 3 Stunden vergangen sein.
Wenn du etwas erzwingen willst, nutze addLog entweder direkt eingebaut in DbLog oder als separaten Befehl wie z.B. im Wiki beschrieben: https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden
Ich möchte nur vermeiden, dass sich gleich zu Anfang etwas im Kopf falsch festsetzt ;)
Grüße,
Heiko
Danke für die Klarstellung. Hier ist das kein größeres Problem (jedenfalls, solange der Sensor was liefert), da dieser alle 5 Min abgefragt wird. Spätestens nach 20 Min. landet also was im Log.
Danke für den Hinweis, ich frage zum Thema addlog nochmal zum Verständnis nach:
Zitat
Internals:
CFGFN
COMMAND {addLog("1wire_Temp1","temperature")}
DEF +*01:00 {addLog("1wire_Temp1","temperature")}
FUUID 5df8bfe2-f33f-4dec-2b35-9214e90eb1be18d2
NAME add_Logentry1
NR 358
NTM 13:47:20
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 13:47:20
TIMESPEC 01:00
TRIGGERTIME 1576586840.50867
TRIGGERTIME_FMT 2019-12-17 13:47:20
TYPE at
READINGS:
2019-12-17 12:47:20 state Next: 13:47:20
Attributes:
room Logfiles
Habe das obige mit
define add_Logentry1 at +*01:00 {addLog("1wire_Temp1","temperature")}angelegt. Im Reading sehe ich brav den nächsten geplanten Event in knapp einer Stunde. Im Code habe ich dem addLog-Befehl mitgeteilt, welches Device mit welchem Reading es in ein Log eintragen soll. Sprich, Zeit und Inhalt sind definiert. Aber woher weiß "addLog" in welches Logfile der Eintrag geschrieben werden soll ? (Das FileLog-Device "Log_RaumtempEG" existiert bereits). Der Zusammenhang ist mir unklar, ich hätte nun erwartet, dass in obiger Konfiguration dazu Bezug genommen werden muss.
Zitat von: Dracolein am 17 Dezember 2019, 12:56:25
Danke für den Hinweis, ich frage zum Thema addlog nochmal zum Verständnis nach:
addlog ist ein set Befehl für ein dblog device.
falls alsi deine Log-Datenbank z.B. "logDB" benannt ist machst Du so einen Logeintrag:
(set logDB addLog 1wire_Temp1:temperature)falls Du über DbLogExclude das reading "temperature" ausgenommen hast muss noch ein " !useExcludes" an den Befehl dran.
Aha, das war mir so nicht klar. Danke.
@Frank_Huber: Er bezieht sich mit einiger Wahrscheinlichkeit auf https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden#Implementierung...
Das at löst einen trigger-Befehl aus. Schau bitte in der commandref mal nach "trigger". (Auch FileLog ist nur ein Eventhandler...)
(Nur für Plots gab's übrigens auch noch logproxy: https://wiki.fhem.de/wiki/LogProxy#M.C3.B6gliche_.3Coptions.3E, und für statistische Zwecke braucht man uU. tatsächlich aufbereitete Werte, die liefert aber z.b. das Modul statistics => Ich komme zurück auf das, was ich zuvor schon zu "aufbereiteten" Werten geschrieben hatte: man braucht sowas in der Regel eher nicht bzw. sollte sich genau überlegen, warum man etwas braucht...)
Zitat von: Beta-User am 17 Dezember 2019, 13:11:45
@Frank_Huber: Er bezieht sich mit einiger Wahrscheinlichkeit auf https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden#Implementierung...
Danke! Das ist mir neu.
d.h. damit kann man
nach Anlegen der Sub in der myUtils in jedes Log-Device (auch FileLog) einen Eintrag erzwingen.
Ja.
Nur (wie gesagt): Mit LogProxy kann man (im Prinzip) dasselbe erreichen, ohne die Nebenwirkung, dass auch alle anderen Eventhandler ein (unnötiges) Event bekommen...
LogProxy funktioniert auch mit beiden Logging-Varianten (FileLog und DBLog).
(Wenn man nicht SVG iVm. DBLog nutzt, hat man vermutlich noch mehr Optionen, aber z.B. mit Grafana, das scheinbar sehr gut ist, kenne ich mich nicht aus).
Um es abzukürzen, wenn ich das hier ( https://forum.fhem.de/index.php/topic,106343.msg1002644.html#msg1002644 ) gelöst habe, erübrigt sich die gesamte Mühe dieses Threads.
Aber dafür muss ich heute abend erst ein Backup laufen lassen, bevor ich herumprobiere.