DBLog Readings Aktualisierungsintervall differenzieren

Begonnen von thomasg, 17 Februar 2025, 12:26:06

Vorheriges Thema - Nächstes Thema

thomasg

Hi,

damit meine SQLite Logdatenbank nicht so groß wird habe ich die zu loggenden Readings explizit in der DBLOG-Definition gelistet und darüber hinaus minintervall gesetzt:

define horstDbLog DbLog ./db.conf .*:(temperature|humidity|power|consumption|VOC|heating|Main_Target_Temp|Fan1_Motor_Speed|Compressor_Freq|Operations_Counter|Operations_Hours|Pump_Speed|DHW_Temp|High_Pressure|Low_Pressure|Heatpump_State|Operating_Mode_State|ThreeWay_Valve_State|116183066637_0_yieldday|116183066637_0_yieldtotal|Outside_Pipe_Temp|Inside_Pipe_Temp|Outside_Temp|Compressor_Current|Eva_Outlet_Temp|Discharge_Temp|Main_Outlet_Temp|Main_Inlet_Temp|Main_Hex_Outlet_Temp|Pump_Flow|Internal_Heater_State).*
attr horstDbLog DbLogType Current/History
attr horstDbLog asyncMode 1
attr horstDbLog defaultMinInterval .*::3600::force
attr horstDbLog room Datenbank


Jetzt möchte ich die zum Device MQTT_HEISHAMON gehörigen Readings (Compressor_Current|Eva_Outlet_Temp|Discharge_Temp ....) zur besseren Analyse in kürzeren Abständen loggen. Kann ich das explzit für sämtliche Readings eines Devices so einstellen. Und könnte ich dann auch um die Logdatei klein zu halten bspw. mit DBRep dann sagen dass die Readings des devices die älter als 2 Wochen sind ausgedünnt werden, so dass pro Stunde nur noch maximal ein Messwert enthalten ist?

Danke Euch
Fhem + knx + 1wire auf raspi 2

betateilchen

Steht doch alles in der commandref zu DbLog und DbRep?

  • das Attribut defaultMinInterval verarbeitet eine kommagetrennte Liste, also sollten dort mehrere Angaben möglich sein
  • beim nachträglichen Ausdünnen von Werten mittels DbRep gibt es kaum etwas, das man nicht umsetzen könnte. Bei mir werden z.B. immer Ende des laufenden Monats immer die Werte des Vormonats so reduziert, dass pro Tag nur ein Wert übrigbleibt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

thomasg

Hi,

habe mal versucht das defaultMinInterval zu ändern. allerdings sehe ich nicht, dass ich mher einträge bekomme. kann es sein, dass die Reihenfolge der Parameter relevant ist?

define horstDbLog DbLog ./db.conf .*:(temperature|humidity|power|consumption|VOC|heating|Main_Target_Temp|Fan1_Motor_Speed|Compressor_Freq|Operations_Counter|Operations_Hours|Pump_Speed|DHW_Temp|High_Pressure|Low_Pressure|Heatpump_State|Operating_Mode_State|ThreeWay_Valve_State|116183066637_0_yieldday|116183066637_0_yieldtotal|Outside_Pipe_Temp|Inside_Pipe_Temp|Outside_Temp|Compressor_Current|Eva_Outlet_Temp|Discharge_Temp|Main_Outlet_Temp|Main_Inlet_Temp|Main_Hex_Outlet_Temp|Pump_Flow|Internal_Heater_State).*
attr horstDbLog DbLogType Current/History
attr horstDbLog asyncMode 1
attr horstDbLog defaultMinInterval .*::3600::force,MQTT2_HeishaMon::360
attr horstDbLog room Datenbank
#   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
#   CONFIGURATION ./db.conf
#   DEF        ./db.conf .*:(temperature|humidity|power|consumption|VOC|heating|Main_Target_Temp|Fan1_Motor_Speed|Compressor_Freq|Operations_Counter|Operations_Hours|Pump_Speed|DHW_Temp|High_Pressure|Low_Pressure|Heatpump_State|Operating_Mode_State|ThreeWay_Valve_State|116183066637_0_yieldday|116183066637_0_yieldtotal|Outside_Pipe_Temp|Inside_Pipe_Temp|Outside_Temp|Compressor_Current|Eva_Outlet_Temp|Discharge_Temp|Main_Outlet_Temp|Main_Inlet_Temp|Main_Hex_Outlet_Temp|Pump_Flow|Internal_Heater_State).*
#   FD         10
#   FUUID      5dd1401c-f33f-c37d-7f48-21dd73f2a44f4911
#   FVERSION   93_DbLog.pm:v5.11.0-s29401/2024-12-05
#   MODE       asynchronous
#   MODEL      SQLITE
#   NAME       horstDbLog
#   NR         2
#   NTFY_ORDER 50-horstDbLog
#   PID        24799
#   REGEXP     .*:(temperature|humidity|power|consumption|VOC|heating|Main_Target_Temp|Fan1_Motor_Speed|Compressor_Freq|Operations_Counter|Operations_Hours|Pump_Speed|DHW_Temp|High_Pressure|Low_Pressure|Heatpump_State|Operating_Mode_State|ThreeWay_Valve_State|116183066637_0_yieldday|116183066637_0_yieldtotal|Outside_Pipe_Temp|Inside_Pipe_Temp|Outside_Temp|Compressor_Current|Eva_Outlet_Temp|Discharge_Temp|Main_Outlet_Temp|Main_Inlet_Temp|Main_Hex_Outlet_Temp|Pump_Flow|Internal_Heater_State).*


