Hallo Rudi,
ich würde gern den Timestamp von logeinträgen vorgeben.
Dazu benutze ich $hash->{CHANGETIME}->[], das wied in FileLog und DBLog beachtet. Das funktioniert. Leider kann ich $hash->{CHANGETIME} nicht in modul löschen weil das notify (log) die Information danach benötigt.
Meiner Meinung nach müsste das in fhem.pl am ende von DoTrigger stattfinden:
#3125
if(!defined($hash->{INTRIGGER})) {
delete($hash->{CHANGED});
delete($hash->{CHANGEDWITHSTATE});
}
zu
if(!defined($hash->{INTRIGGER})) {
delete($hash->{CHANGED});
delete($hash->{CHANGETIME});
delete($hash->{CHANGEDWITHSTATE});
}
würdest Du einen patch akzeptieren (oder das so nehmen) ?
Danke und Grüße
jörg
es gibt ein $hash->{".updateTimestamp"} das du vor jedem readingsBulkUpdate setzen kannst um den timestamp für das reading der im log landet zu setzen. das wird auch nach dem readingsEndUpdate automatisch wieder gelöscht.
das ganze funktioniert so lange problemlos wie bei FileLog pro file die zeiten streng monoton steigend sind und nicht zum beispiel ein anwender mehrere device in ein file loggen lässt.
gruss
andre
bist Du da sicher ?
$hash->{".updateTimestamp"} wird mMn zwar von fhemweb nicht jedoch von Filelog verwendet.
Schau mal die Zeilen
# 181,182
# 189
in 92_FileLog an.
Dort wird ausschließlich $hash->{CHANGETIME}->[] betrachtet, was auch Sinn macht(*). Wenn Du über dispatch kommst werden die trigger nicht sofort bei ..endUpdate ausgelöst.
Ich lösche CHANGETIME jetzt vor beginUpdate, ist aber eben nicht ganz sauber.
vg
joerg
edith
* = Sinn macht weil damit jedes event einen individuellen timestamp bekommen kann.
du hast natürlich völlig recht. vergiss einfach was ich gesagt habe. ich glaube ich schlafe schon :)
übrigens wird keins von beiden von fhemweb ausgewertet. deshalb sind auch die timestamps die per longpoll sichtbar sind falsch wenn man die timestamps über CHANGETIME manipuliert.
gruss
andre
ps: das mit den problemen sobald mehr als ein device ins gleiche file loggt stimmt aber :)
Wenn du ein readingsSingleUpdate machst, könntest du mit $hash->{".updateTimestamp"} und $hash->{CHANGETIME} jedesmal die Zeit selber setzen, das Event wird dann auch mit diesem Timestamp gefeuert und an FileLog gegeben. Vorraussetzung ist wiegesagt, das die Zeitangaben weiterhin aus der Vergangenheit fortlaufend sind.
ja. genau. Das funktioniert auch prima :)
$hash->{CHANGETIME} wird derzeit NICHT von fhem.pl GELÖSCHT.
Das bedeutet das NACHFOLGENDE, ganz andere und völlig unabhängige events des gleichen device das immer noch im hash gesetzt finden und dann DEN FALSCHEN ts ins log schreiben. (wenns blöd läuft :) )
Deswegen muss man CHANGETIME löschen NACHDEM das event fertig bearbeitet (sprich ins log geschrieben) ist. Das geht im modul nicht sauber. Sauber geht nur an der von mir beschriebenen Stelle in fhem.pl.
Besser erklärt ?
vg
joerg
Habe die vorgeschlagene Zeile eingebaut.
vielen Dank.
Ah, gutes Thema!
Gibt es denn mittlerweile einen anerkannten Weg, Readings mit alten Timestamps zu loggen?
Mir ist heute erst aufgefallen dass ich es scheinbar bei Livetracking nicht sauber hinbekommen habe und es sowohl bei Withings als auch bei Netatmo nicht zu 100% funktioniert.
Hat jemand eine Codestelle für mich die funktioniert?
sehr gern:
delete $hash->{CHANGETIME}; # clean up, workaround for fhem prior http://forum.fhem.de/index.php/topic,47474.msg391964.html#msg391964
# day period changed
$ats = ReadingsTimestamp($hash->{NAME},"current_period", "0");
$ts = sprintf ("%02d-%02d-%02d 00:00:00", $msg->{actual}->{year}, $msg->{actual}->{month}, $msg->{actual}->{day});
if ($ats ne $ts) {
readingsBeginUpdate($hash);
$hash->{".updateTimestamp"} = $ts;
readingsBulkUpdate($hash, "meter", $msg->{meter});
readingsBulkUpdate($hash, "current_period", $msg->{actualVal});
$hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }] = $ts;
readingsEndUpdate($hash, 1);
}
aus 32_Techem.*
$hash->{".updateTimestamp"} = $ts; ist fürs webif
$hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }] = $ts; für die logfiles
vg
joerg
Mir ist nicht ganz klar wann und wie oft ich $hash->{".updateTimestamp"} und $hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }] setzen muss.
Ich habe wie im Beispiel die Zeilen zu Anfang und Ende des BulkUpdates eingefügt, dazwischen sind einige Readings.
Im DbLog haben meine Einträge leider trotzdem den aktuellen Zeitstempel.
.updateTimestamp ein mal, CHANGETIME für jedes readingsBulkUpdate jeweils mit dem passenden index.
gruss
andre
genau was andre sagt.
Ich ergänze noch: jeweils *nach* dem readingsBulkUpdate. Mit dem Befehl so wie er da steht sollte der index damit immer passend zu $hash->{CHANGED} hochzählen.
vg
joerg
Zitat von: herrmannj am 18 Januar 2016, 23:29:28Ich ergänze noch: jeweils *nach* dem readingsBulkUpdate. Mit dem Befehl so wie er da steht sollte der index damit immer passend zu $hash->{CHANGED} hochzählen.
Nachher scheint zu funktionieren, dein Befehl crasht bei mir unter bestimmten Voraussetzungen aber FHEM mit
Modification of non-creatable array value attempted, subscript -1
das musst Du mal prüfen. Für den Befehle gäbe es ja alternative Möglichkeiten.
Was im Augenblick stattfindet:
readingsBulkUpdate($hash, "current_period", $msg->{actualVal});
"pushed" ein event nach $hash->{CHANGED}, eine ref auf ein array. $hash->{CHANGETIME} ist seinerseits eine Refenrenz auf ein array, dort wird die CHANGETIME mit gleichem index wie das dazugehörige event in $hash->{CHANGED} gespeichert.
Die Konstruktion $hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }] = $ts; erzeugt also einen index der gleich dem höchsten Index in $hash->{CHANGED} ist. Wenn jetzt in $hash->{CHANGED} nichts steht ergibt die Konstruktion -1, ein ungültiger Index.
Daraus ergibt sich die Frage: warum steht nichts in $hash->{CHANGED} ?
Eventuell solltest Du das debuggen (DATA::DUMPER auf $hash->{CHANGED}) unmittelbar vor dem setzen des timestamp. Dann solltest Du im Fehlerfall in der Lage sein das nachzuvollziehen.
Den von Dir beschriebenen Fehler habe ich noch nie gesehen. Völlig ins blaue: vielleicht greifen hier "event-on-xx" attribute ein. Wenn das so wäre müsste man nach dem readingsBulk prüfen ob tatsächlich in events etwas dazugekommen ist und nur dann CHANGETIME setzen. Andernfalls wären CHANGE und CHANGETIME sowieso nicht synchron, was ja zu anderen Fehlern führt auch wenn der Index >0 ist.
Bitte berichten :)
vg
joerg
die event-on-xx attribute können es nicht sein. die greifen erst nach dem readingsEndUpdate.
-1 kann es nur geben wenn das CHANGED array leer ist. das kann nach einem readingsBulkUpdate eigentlich nur passieren wenn das reading oder der wert nicht definiert waren oder .updateTimestamp nicht definiert ist was nur nach einem vergessenen readingsBeginUpdate passieren sollte. dafür gibt es aber eine meldung im log.
gruss
andre
tja, so schnell kann's gehen. Hier http://forum.fhem.de/index.php/topic,42232.msg397141.html#msg397141 bekomme ich einen gleichlautenden Bericht rein.
Der user sagt das es bei einem update entstanden ist. Da müsste es ja recent Änderungen in fhem.pl gegeben haben ? Checke ich wenn ich den zeitraum kenne. Vielleicht weiß es ja jemand so.
Syntaktisch ist nach meinem Verständnis das
$hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }]
und das
$hash->{CHANGETIME}[$#{ $hash->{CHANGED} }]
gleich.
Lieg ich da falsch ?
vg
joerg
Markus,
welches perl und welches os hast Du ?
Kannst Du "unter bestimmten Umständen" präzisieren ? Kennst Du ein bestimmtes Szenario in dem man das reproduzieren kann ?
Danke vg
joerg
Perl 5.20.2
Nachvollziehbar ist es meiner Meinung nach immer dann passiert, wenn es nur einen Wert im Update gab.
Wo ich das vorher wusste, steht bei mir jetzt einfach $hash->{CHANGETIME}[0].
Dummerweise ist es danach an den anderen Stellen immer noch passiert, weshalb mein Setup jetzt so aussieht:
readingsBeginUpdate($hash);
$hash->{".updateTimestamp"} = FmtDateTime($data->{timestamp});
my $changeindex = 0;
readingsBulkUpdate($hash, "reading", $data->{value});
$hash->{CHANGETIME}[$changeindex++] = FmtDateTime($data->{timestamp});
...
readingsEndUpdate($hash, 1);
Das funktioniert aktuell noch ohne Abstürze, ich hoffe das bleibt so.
Lustig, dass wir alleine zwischen uns dreien schon mindestens 5 verschiedene Arten durch haben dürften, das gleiche zu erreichen.
Bei meiner letzten Iteration bin ich übrigens damit auf die Schnauze gefallen dass ich versucht habe, mehrere Timestamps in einer Update-Schleife unterzubringen - das hat auch nicht wirklich funktioniert.
Danke.
Der andere user hat auch 5.20 - vielleicht ist da was buggy.
Mit dem Index ist verständlich - ich denke ich werde das aber mal so umabuen das er sich den Index weiterhin zieht.
Müsste ja auch so gehen: (peudo)
bulbUpdate ...
my $index = int(@{$hash->{CHANGED}}) -1;
if ($index < 0) {
Log3 name, 2, "was falsch";
} else {
$hash->{CHANGETIME}[$index] == $ts;
}
Da fühle ich mich besser weil man unabhängig davon agiert was fhem.pl in die events pushed.
Ich konnte den Fehler auf perl 18 nicht nachstellen.
vg
joerg