DBrep - Löschen von on und Off Werten

Begonnen von Sidey, 21 Juli 2023, 19:11:41

Vorheriges Thema - Nächstes Thema

Sidey

Hi,

Ich hätte da mal ein Problem.

Ich habe MQTT2 Devices die einen Status  von einem Relais loggen.

Der ist entweder on oder Off.

Geloggt wird alle 5 Minuten und bei einem Statuswechsel sofort.

Ich möchte die doppelten Meldungen vom Vortag löschen. Dazu verwende ich "delSeqDoublets"

Die löscht aber zu viel weg.
Das kann man am Beispiel "MagnetventilBlumen" "POWER2" sehen.
Um 10:00 Uhr wird eingeschaltet und um 10:02 wird es wieder ausgeschaltet. Allerdings wird der Eintrag um 10:02 gelöscht und dann sieht es so aus, als ob es erst um 19:00 auf OFF geht.


define DBRep.au.Magnetventil DbRep LoggingDB
attr DBRep.au.Magnetventil aggregation minute
attr DBRep.au.Magnetventil allowDeletion 1
attr DBRep.au.Magnetventil device au.Magnetventil.*
attr DBRep.au.Magnetventil event-on-update-reading state
attr DBRep.au.Magnetventil fastStart 1
attr DBRep.au.Magnetventil fetchMarkDuplicates red
attr DBRep.au.Magnetventil group DB
attr DBRep.au.Magnetventil reading POWER%
attr DBRep.au.Magnetventil room system->Datenbank
attr DBRep.au.Magnetventil showproctime 1
attr DBRep.au.Magnetventil timestamp_begin previous_day_begin
attr DBRep.au.Magnetventil timestamp_end previous_day_end
#   CFGFN     
#   DATABASE   fhem
#   DEF        LoggingDB
#   FUUID      64b83ab0-f33f-f610-89af-deb0b2c9d7901542
#   FVERSION   93_DbRep.pm:v8.52.3-s27396/2023-04-05
#   LASTCMD    delSeqDoublets adviceRemain
#   MODEL      Client
#   NAME       DBRep.au.Magnetventil
#   NOTIFYDEV  global,DBRep.au.Magnetventil
#   NR         44498
#   NTFY_ORDER 50-DBRep.au.Magnetventil
#   ROLE       Client
#   STATE      done
#   TYPE       DbRep
#   UTF8       1
#   eventCount 23
#   HELPER:
#     DBLOGDEVICE LoggingDB
#     GRANTS     FILE,DELETE,INSERT,SELECT,UPDATE
#     IDRETRIES  2
#     MINTS      2019-06-23 20:41:58
#     PACKAGE    main
#     VERSION    8.52.3
#     CV:
#       aggregation minute
#       aggsec     60
#       destr      2023-07-20
#       dsstr      2023-07-20
#       epoch_seconds_end 1689890399
#       mestr      07
#       msstr      07
#       testr      23:59:59
#       tsstr      00:00:00
#       wdadd      345600
#       yestr      2023
#       ysstr      2023
#     DBREPCOL:
#       COLSET     1
#       DEVICE     64
#       EVENT      512
#       READING    64
#       TYPE       64
#       UNIT       32
#       VALUE      128
#   OLDREADINGS:
#   READINGS:
#     2023-07-21 06:58:23   2023-07-20_00-00-43__au.MagnetventilBlumen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_00-00-43__au.MagnetventilRasen__POWER1 OFF
#     2023-07-21 06:58:23   2023-07-20_09-55-44__au.MagnetventilBlumen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_10-00-00__au.MagnetventilRasen__POWER2 ON
#     2023-07-21 06:58:23   2023-07-20_10-00-44__au.MagnetventilBlumen__POWER2 ON
#     2023-07-21 06:58:23   2023-07-20_10-02-00__au.MagnetventilRasen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_10-05-30__au.MagnetventilRasen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_18-55-45__au.MagnetventilBlumen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_19-00-00__au.MagnetventilRasen__POWER2 ON
#     2023-07-21 06:58:23   2023-07-20_19-00-45__au.MagnetventilBlumen__POWER2 ON
#     2023-07-21 06:58:23   2023-07-20_19-02-00__au.MagnetventilRasen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_19-05-30__au.MagnetventilRasen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_22-10-45__au.MagnetventilBlumen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_22-10-45__au.MagnetventilRasen__POWER1 OFF
#     2023-07-21 06:58:23   2023-07-20_22-11-01__au.MagnetventilRasen__POWER1 ON
#     2023-07-21 06:58:23   2023-07-20_22-11-24__au.MagnetventilBlumen__POWER2 ON
#     2023-07-21 06:58:23   2023-07-20_22-11-24__au.MagnetventilRasen__POWER2 ON
#     2023-07-21 06:58:23   2023-07-20_22-11-25__au.MagnetventilRasen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_23-55-45__au.MagnetventilBlumen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_23-55-45__au.MagnetventilRasen__POWER1 OFF
#     2023-07-21 06:58:23   number_rows_to_remain 22
#     2023-07-21 06:58:23   state           done
#

