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

chunter1

FileLog schreibt ja nur Werte, wenn ein entsprechendes Event auftritt.
Gibt es eine elegante Möglichkeit in regelmäßigen Abständen die im FileLog definierten Quellen zu "pollen" um so "Stützpunkte" für die Diagramme zu generieren?
Ich denke eine im FileLog selbst integrierte Lösung wäre am idealsten?

Beta-User

Kannst du den Thread bitte von "Forum-Software" wegverschieben?

Zur Lösung des Problems "Plot-Abriss vermeinden" gibt es einen Artikel im Wiki, die elegante Variante ist vermutlich LogProxy...
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

ZitatGibt es eine elegante Möglichkeit in regelmäßigen Abständen die im FileLog definierten Quellen zu "pollen" um so "Stützpunkte" für die Diagramme zu generieren?
Das habe ich selbst nach dreimaligen Lesen nicht verstanden.

Was ich per "Brainstorming" liefern kann:
- es gibt ein inotify Modul (Linux-only)
- wenn ein notify mit den gleichen Regexp wie FileLog bestueckt ist, dann kann man eine Aktion ausfuehren.
- SVG versucht bei longpollSVG die Grafik zu refreshen. Ist aber nicht perfekt.

chunter1

Zitat von: Beta-User am 19 Dezember 2019, 13:49:22
Zur Lösung des Problems "Plot-Abriss vermeinden" gibt es einen Artikel im Wiki, die elegante Variante ist vermutlich LogProxy...

LogProxy hilft mir doch auch nicht wenn die letzte Statusänderung / der letzte Eintrag ein Monat zurück liegt und ich mir den Plot der letzten 24h ansehe?

Beta-User

@Rudi:
Verstanden habe ich das auch nicht ganz, hatte aber den Eindruck, dass das nahe bei der Diskussion rund um diesen Beitrag ist: https://forum.fhem.de/index.php/topic,106385.msg1002414.html#msg1002414.

(Und da du Mod bist: Magst du ausnahmsweise diesen Beitrag verschieben; gehört vermultlich zu FileLog=>Automatisierung)

@chunter1:
"Kleben" der logfiles und ggf. die Zeitgrenzen in LogProxy entsprechend anpassen _könnte_ helfen.
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

chunter1

Zitat von: rudolfkoenig am 19 Dezember 2019, 13:55:10
Das habe ich selbst nach dreimaligen Lesen nicht verstanden.

Was ich per "Brainstorming" liefern kann:
- es gibt ein inotify Modul (Linux-only)
- wenn ein notify mit den gleichen Regexp wie FileLog bestueckt ist, dann kann man eine Aktion ausfuehren.
- SVG versucht bei longpollSVG die Grafik zu refreshen. Ist aber nicht perfekt.

Sorry, ich versuchs mal so...
Ich hab z.B. folgendes FileLog definiert das alle Daten einer Heizungssteuerung mitloggt:

define FileLog_COE_Node_CMI_2 FileLog ./log/COE_Node_CMI_2-%W.log COE_Node_CMI_2

In diesem Fall werden alle Readings von "COE_Node_CMI_2" bei einem entsprechenden Event geschrieben.
Es wäre doch praktisch wenn man mittels attribut das FileLog anweisen könnte, dass alle z.B. 60 Sekunden alle Readings des device "COE_Node_CMI_2" gelesen und geloggt werden sollen.
Wenn im Filelog explizit einzelne Readings angegeben werden, dann sollen nur diese "gepollt" werden.

Ich weiß nicht ob das eine gute Idee ist - ich möchte nur fehleranfällige Redundanz vermeiden und denke, dass eine direkte Integration in FileLog am elegantesten wäre?


rudolfkoenig

Wozu pollen, wenn die Events selbst kommen?
Wenn zu viele kommen, dann kann man sie entweder per event-min-interval oder sonstwie begrenzen.
Wenn zu wenig, wieso was erfinden? Nur damit die Linie schoen ist?
Wenn einen nur Stunden/Tages/etc Werte interessieren, dann berechnet man diese erst (per statistik/etc) und zeichnet nur diese auf.

Beta-User

Auch zwischenzeitlich fertig getippt...

MMn ist das keine so tolle Idee, warum sollte was geloggt werden, ohne dass tatsächlich ein zugehöriges Event stattgefunden hat?

Soweit es um die "Schönheit" von SVGs geht, kann ich das nachvollziehen, aber alles andere ist nur "Stress" bzw. "Datenmüll".

@Rudi:
Die "addLog"-Variante aus dem Wiki hat aber mindestens den Nachteil, dass (allgemeine) Events erzeugt werden, nur um Logeinträge zu erzeugen.
Vielleicht könnte man eine (Perl-)-Anweisung zulassen, mit der nur FileLog angewiesen wird, eine Art "addLog" zu schreiben? (Der Spur nach: filelogtrigger("<device>","<Event>")).

(OT: In dem anderen Thread gab es eine Diskussion, ob man für FileLog ggf. separate "event-on-" Attribute haben sollte, um weniger/nicht alle Events zu loggen; ist mMn unnötig, aber evtl. siehst du das ja anders...)
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

