DbRep und Verständnisfrage bei Reduzierung der Einträge

[Gear]

Hallo zusammen,

ich starte die Reduzierung über den CMD: set DBLogging.DbRep reduceLog average und im DbRep habe ich unter dem Attr: Device Geräte / Readings, welche nicht mit dem Durchschnitt reduziert werden sollen.

1.
Nun würde ich hier gerne einige der ausgeschlossenen Geräte verwenden, um hier den höchsten Wert in einer Stunde zu behalten und den Rest zu löschen, weil der Durchschnitt keinen Sinn ergibt.

2.
Neu kommen heute noch Motion Sensoren hinzu, diese sollen auch reduziert werden, aber auf geänderten Status. (1 = Motion, 0 = No Motion)
> Eine Möglichkeit wäre, hier nur zu loggen, wenn der Status sich ändert und gleichbleibende Werte nich mitzuloggen. bzw, gleiche Werte alle X Zeit erneut zulassen.

Code Auswählen Erweitern

define DBLogging.DbRep DbRep DBLogging
attr DBLogging.DbRep DbLogExclude .*
attr DBLogging.DbRep DbLogInclude DumpRowsCurrent,DumpRowsHistory
attr DBLogging.DbRep device EXCLUDE=WOL.%:OnlineState,%.PmTmt:PmPower,%.PmESP:PmPower,%.PmShly:PmPower,%.Fenster.%:OpenState,IT.Speedtest:%,SystemMonitor:uptime,FL.Klingel.HMIP:RingState,FL.Eingangstuere.HMIP:OpenState,FL.Tuerschloss.HMIP:LockState
attr DBLogging.DbRep dumpFilesKeep 1
attr DBLogging.DbRep event-on-change-reading state
attr DBLogging.DbRep event-on-update-reading state,DumpRowsHistory
attr DBLogging.DbRep executeBeforeProc set DBLogging commitCache
attr DBLogging.DbRep group DbLog
attr DBLogging.DbRep optimizeTablesBeforeDump 1
attr DBLogging.DbRep room 23 Logging
attr DBLogging.DbRep stateFormat DumpFile Created: DumpFileCreated<br>\
DumpFile Deleted: DumpFilesDeleted<br>\
<br>\
DumpFile Size: DumpFileCreatedSize<br>\
DumpFile Size Current: DumpRowsCurrent<br>\
DumpFile Size History: DumpRowsHistory<br>\
DumpFile Created Time: background_processing_time
attr DBLogging.DbRep timeDiffToNow d:95
attr DBLogging.DbRep timeOlderThan d:90
#   DATABASE   fhem
#   DEF        DBLogging
#   FUUID      63c3b5eb-f33f-cc91-e722-f966403f97f80d8a
#   FVERSION   93_DbRep.pm:v8.52.7-s27577/2023-05-16
#   LASTCMD    dumpMySQL clientSide
#   MODEL      Client
#   NAME       DBLogging.DbRep
#   NOTIFYDEV  global,DBLogging.DbRep
#   NR         124
#   NTFY_ORDER 50-DBLogging.DbRep
#   ROLE       Client
#   STATE      DumpFile Created: DumpFileCreated<br>
#DumpFile Deleted: DumpFilesDeleted<br>
#<br>
#DumpFile Size: DumpFileCreatedSize<br>
#DumpFile Size Current: DumpRowsCurrent<br>
#DumpFile Size History: DumpRowsHistory<br>
#DumpFile Created Time: background_processing_time
#   TYPE       DbRep
#   UTF8       1
#   eventCount 42
#   HELPER:
#     DBLOGDEVICE DBLogging
#     GRANTS     CREATE VIEW,CREATE TEMPORARY TABLES,DROP,EVENT,USAGE,INDEX,SHOW VIEW,LOCK TABLES,EXECUTE,CREATE ROUTINE,CREATE,SELECT,REFERENCES,TRIGGER,DELETE,INSERT,ALTER ROUTINE,ALTER,UPDATE
#     IDRETRIES  2
#     MINTS      2018-05-02 10:52:00
#     PACKAGE    main
#     VERSION    8.52.7
#     CV:
#       aggregation no
#       aggsec     1
#       destr      2023-03-23
#       dsstr      2023-03-18
#       epoch_seconds_end 1679559010.6942
#       mestr      03
#       msstr      03
#       testr      09:10:10
#       tsstr      09:10:10
#       wdadd      172800
#       yestr      2023
#       ysstr      2023
#     DBREPCOL:
#       COLSET     1
#       DEVICE     64
#       EVENT      512
#       READING    64
#       TYPE       64
#       UNIT       32
#       VALUE      128
#     RUNNING_BACKUP_CLIENT:
#       abortFn    DbRep_DumpAborted
#       bc_pid     60025
#       finishFn   DbRep_DumpDone
#       fn         DbRep_mysql_DumpClientSide
#       loglevel   5
#       pid        3170507
#       telnet     telnetForBlockingFn_1686979294.73367_127.0.0.1_35574
#       timeout    86400
#       abortArg:
#       arg:
#         name       DBLogging.DbRep
#         table      history
#         hash:
#   Helper:
#     DBLOG:
#       DumpRowsHistory:
#         DBLogging:
#           TIME       1687331017.92858
#           VALUE      3815094
#   OLDREADINGS:
#   READINGS:
#     2023-06-21 09:10:27   state           clientSide Dump is running - be patient and see Logfile !
#   hmccu:
#
setstate DBLogging.DbRep DumpFile Created: DumpFileCreated<br>\
DumpFile Deleted: DumpFilesDeleted<br>\
<br>\
DumpFile Size: DumpFileCreatedSize<br>\
DumpFile Size Current: DumpRowsCurrent<br>\
DumpFile Size History: DumpRowsHistory<br>\
DumpFile Created Time: background_processing_time
setstate DBLogging.DbRep 2023-06-21 09:10:27 state clientSide Dump is running - be patient and see Logfile !