Es sollten doch bei Statuswechsel die Werte erhalten bleiben.

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

DS_Starter

Moin,

ich habe nach einer Weile hinschauen ein Theorie.
Hier sind mal nur die Datensätze von MagnetventilBlumen herausgezogen:

#     2023-07-21 06:58:23   2023-07-20_00-00-43__au.MagnetventilBlumen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_09-55-44__au.MagnetventilBlumen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_10-00-44__au.MagnetventilBlumen__POWER2 ON
#     2023-07-21 06:58:23   2023-07-20_18-55-45__au.MagnetventilBlumen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_19-00-45__au.MagnetventilBlumen__POWER2 ON
#     2023-07-21 06:58:23   2023-07-20_22-10-45__au.MagnetventilBlumen__POWER2 OFF
#     2023-07-21 06:58:23   2023-07-20_22-11-24__au.MagnetventilBlumen__POWER2 ON
#     2023-07-21 06:58:23   2023-07-20_23-55-45__au.MagnetventilBlumen__POWER2 OFF

Mit delSeqDoublets adviceRemain werden die Datensätze angezeigt, die erhalten bleiben.
Um 10:00:44 wird eingeschaltet (grün) und um 18:55:45 aus (rot).
Jetzt gibt es offensichtlich noch ein ausschalten um 10:02 wie du schreibst, der gelöscht wird. Das wäre aus Sicht des Moduls richtig sofern zwischen 10:02 und dem OFF um 18:55:45 nicht nochmal ein ON kommt.

Das ist hier leider nicht zu sehen. Man müßte dazu den Ausgangszustand, also ein fetchrows, dagegenhalten.
Rein von der hier sichtbaren Abfolge her bleiben die Statuswechsel so erhalten wie sie sollen.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Sidey

Ich habe noch ein wenig herum experimentiert.

Wenn ich mir adviceRemain and adviceDelete ansehe, dann sieht das so aus, wie ich es brauche.
Wenn ich dann aber delete ausführe, fehlt meiner Meinung nach wieder zu viel.


Ich habe die Logdaten vorher gesichert:
https://paste.c-net.org/VictorLurking

Ich habe mit aggregation ein wenig getetset, der Wert "day" scheint mir am passendsten.

2023-07-22_00-01-10__1__au.MagnetventilBlumen__POWER2 OFF
2023-07-22_00-01-10__1__au.MagnetventilRasen__POWER1 OFF
2023-07-22_09-56-12__1__au.MagnetventilBlumen__POWER2 OFF
2023-07-22_10-01-12__1__au.MagnetventilBlumen__POWER2 ON
2023-07-22_18-56-13__1__au.MagnetventilBlumen__POWER2 OFF
2023-07-22_19-01-12__1__au.MagnetventilBlumen__POWER2 ON
2023-07-22_23-56-13__1__au.MagnetventilBlumen__POWER2 OFF
2023-07-22_23-56-13__1__au.MagnetventilRasen__POWER1 OFF

Es fehlt der Wert "OFF" : "2023-07-22 10:02:00","au.MagnetventilBlumen","MQTT2_DEVICE","POWER2: O


