FileLog soll regelmäßig Werte auch ohne Event "pollen" - elegante Lösung?

Begonnen von chunter1, 19 Dezember 2019, 13:44:20

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Ich habe die FileLog Attribute addLog und filelog-event-min-interval hinzugefuegt:
ZitataddLog
    This attribute takes a comma-separated list of devspec:reading:maxInterval
    triples.  You may use regular expressions for reading. The last value of
    the reading will be written to the logfile, if after maxInterval seconds
    no event for this device/reading has arrived.

filelog-event-min-interval
    This attribute takes a comma-separated list of devspec:reading:minInterval
    triples.  You may use regular expressions for reading. Events will only be
    generated, if at least minInterval seconds elapsed since the last reading
    of the matched type.

Beta-User

Thx!

@amenomade hatte dankenswerterweise bereits einen Hinweis im Wiki bei Plot-Abriss eingetragen, hab's jetzt noch etwas umstrukturiert.

Dazu eine Frage zur commandref:
Ist "Events will only be generated..." zutreffend? Oder sollte da "logged" stehen?

(Etwas OT: Es hat mich etwas gewundert, dass das Timer-Thema Eingang gefunden hat, nicht aber das Hysterese-Ding aus "event-on-change..", um das Logging ggf. zu reduzieren. Der Grund wäre interessant, oder war's "nur" das Aufwandsthema? (Ist nicht als Kritik gemeint, reines persönliches Interesse, und ich bruache auch nicht unbedingt eine Antwort dazu!))
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatIst "Events will only be generated..." zutreffend? Oder sollte da "logged" stehen?
Natuerlich Letzteres, habs korrigiert.

Wg. event-on-change-:
- insb bei der Kombination dieser Attribute wird es zunehmend kompliziert und Fehleranfaellig.
- ich meine immer noch, dass diese Attribute nicht wirklich notwendig sind. Und bei Weihnachts-Geschenken ist irgendwo Schluss :)

Maista

@rudolfkoenig

Hallo Rudi,

seit dem Update von 92_FileLog.pm am 19.12.19 funktioniert bei mir das Schreiben von Daten in einer bestimmten Konstellation nicht mehr.

Ich hole mir von meiner Fritzbox mit dem Modul FBREMOTE die Pegel des Kabelmodems.
Die stehen in einem Reading ZKanal.
Wenn das gelesen wurde, rufe ich ein Notify auf welches ein myModul aufruft. In diesem generiere ich jeweils neue Readings für das Modul FBREMOTE.

   fhem("setreading FB6490 RxFrequenz $RxFrequenz"); #Reading setzen

Das funktioniert soweit alles.

Wenn nun dieses Reading gesetzt wurde wird das Logfile geschrieben.

Internals:
   CFGFN      /opt/fhem/FHEM/fritzbox.cfg
   DEF        /opt/fhem/log/FileLog_DOCSIS-%Y-%m.log FB6490:RxFrequenz|FB6490:RxPowerLevel|FB6490:RxMSE|FB6490:Rxkorr_Fehler|FB6490:RxNicht_korr_Fehler|FB6490:Frequenz|FB6490:TxFrequenz|FB6490:TxPower_Level
   FD         10
   FUUID      5d99d47f-f33f-e1be-c968-e726c86566fd22fd
   NAME       FileLog_DOCSIS
   NOTIFYDEV  FB6490
   NR         127
   NTFY_ORDER 50-FileLog_DOCSIS
   REGEXP     FB6490:RxFrequenz|FB6490:RxPowerLevel|FB6490:RxMSE|FB6490:Rxkorr_Fehler|FB6490:RxNicht_korr_Fehler|FB6490:Frequenz|FB6490:TxFrequenz|FB6490:TxPower_Level
   STATE      active
   TYPE       FileLog
   currentlogfile /opt/fhem/log/FileLog_DOCSIS-2019-12.log
   logfile    /opt/fhem/log/FileLog_DOCSIS-%Y-%m.log
   READINGS:
     2019-12-24 16:31:43   linesInTheFile  19757
Attributes:
   createGluedFile 1
   room       1Testen,Ereignisse->FB,Logs,System


Seit einem Update am 22.12. wurde das nicht mehr geschrieben.
Ich habe das erst heute bemerkt und einige Zeit damit verbracht und es nicht mehr zum schreiben bewegen können.
Ich hatte auch schon
REGEXP     FB6490:RxFrequenz..*|FB6490:RxPowerLevel..*|FB6490:RxMSE..*|FB6490:Rxkorr_Fehler..*|FB6490:RxNicht_korr_Fehler..*|FB6490:Frequenz..*|FB6490:TxFrequenz..*|FB6490:TxPower_Level..*
probiert, aber half ebenfalls nichts.