Fhem + knx + 1wire auf raspi 2

betateilchen

Ich bin mir nicht sicher, ob das Rumkaspern mit diesem Attribut wirklich zu dem Ergebnis führen wird, das Du erwartest.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

thomasg

#4
Würdest du das Attribut defaultMinInterval löschen - wie könnte ich das dann alternativ steuern? 

Ich könnte überlegen mit DbLogSelectionMode Include zu arbeiten.

Dann hätte ich einmal den Aufwand je device festzulegen was zu loggen ist. Kann dan nach meinem Verständnis aber auch je device individuell einstellen in welchem Intervall etc
Fhem + knx + 1wire auf raspi 2

betateilchen

Mit diesen ganzen Attributen zum ein- und ausschließen von Daten arbeite ich überhaupt nicht.

Wenn man ohnehin die Daten ausdünnen möchte, ist es auch nicht sonderlich schädlich, erstmal alles zu loggen, was kommt. Um den Zeitraum von 14 Tagen einzuhalten, lässt man ja ohnehin täglich einen DbRep Job laufen, da kann man ja auch schon andere Bereinigungen mit einbauen.

Bei mir ist das DbLog auch so aufgebaut, dass ich im DEF alles angebe, was ich gelogged haben möchte. Die Daten werden aber nur 3 Tage gespeichert und grafisch dargestellt (z.B. SVG).
Alle Daten, die ich langfristig auswerten möchte (und das sind sehr wenige...) werden in ein zweites DbLog geschrieben, quasi als "Langzeitlog". Dort erfolgt das schon beschriebene monatliche Ausdünnen auf einen Wert pro Tag. Für eine Jahresbetrachtung ist das völlig ausreichend.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

thomasg

Ah. Danke für die Gedanken dazu. Hört sich schlüssig an. Dann schaue ich mir erstmal an wie ich mit dbrep die Bereinigung machen kann. Ich würde es allerdings bei einer dB belassen ...
Fhem + knx + 1wire auf raspi 2

thomasg

#7
Guten Morgen,

bin ich da vom Konzept her auf dem richtigen Weg? Ich lege für jedes relevante Device, dessen Logdaten ich reduzieren möchte ein DBLOG und ein AT Device an. Werden dann ein paar mehr Devices .....


Internals:
   CFGFN     
   DATABASE   /opt/fhem/log/testdb_horst.db
   DEF        horstDbTest
   FUUID      67b4da2e-f33f-f90e-4c08-44262fd06ff12b01
   FVERSION   93_DbRep.pm:v8.53.16-s29390/2024-12-01
   LASTCMD    fetchrows history
   MODEL      Client
   NAME       DbRep.OpenDTU.Reduce
   NOTIFYDEV  global,DbRep.OpenDTU.Reduce
   NR         260
   NTFY_ORDER 50-DbRep.OpenDTU.Reduce
   ROLE       Client
   STATE      done
   TYPE       DbRep
   eventCount 30
   HELPER:
     DBLOGDEVICE horstDbTest
     IDRETRIES  2
     MINTS      2022-02-19 12:00:00
     PACKAGE    main
     VERSION    8.53.16
     CV:
       aggregation no
       aggsec     1
       destr      2025-02-18
       dsstr      2025-02-17
       epoch_seconds_end 1739854862.28087
       mestr      02
       msstr      02
       testr      06:01:02
       tsstr      06:01:02
       wdadd      604800
       yestr      2025
       ysstr      2025
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2025-02-19 06:01:03   2025-02-17_23-59-59__1__OpenDTU_6813860__116183066637_0_yieldday 35.0000
     2025-02-19 06:01:03   2025-02-17_23-59-59__1__OpenDTU_6813860__116183066637_0_yieldtotal 950.5900
     2025-02-19 06:01:03   number_fetched_rows 2
     2025-02-19 06:01:03   state           done