define DBRep.au.Magnetventil DbRep LoggingDB
attr DBRep.au.Magnetventil aggregation day
attr DBRep.au.Magnetventil allowDeletion 1
attr DBRep.au.Magnetventil device au.Magnetventil.*
attr DBRep.au.Magnetventil event-on-update-reading state
attr DBRep.au.Magnetventil fastStart 1
attr DBRep.au.Magnetventil fetchMarkDuplicates red
attr DBRep.au.Magnetventil group DB
attr DBRep.au.Magnetventil reading POWER%
attr DBRep.au.Magnetventil room system->Datenbank
attr DBRep.au.Magnetventil showproctime 1
attr DBRep.au.Magnetventil timestamp_begin previous_day_begin
attr DBRep.au.Magnetventil timestamp_end previous_day_end

Mach ich was falsch oder ist das ein Bug?

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

DS_Starter

Deine Daten habe ich mal bei mir importiert und konnte dadurch das Problem identifizieren.

Problematisch sind diese absolut zeitgleichen und vom Wert identischen Datensätze:

"2023-07-22 10:02:00","au.MagnetventilBlumen","MQTT2_DEVICE","POWER2: OFF","POWER2","OFF",""
"2023-07-22 10:02:00","au.MagnetventilBlumen","MQTT2_DEVICE","POWER2: OFF","POWER2","OFF",""

Wenn du genau hinschaust, erscheint dieser Datensatz sowohl bei adviceRemain als auch bei adviceDelete.
Das Modul will den ersten dieser Sätze behalten und den zweiten löschen. Das entspricht der Logik.
Allerdings löscht das delete-Statement natürlich beide Sätze, denn delete arbeitet die Liste von adviceDelete ab und da beide absolut (leider auch der Zeitstempel) gleich sind, werden beide gelöscht.

Zur Lösung des Problems habe ich zunächst ein delDoublets ausgeführt um solche Daten zu eliminieren. Es gibt noch ein paar mehr solcher Paare.
Danach habe ich delSeqDoublets ausgeführt und erhalte dann das erwartete Ergebnis:

   READINGS:
     2023-07-23 19:44:24   2023-07-22_09-51-12__1__au.MagnetventilBlumen__POWER2 OFF
     2023-07-23 19:44:24   2023-07-22_09-56-12__1__au.MagnetventilBlumen__POWER2 OFF
     2023-07-23 19:44:24   2023-07-22_10-00-00__1__au.MagnetventilBlumen__POWER2 ON
     2023-07-23 19:44:24   2023-07-22_10-01-12__1__au.MagnetventilBlumen__POWER2 ON
     2023-07-23 19:44:24   2023-07-22_10-02-00__1__au.MagnetventilBlumen__POWER2 OFF
     2023-07-23 19:44:24   2023-07-22_18-56-13__1__au.MagnetventilBlumen__POWER2 OFF
     2023-07-23 19:44:24   2023-07-22_19-00-00__1__au.MagnetventilBlumen__POWER2 ON
     2023-07-23 19:44:24   2023-07-22_19-01-12__1__au.MagnetventilBlumen__POWER2 ON
     2023-07-23 19:44:24   2023-07-22_19-02-00__1__au.MagnetventilBlumen__POWER2 OFF
     2023-07-23 19:44:24   2023-07-22_23-56-13__1__au.MagnetventilBlumen__POWER2 OFF
     2023-07-23 19:44:24   background_processing_time 0.0091
     2023-07-23 19:44:24   number_fetched_rows 10
     2023-07-23 19:44:24   sql_processing_time 0.0011
     2023-07-23 19:44:24   state           done

Du kannst das Problem so lösen wie eben gezeigt. Besser wäre es wenn die Duplikate erst garnicht in der Datenbank entstehen würden. event-on-change-reading kann man allerdings nicht verwenden, sonst hat man nicht den letzten gleichen Status vor einem Wechsel in der DB.
Musst du mal schauen wo das eventuell herkommt.
Noch besser wäre es wenn ich auch Millisekunden im Zeitstempel in der DB loggen würde. Dann hätte man keine Doubletten, denn im Millisekundenbereich wären die Datensätze sicher nicht identisch.
Mal schauen ob ich mich mal daran setze wenn ich mich mit DbLog mal wieder beschäftige.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Sidey

Danke für die Untersuchung.

Ich weiss nicht genau wie die Datensätze selektiert werden, aber vielleicht reicht ein Zusatz "limit 1" beim Löschen.

Wenn ich das ganze richtig verstanden habe, dann sollte es schon reichen, wenn ich nicht um 10:00 Uhr sondern um 10:02 Uhr schalte.
Naja, morgen Abend weiss ich dann mehr