chunter1

Zitat von: rudolfkoenig am 19 Dezember 2019, 14:22:28
Wozu pollen, wenn die Events selbst kommen?
Das Problem ist ja, dass eben keine Events kommen weil z.B. die Heizkreispumpe seit Monaten durchläuft.
Das erste Event das im Jahre vorkommt ist z.B. am 1. Oktober wenn die Pumpe von aus auf ein geht.
Das zweite Event ist dann im April wenn die Pumpe von ein nach aus wechselt.

Zitat von: rudolfkoenig am 19 Dezember 2019, 14:22:28
Wenn zu wenig, wieso was erfinden? Nur damit die Linie schoen ist?
Sie sind ja nicht unschön sondern gar nicht vorhanden. :)
Meine Filelogs sind immer Wochenweise - also mit "%W".
Ich verwende auch "creategluedfile".
Das alles hilft aber nicht wenn das letzte Event Monate zurückliegt und ich mir nur den aktuellen Tag ansehe.

Ich finde z.B. alle 24h einmal alle Stati zu lesen und ins FileLog zu schreiben keinen Datenmüll sondern Konistenzsteigerung :)

Beta-User

OK, für solche Sonderfälle kann ich es nachvollziehen, dass man irgendwann einen Status schreibt...

Warum dann nicht die "addLog"-Variante aus dem Wiki? Hängt an dem/den Events noch mehr dran an Eventhandlern? (ggf.: kann man die begrenzen, dass die nicht auf "addLog"-endende trigger reagieren?)
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

chunter1

Zitat von: Beta-User am 19 Dezember 2019, 14:54:00
Warum dann nicht die "addLog"-Variante aus dem Wiki? Hängt an dem/den Events noch mehr dran an Eventhandlern? (ggf.: kann man die begrenzen, dass die nicht auf "addLog"-endende trigger reagieren?)

Naja, addLog ist zwar nett, aber meiner Meinung nach eben eine parallel existierende, redundante und fehleranfällige (Vergessen/Übersehen) Lösung.
Erfahrungsgemäß sind Umsetzungen die nur an einem einzigen Punkt gewartet/geändert werden müssen am idealsten.
Alle Infos sind ja in der Definition von FileLog selbst schon vorhanden - einzig ein Timer fehlt (einfach gesagt :) )

Wernieman

dad geid so nischd ....

flielog ist doch praktisch ein "notify fürs Wegschreiben ins log" (Sorry fürs vereinfachen).

Wenn Du z.B. auf *broetchen* trickerst, um alle brötchensorten (wurstbroetchen, kaesebroetchen) wegzuschreiben, wie soll dann das filelog Wissen, was es für brötchen gibt? Falls der RegEx Ausruck noch komplizirter wird, z.B. +(broetchen|semmel)* würde es noch viel Komplizierter ....

Edit:
Beta-User hat es (unter diesem Beitrag) sogar besser erklärt: Stichwort Eventbasiert
- 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

Beta-User

Na ja, m.E. ist das "Problem", dass FileLog eventbasiert arbeitet und daher eben auf die entsprechenden Strukturen zugreift
(https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/92_FileLog.pm#L184). Ob die nach der Event-Verarbeitung noch existieren, kann ich nicht definitiv sagen, vermute aber eher nicht...
Wenn die Vermutung stimmt, hat FileLog eben nicht alles an Infos zum loggen, sondern außerhalb der Eventverarbeitung keine Ahnung, was es tun soll ;) .

Auf die Devices/Readings rückwärts zu kommen, würde vielleicht noch gehen (devspec2array), aber dann müßte man wissen/davon ausgehen, dass dann alles geloggt werden soll. Das Abgrenzen der wichtigen/wirklich gewünschten Daten geht "anders rum" (via addLog) mMn. viel eher.
(Ich selbst nutze übrigens DBLog, von daher existiert das Problem für mich so nicht...)
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

chunter1

Zitat von: Beta-User am 19 Dezember 2019, 15:25:07
(Ich selbst nutze übrigens DBLog, von daher existiert das Problem für mich so nicht...)

Ok, ich denke, ich werde mir mal das DBLog genauer anschaun (obwohl mir noch ein Server und dessen Wartung/Probleme etc. gar nicht gefällt).

Beta-User

Na ja, habe auch lange gezaudert (und weiß bis heute nicht, ob das aus den von dir genannten Gründen eine für mich weise Entscheidung war; plotten geht damit jedenfalls deutlich schneller und man hat _eine_ Datenbasis, was die Auswertung "crossover" vereinfacht)...
Die mariadb liegt auf demselben Server (kein Pi!).

Aber auch da mußt du ggf. mit logProxy erst einen "ersten Wert" finden lassen (oder die dortige addlog-Funktion nutzen), von ganz alleine geht das auch mit DBLog nicht. Von daher würde ich eher die simple "addLog"-at-Variante empfehlen, wenn das sonst für dich paßt.

(Ich habe das nur erwähnt, damit keiner den Eindruck hat, ich würde mich aus eigennützigen Motiven mit dem FileLog-Code rumschlagen, dann aber um die Umsetzung drücken...)
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

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?