[Gelöst]Ergebnis einer Berechnung mit DbRep fehlerhaft, wo ist das Problem?

[Rewe2000]

Hallo,

da brauche ich echt mal Hilfe von den Experten.
Mir ist eben durch Zufall aufgefallen, als ich meine Stromzählerwerte geprüft habe, dass es Differenzen in der Berechnung gibt.

Berechne ich z.B. die Stromeinspeisung mit dem Taschenrechner, erhalte ich 931,2889 kWh, DbRep dagegen kommt auf ein Ergebnis von 950.3660 kWh.
Abweichungen treten auch bei anderen Readings auf.

Rechne ich da irgend etwas falsch, es kann ja nicht sein, dass dbRep hier Probleme hat.
Der zur Berechnung ausgewählte Monat hat 2640 Datensätze mit bis zu 11 Nachkommastellen in der MySQL Datenbank.
Kann sich die Differenz aus den Nachkommastellen ergeben?

Code Auswählen Erweitern


2020-06-01 00:00:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;Netzeinspeisung_kWh: 1275.68899154936;Netzeinspeisung_kWh;1275.68899154936;
2020-05-31 23:58:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;Netzeinspeisung_kWh: 1275.68895332204;Netzeinspeisung_kWh;1275.68895332204;
2020-05-31 23:56:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;Netzeinspeisung_kWh: 1275.68891496247;Netzeinspeisung_kWh;1275.68891496247;
2020-05-31 23:54:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;Netzeinspeisung_kWh: 1275.68888030651;Netzeinspeisung_kWh;1275.68888030651;
............
............
2020-05-01 02:30:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;rl_av_h;Netzeinspeisung_kWh;344.409;
2020-05-01 01:30:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;rl_av_h;Netzeinspeisung_kWh;344.408;
2020-05-01 00:30:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;rl_av_h;Netzeinspeisung_kWh;344.407;
2020-04-30 23:30:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;rl_av_h;Netzeinspeisung_kWh;344.405;

Anbei ein List meines DbRep Device:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        DBLogging
   FUUID      5ef8a206-f33f-7df9-1576-dd0442ba24b1d495
   FVERSION   93_DbRep.pm:v8.40.1-s21965/2020-05-18
   LASTCMD    diffValue display
   MODEL      Client
   NAME       DBRep_Test_letzter_Monat
   NOTIFYDEV  global,DBRep_Test_letzter_Monat
   NR         7413
   NTFY_ORDER 50-DBRep_Test_letzter_Monat
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE DBLogging
     GRANTS     INSERT,SELECT,FILE,DELETE,UPDATE
     IDRETRIES  2
     MINTS      2019-06-23 05:00:00
     PACKAGE    main
     SQLHIST   
     VERSION    8.40.1
     CV:
       aggregation no
       aggsec     1
       destr      2020-05-31
       dsstr      2020-05-01
       epoch_seconds_end 1590962399
       mestr      05
       msstr      05
       testr      23:59:59
       tsstr      00:00:00
       wdadd      259200
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1593352710.85493
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2020-06-28 16:09:27   2020-05-31_23-58-00__Netzuebergabepunkt_Leistung__Netzeinspeisung_kWh__DIFF__no_aggregation 950.3660
     2020-06-28 16:09:27   background_processing_time 0.3330
     2020-06-28 16:09:27   sql_processing_time 0.1822
     2020-06-28 16:09:27   state           done
Attributes:
   DbLogExclude .*
   aggregation no
   devStateIcon connected:Restart .*disconnect:message_attention .*done:StandBy
   device     Netzuebergabepunkt_Leistung
   event-on-update-reading state
   fastStart  1
   icon       it_nas@green
   reading    Netzeinspeisung_kWh
   room       Test
   showproctime 1
   timeout    180
   timestamp_begin 2020-05-01 00:00:00
   timestamp_end 2020-05-31 23:59:59
   verbose    2

Ich habe dieses nur in Minimalkonfiguration erstellt, um den "Fehler" zu reproduzieren.
Auch habe ich bewusst nicht alle 2600 Datensätze der Datenbank mit angehängt, kann ich aber zu Testzwecken gerne zur Verfügung stellen.

Ich würde mir wünschen, hierfür gibt es eine einfache Erklärung.

Gruß Reinhard

[DS_Starter]

Hallo Reinhard,

erstmal die gute Nachricht, DbRep rechnet per se nicht falsch. Habe es zur Sicherheit mit meinem Energymeter und den gleichen Einstellungen wie bei dir durchgeführt. Die manuell ermittelte Diff zwischen End- und Anfangswert und der mit DbRep errechnete Wert waren identisch.

