DbRep und Funktion diffValue

[h002]

Ich erfasse die Impulse meines Stromzählers über RPI_GPIO und zähle diese über einen Counter fortlaufend hoch (1000 Impulse je kWh). Damit ich in FHEM immer den aktuellen Zählerstand habe, addiere ich diesen Werte zusätzlich zu einem initial erfassten Zählerstand. Dieser wird also inkrementiert. Nun ist es ja ein bekanntest Problem, dass die S0-Schnittstellen an den Zählern nicht so genaue Werte liefern. Mir kommt es nicht auf jedes Watt an, aber ab und zu möchte ich den Zählerstand neu "initialisieren". Nun kommt es mit diffValue zu folgendem Problem.

Angenommen ich habe 0:01 Uhr einen Stand von 5112.167 und 23:59 Uhr einen Stand von 5125.004, aber habe gegen 13:30 Uhr den Zähler von 5128.563 (höher als am tatsächlichen Tagesende) auf 5122.653 neu gesetzt, bekomme ich mit den Tagesdifferenzen Abweichungen. Subtrahiere ich an diesem Tag den Wert vom größten Timestamp mit dem Wert vom kleinsten Timestamp, dann komme ich auf andere Werte - die ich auch gerne hätte.

Ich habe die Beschreibung aus der Commandref so verstanden, dass diese Funktion fortlaufend steigende Werte annimmt. Dadurch hätte ich auch erwartet, dass der höchste Timestamp-Wert mit dem kleinsten Timestamp-Wert innerhalb eines timestamp_begin/ timestamp_end Zeitraums als Berechnungsgrundlage dient.

In der commandref steht dazu folgender Passus.

Es wird immer die Differenz aus dem Value-Wert des ersten verfügbaren Datensatzes und dem Value-Wert des letzten verfügbaren Datensatzes innerhalb der angegebenen Zeitgrenzen/Aggregation gebildet, wobei ein Übertragswert der Vorperiode (Aggregation) zur darauf folgenden Aggregationsperiode berücksichtigt wird sofern diese einen Value-Wert enhtält.

Folgende Definition zum DbRep habe ich.

Code Auswählen Erweitern


Internals:
   DATABASE   fhem
   DEF        dbLog
   FUUID      5dcc272e-f33f-8b20-cc5f-40db2abbf8398c53
   FVERSION   93_DbRep.pm:v8.28.2-s20379/2019-10-18
   LASTCMD    diffValue display
   MODEL      Client
   NAME       dbReportDimplexDailyElectricEnergy
   NOTIFYDEV  global,dbReportDimplexDailyElectricEnergy
   NR         244
   NTFY_ORDER 50-dbReportDimplexDailyElectricEnergy
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE dbLog
     IDRETRIES  3
     MINTS      2019-09-05 22:08:57
     PACKAGE    main
     VERSION    8.28.2
     CV:
       aggregation day
       aggsec     86400
       destr      2019-11-20
       dsstr      2019-11-20
       epoch_seconds_end 1574290799
       mestr      11
       msstr      11
       testr      23:59:59
       tsstr      00:00:00
       wdadd      432000
       yestr      2019
       ysstr      2019
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2019-11-21 12:32:55   2019-11-20_23-53-20__GPIO3__actualEnergyUnitValue__DIFF__2019-11-20 18.2460
     2019-11-21 12:32:55   state           done
Attributes:
   aggregation day
   device     GPIO3
   diffAccept 1000
   executeAfterProc {calcDimplexValues("dbReportDimplexDailyElectricEnergy")}
   reading    actualEnergyUnitValue
   room       Dimplex
   timestamp_begin previous_day_begin
   timestamp_end previous_day_end
   verbose    5


Wo ist hier mein Denkfehler und wie könnte ich mein Problem lösen, ohne gleich einen neuen Zähler mit Modbus kaufen zu müssen? Vielen Dank!

[DS_Starter]

Guten Abend,

ich glaube ich muss die commandref etwas anpassen.
Bin erst morgen wieder zu Hause und kann erst dann wieder in der Code schauen. Aber wenn ich mich niht täusche werden inzwischen Teildifferenzen der vorhandenen Werte innerhalb der Aggregationsperiode ermittelt und aufsummiert.
Das ist insofern wichtig, damit ein Zwischenzeitlicher Reset eines Zählers berücksichtigt werden kann.

