readingsUpdate und Loginterval

[Willi]

Hallo,

Boris hatte readingsUpdate bereitgestellt, mit event-on-change.

Danke dafür Boris!

Ich habe jetzt vor meine TRX-Module auf readingsUpdate umzustellen.

Die Oregon-Sensoren loggen sehr häufig, teilweise alle 20 Sekunden. Durch die Größe des Filelog wird pgm2 langsam bei der Anzeige langsam. Das stört insbesondere bei langsamen Prozessoren.

event-on-change ist da (fast) die richtige Lösung. Ich habe mir meine Logfiles angesehen. bei event-on-change könnte es sein, dass auch halbe Stunde oder länger keine Daten ins Log kommen. Die Gplots können dann insbesondere bei Wechsel von einem Tag auf den anderen Tag etwas seltsam aussehen.

@Boris: Wäre es möglich readingsUpdate so zu erweitern, dass man alle x Minuten einen garantierten Logeintrag bekommt? So etwas wie  event-on-change-reading-5m ? Oder evtl. sogar über Parameter die Zeiteinheit einstellbar?

Eine andere Alternative wäre, dass ich diese Funktionalität in mein TRX-WEATHER-Modul einbaue.

Dann würde mir ein readingsUpdate fehlen, bei dem man alternative mit oder ohne event die Readings generieren kann.

Das wäre so etwas wie ein readingsUpdate_noevent().

Evtl. wäre das ja die bessere Lösung?

Grüße

Willi

[Dennis G]

PING Boris :-)

Das wäre in der Tat ein wünschenswertes Feature, event-on-change ist
schon eine schöne
Sache bis auf die Tatsache das die Plots bei tageswechsel abreissen.
Ein definierbares
Logintervall (alle x minuten wird geloggt egal welcher wert geliefert
wird) wäre für schöne
und schnelle Plots super hilfreich. Geht da was ? :-)

Schöne Grüße ...

Dennis

[Dr. Boris Neubert]

Hallo,

Am 18.10.2012 06:59, schrieb Dennis G:
> Ein definierbares
> Logintervall (alle x minuten wird geloggt egal welcher wert geliefert

> wird) w�re f�r sch�ne

> und schnelle Plots super hilfreich. Geht da was ? :-)
>

ich habe das mit Willi privatissime diskutiert. Ich bin noch nicht davon
ueberzeugt, dass das die richtige Loesung fuer das Problem ist.

Soweit ich das verstanden habe, loest event-on-change-reading das
Problem, dass die Logfiles platzen.

Plots beginnen erst mit dem ersten Wert, der im FileLog geschrieben ist.
Wenn man tageweise Plots hat und die erste Aenderung um 4 Uhr morgens
einlaeuft, beginnt die Liniengrafik auch erst um vier Uhr. Das ist das
eigentliche Problem, das geloest werden soll, nicht wahr?

Ich wuerde gerne hier diskutieren, wie man das am besten loest, und
mache mal einen Vorschlag ins Blaue: neues Attribut overlap am FileLog,
welches dafuer sorgt, dass beim Logfilewechsel die letzte Zeile aus dem
vorigen Log ins neue Log kopiert wird. Achso, getestet habe ich
allerdings nicht, ob das auch zur gewuenschten Darstellung fuehrt.

Meinungen?

Gruesse
Boris

[Dennis G]

Hi Boris,

Am Donnerstag, 18. Oktober 2012 17:14:01 UTC+2 schrieb Boris Neubert:

Ich wuerde gerne hier diskutieren, wie man das am besten loest, und
mache mal einen Vorschlag ins Blaue: neues Attribut overlap am FileLog,
welches dafuer sorgt, dass beim Logfilewechsel die letzte Zeile aus dem
vorigen Log ins neue Log kopiert wird. Achso, getestet habe ich
allerdings nicht, ob das auch zur gewuenschten Darstellung fuehrt.

Meinungen?

das Logfile wird ja nicht unbedingt tageweise rotiert sondern z.B. einmal im Monat/Jahr, der 

Overlap müsste also jeden Tag um 00:01 Uhr den letzten Eintrag des Vortages Logfileintern kopieren.

Das wäre eine Verbesserung - Hat zugleich jedoch auch einen Haken: Nehmen wir an der Wert um 

00:01 ist 100 und die nächste Veränderung um 12:00 Uhr ist 0 -.Dann wäre im Plot nun eine Linie mit 

45° Winkel von links oben nach mitte unten zu sehen, Richtig wäre jedoch eine horizontale Linie bis kurz vor 

12 Uhr die dann senkrecht nach unten gezeichnet ist.Das liesse sich nur mit regelmäßigen Logfileeinträgen erreichen oder gplot 

auf "with steps" anstatt "with lines" einstellen ? Würde evt. auch zu unerwünschten Effekten führen.

Any thought`s ? ;-)

Dennis

 

[Willi]

Am Donnerstag, 18. Oktober 2012 18:54:31 UTC+2 schrieb Dennis G:

Das wäre eine Verbesserung - Hat zugleich jedoch auch einen Haken: Nehmen wir an der Wert um 

00:01 ist 100 und die nächste Veränderung um 12:00 Uhr ist 0 -.Dann wäre im Plot nun eine Linie mit 

45° Winkel von links oben nach mitte unten zu sehen, Richtig wäre jedoch eine horizontale Linie bis kurz vor 

12 Uhr die dann senkrecht nach unten gezeichnet ist.Das liesse sich nur mit regelmäßigen Logfileeinträgen erreichen 

Stimmt. Guter Punkt!

Wobei, es würde auch ohne regelmäßige Einträge gehen. Es fehlt ja nur der letzte Wert vor der Änderung, damit der Plot gut aussieht.

Es fehlt ja die Information, wann der letzte Wert vor der Änderung kam.

Um das zu verhindern, müsste man in readingsUpdate bei einer Änderung nicht nur den aktuellen, also geänderten Wert schreiben, sondern auch noch zusätzlich den vorherigen Wert mit dem Timestamp vorher.

Damit es dann aber nicht zwei gleiche Werte im Filelog auftauchen, muss man sich noch merken, ob dieser Wert bereits ein Event ausgelöst hat. Letzteres wird dann wohl kompliziert.......

Oder wie kann man das sonst noch lösen?

[Erwin]

Sorry Gentlemen,

ich hab da eine völlig andere Meinung dazu!

Wir sollten keinesfalls Log-Einträge produzieren, die nicht stattgefunden haben!
Ein (noch) harmloses Beispiel dazu: Die Tiefkühltruhe meldet den letzten gemessenen Wert - einige Wochen lang jeweils um Mitternacht...
.. mit ein wenig Fantasie fällt wahrscheinlich jedem von uns noch schlimmere Beispiele ein...
dazu kommt noch, das die Events nicht nur ins filelog geschrieben werden, sondern evtl. auch in eine sql-datenbank für spätere Auswerungen - und da haben NICHT stattgefunden events absolt nichts verloren.

Ich sehe sehr wohl das Problem, ein Lösungsansatz sollte aber erst in der Auswertung passieren, z.b im fileplot / gnuplot process.

l.g. erwin

[Willi]

Am Donnerstag, 18. Oktober 2012 17:14:01 UTC+2 schrieb Boris Neubert:

Ich wuerde gerne hier diskutieren, wie man das am besten loest, und
mache mal einen Vorschlag ins Blaue: neues Attribut overlap am FileLog,
welches dafuer sorgt, dass beim Logfilewechsel die letzte Zeile aus dem
vorigen Log ins neue Log kopiert wird. Achso, getestet habe ich
allerdings nicht, ob das auch zur gewuenschten Darstellung fuehrt.
Meinungen?

Fände ich eine gute Lösung für den Wechsel der Filelogs. Es gibt allerdings noch das Problem, dass pgm2 nur die Werte berücksichtigt und darstellt für den man den jeweiligen Ausschnitt ausgewählt hat.

- Beispiel:

Ich lasse mir die Tagesstatistik (24 Stunden) von heute 18.10.12 anzeigen. 

Wenn der letzte geänderte Wert vom Vortag ist, beispielsweise am 17.10.12 um 23:45 Uhr und dann der erste geänderte Wert erst am 18.10.12 um 05:00 geschrieben wird, zeigt pgm2 die Kurve erst ab 05:00 Uhr an.

Richtig wäre, dass aber schon ab 00:00 Uhr die Kurve angezeigt wird mit dem Wert vom Vortag.

Um das hinzubekommen, müßte pgm2 auch Werte ausserhalb des Ausschnitts berücksichtigen.

[Willi]

Am Donnerstag, 18. Oktober 2012 19:32:39 UTC+2 schrieb Erwin:

Sorry Gentlemen,

ich hab da eine völlig andere Meinung dazu!

Wir sollten keinesfalls Log-Einträge produzieren, die nicht stattgefunden haben!

Konnte man das so verstehen?

Es geht in der Diskussion um das Attribut event-on-change-reading. Hier werden Events weggelassen, wenn sich die Werte nicht ändern. Das führt allerdings dazu, dass dann pgm2 Informationen für die Darstellung fehlen bzw. die Darstellung falsch ist.

Es soll nur weniger komprimiert werden, aber niemals ein Wert erfunden werden!  

Es werden nur Werte geschrieben, die es auch wirklich gab.

[Erwin]

Sorry für den "forschen Ton" ich wollte damit niemandem zu nahe treten, ganz im Gegenteil, ich bin von dieser Community und dem support hier absolut begeistert und als meist stiller Leser sehr dankbar!
Und ja, das konnte man soo verstehen (Zitate aus diesemThread):

das Logfile wird ja nicht unbedingt tageweise rotiert sondern z.B. einmal im Monat/Jahr, der 

Overlap müsste also jeden Tag um 00:01 Uhr den letzten Eintrag des Vortages Logfileintern kopieren.

Ich wuerde gerne hier diskutieren, wie man das am besten loest, und
mache mal einen Vorschlag ins Blaue: neues Attribut overlap am FileLog,
welches dafuer sorgt, dass beim Logfilewechsel die letzte Zeile aus dem
vorigen Log ins neue Log kopiert wird. Achso, getestet habe ich
allerdings nicht, ob das auch zur gewuenschten Darstellung fuehrt.

ich gebe zu Bedenken, dass das ursprügliche Problem: Die Linie im Monat/Tages/4Stunden Plot beginnt erst mit dem ersten event, der im Log den richtigen Timestamp hat...
nichts mit update/change on reading zu tun hat, sondern grundsätzlich bei jedem event auftritt, der nicht allzu häufig vorkommt.

Die Idee, den letzten wert vor dem Beginn der timerange als Startwert zu nehmen finde ich absolut ok, allerdings sollte dieser Wert nicht ins aktuelle filelog kopiert werden, sondern während des fileplots/gnuplot- prozesse dynamisch geholt/generiert werden.  Damit würde mein geschildertes Beispiel auch nicht passieren: Falls im Timeintervall kein (reeller) event passiert - wird gar nix geplottet!
 
l.g. erwin

[Willi]

Am Donnerstag, 18. Oktober 2012 20:13:53 UTC+2 schrieb Erwin:

Und ja, das konnte man soo verstehen (Zitate aus diesemThread):

das Logfile wird ja nicht unbedingt tageweise rotiert sondern z.B. einmal im Monat/Jahr, der 

Overlap müsste also jeden Tag um 00:01 Uhr den letzten Eintrag des Vortages Logfileintern kopieren.

Kein Problem. 

Ich hatte diesen Vorschlag von Boris so verstanden, dass er den Eintrag mit dem alten Timestamp (also vom Vorjahr) ins neue Logfile kopiert.

Aber evtl. hatte ich Boris ja auch falsch verstanden...

[Dr. Boris Neubert]

Hallo,

Am 18.10.2012 21:00, schrieb Willi:
>
> Ich hatte diesen Vorschlag von Boris so verstanden, dass er den
> Eintrag mit dem alten Timestamp (also vom Vorjahr) ins neue Logfile
> kopiert.
>
>

genau das meinte ich auch.

Gruesse
Boris

[Martin Fischer]

Am Donnerstag, 18. Oktober 2012, 10:32:39 schrieb Erwin:
> [...]

> Wir sollten keinesfalls Log-Einträge produzieren, die nicht stattgefunden
> haben!

da gehe ich absolut mit! was ist wenn der letzte logeintrag z.b. eine
fehlermeldung vom device ist, die gar nicht den erwarteten wert zur
darstellung eines plots enthält?

also: auch ich bin der meinung, das logeinträge den momentanen ist-zustand
wiedergeben und nicht eine "kopie" eines vorher stattgefundenen events
darstellen sollten.

[Martin Fischer]

Am Donnerstag, 18. Oktober 2012, 21:43:52 schrieb Dr. Boris Neubert:
> [...]

aber genau das ist aus meiner sicht eben nicht der richtige ansatz. ein
logfile dokumentiert doch den zu dem zeitpunkt eingetretenen zustand.

findet eine rotation des logfiles statt, so habe ich das als konsument zu
berücksichtigen und muss halt in dem vorangegangenem logfile den letzten wert
suchen.

daher sollte die logik (wo erhalte ich den letzten zustand eines devices)
nicht auswirkungen auf die logfiles haben, sondern in der plot funktion
vorgenommen werden. und wenn das nur ein auslesen des letzten aktuellen wertes
des devices ist, anhand dessen timestamps und des logfiles verglichen wird ob
der wert bereits exisitert. wenn nein, dann nimm für den plot den letzten wert
des devices, und wenn er in beiden identisch ist, dann verlass dich aufs
logfile..

[Dennis G]

Oder eben ein "logDelay" Attribut, es wird "event-on-change" gelogt
und wenn es XX minuten keine Change gibt (sondern einen
gleichbleibenden Wert) dann wird dieser trotz "event-on-change"
geschrieben um ein Zeitraster im Log zu haben...

Das entspricht Willis Idee und wäre doch eine Lösung die nicht die
Daten verfälscht, saubere Plots generiert, auch bei Logrotate
funktioniert und nur minimal mehr Daten im Log produziert...

Was spricht dagegen ?

Gruß Dennis

[Martin Fischer]

Am Freitag, 19. Oktober 2012, 04:42:27 schrieb Dennis G:
> [...]

> Das entspricht Willis Idee und wäre doch eine Lösung die nicht die
> Daten verfälscht, saubere Plots generiert, auch bei Logrotate
> funktioniert und nur minimal mehr Daten im Log produziert...
>
> Was spricht dagegen ?

aus meiner sicht spricht dagegen, das ein logfile eintrag eben nur von einem
modul, das für den jeweiligen logfileeintrag zuständig ist, geschrieben werden
sollte.

es geht nicht um die "minimalen daten mehr" im logfile, sondern wer die hoheit
über einen logeintrag behält.

mir ist bisher (zumindest nicht bewusst) noch kein logfile im kompletten
unix/linux umfeld untergekommen, das diesen "workaround" "schreibe alte
zustände, bei einer rotation in neues logfile" vornimmt. ein logfile eintrag
ist (zumindest aus meiner sicht) _immer_ ein abbild einer momentaufnahme.
daher auch der timestamp.

beispiel anhand eines monatlichen logrotate:
wenn z.b. ein device am 30.09.2012 um 12:12 uhr seinen letzten eintrag in der
folgenden form erzeugt:

30.09.2012 12:12 foobar: moo

und darauf hin das logfile noch bis 23:59:59 mit weiteren informationen aus
anderen devices "gefüttert" wird, dann kann doch nicht das logfile am
01.10.2012 00:00:00 mit dem eintrag:

30.09.2012 12:12 foobar: moo

anfangen! ich erwarte in einem logfile, das z.b. fhem-2012-10.log heisst
_keine_ daten mehr aus 09.

würde man nun aber sagen: "ok, filelog holt sich die aktuellen werte und
schreibt sie rein" müsste der eintrag aus meiner sicht mit dem timestamp des
letzten readings stattfinden. das bedeutet, das im neuen logfile von 10-2012
ein eintrag aus 09-2012 landet.

würde man nun sagen "filelog holt sich den letzten wert (30.09.2012 12:12) und
schreibt ins logfile "01.10.2012 00:00" dann ist das schlichtweg falsch, da
das device tatäschlich diese meldung nicht vorgenommen hat. tatsächlich hat
das device in diesem beispiel seinen letzten eintrag am 30.09.2012 um 12:12
vorgenommen und eben nicht am 01.10.2012 um 00:00. dies verfälscht das
logfile.

bei den gemachten vorschlägen handelt es sich aus meiner sicht um eine
"verwässerung" zwischen der protokolierung und der zur darstellung benötigten
werte. und wenn für letzteres werte benötigt werden, dann sollte das logfile
eben unangetastet bleiben.

ein logfile nutzt man eben auch zur fehleranalyse. ein plot stellt _ein_
_bestimmtes_ verhaltensmuster halt hübsch dar. das ist aus meiner sicht der
gravierende unterschied.

gruss martin

[Martin Fischer]

Am Freitag, 19. Oktober 2012, 04:42:27 schrieb Dennis G:
> [...]

> Das entspricht Willis Idee und wäre doch eine Lösung die nicht die
> Daten verfälscht, saubere Plots generiert, auch bei Logrotate
> funktioniert und nur minimal mehr Daten im Log produziert...

nachtrag:
ich hatte bei meiner antwort den beitrag von willi "ausgeblendet". sein
problem ist ja, das die devices zuviel bzw. in relativ kurzen abstand daten
liefern.

in der tat, stellt das dann ein problem dar. aber auch hier bin ich der
meinung, dass das im modul selber aggregiert, kummuliert oder was auch immer
gemacht werden sollte. das wäre durchaus mit dem InternalTimer in verbindung
mit event-on-change zu realisieren. dann wäre es vom modul so gewünscht.

dennoch tendiere ich zu einer anpassung in der plot funktion, wenn es darum
geht, das zitat boris:

Am Donnerstag, 18. Oktober 2012, 17:13:50 schrieb Dr. Boris Neubert:
> Plots beginnen erst mit dem ersten Wert, der im FileLog geschrieben ist.
> Wenn man tageweise Plots hat und die erste Aenderung um 4 Uhr morgens
> einlaeuft, beginnt die Liniengrafik auch erst um vier Uhr. Das ist das
> eigentliche Problem, das geloest werden soll, nicht wahr?

und nicht zu einem "overlap am filelog". die plot funktion sollte sich den
letzten wert (wenn nicht vorhanden) dynamisch aus dem reading holen.

gruss martin

[Willi]

Am Freitag, 19. Oktober 2012 14:51:53 UTC+2 schrieb Martin Fischer:

nachtrag:
ich hatte bei meiner antwort den beitrag von willi "ausgeblendet". sein
problem ist ja, das die devices zuviel bzw. in relativ kurzen abstand daten
liefern.

in der tat, stellt das dann ein problem dar. aber auch hier bin ich der
meinung, dass das im modul selber aggregiert, kummuliert oder was auch immer
gemacht werden sollte. das wäre durchaus mit dem InternalTimer in verbindung
mit event-on-change zu realisieren. dann wäre es vom modul so gewünscht.

Danke, dass Du auf das ursprünglichen Posting Bezug nimmst.

Meine Hoffnung war, dass wir event-on-change so umgestalten können, dass bei Nutzung Grafiken erhält die denen entsprechen, die man ohne event-on-change erhält.

Die einzige pragmatische Lösung ist wohl zwangsweise alle x Minuten ein Event zu generieren, auch wenn sich der Wert nicht geändert hat.

Leider bietet readingsUpdate() selbst keine Möglichkeit ein Event zwangsweise auszulösen (und damit alle x-Minuten einen Eintrag im Filelog zu setzen), wenn event-on-change gesetzt ist und sich der Wert nicht geändert hat.

Theoretisch wäre eine sehr unschöner Hack möglich: Man könnte sich den Inhalt des Attributs event-on-change merken, dieses Attribut zu löschen, readingsUpdate ausführen und dann wieder das Attribut zu setzen. Das gefällt mir allerdings überhaupt nicht.

Vermutlich ist es am besten ein eigenes myreadingsUpdate() im Modul zu schreiben, welches die Logik des Timeouts realisiert und zwar readingsUpdate() verwendet, aber im Anschluss selbst addEvent() aufruft bzw. ein Event erzeugt. Dazu ist dann auch keine Änderung in fhem.pl notwendig.

Auch nicht schön, aber etwas anderes fällt mir aber derzeit nicht ein. Ich werde das bei Gelegenheit mal probieren. Wenn dies nicht funktioniert, muss ich evtl. doch auf wieder auf readingsUpdate() verzichten und die Logik zur Aggregierung selbst realisieren (also eigenes readingsUpdate im Modul).

[Dennis G]

Hallo Willi,

Am Freitag, 19. Oktober 2012 16:36:32 UTC+2 schrieb Willi:

Danke, dass Du auf das ursprünglichen Posting Bezug nimmst.

Meine Hoffnung war, dass wir event-on-change so umgestalten können, dass bei Nutzung Grafiken erhält die denen entsprechen, die man ohne event-on-change erhält.

Die einzige pragmatische Lösung ist wohl zwangsweise alle x Minuten ein Event zu generieren, auch wenn sich der Wert nicht geändert hat.

Leider bietet readingsUpdate() selbst keine Möglichkeit ein Event zwangsweise auszulösen (und damit alle x-Minuten einen Eintrag im Filelog zu setzen), wenn event-on-change gesetzt ist und sich der Wert nicht geändert hat.

Ich würde einen neuen event-on-timer vorschlagen der x Minuten nichts durchlässt, das nächste Zutreffende event zulässt (egal ob change stattgefunden hat) und dann wieder für x Minuten sperrt.

So könnte man Wertunabhängig, jedoch mit Zeitraster, loggen...

Gruß Dennis