Aber DbRep rechnet nicht einfach Endwert - Anfangswert, sondern erstellt intern aus den verfügbaren Datensätzen Einzeldifferenzen die geprüft und aufsummiert werden.
Das hat einerseits mit notwendigen Werteübertragungen zu tun wenn eine aggregation eingestellt ist und außerdem sollen Nulldurchgänge sowie außergewöhnlich hohe Einzeldifferenzen (siehe Attr diffAccept) erkannt und entsprechend behandelt werden.

Jetzt ist natürlich die Frage woher bei dir die Abweichung kommt. Ein Check wäre dies:

1. stelle im DbRep verbose 5 ein und lasse diffValue laufen. Es wird sehr viele Ausschriften zu den Einzelschritten geben. Ganz am Ende findest du einen Logeintrag "count of values used for calc":

Code Auswählen Erweitern


2020.06.28 18:18:30.206 4: DbRep Rep.SMAEM.Einspeisung - count of values used for calc:
2020.06.28 18:18:30.206 4: no_aggregation => 43862


2. führe mit diesem Device eine countEntries aus. Das Ergebnis sollte identisch sein mit dem Ergebnis "count of values used for calc":

Code Auswählen Erweitern


2020-06-28 21:10:33   2020-05-01__COUNT_history__no_aggregation 43862


Als nächsten Check führe mit diesem Device ein fetchrows aus und schaue nach Doubletten (siehe commandref fetchrows).
Wenn es sie gibt, kannst du sie löschen mit "delDoublets delete".
Vielleicht findest du mit fetchrows auch andere Unregelmäßigkeiten die dir auffallen.

DbRep geht bei diffValue davon aus, dass im Normalfall der Wert aufeianderfolgender Datensätze sich beständig erhöht.
Es könnte bei dir zum Beispiel sein, dass ein erreichter Messwert (a) auf einen tieferen Wert sinkt (b) sinkt um danach erneut den Wert (a) zu erreichen. Dadurch würde die Differenz (a - b) zweimal auftreten und aufsummiert werden, was zu einem Wertefehler führen würde.
Dieses Szenario darf aber bei einem stetigen Zähler garnicht auftauchen.
Soweit erstmal zur Theorie.
Bei dir ist mir aber augefallen, dass sich der Aufbau der Datensätze zwischen dem 01.05. und dem 31.05. unterscheidet:

Code Auswählen Erweitern


2020-05-01 00:30:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;rl_av_h;Netzeinspeisung_kWh;344.407;
2020-05-31 23:58:00;Netzuebergabepunkt_Leistung;MODBUSREGISTER;Netzeinspeisung_kWh: 1275.68895332204;Netzeinspeisung_kWh;1275.68895332204;


Dazwischen scheint irgendetwas verändert worden zu sein. Speziell "rl_av_h;Netzeinspeisung_kWh;344.407" entgegen "Netzeinspeisung_kWh: 1275.68895332204;Netzeinspeisung_kWh;1275.68895332204"

Grüße,
Heiko

[Rewe2000]

Hallo Heiko,

zunächst mal vielen Dank für deine ausführliche Antwort.

erstmal die gute Nachricht, DbRep rechnet per se nicht falsch.

Ich hatte schon spekuliert, dass der Fehler bei DbRep liegt, dann müsste nicht ich bei mir den Fehler finden

Deine Vorschläge zur Fehlereingrenzung habe ich befolgt.

Im Log finde ich bei mir:

Code Auswählen Erweitern

2020.06.29 14:55:19 4: DbRep DBRep_Test_letzter_Monat - count of values used for calc:
2020.06.29 14:55:19 4: no_aggregation => 1970

countEntries ergibt bei mir:

Code Auswählen Erweitern

2020-05-01__COUNT_history__no_aggregation           1970     2020-06-29 15:03:38

fetchrows zeigt bei mir auch alle 1970 Datensätze, ohne jegliche Auffälligkeiten (Dubletten, etc.)

Auch unter meinem SQL Programm unter WIN10, (Heidi-SQL) werden mir mit folgender Abfrage 1970 Datensätze angezeigt:

Code Auswählen Erweitern

DEVICE = 'Netzuebergabepunkt_Leistung' AND `READING`='Netzeinspeisung_kWh' AND `TIMESTAMP`>'2020-05-01 00:00:00'AND `TIMESTAMP`<'2020-05-31 23:59:59'