Zitat

Dabei wird ein Zählerüberlauf (Neubeginn bei 0) mit berücksichtigt (vergleiche Attribut "diffAccept").

Zur Lösung deiner Aufgabe schlage ich folgenden Weg vor.
Ändere den besagten Wert um einen recht hohen Betrag und definiere das Attribut diffAccept auf einen Wert der darunter liegt. Das führt dazu das die in dem Fall auftretende hohe positve Differenzflanke nicht in die Berechnung eingeht und ausgefiltert wird. Die negative Flanke wird eh ignoriert.
Der default von diffAccept ist 20. Du könntest auch nur diesen Wert reduzieren bzw. anpassen.

Probier mal. Und ich passe morgen die Commandref an wenn ich das gecheckt habe 

LG,
Heiko

[h002]

Ist schon etwas später, kann dir glaube nicht so recht folgen. 

Ich habe mal einen Export der betroffenen Daten angehangen. Das Ergebnis von diffValue ist bei diesen Daten ist 17.641.

Code Auswählen Erweitern


2019-11-21 22:49:15 DbRep dbReportDimplexDailyElectricEnergy 2019-11-20_23-53-20__GPIO3__actualEnergyUnitValue__DIFF__2019-11-20: 17.6410
2019-11-21 22:49:15 DbRep dbReportDimplexDailyElectricEnergy db_lines_processed: 1
2019-11-21 22:49:15 DbRep dbReportDimplexDailyElectricEnergy done


Den Zähler habe ich (siehe Anhang) um die Zeit 16:36:42 angepasst.

Wenn ich die Daten zeitlich absteigend sortiere, gibt es zwei unterschiedliche min/max-Aggregationsperioden. Einer von "2019-11-20 00:13:26" (Wert 5112.167) bis "2019-11-20 13:53:37" (Wert 5124.91) mit einer Differenz von 12,743 und von "2019-11-20 16:36:42" (Wert 5120.22) bis "2019-11-20 23:53:20" (Wert 5125.004) mit einer Differenz von 4,784. Die gesamt Differenz beträgt 17,527. Der Zeitsprung zwischen den zwei Aggregationsperioden hängt mit dem Löschen von ein paar Daten zusammen. "diffValue" wurde aber nach dem Löschen noch mal neu ausgeführt.

Mein gewünschter Wert sollte eigentlich die Differenz von 12,837 sein ("2019-11-20 23:53:20" (Wert 5125.004) minus "2019-11-20 00:13:26" (Wert 5112.167)).

Wann werden eigentlich die Teildifferenzen gebildet? Was ist das Kriterium dazu, die Aufsummierung durchzuführen? Hängt das mit dem "diffAccept" zusammen? Ein Reset funktioniert sicher, wenn man immer von 0 ausgeht. Mein Ziel ist allerdings, irgendwie den tatsächlichen Soll-Zählerstand im Reading zu sehen, damit ich Abweichungen vom Ist-Zählerstand besser erkennen kann. Oder ich muss das Zählen und den Zählerstand getrennt betrachten.

Kann man eine Art Option einbauen, dass bei diffValue der Wert "value" vom größten Timestamp, mit "value" des niedrigsten Timestamps subtrahiert wird?

Hoffentlich habe ich mich hier nicht zu sehr verzettelt und bin auf einem sehr umständlich Weg unterwegs.

Eine weitere Alternative wäre natürlich gleich ein SQL, was die Berechnung in einem Statement erledigt. So was wie in dieser Art, um die Tagesdifferenzen zu ermitteln.

Code Auswählen Erweitern