Attributes:
   comment    Ausdünnen Stromwerte
   device     OpenDTU_6813860
   event-on-update-reading state
   reading    116183066637_0_yieldday,116183066637_1_yieldday,116183066637_2_yieldday,116183066637_3_yieldday,116183066637_4_yieldday,116183066637_0_yieldtotal,116183066637_0_power,116183066637_1_power,116183066637_2_power,116183066637_3_power,116183066637_4_power
   room       Datenbank
   timeDiffToNow d:2
   timeOlderThan d:1

Aufruf im AT-Device dann:

Zitatset DbRep.OpenDTU.Reduce reduceLog max


Du darfst diesen Dateianhang nicht ansehen.


Viele Grüße
Fhem + knx + 1wire auf raspi 2

betateilchen

DbRep bietet die Möglichkeit, mehrere Bereinigungen in einem Aufruf durchzuführen. Genau aus dem Grund, um eine Vielzahl von devices zu vermeiden.

Schau mal in der commandref zu DbRep unter

- multiCmd {<Befehl-Hash>}
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rabehd

Zitat von: thomasg am 19 Februar 2025, 07:58:34Guten Morgen,

bin ich da vom Konzept her auf dem richtigen Weg? Ich lege für jedes relevante Device, dessen Logdaten ich reduzieren möchte ein DBLOG und ein AT Device an. Werden dann ein paar mehr Devices .....


Internals:
   CFGFN     
   DATABASE   /opt/fhem/log/testdb_horst.db
   DEF        horstDbTest
   FUUID      67b4da2e-f33f-f90e-4c08-44262fd06ff12b01
   FVERSION   93_DbRep.pm:v8.53.16-s29390/2024-12-01
   LASTCMD    fetchrows history
   MODEL      Client
   NAME       DbRep.OpenDTU.Reduce
   NOTIFYDEV  global,DbRep.OpenDTU.Reduce
   NR         260
   NTFY_ORDER 50-DbRep.OpenDTU.Reduce
   ROLE       Client
   STATE      done
   TYPE       DbRep
   eventCount 30
   HELPER:
     DBLOGDEVICE horstDbTest
     IDRETRIES  2
     MINTS      2022-02-19 12:00:00
     PACKAGE    main
     VERSION    8.53.16
     CV:
       aggregation no
       aggsec     1
       destr      2025-02-18
       dsstr      2025-02-17
       epoch_seconds_end 1739854862.28087
       mestr      02
       msstr      02
       testr      06:01:02
       tsstr      06:01:02
       wdadd      604800
       yestr      2025
       ysstr      2025
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2025-02-19 06:01:03   2025-02-17_23-59-59__1__OpenDTU_6813860__116183066637_0_yieldday 35.0000
     2025-02-19 06:01:03   2025-02-17_23-59-59__1__OpenDTU_6813860__116183066637_0_yieldtotal 950.5900
     2025-02-19 06:01:03   number_fetched_rows 2
     2025-02-19 06:01:03   state           done
Attributes:
   comment    Ausdünnen Stromwerte
   device     OpenDTU_6813860
   event-on-update-reading state
   reading    116183066637_0_yieldday,116183066637_1_yieldday,116183066637_2_yieldday,116183066637_3_yieldday,116183066637_4_yieldday,116183066637_0_yieldtotal,116183066637_0_power,116183066637_1_power,116183066637_2_power,116183066637_3_power,116183066637_4_power
   room       Datenbank
   timeDiffToNow d:2
   timeOlderThan d:1

Aufruf im AT-Device dann:

Zitatset DbRep.OpenDTU.Reduce reduceLog max


Du darfst diesen Dateianhang nicht ansehen.


Viele Grüße


Komische Idee. Siehe auch Beta Teilchen.
Ich habe ein DBrep-Device. Dort kann man sich die verschiedenen Befehle zusammen basteln.
Diese Befehle lasse ich über ein DOIF zu jeweils einen anderen Zeitpunkt ausführen.
Auch funktionierende Lösungen kann man hinterfragen.