Ich bin nun einen Schritt weiter gegangen und habe die 1970 Datensätze nach Excel exportiert, da kenn ich mich gut aus und kann nach Auffälligkeiten suchen.
Hier habe ich den Fehler gefunden, es waren einige Werte in den Datensätzen, welche minimal kleinere Werte enthielten, als der vorhergehende Datensatz. Dies sollte bei einem aufsteigenden Zähler ja nicht vorkommen. Somit kann ich mir die Abweichungen in der Berechnung erklären und kann wieder ruhig schlafen.
Woher die fehlerhaften Werte kamen, kann ich zum jetzigen Zeitpunkt leider nicht mehr feststellen.

Hinweis:
Alle Daten mit dem Zusatz "rl_av_h" waren bereits von DbRep "reduceLog average" berechnete Mittelwerte.
Dies habe ich nun umgestellt. Ich berechne nun mit DbRep zuerst meine Tages und Monatswerte, schreibe diese über ein dummyDevice wieder in die SQL-Datenbank und lösche mit DbRep dann regelmäßig die "Rohdaten", damit meine SQL-Datenbank auf meinem Raspi3 nicht "Explodiert".

Heiko nochmals vielen Dank für die vielen Denkanstöße, ich hatte gestern ähnliches vermutet, aber meine Daten nur überflogen, deshalb habe ich die geringen Abweichungen nicht gesehen.

Gruß Reinhard

[stera]

Hallo Heiko,

gibt es hier vllt eine Möglichkeit um genau das zu machen:
Aber DbRep rechnet nicht einfach Endwert - Anfangswert, sondern erstellt intern aus den verfügbaren Datensätzen Einzeldifferenzen die geprüft und aufsummiert werden.

Also zwischen Anfang und Endwert die Differenz zu berechnen ohne die Zwischenwerte zu berücksichtigen?

Viele Grüße,
Stefan

[DS_Starter]

Naja, man muß "nur" dafür sorgen dass es keine Zwischenwerte in einer Aggregationsperiode (day, week, hour etc.) gibt.
Das kann man vorab mit einem Lauf "delSeqDoublets" mit entsprechend eingestellten Attributen (aggregation, seqDoubletsVariance !) erreichen.

Grüße,
Heiko

[stera]

Naja, man muß "nur" dafür sorgen dass es keine Zwischenwerte in einer Aggregationsperiode (day, week, hour etc.) gibt.
Das kann man vorab mit einem Lauf "delSeqDoublets" mit entsprechend eingestellten Attributen (aggregation, seqDoubletsVariance !) erreichen.

Grüße,
Heiko

Geht das nur über Daten löschen? Das komische ist, dass die Werte ja in den Berechnungen anders sind. Zum Bespiel bei einem Jahresverbrauch bei Gas habe ich über HeidiSQL ca.. 645m³ errechnet und über Grafana bei 365Tagen zeigt er mir auch die 645m² an. In DBRep komme ich bei 365Tagen (TimetoDiff) auf 660m³..

Gruß,
Stefan

[DS_Starter]

Hallo Stefan,

setz dir doch mal verbose 5 im Device und schaue dir die SQL-Statements sowie deren Ergebnisse an.
Welche SQLs verwendest du denn in Heidi bzw. Grafana ?

LG

[stera]

Hi Heiko,

hier habe ich auch den Fehler gefunden. Manchmal kommen wohl alte Werte in die Datenbank und dann gibt es beim aufsummieren Probleme. Habe nun den diff_limit auf "1" gesetzt. Dann bin ich bei 648m³. Damit kann ich leben.

Code Auswählen Erweitern


|| *TIMESTAMP* || *DEVICE* || *TYPE* || *EVENT* || *READING* || *VALUE* || *UNIT* ||
|| 2022-01-06 09:37:28 || HM_Zaehlersensor_Gas || DUMMY || gas_total_m3: 4990.84000000609 || gas_total_m3 || 4990.84000000609 ||  ||
|| 2022-01-06 09:34:49 || HM_Zaehlersensor_Gas || DUMMY || gas_total_m3: 4990.83000000609 || gas_total_m3 || 4990.83000000609 ||  ||
|| 2022-01-06 09:30:32 || HM_Zaehlersensor_Gas || DUMMY || gas_total_m3: 4990.82000000609 || gas_total_m3 || 4990.82000000609 ||  ||
|| 2022-01-06 09:30:31 || HM_Zaehlersensor_Gas || DUMMY || gas_total_m3: 4988.53000000609 || gas_total_m3 || 4988.53000000609 ||  ||
|| 2022-01-06 09:20:15 || HM_Zaehlersensor_Gas || DUMMY || gas_total_m3: 4990.82000000614 || gas_total_m3 || 4990.82000000614 ||  ||
|| 2022-01-06 09:18:35 || HM_Zaehlersensor_Gas || DUMMY || gas_total_m3: 4988.55000000609 || gas_total_m3 || 4988.55000000609 ||  ||
|| 2022-01-06 09:18:02 || HM_Zaehlersensor_Gas || DUMMY || gas_total_m3: 4990.82000000614 || gas_total_m3 || 4990.82000000614 ||  ||
|| 2022-01-06 09:15:35 || HM_Zaehlersensor_Gas || DUMMY || gas_total_m3: 4990.81000000613 || gas_total_m3 || 4990.81000000613 ||  ||