select date_format(history.timestamp,'%Y%m%d'),
round((maxDayElectric.value - minDayElectric.value),3) as diff_energy,
(maxDayThermic.value - minDayThermic.value) as diff_thermic,
round(((maxDayThermic.value - minDayThermic.value) / (maxDayElectric.value - minDayElectric.value)),2) as dayJAZ
from
fhem.history,
(select date_format(timestamp,'%Y%m%d') as day,min(value) as value from fhem.history where device='GPIO3' and reading='actualEnergyUnitValue'  group by day having min(timestamp))minDayElectric,
(select date_format(timestamp,'%Y%m%d') as day,max(value) as value from fhem.history where device='GPIO3' and reading='actualEnergyUnitValue'  group by day having max(timestamp))maxDayElectric,
(select date_format(timestamp,'%Y%m%d') as day,min(value) as value from fhem.history where device='GPIO3' and reading='actualFullThermicEnergy'  group by day having min(timestamp))minDayThermic,
(select date_format(timestamp,'%Y%m%d') as day,max(value) as value from fhem.history where device='GPIO3' and reading='actualFullThermicEnergy'  group by day having max(timestamp))maxDayThermic
where
date_format(history.timestamp,'%Y%m%d') = minDayElectric.day and
date_format(history.timestamp,'%Y%m%d') = maxDayElectric.day and
date_format(history.timestamp,'%Y%m%d') = minDayThermic.day and
date_format(history.timestamp,'%Y%m%d') = maxDayThermic.day
group by date_format(history.timestamp,'%Y%m%d');


Output:

Tag	diff_energy	diff_thermic_energy	dayJAZ
20191114	15,423	64	4,15
20191115	9	37	4,11
20191117	10,5	44	4,19
20191118	11,5	49	4,26
20191119	15,5	64	4,13
20191120	12,837	51	3,97
20191121	10,675	41	3,84

[DS_Starter]

Guten morgen,

ja, man bekommt leicht einen Knoten ins Hirn. 

Also ich denke mit der von mir vorgeschlagenen Methode kommen wir in deinem speziellen Fall nicht zum Ziel.

Wann werden eigentlich die Teildifferenzen gebildet?

Es hängt davon ab, wieviele Werte in einem Aggregationszeitraum in der DB stehen, also wenn aggregation=day und in diesem Tageszeitraum stehen 50 Werte drin werden49 Teildifferenzen (50-1) gebildet und unter Berücksichtigung von "diffAccept" aufsummiert, stehen nur 2 drin für Tagesanfung und -ende, wird nur eine Differenz aus diesen beiden Werten gebildet.

Was ist das Kriterium dazu, die Aufsummierung durchzuführen? Hängt das mit dem "diffAccept" zusammen?

Es werden nur positive Differenzen aufsummiert, d.h. Voraussetzung ist ein stetig steigender Wert des ausgewerteten Values. Aber man kann unlogische "Unstetigkeitkeiten" wie Sprünge durch Messfehler etc. über das Attribut diffAccept ausblenden, sodass der über diffAccept liegende Wert ignoriert wird.
Bespiel: die Differenzen zwischen zwei Messwerten verbrauchter kWh liegt typisch zwischen 0,01 und 0,5. Eine plötzliche Diff von 1000 kann nicht richtig sein und wird mit dem default diffAccept=20 ausgefiltert. Diese Filterung wird im Device in einem Reading dokumentiert.

Kann man eine Art Option einbauen, dass bei diffValue der Wert "value" vom größten Timestamp, mit "value" des niedrigsten Timestamps subtrahiert wird?

Im Prinzip ja, aber weil das hier schon ein recht spezieller Anwendungsfall ist würde ich lieber eine der nachfolgenden Lösungsmöglichkeiten in Betracht ziehen.


Ein einfacher Fall wäre, wenn du je Aggregationszeitraum nur den Anfangs und Endwertwert, also z.B. Anfangswert und Endwert des Tages in der DB lässt und darüber dann diffvalue ausführst.
Die Bereinigung geht ganz einfach mit Bordmitteln:

    - setze das Attribut seqDoubletsVariance auf einen hohen Wer, z.B. 1000
    - setze Attribut aggragation = day
    - führe delSeqDoublets delete aus

Im Ergebnis verbleiben nur die Anfangs und Endwerte des jeweiligen (dynamisch berechneten) Aggregationszeitraums (day) in der Datenbank wenn seqDoubletsVariance hinreichend groß ist .
Wenn du in diesem DbRep-Device das Attribut "executeAfterProc = set <name> diffValue" ebenfalls setzt, wird nach der Bereinung der Db gleich der Differenzwert ermittelt.
Das Verfahren solltest natürlich vorher mal testen, d.h. ein Backup für den Notfall haben. 