DbRep habe ich anhand der WiKi Seite gemacht: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten

Ich möchte nicht ausschließen, hier etwas übersehen oder falsch verstanden zu haben.

Vielen Dank
Grüße
Gear

[DS_Starter]

Ich weiß nicht ob ich dein Anliegen richtig verstanden habe, aber ich versuche es mal.

1.
Nun würde ich hier gerne einige der ausgeschlossenen Geräte verwenden, um hier den höchsten Wert in einer Stunde zu behalten und den Rest zu löschen, weil der Durchschnitt keinen Sinn ergibt.

Dafür ist reduceLog (average) nicht das Richtige.
Ein "maxValue deleteOther" mit einem Attr aggregation = hour wäre m.M. nach passend für dein Ziel.
Dafür für die jeweiligen device/readings ein separates DbRep definieren/kopieren und laufen lassen.

2.
Neu kommen heute noch Motion Sensoren hinzu, diese sollen auch reduziert werden, aber auf geänderten Status. (1 = Motion, 0 = No Motion)
> Eine Möglichkeit wäre, hier nur zu loggen, wenn der Status sich ändert und gleichbleibende Werte nich mitzuloggen. bzw, gleiche Werte alle X Zeit erneut zulassen.

Da habe ich die Frage nicht verstanden bzw. keine gesehen ?
Eine Möglichkeit hast du ja bereits genannt. Was schon in der DB drin ist könntest du vermutlich mit einem "delSeqDoublets" bereinigen. Schau dir dazu die Hilfe an.

LG

[RalfRog]

Wenn ich deinen Beitrag so sehe (list vom DBLogging.DbRep), sieht es aus als hättest du gerade mit DBLog /DBRep angefangen.

Wenn das so ist glaube ich, dass du eventuell noch nicht ganz auf dem richtigen Dampfer bist.

Z.B. die Attribute:

Code Auswählen Erweitern

attr DBLogging.DbRep DbLogExclude .*
attr DBLogging.DbRep DbLogInclude DumpRowsCurrent,DumpRowsHistory
müssten statt im DBRep eher in den eigentlichen Devices konfiguriert werden.

Auch:

Code Auswählen Erweitern

attr DBLogging.DbRep event-on-change-reading state
attr DBLogging.DbRep event-on-update-reading state,DumpRowsHistorybraucht man im DBRep eher nicht.

[Gear]

Dafür für die jeweiligen device/readings ein separates DbRep definieren/kopieren und laufen lassen.

Ok, also quasi ein weiteres Define und dann darüber die Reduzierung mit anderen Argumenten, Danke.

Da habe ich die Frage nicht verstanden bzw. keine gesehen ?
Eine Möglichkeit hast du ja bereits genannt. Was schon in der DB drin ist könntest du vermutlich mit einem "delSeqDoublets" bereinigen. Schau dir dazu die Hilfe an.

