hallo zusammen,
erst seit kurzen wurde mir gezeigt, wie man alle neuen Devices mit attr xxxxxx dblogeclude .* vom Schreiben in die Datenbank abhalten kann.
Einige Devices habe ich auch mit rename umbenannt.
Jedenfalls habe ich 100tausende Einträge mit devices a la
tuya_local_xxxxxxxxxxxxxxx
wie kann ich alle diese Einträge mit einem Befehl aus der dbLog löschen?
mit dbLog sieht so aus:
[code]define dblog_THB DbLog ./configDB.conf .*:.*
attr dblog_THB DbLogType Current/History
attr dblog_THB alias dblog_THB
attr dblog_THB asyncMode 1
attr dblog_THB bulkInsert 1
attr dblog_THB cacheLimit 5000
attr dblog_THB comment ./configDB.conf .*:(state|temperature|power|humidity|va_temperature|va_humidity|humidity_value|desiredTemperature|valveposition|\\
\/buderus:heatSources\/systemPressure|CHpumpModulation|actualDHWPower|actualCHPower|flameStatus|\\
applianceSupplyTemperature|actualSupplyTemperature|supplyTemperatureSetpoint|outdoor_t1|supply_t1|supply_t1_setpoint|\\
actualTemp|currentSetpoint|charge|chargeDuration|setpoint|singleChargeSetpoint|workingTime|oilfox_metering_liters).*
attr dblog_THB commitMode ac:on_ta:off
attr dblog_THB room DBLog
attr dblog_THB syncInterval 30
attr dblog_THB useCharfilter 1
attr dblog_THB verbose 1
# COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
# CONFIGURATION ./configDB.conf
# DEF ./configDB.conf .*:.*
# FD 5
# FUUID 63a33b3f-f33f-fd5f-7f81-5787629cdd49cde5
# FVERSION 93_DbLog.pm:v5.5.9-s26923/2022-12-29
# MODE asynchronous
# MODEL MYSQL
# NAME dblog_THB
# NR 2
# NTFY_ORDER 50-dblog_THB
# PID 23424
# REGEXP .*:.*
# SBP_PID 27933
# SBP_STATE running
# STATE connected
# TYPE DbLog
# UTF8 0
# dbconn mysql:database=fhem;host=localhost;port=3306
# dbuser fhemuser
# eventCount 71
# HELPER:
# COLSET 1
# DEVICECOL 64
# EVENTCOL 512
# LONGRUN_PID 1673452155.67657
# OLDSTATE connected
# PACKAGE main
# READINGCOL 64
# TC current
# TH history
# TYPECOL 64
# UNITCOL 32
# VALUECOL 128
# VERSION 5.5.9
# Helper:
# DBLOG:
# CacheOverflowLastNum:
# dblog_THB:
# TIME 1673452155.67046
# VALUE 0
# state:
# dblog_THB:
# TIME 1673450131.0978
# VALUE connected
# OLDREADINGS:
# READINGS:
# 2023-01-11 16:49:15 CacheOverflowLastNum 0
# 2022-12-31 19:49:09 CacheOverflowLastState normal
# 2023-01-11 16:49:15 CacheUsage 1
# 2023-01-11 16:49:15 NextSync 2023-01-11 16:49:45 or when CacheUsage 5000 is reached
# 2023-01-11 16:49:15 state connected
#
setstate dblog_THB connected
setstate dblog_THB 2023-01-11 16:49:15 CacheOverflowLastNum 0
setstate dblog_THB 2022-12-31 19:49:09 CacheOverflowLastState normal
setstate dblog_THB 2023-01-11 16:49:15 CacheUsage 1
setstate dblog_THB 2023-01-11 16:49:15 NextSync 2023-01-11 16:49:45 or when CacheUsage 5000 is reached
setstate dblog_THB 2023-01-11 16:49:15 state connected
[/code]
danke sehr für Eure Hilfe
Thomas
Im DbRep (sqlCmd) oder einem SQL Editor deiner Wahl ...
Zuerst mit einem count checken ob das Ergebnis den Erwartungen entspricht:
select count(*) from history where device like "tuya_local_%";
Und dann löschen:
delete from history where device like "tuya_local_%";
(Eine DB Sicherung sollte man immer haben)
Zitat von: DS_Starter am 11 Januar 2023, 17:01:10
danke, Heiko
(Eine DB Sicherung sollte man immer haben)
peinliche Frage ;-) wie erstelle ich die am Besten?
mit
mit dumpMySql clientside ?
wohin wird der dump dann geschrieben ?
Es gibt je nach Datenbanktyp diverse Möglichkeiten die vom Typ abhängen.
Im DbRep habe ich für MySQL/MariaDB und SQLite Befehle eingebaut um aus FHEM heraus eine (regelmäßige) Sicherung zu machen.
Im Wiki:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Backup.2FRestore_einer_SQLite_Datenbank_im_laufenden_Betrieb
bzw.
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Backup.2FRestore_einer_MySQL.2FMariaDB_Datenbank_im_laufenden_Betrieb
Wenn du DB nutzt, solltest du auf jeden Fall eine regelmäßige Sicherung anfertigen. Es kann immer mal etwas schiefgehen.
Zitat
wohin wird der dump dann geschrieben ?
Steht doch in der Commandref:
Zitat
Option clientSide
Der Dump wird durch den Client (FHEM-Rechner) erstellt und per default im log-Verzeichnis des Clients gespeichert. Das Zielverzeichnis kann mit dem Attribut dumpDirLocal verändert werden und muß auf dem Client durch FHEM beschreibbar sein.
....
das mache ich regelmäßig mit:
[code]define at_dblog_THBDump at *04:00:00 set Report_DumpsRows dumpMySQL clientSide
attr at_dblog_THBDump DbLogExclude .*
attr at_dblog_THBDump alias THBDUMP 4:00
attr at_dblog_THBDump room DBLog,xTimer
# COMMAND set Report_DumpsRows dumpMySQL clientSide
# DEF *04:00:00 set Report_DumpsRows dumpMySQL clientSide
# FUUID 61daea6a-f33f-21fb-b2e6-a7e04cc6a8d5bed2
# NAME at_dblog_THBDump
# NR 48
# PERIODIC yes
# RELATIVE no
# REP -1
# STATE Next: 04:00:00
# TIMESPEC 04:00:00
# TRIGGERTIME 1673492400
# TRIGGERTIME_FMT 2023-01-12 04:00:00
# TYPE at
# READINGS:
# 2023-01-11 16:14:24 state Next: 04:00:00
#
setstate at_dblog_THBDump Next: 04:00:00
setstate at_dblog_THBDump 2023-01-11 16:14:24 state Next: 04:00:00
[/code]
ich weiß nur nicht, wohin der dump geschrieben wird, damit ich es überprüfen könnte..
Zitat
ich weiß nur nicht, wohin der dump geschrieben wird, damit ich es überprüfen könnte..
siehe meine Antwort oben.
Vllt. sollte ich in der ComRef schreiben /opt/fhem/log -> wäre wohl eindeutiger. Muss ich mal dran denken.
Zitat von: DS_Starter am 11 Januar 2023, 17:26:22
siehe meine Antwort oben.
du schreibst schneller wie ich denke..
nur finde ich im Log nur fhemlog-Dateien
was mache ich in der Def oben falsch?
Sieht alles richtig aus.
Führe den Befehl doch im DbRep mal manuell aus, setze dabei evtl. verbose 4 um Logausgaben zu sehen und prüfe ob alles funktioniert.
Möglicherweise hast du die Lage auch mit dem Attr dumpDirLocal geändert, sieht man hier ja nicht.
Zitat von: DS_Starter am 11 Januar 2023, 17:37:02
Sieht alles richtig aus.
Führe den Befehl doch im DbRep mal manuell aus, setze dabei evtl. verbose 4 um Logasusagen zu sehen und prüfe ob alles funktioniert.
Möglicherweise hast du die Lage auch mit dem Attr dumpDirLocal geändert, sieht man hier ja nicht.
ok habe nun mal manuell gestartet:
2023.01.11 17:37:33 3: DbRep ReportDbLog_THB - ################################################################
2023.01.11 17:37:33 3: DbRep ReportDbLog_THB - ### New database clientSide dump ###
2023.01.11 17:37:33 3: DbRep ReportDbLog_THB - ################################################################
2023.01.11 17:37:33 3: DbRep ReportDbLog_THB - Starting dump of database 'fhem'
2023.01.11 17:37:33 3: DbRep ReportDbLog_THB - Characterset of collection set to utf8.
2023.01.11 17:37:33 3: DbRep ReportDbLog_THB - Searching for tables inside database fhem....
2023.01.11 17:37:38 3: HUESensor6: Batteriewarnung battery: 77
2023.01.11 17:37:38 3: DbRep ReportDbLog_THB - Found 2 tables with 2751106 records.
2023.01.11 17:37:38 3: DbRep ReportDbLog_THB - Dumping table current (Type InnoDB):
2023.01.11 17:37:39 3: DbRep ReportDbLog_THB - 13669 records inserted (size of backupfile: 2.60 MB)
2023.01.11 17:37:39 3: DbRep ReportDbLog_THB - Dumping table history (Type InnoDB):das wird wohl nun ne weile dauern
wie muss das Zielverzeichnis für dumpDirLocal angeben werden ?
attr dumpDirLocal /fhem/sqllog oder so?
jedenfalls kommt nun im log Verzeichnis was an..
dann stimmt wohl an meinem at was nicht ?
Zitat
wie muss das Zielverzeichnis für dumpDirLocal angeben werden ?
Steht doch auch in der (Direkt)hilfe zum Attribut als Beispiel:
Zitat
attr <Name> dumpDirLocal /sds1/backup/dumps_FHEM/
(Lesen ? :o)
Du kannst dein at auch mit "set ... execNow" mal manuell starten und dann kannst du im Log verfolgen was DbRep macht.
Schau mal in deinem at steht
set Report_DumpsRows dumpMySQL clientSide
Jetzt hast du das Device ReportDbLog_THB gestartet !
super; mein Dump läuft nun prima auch mit Trigger
danke
nun mache ich mich ans Löschen
:) ... na dann ...
Heiko, vielen Dank
das hat super geklappt :-) und mit SQL kann ich nun auch ein wenig umgehen...
nun habe ich noch mal eine Frage zur eigentlichen Ursache der Datenflut:
für meine tuya_local habe ich ind der Befehlszeile für jedes der 40 Geräte einzeln
attr TUYA_JLxx dblogExcluse .* eingegeben.
gibt es wirklich keine Möglichkeit, dies maskiert für ALLE Geräte vom Typ TUYA in einem Rutsch zu erledigen?
Zitat von: thburkhart am 12 Januar 2023, 10:30:42
...eine Frage zur eigentlichen Ursache der Datenflut:
für meine tuya_local habe ich ind der Befehlszeile für jedes der 40 Geräte einzeln
attr TUYA_JLxx dblogExcluse .* eingegeben.
gibt es wirklich keine Möglichkeit, dies maskiert für ALLE Geräte vom Typ TUYA in einem Rutsch zu erledigen?
Wenn deine TUYA-Devices einen einheitlichen Namen haben mit:
attr TUYA_.* dblogExclude .*
Im Dblog gibt es auch das Attribut excludeDevs mit dem man per devspec (https://fhem.de/commandref_DE.html#devspec) konsequent vom Logging ausschließen kann.
Inhalt des Attr könnte z.B. sein (mehrzeilig möglich):
global,Log.*,
TYPE=DbLog
TYPE=SSCam
siehe commandref.
das klappt wunderbar :-)
gibt's das auch als include?
Zitat
gibt's das auch als include?
Nein.
Braucht man auch nicht, denn mit DEF .... .*:.* kommt alles in die DB es sei denn man hat devspec in excludeDevs konsequent ausgeschlossen.
Zitat von: DS_Starter am 12 Januar 2023, 18:11:08
Nein.
Braucht man auch nicht, denn mit DEF .... .*:.* kommt alles in die DB es sei denn man hat devspec in excludeDevs konsequent ausgeschlossen.
manchmal wäre es nützlich ...
z.B. von den ca. 60 readings von Buderus brauche ich nur 5
Mag sein, doch es gibt in DbLog wirklich schon genug Gestaltungsmöglichkeiten.
Schaue dir das Attr valueFn an. Hier kannst du mit einer eigenen Funktion und $IGNORE = 1 Ausschlüsse vornehmen.
Nur so als zusätzlichen Hinweis.