Ansonsten geht natürlich auch das von dir dargestellte Statement über sqlCmd mit entsprechenden Weiterverabeitungen.
Schau mal welche Variante in Sachen Aufwand Weiterverabeitung dir am Besten ins Konzept passt. Das wärs dann denke ich.

LG,
Heiko
 

[h002]

Die Idee ist gut und ich werde es mit mit "delSeqDoublets" versuchen aufzubauen. Dies wollte ich ggf. gleich mit deiner beschriebenen seq. Befehlskette testen https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Abarbeitung_einer_sequentiellen_Befehlskette_mittels_non-blocking_sqlCmd-Kommandos.

Dazu noch eine Frage. Was passiert, wenn bei "Auswertung der 1. Operation" der "state" nicht "done" ist, weil das "insert" bei "Start der 1. Operation" noch nicht fertig verarbeitet wurde? In diesem Fall wäre doch nicht sichergestellt, dass die Befehlskette komplett abgearbeitet wird, oder?

[DS_Starter]

Dazu noch eine Frage. Was passiert, wenn bei "Auswertung der 1. Operation" der "state" nicht "done" ist, weil das "insert" bei "Start der 1. Operation" noch nicht fertig verarbeitet wurde? In diesem Fall wäre doch nicht sichergestellt, dass die Befehlskette komplett abgearbeitet wird, oder?

Wenn die Routine im Attribut "executeAfterProc" angestartet wird, ist der vorherige Befehl 100%ig fertig. Das ist im Code so sichergestellt. Möglich ist allerdings, dass der vorherige Befehl nicht erfolgreich war. Wenn man 1000%ig sicher gehen will, dann kann man eine Routine im Attribut userExitFn hinterlegen. In dieser Routine muss man dann selbst überprüfen ob state erst "running" und dann state="done" ist bzw. einen Fehlercode enthält.
Aber ich denke executeAfterProc  würde in diesem Fall ausreichen.

[h002]

Wenn man 1000%ig sicher gehen will, dann kann man eine Routine im Attribut userExitFn hinterlegen. In dieser Routine muss man dann selbst überprüfen ob state erst "running" und dann state="done" ist bzw. einen Fehlercode enthält.

Nur zum Verständnis, in dem erwähnten Beispiel prüfst du über

Code Auswählen Erweitern

if($reading eq "state" && $value eq "done")
ab, ob das "insert" erledigt ist. Was ist, wenn dies nicht auf "done" steht, sondern auf "running". Wie wird die sub "chain" dann noch mal angetriggert? Es wird ja dann nicht noch mal das Device "Rep.insert" mit  "userExitFn chain" ausgeführt, um in diesen Zweig das "done" verarbeiten zu können.

[DS_Starter]

Was ist, wenn dies nicht auf "done" steht, sondern auf "running". Wie wird die sub "chain" dann noch mal angetriggert? Es wird ja dann nicht noch mal das Device "Rep.insert" mit  "userExitFn chain" ausgeführt, um in diesen Zweig das "done" verarbeiten zu können.

Die in userExitFn angegebene Routine (chain in dem Beispiel) wird nach jeder Generierung eines Readings in dem Device aufgerufen. Also wenn wenn du mit "set ... irgendwas" einen Lauf startest, wird state auf running gesetzt und die Routine aufgerufen. Hier kannst du jetzt prüfen ob "running" Status wahr ist.
Nach dem Lauf wird bei jedem einzelnen erstellten Reading auch die Routine aufgerufen und ebenso wiederum nach dem Setzen von state, was du nun auf "done" prüfen kannst (oder eben einen Fehlerstatus).

Vielleicht muss ich das in der Doku noch besser herausstellen, da es augenscheinlich nicht so deutlich geworden ist.

LG,
Heiko

[h002]

Sehr gut, hab es verstanden. Mal sehen wie ich es umsetzen kann.

[h002]

Nun habe ich anhand deines Beispiels eine "chain" erstellt und bekomme eine Warnung, wo ich mir nicht sicher bin, ob diese negative Auswirkungen haben könnte.