Das hilft mir, Danke!
Muss ich später testen, war mir auch nicht sicher, ob es Sinn macht ein weiteres DbRep anzulegen (und ob man es darf).
Dachte, man muss hinter den Befehl set DBLogging.DbRep reduceLog average das EXCLUDE= anhängen. (Das ging aber auch nicht oder ich war zu doof. )

Wenn ich deinen Beitrag so sehe (list vom DBLogging.DbRep), sieht es aus als hättest du gerade mit DBLog /DBRep angefangen.

Wenn das so ist glaube ich, dass du eventuell noch nicht ganz auf dem richtigen Dampfer bist.

Naja, DbLog + DbRep nutze ich schon lange, aber habe mich damit nie so richtig befasst.
Hatte bisher ja immer funktioniert und nun ist mir aufgefallen, dass nicht alles nach meiner Zufriedenheit ist.

Z.B. die Attribute:

Code Auswählen Erweitern

attr DBLogging.DbRep DbLogExclude .*
attr DBLogging.DbRep DbLogInclude DumpRowsCurrent,DumpRowsHistory
müssten statt im DBRep eher in den eigentlichen Devices konfiguriert werden.

Das hat schon seine Richtigkeit...
DbLogExclude .* == Sagt ja eig. nur, es sollen erstmal generell keine Readings von diesem Device in der DB gespeichert werden.
DbLogInclude DumpRowsCurrent,DumpRowsHistory == Und hier sollen eben diese beiden Readings in der DB gespeichert werden.
Mein Verständnis und es macht, was es soll.

Auch:

Code Auswählen Erweitern

attr DBLogging.DbRep event-on-change-reading state
attr DBLogging.DbRep event-on-update-reading state,DumpRowsHistorybraucht man im DBRep eher nicht.

Gut, ich habe nach dem Post event-on-update-reading angepasst und um DumpRowsCurrent erweitert.
Und das attr event-on-change-reading habe ich gelöscht, da ich da zuvor so hatte und vergessen hatte zu löschen.
Naja, spricht aber auch nichts dagegen. (Reduktion von Events)

Vielen Dank, werde das testen.

Grüße und frohes schwitzen bei den Temperaturen.
Gear

[RalfRog]

Ja stimmt. War mein erster Eindruck. Umso besser wenn du die Richtung kennst.

Meine DBRep-Devices sind an der Stelle ziemlich schlank (die loggen aber auch nichts ausser fhem.log bei verbose x).
Es sind praktisch nur die Attribute gesetzt, die der Selektion für die Aufgabe dienen.

[Gear]

Ja ok, so hatte ich das DbRep noch nie gesehen.
Logge die Einträge in der DB mit, einfach aus Interesse, hatte das zuvor direkt im DbLog Device gemacht, nur kommt da auch immer die Meldung, man solle das über DbRep machen.

Und das DbRep nutze ich auch für den nächtlichen Dump der DB.

Dann muss ich mir am WE Gedanken machen, wie ich das für mich am vernünftigsten mit mehreren DbRep's umsetze.

Werde das Thema nach der Umsetzung als [Gelöst] markieren, daher lasse ich das erstmal noch offen, wenn noch Fragen oder Probleme auftreten.

Danke!

[RalfRog]

Zwei Aufgaben (Dump & reducelog) im gleichen DBRep-Device über die Attribute definieren macht es unübersichtlich bzw. ist ggfs. auch unmöglich.
Das Attribut "attr DBLogging.DbRep device EXCLUDE=..." spielt denke ich für den Dump keine Rolle.
Für ein ReduceLog würde das Attribut reading fehlen aber da braucht es die ganzen dump-Attribute nicht.

Hier mal zwei Beispiele meiner mittlerweile 12 DBRep Devices.

• DS_Starter empfiehlt ja eine Aufgabe -> ein Device

2-tägliche Reduzierung der Powerreadings (vor 15 Tagen) meiner beiden Shellies und des Stromzählers per AT => set DBRep_reduPower reduceLog max (ähnlich deinem ersten Post unter 1.)

Code Auswählen Erweitern

NAME       DBRep_reduPower