Selbst mit der Event-Monitor-Funktion die Defines dazu erzeugt funktionierte es nicht.
Erzeugt wurde hierdurch:
DEF ./log/FB6490_FileLog_1.log FB6490:RxFrequenz:..*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
Was aber zu keinem Eintrag führte.

Der Mittschnitt im Event-Monitor sieht so aus:
Zitat2019-12-24 16:31:43 FBREMOTE FB6490 RxFrequenz: 578 490 522 530 538 546 562 570 474 594 626 642 650 658 666 674 682 690 698 706 746 754 762 770
2019-12-24 16:31:43 FBREMOTE FB6490 RxPowerLevel: 5.9 8.4 6.6 6.2 5.6 5.7 5.8 5.8 8.9 6.7 8.1 8.7 9.0 9.2 8.9 8.9 8.9 8.7 8.7 8.7 8.2 7.2 7.3 6.4
2019-12-24 16:31:43 FBREMOTE FB6490 RxMSE: -37.4 -37.4 -37.4 -37.4 -36.6 -36.6 -37.4 -37.4 -39.0 -37.6 -38.6 -39.0 -38.6 -38.6 -39.0 -37.6 -38.6 -38.6 -38.6 -38.6 -37.6 -37.6 -37.6 -37.4
2019-12-24 16:31:43 FBREMOTE FB6490 Rxkorr_Fehler: 22098 189 130696 370 536 588 516 390 184 176 101 110 126 115 151 93 99 69 87 86 95 92 104 130
2019-12-24 16:31:43 FBREMOTE FB6490 RxNicht_korr_Fehler: 0 0 0 0 102 0 0 0 0 0 0 0 95 0 99 0 96 0 409 0 0 0 0 0
2019-12-24 16:31:43 FBREMOTE FB6490 TxFrequenz: 45.2 58.4 51.8 30.8 37.4
2019-12-24 16:31:43 FBREMOTE FB6490 TxPower_Level: 41.8 41.0 41.3 42.8 43.2

Mit der Datei von
Zitat# $Id: 92_FileLog.pm 20537 2019-11-18 21:28:30Z rudolfkoenig $
funktioniert es wieder.

Muss hier nun ein Attribut gesetzt werden oder ist das ein Bug?

Allen ein schönes Fest

Danke und Gruss
Gerd

rudolfkoenig

ZitatREGEXP     FB6490:RxFrequenz|FB6490:RxPowerLevel|FB6490:RxMSE|FB6490:Rxkorr_Fehler|FB6490:RxNicht_korr_Fehler|FB6490:Frequenz|FB6490:TxFrequenz|FB6490:TxPower_Level
Achtung: dein Regexp wird in FileLog (und notify/etc) mit ^FB6490:RxFrequenz|...|FB6490:TxPower_Level$ geprueft, das ist vmtl. nicht das, was du willst.
Ich schlage als FileLog REGEXP (FB6490:RxFrequenz|...|FB6490:TxPower_Level) vor.

ZitatSeit einem Update am 22.12. wurde das nicht mehr geschrieben.
Mag sein, ich kann das aber nicht nachvollziehen: mit der gezeigten FileLog Definition landen die setreading Daten aus dem angehaengten Event-Monitor Ausschnitt bei mir in der FileLog-Datei. Vermutlich fehlt mir noch ein Detail.

ZitatDEF   ./log/FB6490_FileLog_1.log FB6490:RxFrequenz:..*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
Das ist ja haesslich, das habe ich jetzt etwas verschoenert.

Maista

Hallo Rudi,

danke für die Antwort.
Ich war gerade dabei zu schreiben das ich das Problem nun gefunden habe.

In meinem MyModul hatte ich die Readings (und fünf weitere) als Beispiel mit
   fhem("setreading FB6490 RxFrequenz $RxFrequenz");
gesetzt.

Mit dem alten 92_FileLog.pm funktionierte es bis vorhin wieder. Ich hatte aber das Moduls mit Komma anstatt mit Leerzeichen in den Globals als  Exclude stehen.
Dadurch wurde das alte Modul durch das neue beim Update wieder überschrieben.
Nach dem ich das alte wieder aufgespielt hatte wollte das setzten dann auch nicht mehr Funktionieren ::) :o

