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
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.
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).*
Ich bin mir nicht sicher, ob das Rumkaspern mit diesem Attribut wirklich zu dem Ergebnis führen wird, das Du erwartest.
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
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.
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 ...
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
Screenshot 2025-02-19 075330.png
Viele Grüße
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>}
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
Screenshot 2025-02-19 075330.png
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.