Code Auswählen Erweitern


DbRep dbReportDimplexDailyThermicEnergy - WARNING - old process 4617 will be killed now to start a new BlockingCall


Logauszug komplett

Code Auswählen Erweitern


2019.11.24 00:15:00 1: dbReportDimplexDailyElectricEnergy - Starte delSeqDoublets
2019.11.24 00:15:00 1: IF-01 - writeDimplexValueToDB eq writeDimplexValueToDB && chainstart eq chainstart
2019.11.24 00:15:00 3: DbRep dbReportDimplexDailyElectricEnergy - rows deleted by "delSeqDoublets delete": 49
2019.11.24 00:15:00 1: IF-02 - state eq state && done eq done
2019.11.24 00:15:00 1: IF-03 - dbReportDimplexDailyElectricEnergy eq dbReportDimplexDailyElectricEnergy && delSeqDoublets delete eq delSeqDoublets delete
2019.11.24 00:15:00 1: dbReportDimplexDailyElectricEnergy - number_rows_deleted: 49
2019.11.24 00:15:00 3: DbRep dbReportDimplexDailyElectricEnergy - WARNING - old process 4615 will be killed now to start a new BlockingCall
2019.11.24 00:15:00 1: dbReportDimplexDailyElectricEnergy - Starte writeToDB diffValue
2019.11.24 00:15:00 3: DbRep dbReportDimplexDailyElectricEnergy - number of lines updated in "dbLog": 0
2019.11.24 00:15:00 3: DbRep dbReportDimplexDailyElectricEnergy - number of lines inserted into "dbLog": 1
2019.11.24 00:15:00 1: IF-02 - state eq state && done eq done
2019.11.24 00:15:00 1: IF-04 - dbReportDimplexDailyElectricEnergy eq dbReportDimplexDailyElectricEnergy && diffValue writeToDB eq diffValue writeToDB
2019.11.24 00:15:00 1: dbReportDimplexDailyElectricEnergy - db_lines_processed: 1
2019.11.24 00:15:00 1: dbReportDimplexDailyThermicEnergy - Starte delSeqDoublets delete
2019.11.24 00:15:00 3: DbRep dbReportDimplexDailyThermicEnergy - rows deleted by "delSeqDoublets delete": 48
2019.11.24 00:15:00 1: IF-02 - state eq state && done eq done
2019.11.24 00:15:00 1: IF-05 - dbReportDimplexDailyThermicEnergy eq dbReportDimplexDailyThermicEnergy && delSeqDoublets delete eq delSeqDoublets delete
2019.11.24 00:15:00 1: dbReportDimplexDailyThermicEnergy - number_rows_deleted: 48
2019.11.24 00:15:00 3: DbRep dbReportDimplexDailyThermicEnergy - WARNING - old process 4617 will be killed now to start a new BlockingCall
2019.11.24 00:15:01 1: dbReportDimplexDailyThermicEnergy - Starte writeToDB diffValue
2019.11.24 00:15:01 3: DbRep dbReportDimplexDailyThermicEnergy - number of lines updated in "dbLog": 0
2019.11.24 00:15:01 3: DbRep dbReportDimplexDailyThermicEnergy - number of lines inserted into "dbLog": 1
2019.11.24 00:15:01 1: IF-02 - state eq state && done eq done
2019.11.24 00:15:01 1: IF-06 - dbReportDimplexDailyThermicEnergy eq dbReportDimplexDailyThermicEnergy && diffValue writeToDB eq diffValue writeToDB


Sub-Routing

Code Auswählen Erweitern