[DS_Starter]

Hallo Stefan,

Ja das ist blöd. Normalerweise sollte HM_Zaehlersensor_Gas ein kontinuierlich aufwärts zählender Zähler sein.
Ein Wechsel von 4990.82000000614 nach 4988.55000000609 und dann wieder zurück nach 4990.82000000614 ist nicht sehr kontinuierlich. Es wäre sinvoll herauszubekommen wieso dieser Zähler sich so verhält und evtl. zu lösen. Dann wäre die eigentliche Ursache eliminiert.

Edit: Alternativ könnte man sich ein userreading erzeugen welches nur dann gesetzt wird wenn der Zähler größer ist als der bestehende Wert im userreading. Das userreading würde man dann loggen weil es mit Sicherheit kontinuierlich hoch zählt.

[stera]

Hallo Stefan,

Ja das ist blöd. Normalerweise sollte HM_Zaehlersensor_Gas ein kontinuierlich aufwärts zählender Zähler sein.
Ein Wechsel von 4990.82000000614 nach 4988.55000000609 und dann wieder zurück nach 4990.82000000614 ist nicht sehr kontinuierlich. Es wäre sinvoll herauszubekommen wieso dieser Zähler sich so verhält und evtl. zu lösen. Dann wäre die eigentliche Ursache eliminiert.

Edit: Alternativ könnte man sich ein userreading erzeugen welches nur dann gesetzt wird wenn der Zähler größer ist als der bestende Wert im userreading. Das userreading würde man dann loggen weil es mit Sicherheit kontinuierlich hoch zählt.

Ja daran muss ich nochmal arbeiten. Habe damals ein Userreading für die Homematiczähler angelegt:

userReadings gas_total_m3 monotonic { ReadingsVal("$name","gasCnt",0)}

und summiere es ständig auf, um nach einen Batteriewechsel etc. nicht ein Offset neu setzen zu müssen. Die Werte gehen dann per MQTT an eine andere FHEM Instanz und nach einem Neustart des Servers schickt MQTT wohl einmal den Anfangswert vom Tag oder so ähnlich 

[DS_Starter]

Ich würde es so probieren:

Code Auswählen Erweitern


userReadings gas_total_m3:gasCnt {
     my $ov = ReadingsVal("$name","gas_total_m3",0);
     my $va = ReadingsVal("$name","gasCnt",0);
     if ($va > $ov) {
        $va;
     }
     else {
        $ov;
     }
}


[stera]

Aber ich brauch ja die Aufsummierung. Der Wert "gasCnt" vom HomematicZähler stimmt mit dem richtigen GasZähler nicht überein.

Code Auswählen Erweitern


   READINGS:
     2022-04-03 21:12:59   1.ENERGY_COUNTER 0
     2022-04-03 21:12:59   1.POWER         0
     2022-04-03 21:12:36   IODev           d_ccu
     2022-04-03 21:12:59   activity        alive
     2022-04-03 21:12:59   battery         ok
     2022-04-03 21:13:23   gasCnt          1868.4
     2022-04-03 21:13:23   gasPower        0.024
     2022-04-03 21:13:23   gas_total_m3    5260.39000001078
     2022-04-03 21:13:23   hmstate         Initialized
     2022-04-03 21:12:59   rssidevice      -255
     2022-04-03 21:12:59   rssipeer        -68
     2022-04-03 21:12:59   sign            off
     2019-12-20 22:22:24   state           Initialized


Habe gerade ein Workaround gefunden und nun scheint das Problem bei einem Neustart nicht mehr vor zu kommen.
https://forum.fhem.de/index.php?topic=83526.0

Gruß,
Stefan

[DS_Starter]

Sollte ja nur als Idee / Grundgerüst dienen. Viele Wege führen zum Ziel. 

[stera]

Ja vielen Dank. Bin auch immer sehr dankbar für deine Hilfe und schnelle Umsetzung 

Hab noch einen schönen Abend.

[DS_Starter]

Danke Stefan, das wünsche ich dir auch 

LG