Grüße
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

betateilchen

Zitat von: DS_Starter am 23 Juli 2023, 20:04:00Noch besser wäre es wenn ich auch Millisekunden im Zeitstempel in der DB loggen würde. Dann hätte man keine Doubletten, denn im Millisekundenbereich wären die Datensätze sicher nicht identisch.

Darauf wetten solltest Du besser nicht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

DS_Starter

#6
@betateilchen,

ZitatDarauf wetten solltest Du besser nicht.
Nein, so vermessen bin ich nicht. Aber anschauen würde ich mir das vllt. mal.

@sidey,

Zitatich weiss nicht genau wie die Datensätze selektiert werden, aber vielleicht reicht ein Zusatz "limit 1" beim Löschen.
Nein, leider nicht. Solche Datensätze wie oben beschrieben können durchaus auch irgendwo in der Mitte zwischen den Statuswechseln vorkommen die man durchaus alle löschen möchte.
Edit: Allerdings könnte dem Problem vorgebeugt werden wenn ich vor dem Lauf von delSeqDoublets  intern ein delDoublets vorausgeschickt wird. Das müsste ich mir aber erstmal anscjauen und durch den Kopf gehen lassen.

ZitatWenn ich das ganze richtig verstanden habe, dann sollte es schon reichen, wenn ich nicht um 10:00 Uhr sondern um 10:02 Uhr schalte.
Wann du schaltest ist egal. Störend ist hier, dass direkt nach dem Statuswechsel zwei absolut identische Datensätze (Events) mit dem gleichen Wert und Zeitstempel erzeugt werden.
Der Grund dafür liegt m.M. nach im Quellendevice.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Sidey

Es ist ein Shelly auf dem Tasmota läuft und der sendet per MQTT.

Ich habe da auch schon geschaut ob ich ihm abgewöhnen kann zwei Nachrichten zeitlich so dicht hintereinander zu senden aber nichts gefunden.

Mit event-on müsste ich das aber sicherlich hinbekommen dass nur ein Wert pro Sekunde ein Event erzeugt.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

DS_Starter

event-min-interval wäre vllt. die Lösung. Oder wenn du global agieren willst gibt es im DbLog ein Attr defaultMinInterval was wahrscheinlich auch helfen würde.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Sidey

Zitat von: DS_Starter am 24 Juli 2023, 08:54:45event-min-interval wäre vllt. die Lösung. Oder wenn du global agieren willst gibt es im DbLog ein Attr defaultMinInterval was wahrscheinlich auch helfen würde.

Danke für den guten Support.
Ich habe mich für 'defaultMinInterval' entschieden und es für alles auf 1 Sekunde gesetzt. Das erscheint mir passend und führt zum Erfolg, dass ich nun nur noch einen Wert um 19:02 Uhr habe:
2023-07-24_19-01-18__1__au.MagnetventilBlumen__POWER2 OFF
2023-07-24_19-02-00__1__au.MagnetventilBlumen__POWER2 ON
2023-07-24_19-04-00__1__au.MagnetventilBlumen__POWER2 OFF

Das Verschieben um 2 Minuten hat nichts gebracht, denn es sind tatsächlich Updates die nichts mit dem Statusbericht alle 5 Minuten zu tuen haben.
Das Verhalten ist so auch in der Tasmota Dokumentation hinterlegt, es werden vom Tasmota Device zwei Topics aktualisiert, einmal das Ergebnis des Schaltbefehles und dann der Zustand vom Relay:

2023.07.24 21:50:28 4:  MQTT2_FHEM_Server_10.2.11.28_62709 DVES_BA7116 PUBLISH stat/zuhause/garten/Magnetventil/POWER1:ON
2023.07.24 21:50:28 4:  MQTT2_FHEM_Server_10.2.11.28_62709 DVES_BA7116 PUBLISH stat/zuhause/garten/Magnetventil/RESULT:{"POWER1":"ON"}

In beiden Fällen wir das Reading POWER1 aktualisiert. Ich könnte das natürlich auch an dieser Stelle unterbinden, fand es aber prinzipiell richtig, dass beide Topics das gleiche Reading aktualisieren


Viele Grüße
Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

DS_Starter

Na dann sieht es ja so aus dass du die Ursache und auch eine Lösung/Workaround gefunden hast. :)
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter