Autor Thema: FileLog soll regelmäßig Werte auch ohne Event "pollen" - elegante Lösung?  (Gelesen 1362 mal)

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
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?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21661
Zitat
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?
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.

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
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?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
@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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
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?

« Letzte Änderung: 19 Dezember 2019, 14:13:35 von chunter1 »

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21661
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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
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.

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 :)
« Letzte Änderung: 19 Dezember 2019, 14:55:02 von chunter1 »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
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 :) )

Offline Wernieman

  • Hero Member
  • *****
  • Beiträge: 5934
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
« Letzte Änderung: 19 Dezember 2019, 15:33:23 von Wernieman »
- 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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
(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).

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}