Attributes:
muss->
device     shelly.*,MQTT2_ESP_2
reading    power,total_power,MT691_power
timeDiffToNow d:17 FullDay
timeOlderThan d:15 FullDay
zusätzlich->
comment    durch ein at aufgerufene 2-taegliche Reduzierung der Powerwerte auf einen stuendlichen MAX Wert
executeAfterProc msg push -1 [DBRep_reduPower:state] fuer Plug:power, 3EM:total_power und MT691:MT691_power
numDecimalPlaces 0
room       Dbase

tägliches Backup in ein CSV File per AT => set DBRep_BackupWoche exportToFile     (monatlich weiteres DBRep-Device mit DUMP)

Code Auswählen Erweitern

NAME       DBRep_BackupWoche

Attributes:
muss->
expimpfile /opt/fhem/backup/db_back/week/fhem_history_since-prev-week_%Y-%U_%w.csv
timestamp_begin previous_week_begin
zusätzlich->
comment    sichert die DB seit prev_week (Aufruf mit Kommando exportToFile) per userExitFN wird die Datei noch gezippt
userExitFn db_File_Cleanup state:done
executeBeforeProc set DBLogging reopen 300
room       Dbase


[Gear]

@RalfRog
Danke!

Ich mache da immer ein komplettes DUMP.

Meine BackUp Routine in einem DOIF sieht aktuell so aus:
(Und ja, ist ggf. auch ein bisschen missbraucht, aber alles in einem DOIF und es geht. )

Code Auswählen Erweitern

([03:00])
 (set DBLogging.DbRep reduceLog average)

DOELSEIF ([DBLogging.DbRep:"^reduceLog.of.fhem.finished$"])
 (set DBLogging.DbRep dumpMySQL clientSide)

DOELSEIF ([DBLogging.DbRep:"^Database.backup.finished$"])
 (backup)

DOELSEIF ([global:"^backup.done$"])
 ("python3 /opt/fhem/FHEM/98_BackUp2FTP.py <HOST> <PORT> <Protokoll> <FHEM-User> <FHEM-Pass> <BackUp-Dummy> &")

DOELSEIF ([Dummy.BackUp2FTP.Server0:"^Finish$"])
 ("python3 /opt/fhem/FHEM/98_BackUp2FTP.py <HOST> <PORT> <Protokoll> <FHEM-User> <FHEM-Pass> <BackUp-Dummy> &")
 
DOELSEIF ([Dummy.BackUp2FTP.Server1:"^Finish$"])
 ({myUtils_EMail_BackUp_Finish()})

[RalfRog]

Hi
Naja du versuchst mit dem gleichen Device "DBLogging.DbRep" zwei Dinge zu tun:

• set DBLogging.DbRep reduceLog average => Datenbankeinträge zu reduzieren
• set DBLogging.DbRep dumpMySQL clientSide  => Datensicherung

Zu 1
Lt. Ursprungsbeitrag möchtest du die Max-Werte halten und nicht den Durchschnitt bilden.
=> Da wäre statt "average" eher "max" anzuwenden. Ich glaub in Default ist die Aggregationzeit eine Stunde. Das würde passen.
=> Neben der Angabe (per Attribut) der Devices musst du aber auch die Readings und den Zeitraum bestimmen (das fehlt meines Erachtens).

Daher wäre es sinnvoll ein weiteres DBRep für diesen Zweck zu definieren mit den Attributen device, reading & time*
=> define <name> DbRep <Name der DbLog-Instanz>. Bei vielen Devices ggfs. auch mehrere DBRep's für verschiedene Gruppen von Devices. Beispiel:

Code Auswählen Erweitern

define DBLogging.DbRepReduce DbRep DBLogging
attr DBLogging.DbRepReduce device  <devices oder RegEx der zu reduzierenden Devices>
attr DBLogging.DbRepReduce reading <readings oder RegEx der zu reduzierenden readings>
attr DBLogging.DbRepReduce timestamp_begin <oder ein anderes passendes Time-Attribut>
attr DBLogging.DbRepReduce timestamp_end   <oder ein anderes passendes Time-Attribut>
ein Aufruf z.B. per DoIf "set DBLogging.DbRepReduce reduceLog max"

Zu 2
Das bestehende "DBLogging.DbRep" für die Aufgabe des Dumps aufräumen. Sprich unnötige Attribute löschen.

Gruß Ralf

[RalfRog]

Hallo Gear

Ich will mich hier nicht zu weit aus dem Fenster lehnen, da ich auch immer Unterstützung der Commandref/Beispielen brauche um die Sache hin zu bekommen.