Schlussendlich habe ich dann die Commandref bemüht.
In der steht zu setreading:
ZitatNote: setreading won't generate an event for device X, if it is called from a notify for device X. Use "sleep 0.1; setreading X Y Z" in this case.

In meinem myModul setze ich nun die Readings mit
   fhem("sleep 0.1;setreading FB6490 RxFrequenz $RxFrequenz");
und nun wird das Reading wieder geschrieben!
Auch mit der neuen 92_FileLog.pm vom 22.12.19!

Das RegEx habe ich nun auch einfach gekürzt
FB6490:Rx.*|FB6490:Tx.*

Funktioniert also. Ist das eventl. ein Zeitproblem gewesen?

ZitatDas ist ja haesslich, das habe ich jetzt etwas verschoenert.
Ok ;)

Danke für deine Info.

Eventl. probiere ich ob es mit deinem Vorschlag auch funktioniert.
Warum das bis zum 22.12 funktioniert hatte ist mir ein Rätsel.

Wenn nötig kann ich dir weitere Daten zu kommen lassen.

Dir noch schöne Feiertage

Gruss Gerd

M.Piet

Moin,
ich grab das Thema mal aus, da ich genau dazu ein Problem habe.

Mein Filelog funktioniert und schreibt in dem Format (Wert ist nur 0 oder 1, ich visualisiere damit, wann der Solarregler vom Pool an war):

024-07-06_10:55:25 DummyLogSolar 1
2024-07-06_20:30:17 DummyLogSolar 0
2024-07-07_10:01:55 DummyLogSolar 1
2024-07-07_20:30:17 DummyLogSolar 0
2024-07-08_10:01:55 DummyLogSolar 1

Damit der Plot sauber aussieht, möchte ich alle 5 Minuten einen neuen Wert Wert  im Log haben.
   
Dazu habe ich im Filelog das Attribut DummyLogSolar:state:60 gesetzt.

Nun schreibt mir aber das Attribut den Text "state" mit rein:

2024-07-07_20:30:17 DummyLogSolar 0
2024-07-08_10:01:55 DummyLogSolar 1
2024-07-08_20:30:17 DummyLogSolar 0
2024-07-09_10:01:55 DummyLogSolar 1
2024-07-09_15:37:37 DummyLogSolar state: 1
2024-07-09_15:37:38 DummyLogSolar state: 1
2024-07-09_15:37:39 DummyLogSolar state: 1


Ich habe nun schon einiges ausprobiert und gefühlt alle Postings zu dem Thema "addLog" gelesen.
Jemand eine Idee, wie ich verhindere, dass "state" mit im Log steht?
Danke schön.


betateilchen

Zitat von: M.Piet am 10 Juli 2024, 07:48:23ich grab das Thema mal aus, da ich genau dazu ein Problem habe.

Nach fast 5 Jahren macht sowas keinen Sinn. Es kann sich in einem so langen Zeitraum durchaus einiges in der Handhabung der betroffenen Module geändert haben. So auch hier: das Attribut addLog existiert erst seit August 2020.

Bei Verwendung des Attributes addLog wird immer der angegebene readingName mit ins Log geschrieben.
Works as designed.

Wenn Du das anders haben möchtest, musst Du Dir einen anderen Lösungsweg suchen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

gichtl

Wozu braucht mach diese redundanten Log-Einträge im Filelog? Meines Wissens doch nur um Log-Abrisse zu vermeiden.

Den kann man beim Tagesplot durch zwei AddLogs um 23:59:59 und um 00:00:00 Uhr umgehen, aber für die nächste Zoomstufe bräuchte man weitere AddLogs um 05:59:59/06:00:00, 11:59:59/12:00:00 sowie 17:59:59:00/18:00:00. Und beim Zoom auf die Stunde insgesamt 48 Addlogs pro Tag - und das für jedes mögliche Reading. Dadurch bläht man sich natürlich das Log mächtig auf, auch wenn man nur 3x im Jahr tatsächlich bei irgendeinem Ereignis nachträglich im Log analysieren möchte. Die Umsetzung von addLog ist jedoch einwandfrei und ermöglicht durch das Anhängsel " << addLog" die Unterscheidung zu echten Events. Und damit kann man die Logs auch nachträglich wieder verdichten.

Das eigentliche "Problem" beim Plot ist daß aus dem Filekog ausschließlich der Plot-Anzeigezeitraum herangezogen wird.
Eine schöne Erweiterung wäre wenn auch die komplette Vorgeschichte aus dem Log verarbeitet werden würde und davon der letzte Wert im Diagramm geplottet wird. Analog natürlich für den Rest vom Logfile bis zum nächsten Auftreffen des Readings.
Natürlich ist das nicht ganz trivial, und man kann die Plot-Linie nicht einfach durchzeichnen sondern muß die entsprechend der Diagrammfläche passend beschneiden wenn der letzte Eintrag um 23 Uhr und der nächste um 1 Uhr war.

