Hallo zusammen,
kann es sein das beim Setzen des DbLogSelectionMode auf Include eine explizite Einschränkung der Readings z.B. .*:(temperature|valveposition|humidity).* ignoriert wird?
Hintergrund: Ich habe 2 DBs. 1. DB enthält Datensätze, die maximal 3 Tage benötigt werden (Kurzzeit DB). 2. DB enthält Datensätze, die ich 2 Jahre aufbewahre (Langzeit DB)
Wenn die Datensätze, welche 2 Jahre aufbewahrt werden, in beide DBs geschrieben werden ist das o.k., die Kurzzeit DB wird täglich gestutzt und bleibt somit schön klein. Wenn jetzt aber Datensätze, welche lediglich 3 Tage aufbewahrt werden, in die Langzeit DB gelangen, dann bläht sich die Langzeit DB unnötig auf.
Deshalb habe ich (neben dem DbLogSelectionMode = Include) auch noch eine Regexp erstellt .*:(energy_kWh|meterReading_kWh|meterReading_m3).*, die dafür sorgen soll, dass nur die Datensätze in die Langzeit DB geschrieben werden sollen, die auch länger wie 3 Tage benötigt werden.
Leider musste ich jetzt feststellen dass alle Daten in beide DBs geschrieben werden. D.h., die Regexp hat keinerlei Wirkung.
Internals:
CFGFN
CONFIGURATION /opt/fhem/DbLog_meterReading.conf
DBMODEL SQLITE
DEF /opt/fhem/DbLog_meterReading.conf .*:(countHistory|energy_kWh|meterReading_kWh|meterReading_m3).*
NAME DbLog_meterReading
NR 366
NTFY_ORDER 50-DbLog_meterReading
PID 25861
REGEXP .*:(countHistory|energy_kWh|meterReading_kWh|meterReading_m3).*
STATE connected
TYPE DbLog
dbconn SQLite:dbname=/opt/fhem/DbLog_meterReading.db
dbuser
Helper:
Dblog:
Counthistory:
Dblog_meterreading:
TIME 1472411882.49051
VALUE 1020
Dblog:
TIME 1472411882.49159
VALUE 1020
Readings:
2016-08-28 21:18:02 countCurrent 19
2016-08-28 21:18:02 countHistory 1020
2016-08-28 20:39:31 lastRowsDeleted 852
2016-08-28 21:16:07 state connected
2016-08-28 18:38:41 userCommand "VACUUM history"
Attributes:
DbLogInclude countHistory
DbLogSelectionMode Include
room 06 Logging
Gruß!
Auszug aus der Commandref (http://fhem.de/commandref_DE.html#DbLog):
Zitat
DbLogSelectionMode
attr <device> DbLogSelectionMode
Dieses, fuer DbLog-Devices spezifische Attribut beeinflußt, wie die Device-spezifischen Attributes DbLogExclude und DbLogInclude (s.u.) ausgewertet werden.
Fehlt dieses Attribut wird dafuer "Exclude" als Default angenommen.
Exclude: DbLog verhaelt sich wie bisher auch, alles was ueber die RegExp im DEF angegeben ist, wird geloggt, bis auf das, was ueber die RegExp in DbLogExclude ausgeschlossen wird
Das Attribut DbLogInclude wird in diesem Fall nicht beruecksichtigt
Include: Es wird nur das geloggt was ueber die RegExp in DbLogInclude eingeschlossen wird.
Das Attribut DbLogExclude wird in diesem Fall nicht beruecksichtigt, ebenso wenig, wie die regex im DEF.
Exclude/Include: Funktioniert im Wesentlichen, wie "Exclude", nur das sowohl DbLogExclude, als auch DbLogInclude geprueft werden: Readings, die durch DbLogExclude zwar ausgeschlossen wurden, mit DbLogInclude aber wiederum eingeschlossen wwrden, werden somit dennoch geloggt.
Danke! Habe ich dann sicherlich übersehen.. ;)
ich hätte dazu aber noch mal eine Frage...
um die Anzahl der DB Einträge zu minimieren wollte ich mit einem event-min-interval arbeiten
event-min-interval energy_kWh:3600
demnach sollte nur jede stunde ein event ausgelöst werden. Ich bin dann davon ausgegangen dass auch nur jede Stunde ein Eintrag in die DB erfolgt.
Leider finde ich dann aber zwei Einträge mit einer zeitlichen Differenz von knapp einer Minute in der DB:
2016-08-28 23:58:25: switchable.socket.Waschkeller_Pwr, CUL_HM, energy_kWh: 172.85, energy_kWh, 172.85,
2016-08-28 23:59:04: switchable.socket.Waschkeller_Pwr, CUL_HM, energy_kWh: 172.86, energy_kWh, 172.86,
Wo liegt mein Gedankenfehler?
Gruß!
Darin, dass du kein komplettes list gepostet hast. ;) Du hast ggf. auch noch event-on-change... oder event-on-update... konfiguriert?
Ja, neben dem event-min-intervall existiert im device noch ein event-on-change-reading
ich dachte das sei o.k., da es in der FHEM Referenz für THZ auch so vorkommt.
attr Mythz event-min-interval s.*:4800
attr Mythz event-on-change-reading .*
Gruß!
hier mal eines der Devices:
Internals:
CFGFN
CHANGED
DEF fritz.box.AHA.Wohnzimmer:20000 switch
IODev fritz.box.AHA.Wohnzimmer
LASTInputDev fritz.box.AHA.Wohnzimmer
MSGCNT 9230
NAME FBDECT_fritz.box.AHA.Wohnzimmer_20000
NR 172
STATE on
TYPE FBDECT
fritz.box.AHA.Wohnzimmer_MSGCNT 9230
fritz.box.AHA.Wohnzimmer_RAWMSG 0703001c000008994e2000000000000c00000012000400000000132a
fritz.box.AHA.Wohnzimmer_TIME 2016-08-29 22:09:43
id 20000
props switch
Helper:
Dblog:
Energy_kwh:
Dblog_meterreading:
TIME 1472500705.68044
VALUE 672.11
Dblog:
TIME 1472420908.67862
VALUE 670.09
Power:
Dblog_meterreading:
TIME 1472412877.17912
VALUE 91.19
Dblog:
TIME 1472501383.38045
VALUE 91.98
Readings:
2016-08-29 22:09:43 current 0.4906 A
2016-08-29 22:09:42 energy 672128 Wh
2016-08-29 22:09:43 energy_kWh 672.13
2016-08-29 20:28:00 options powerOnState:last,lock:webUi,remoteFB,button
2016-08-29 22:09:43 power 91.98 W
2016-08-29 22:08:42 powerFactor 793.000
2016-08-29 22:08:43 state on
2016-08-29 22:09:43 voltage 235.487 V
Attributes:
DbLogInclude power
IODev fritz.box.AHA.Wohnzimmer
alias Schaltsteckdose - Keller (Server)
devStateIcon set_off:message_socket_unknown@grey set_on:message_socket_unknown@grey on:message_socket_enabled@green off:message_socket_disabled@red unknown:message_socket_unknown@grey
event-min-interval power:120,energy_kWh:3600
event-on-change-reading energy,power,state,energy_kWh
room 02 Schaltsteckdosen
userReadings energy_kWh {sprintf("%.2f",ReadingsNum("$name","energy",0)/1000)}
der Frage oben (ob neben event-min-interval noch ein event-on-change-reading definiert ist) entnehme ich dass möglicherweise ein event-on-change-reading für des Reading energy_kWh den Effekt des event-min-interval aufhebt?
- war quatsch, hatte noch ein addLog laufen
wie könnte jetzt eine sinnvolle Kombination von event-on-change-reading und/oder event-min-interval aussehen, damit ein Wert pro Stunde in die DB geschrieben wird?