sub dimplexChain{
my ($name,$reading,$value) = @_;
my $hash = $defs{$name};
my $rc;

#Initialer Aufruf zum Start der Ablauflogik über ein at-Device (writeDimplexValueToDB)
if ($name eq "writeDimplexValueToDB" && $reading eq "chainstart"){
CommandSet(undef,"dbReportDimplexDailyElectricEnergy delSeqDoublets delete");
Log3 $name, 1, "dbReportDimplexDailyElectricEnergy - Starte delSeqDoublets";
Log3 $name, 1, "IF-01 - $name eq writeDimplexValueToDB && $reading eq chainstart";
      return;
}
#Wenn des Status des aufrufenden Rep-Devices auf "done" steht
if($reading eq "state" && $value eq "done"){
Log3 $name, 1, "IF-02 - $reading eq state && $value eq done";
if ($name eq "dbReportDimplexDailyElectricEnergy" && $hash->{LASTCMD} eq "delSeqDoublets delete"){
Log3 $name, 1, "IF-03 - $name eq dbReportDimplexDailyElectricEnergy && $hash->{LASTCMD} eq delSeqDoublets delete";
$rc = ReadingsVal($name, "number_rows_deleted", "");
Log3 $name, 1, "$name - number_rows_deleted: $rc";
CommandSet(undef,"dbReportDimplexDailyElectricEnergy diffValue writeToDB");
Log3 $name, 1, "$name - Starte writeToDB diffValue";
return;
}
if ($name eq "dbReportDimplexDailyElectricEnergy" && $hash->{LASTCMD} eq "diffValue writeToDB"){
Log3 $name, 1, "IF-04 - $name eq dbReportDimplexDailyElectricEnergy && $hash->{LASTCMD} eq diffValue writeToDB";
$rc = ReadingsVal($name, "db_lines_processed", "");
Log3 $name, 1, "$name - db_lines_processed: $rc";
# Start der 2. Operation (select)
CommandSet(undef,"dbReportDimplexDailyThermicEnergy delSeqDoublets delete");
Log3 $name, 1, "dbReportDimplexDailyThermicEnergy - Starte delSeqDoublets delete";
return;
}
if ($name eq "dbReportDimplexDailyThermicEnergy" && $hash->{LASTCMD} eq "delSeqDoublets delete"){
Log3 $name, 1, "IF-05 - $name eq dbReportDimplexDailyThermicEnergy && $hash->{LASTCMD} eq delSeqDoublets delete";
$rc = ReadingsVal($name, "number_rows_deleted", "");
Log3 $name, 1, "$name - number_rows_deleted: $rc";
# Start der 2. Operation (select)
CommandSet(undef,"dbReportDimplexDailyThermicEnergy diffValue writeToDB");
Log3 $name, 1, "$name - Starte writeToDB diffValue";
return;
}
if ($name eq "dbReportDimplexDailyThermicEnergy" && $hash->{LASTCMD} eq "diffValue writeToDB"){
Log3 $name, 1, "IF-06 - $name eq dbReportDimplexDailyThermicEnergy && $hash->{LASTCMD} eq diffValue writeToDB";
$rc = ReadingsVal($name, "db_lines_processed", "");
Log3 $name, 1, "$name - db_lines_processed: $rc";
return;
}
return;
}
}



[DS_Starter]

Hi,

Nun habe ich anhand deines Beispiels eine "chain" erstellt und bekomme eine Warnung, wo ich mir nicht sicher bin, ob diese negative Auswirkungen haben könnte.

Die Meldung kannst du in deinem Fall erstmal ignorieren. Aber sie ist unschön, irritiert und ich werde den Code etwas korrigieren. Wenn ich heute noch dazu komme, stelle ich dir nachher eine Version zur Verfügung die ich dich bitte bei dir zu testen.
Hintergrund: Im vorliegenden Fall "denkt" DbRep dass der laufende Prozess noch nicht abgeschlossen ist, was aber nicht stimmt. Das ist nur ein Reihenfolgeproblem des internen Codes. Diese Meldung bekommt man zum Beispiel nicht, wenn verschiedene DbRep-Devices in eine Chain eingebunden werden.

Grüße,
Heiko

[h002]

Sehr gut. Das mit dem Test ist kein Problem. Einfach Bescheid geben und ich lege los.

[DS_Starter]

So, erledigt.

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:

Code Auswählen Erweitern


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


Danach ein reload oder restart.
Die Warnung sollte nun nicht mehr erscheinen (in diesem Fall).

[h002]

Funktioniert, es kommt für diesen Fall keine Warnung mehr. Vielen Dank!

[DS_Starter]

Prima, dann checke ich die Version auch ein und ist morgen früh im Regelupdate.