DBLog höchster Wert des Tages behalten rest verwerfen/löschen

[DS_Starter]

Ich habe reduceLog für die Erweiterung vorbereitet und komplett überarbeitet.
Wer die neue V testen möchte schaut bitte hier: https://forum.fhem.de/index.php/topic,53584.msg1231080.html#msg1231080

[DS_Starter]

Ich habe die Möglichkeit für reduceLog max bzw. reduceLog max=day eingebaut -> https://forum.fhem.de/index.php/topic,53584.msg1231131.html#msg1231131

[dirk.k]

Danke für den Aufwand.
Ich habe es mehrfach probiert ... erhalte aber nach 7-8 Minuten einen Fehler:
DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 9286.

Mein Befehl:
set DbRep.logdb reduceLog 1 max include=%:Relay,MAX_SC_02543a:onoff,MAX_SC_02543a:on_off_ticker

[DS_Starter]

Je nach Performance kann es notwendig sein die SQLite vor parallelen Schreibprozessen (DbLog) zu
schützen.
Man kann mit den Attributen im DbRep die DbLog temporär während der Laufzeit von reduceLog sperren.
DbLog sollte asynchron eingestellt sein.

Code: [Auswählen]

executeBeforeProc  set <DbLog Device> reopen 3600
executeAfterProc  set <DbLog Device> reopen


[Motivierte linke Hände]

Nur zum Verständnis nochmal: Verstehe ich diesen Faden dahingehend richtig, dass DbRep aktuell, wenn ich für diffValue, averageValue etc. das Attribut "devices" auf mehrere Devices setze, die Aktion nicht für jedes Device einzeln, sondern einmal aggregiert über alle Devices ausführt?

D.h. ich muss mir, wenn ich 20 Geräte habe, für die ich Differenzwerte in die DB schreiben möchte, mir 20 DbReps anlegen - oder für ein DbRep vor jedem Aufruf die Attribute ändern?

Und wenn ich das richtig verstanden habe: Geht was kaputt (weil DbRep Datenbankanfragen NBL ausführt, ich aber rapide Attribute ändere und DbRep-Anfragen auslöse), wenn ich mir eine Perl-Schleife wie die folgende baue:

Code: [Auswählen]


[...]
 foreach my $dev (sort keys %defs) {
    if($defs{$dev}{TYPE} eq 'MQTT2_DEVICE') {
      if (AttrVal($defs{$dev}{NAME},'model','err') eq 'shellyPlus_1pm') {
        fhem("attr myDbRep device $defs{$dev}{NAME}";
        fhem("attr myDbRep device energy_total");
        fhem('set myDBRep diffValue writeToDB");
      } elsif (AttrVal($defs{$dev}{NAME},'model','err') eq 'shelly3em') {
        fhem("attr myDbRep device $defs{$dev}{NAME}";
        fhem("attr myDbRep device emeter_sum_total");
        fhem('set myDBRep diffValue writeToDB");
      }
    }
  }

[DS_Starter]

Verstehe ich diesen Faden dahingehend richtig, dass DbRep aktuell, wenn ich für diffValue, averageValue etc. das Attribut "devices" auf mehrere Devices setze, die Aktion nicht für jedes Device einzeln, sondern einmal aggregiert über alle Devices ausführt?

Ja das ist richtig. Die gesetzten devices und/ oder readings werden wie angegeben in der DB Abfrage includiert (bzw. excludiert) und aus dem Selektionsergebnis der Wert average, min, max ... ermittelt.

D.h. ich muss mir, wenn ich 20 Geräte habe, für die ich Differenzwerte in die DB schreiben möchte, mir 20 DbReps anlegen - oder für ein DbRep vor jedem Aufruf die Attribute ändern?

Ja, normalerweise kopiert man sich einfach ein angelegtes Rep und ändert die Attribute wie gewünscht bzw. benötigt.
Das lässt man dann regelmäßig über die DB arbeiten.
Ein DbRep anzulegen und dann immer die Attr zu ändern würde zwar gehen, war aber von mir nie so gedacht für den produktiven Einsatz.

Geht was kaputt (weil DbRep Datenbankanfragen NBL ausführt, ich aber rapide Attribute ändere und DbRep-Anfragen auslöse), wenn ich mir eine Perl-Schleife wie die folgende baue:

Es geht zwar technisch nichts kaputt, aber das verwendete Device bringt in seinen Readings nicht nachvollziehbare Ergebnisse.
Also besser so nicht machen.
Außerdem würdest du massiv parallele Prozesse starten, die je nach verfügbarer Hardware zu Engpässen führen könnte.
Stimmt nicht, genau das habe ich per Design verboten, d.h. das Device würde erst einen neuen Prozess starten wenn der laufende beendet ist.
Besser mehrere DbRep anlegen und zeitlich "entzerrt" ausführen.
Es gibt noch die Möglichkeit eine Chain aufzubauen, die sebständig nacheinander die Aufgaben ausführt: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Abarbeitung_einer_sequentiellen_Befehlskette_mittels_non-blocking_sqlCmd-Kommandos

[dirk.k]

Hallo,
als Erstes ... es sieht so aus, als bekäme ich die gewünschten Maximalwerte.
Aber ich scheine noch Probleme bei der Geräteauswahl zu haben ...
mein Befehl:
set DbRep.logdb reduceLog 1 max include=%:Relay,MAX_SC_02543a:onoff,MAX_SC_02543a:on_off_ticker

Dieser scheint sich aber auch auf Devices bzw Werte auszuwirken, welche ich gar nicht abgegeben habe.
Die folgende Kurve ist weder relay noch von einem MAX-device

Vermutungen... muss INCLUDE großgeschrieben werden? Und kann ich überhaupt mehrere readings auf einmal wählen?
 

[DS_Starter]

Vermutungen... muss INCLUDE großgeschrieben werden?

Das ist korrekt -> siehe Commandref

Und kann ich überhaupt mehrere readings auf einmal wählen?

Hier ist zu unterscheiden, ob Operatoren in der Befehlszeile angegeben werden oder nicht.
In der Commandref gibt es die Beschreibung der Arbeitsweise mit Angabe von Operatoren in der Befehlszeile oder nicht was dann zur Verwendung der Einträge in den Attributen device und reading führt. Die Beschreibung der Befehlszeilenoperatoren sind exakt zu befolgen und nicht "frei" zu interpretieren, d.h. in dem Fall sind nicht mehrere Readings angebbar.
Die Verwendung der Attr device und reading statt dessen ist sehr viel flexibler als die Befehlszeilenoperatoren, mehrere Readings sind angebbar.