Letzlich ist es so:
- mach es einfach
- teile eine komplexe Anforderung im mehrere Aufgaben auf
- man kann (darf und soll) mehrere DBRep-Devices anlegen

Gruß

p.s.
zwei Auszüge aus der Hilfe zu reducelog:

reduceLog [<no>[:<nn>]] [mode] [EXCLUDE=device1:reading1,device2:reading2,...] [INCLUDE=device:reading]

Reduziert historische Datensätze.

Arbeitsweise ohne Angabe von Befehlszeilenoperatoren

Es werden die Daten innerhalb der durch die time.*-Attribute bestimmten Zeitgrenzen bereinigt. Es muss mindestens eines der time.*-Attribute gesetzt sein (siehe Tabelle unten). Die jeweils fehlende Zeitabgrenzung wird in diesem Fall durch das Modul ermittelt.
Der Arbeitsmodus wird durch die optionale Angabe von mode bestimmt
...
...
...
Arbeitsweise mit Angabe von Befehlszeilenoperatoren

Es werden Datensätze berücksichtigt die älter sind als <no> Tage und (optional) neuer sind als <nn> Tage. Der Arbeitsmodus wird durch die optionale Angabe von mode wie oben beschrieben bestimmt.

Die Zusätze "EXCLUDE" bzw. "INCLUDE" können ergänzt werden um device/reading Kombinationen in reduceLog auszuschließen bzw. einzuschließen und überschreiben die Einstellung der Attribute "device" und "reading", die in diesem Fall nicht beachtet werden.
Die Angabe in "EXCLUDE" wird als 

-

[Gear]

So, nun habe ich eine Frage zu set <DEVICE> maxValue writeToDB.
Würde gerne von allen Geräten die Strommessen, das Reading PmPower mit dem oben stehenden Befehl abdecken.

Mit list .*.PmTmt,.*.PmESP,.*.PmShly kann ich mir die Geräte anzeigen lassen.
Kann ich im DbRep unter dem Attr device das irgendwie einbauen?
Möchte ungern für jedes Device ein DbRep anlegen.

Bekomme immer eine Meldung, dass es keine Liste sein darf.

[RalfRog]

Ich verwende bei mir das Attribut "device  shelly.*,MQTT2_ESP_2".
"shelly.*" erfasst drei Shelly's plus mit Komma abgetrennt der "MQTT2_ESP_2".

Ich würde daher die beiden Attribute setzen (wenn das list die richtigen Devices ausspuckt). 

Code Auswählen Erweitern

device .*.PmTmt,.*.PmESP,.*.PmShly
reading PmPowerDer RegEx-Teil .*. verunsichert mich etwas. Führt .* nicht zum gleichen Ergebnis?

Edit:

Bekomme immer eine Meldung, dass es keine Liste sein darf.

Wo/wann genau? Habe mir mal testhalber ein DBRep angelegt - da wird nicht über die beiden Attribute gemeckert.

[Gear]

Ach, ich glaube, ich hab mich falsch ausgedrückt. Sry 

Wenn ich maxValue deleteOther mache, dann funktioniert das.

Ich habe das Problem bei maxValue writeToDB.
So wie ich gelesen habe, braucht man hier ein Device (und keine Liste), würde scheinbar aber auch nicht anders gehen.
> Hier schreibt er ja neue Einträge, also die Max Werte und überschreibt die alten nicht.

Hatte mir vorhin die Einträge in der DB kaputt gemacht... (Zum Glück eine Kopie des Aktiv-Containers und kein Datenverlust. )

[RalfRog]

Bei der Funktion "maxValue" habe ich keine Erfahrung ob je nach Parameter nur einzelne Devices/Readings erlaubt sind.

Schau mal hier im Thread nach dem Begriff Chain.
Da gab es in am Jahresanfang? eine Diskussion zum Verketten von hintereinander ablaufenden Aufrufen von DBRep. Ggfs. gibt es da auch Hinweise von DS_Starter zu den Einschränkungen bei den Parametern.

[RalfRog]

oh sorry

meinte natürlich den eigentlichen Support-Thread
https://forum.fhem.de/index.php?topic=53584.0

oder
https://forum.fhem.de/index.php?topic=128605.0

oder hier vielleicht
https://forum.fhem.de/index.php?msg=1255834