readings und Events mit datum in der Vergangenheit?

[erwin]

Liebe FHEM Developer!

ich entwickle gerade ein Modul für einen Stromzähler, der von den bisherigen Modulen nicht unterstützt ist. Die Schnittstelle ist über USB ein bidir. IR-Kopf von volkszähler.org.
Die Antwort vom Stromzähler ist ein relativ großer acsii-string (leider), den ich parse. Darin enthalten sind u.a. jede Menge "historische" Werte (z.b. monatsverbrauch der letzten xx Monate, Spitzenverbrauch/Monat, usw... jeweils mit Timestamp.

Anforderung: die "historischen Werte sollen sowohl in den readings, als auch der SQL-datenbank mit dem jeweils "historischen" datum geloggt werden.
Ich hab das durch intensives studieren von readingsUpdate, addevent,.... hinbekommen, das alles bestens funktioniert.
Ich möchte dennoch den code hier zur Diskussion stellen, evtl. gibts ja eine Lösung die die Anforderung "sauberer" erfüllt. Hier der Teil aus der parse Routine:

Code Auswählen Erweitern


    my @logarray;
    $hash->{CHANGED} = ();
    $hash->{CHANGETIME} = ();

        @logarray = ISKRAmeter_GetSerialDataParse2($hash, $buf); # returns line by line, values separated by |
        foreach (@logarray) {
            my ($reading, $value, $oldts) = split(/\|/, $_);

            if (defined($oldts)) {
                my $oldtsF = FmtDateTime($oldts);
                if (ReadingsVal($name,$reading,"") ne $value) { # we have an oldtimestamp and need to update
                    setReadingsVal($hash, $reading, $value, $oldtsF);
                    ## mimic addevent + Timestamp setting
                    push(@{$hash->{CHANGED}}, "$reading: $value");   # this is the function of addEvevnt
                    push(@{$hash->{CHANGETIME}}, $oldtsF);   # set old timestamp
                }
                next; # no update necessary

            } else {  # normal update process
                readingsSingleUpdate($hash,$reading,$value,1);
                $hash->{CHANGED} = (); # need to reset here, else everything gets confused...
                $hash->{CHANGETIME} = ();
            }
        } # foreach (@logarray)
        readingsSingleUpdate($hash,"state","valid",1);
        $hash->{CHANGED} = (); # need to reset here, else everything gets confused...
        $hash->{CHANGETIME} = ();
#???            DoTrigger($hash->{NAME}, undef) if ($init_done);

    return undef; #????


l.g. und Danke
erwin

[justme1968]

readings mit altem timestamp erzeugen ist leider etwas problematisch und geht mit dblog z.b. überhaupt nicht wirklich.

schau mal ins withings und netatmo modul. da siehst du wie ich es da gelöst habe.

gruss
  andre

[erwin]

Hi Andre,
danke für den Hinweis, die Module schau ich mir an.

Mit dem geposteten code funktioniert DbLog (mySQL), ich bin mir nur nicht sicher ob das evtl. "Nebeneffekte" hat.

l.g. erwin

[rudolfkoenig]

Wenn das mit FileLog auch nicht klappt, wuerde ich es naeher anschauen.
Eigentlich muesste CHANGETIME aber auch mit DbLog funktionieren.

Events mit CHANGETIME muessen bei einem FilLog einen monoton wachsenden Zeitstempel haben. Bei DbLog sollte das kein Problem sein.

[betateilchen]

Bei DbLog sollte das kein Problem sein.

sehe ich auch so, weil dort ein Index auf dem Timestamp Feld liegt, wenn ich mich recht erinnere.

[justme1968]

ja. dblog macht keine probleme.

bei filelog ist je nach datenquelle genau das monoton wachsend das problem. wenn die historischen readings nicht in einem rutsch kommen und so auf einen schlag sortiert werden können geht es gar nicht oder nur mit einschränkungen.

die whitings und netatmo module können z.b. nicht aus mehreren devices ins gleiche file loggen weil es keine (vernünftige) möglichkeit gibt die readings device übergreifend passend zu sortieren.

[erwin]

Danke Andre,

Das Problem mit dem monoton ansteigenden datum kann ich lösen (durch filltern/sortieren), solange ich nicht mehr als ein Device in einem FileLog habe. Ein kleines Problem gibts, falls jemand ein device löscht und mit gleichem namen wieder anlegt....., aber Geisterfahrten kann man ja auch nicht wirklich verhindern 

Ich verwende ohnehin DbLog, und da sollte das kein Problem sein.

danke für die Tip's
erwin