Im Prinzip ist das mit LogProxy und der Option extend=31622400 (=60*60*24*366) möglich. Damit hätte man ein für allemal die Plot-Abrisse behoben und kann sich addLog sparen.

betateilchen

Zitat von: gichtl am 11 Juli 2024, 12:08:30Wozu braucht mach diese redundanten Log-Einträge im Filelog?

Wozu braucht man FileLog, wenn es doch DbLog gibt?

Prinzipiell hast Du recht, man kann die Aufgabe auch ohne addLog lösen.
Aber diese Diskussion ist müssig.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

gichtl

Mit DbLog steht man vor genau dem gleichen Problem mit dem Plot-Abriß. Man hat jedoch den Nachteil daß man die AddLogs nicht mehr so einfach los wird wenn man die redundanten Daten zu einem späteren Zeitpunkt verdichten möchte. Beim fileLog hingegen genügt ein
sed -i '/<< addLog/d' *.logum den Spuk zu beenden.

Gerade wenn dir die Diskussion müßig erscheint, warum beteiligst du dich dann an ihr und bringst gar noch die Grundsatzdiskussion über FileLog und DbLog mit ein?

betateilchen

Zitat von: gichtl am 12 Juli 2024, 14:53:42Mit DbLog steht man vor genau dem gleichen Problem mit dem Plot-Abriß. Man hat jedoch den Nachteil daß man die AddLogs nicht mehr so einfach los wird wenn man die redundanten Daten zu einem späteren Zeitpunkt verdichten möchte.

Du meinst diesen Unfug ernst, oder?

Ich geh mal Popcorn holen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

gichtl

Zitat von: betateilchen am 12 Juli 2024, 19:37:13Du meinst diesen Unfug ernst, oder?

Ich geh mal Popcorn holen.

Danke für deinen konstruktiven und überaus hilfreichen Beitrag der eine unbezahlbare Bereicherung hier im Forum darstellt. Was wäre das Forum nur ohne dich und deine selbstlose und überaus wertvollen Unterstützung!

M.Piet

Hallo Zusammen,

da habe ich ja was losgetreten...
trotzdem möchte ich dazu was sagen, auch wenn der Umgangston hier grad sehr komisch war.

Zitat von: betateilchen am 10 Juli 2024, 11:00:24Works as designed.
Ich frage mich grad, wofür es dann designed wurde?

Ich habe es so verstanden, dass dies dafür sorgen soll, dass nach Zeit X der Logeintrag erneuert wird, damit der Plot sauber aussieht.
Das kann er aber nicht, weil addLog einen anderen Wert ins Logs schreibt, als das Log selbst.

2024-07-09_10:01:55 DummyLogSolar 1
2024-07-09_15:37:37 DummyLogSolar state: 1

Somit kann das Ziel nicht erreicht werden, dass der Plot sauber aussieht, weil addLog es ,,anders" ins Log schreib.
Darum die Frage, wofür es dann designed wurde?


gichtl

ZitatSomit kann das Ziel nicht erreicht werden, dass der Plot sauber aussieht, weil addLog es ,,anders" ins Log schreib.
Darum die Frage, wofür es dann designed wurde?

addLog sorg dafür daß der aktuelle Wert genau so (ergänzt um << addLog) ins Log/DbLog geschrieben wird wie die regulären Log-Einträge:
2024-01-01_19:26:27 T.Keller T: 9.3 H: 79
2024-01-01_23:59:59 T.Keller T: 9.3 H: 79   << addLog
2024-01-02_00:00:00 T.Keller T: 9.3 H: 79   << addLog
2024-01-02_00:01:20 T.Keller T: 9.2 H: 78

Um Plot-Abrisse zu vermeiden läßt sich alternativ die extend-Option vom LogProxy verwenden:
Zitatextend=<wert>
Erweitert den aus dem log device abgefragten Bereich am Anfang und am Ende um <wert> Sekunden (oder um <wert> Monate wenn <wert> mit einem m endet)

Wenn also der Logeintrag mindestens einmal täglich geschrieben wird, dann kann man extend=86400 eintragen und LogProxy schaut genau einen Tag vor und zurück und vermeidet ohne redundante AddLog-Einträge auch so Plot-Abrisse.