Hallo,
ich habe mal eine Frage zur Verwendung der Attribute
event-on-change-reading
event-on-update-reading
und evtl.
event-aggregator
event-min-interval
Ich habe diese Attribute vor ewigen Zeiten mal eingebaut, weil ich dachte, dass ich damit die Flut an Logeinträgen etwas eindämmen kann.
Meine Frage ist nun die:
- Wann machen diese Attribute wirklich Sinn?
- Was passiert, wenn ich sie weg lasse?
Mein Anwendungsfall ist der, dass ich:
- die Soll- und Isttemperatur der Thermostate, sowie die Luftfeuchtigkeit
- die Einschaltzeiten und -Dauern der Aktoren für die Heizung
aufzeichnen möchte.
Wenn die Messwerte dann einige Tage alt sind, würde ich diese mittels Min-, Durchschnitt- und Max-Funktionen pro Stunde und später dann sogar nur pro Tag in der Datenbank belassen. Die einzelnen Messwerte würden dann aus der DB entfernt werden.
Für die DB verwende ich das hier:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./mySQLDB.conf
DEF ./mySQLDB.conf Rolladen.*:pct|HzgThermostat.*:batteryLevel|HzgThermostat.*:desired-temp|HzgThermostat.*:measured-temp|HzgThermostat.*:RSSI|HzgStatus.*:humidity|HzgAktor.*:level|HzgAktor.*:RSSI|_HzgAktorBuero00:RSSI|HzgHC.*:*.PerDay|HzgHC.*:countsPerDay|HzgHC.*:countsOverall|HzgHC.*:pulseTimeIncrement|HzgHC.*:pulseTimeEdge|HzgHC.*:pulseTimePerDay|HzgHC.*:pulseTimeOverall|HzgHC.*:pauseTimeIncrement|HzgHC.*:pauseTimeEdge|HzgHC.*:pauseTimePerDay|HzgHC.*:pauseTimeOverall
FUUID 5ed93474-f33f-a625-5c2b-b4f6628ef5ffc1ff
FVERSION 93_DbLog.pm:v4.12.3-s24440/2021-05-15
MODE asynchronous
MODEL MYSQL
NAME mySQLDB
NOTIFYDEV Rolladen.*,HzgAktor.*,_HzgAktorBuero00,HzgThermostat.*,HzgStatus.*,HzgHC.*
NR 156
NTFY_ORDER 50-mySQLDB
PID 23185
REGEXP Rolladen.*:pct|HzgThermostat.*:batteryLevel|HzgThermostat.*:desired-temp|HzgThermostat.*:measured-temp|HzgThermostat.*:RSSI|HzgStatus.*:humidity|HzgAktor.*:level|HzgAktor.*:RSSI|_HzgAktorBuero00:RSSI|HzgHC.*:*.PerDay|HzgHC.*:countsPerDay|HzgHC.*:countsOverall|HzgHC.*:pulseTimeIncrement|HzgHC.*:pulseTimeEdge|HzgHC.*:pulseTimePerDay|HzgHC.*:pulseTimeOverall|HzgHC.*:pauseTimeIncrement|HzgHC.*:pauseTimeEdge|HzgHC.*:pauseTimePerDay|HzgHC.*:pauseTimeOverall
STATE connected
TYPE DbLog
UTF8 0
dbconn mysql:database=fhem;host=192.168.188.6;port=3307
dbuser fhemdbuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
PACKAGE main
READINGCOL 64
TC current
TH history
TYPECOL 64
UNITCOL 32
VALUECOL 128
VERSION 4.12.3
READINGS:
2023-06-09 14:17:35 CacheOverflowLastNum 0
2022-01-17 19:09:18 CacheOverflowLastState normal
2023-06-09 14:20:16 CacheUsage 17
2023-06-09 14:17:35 NextSync 2023-06-09 14:21:35 or if CacheUsage 1500 reached
2023-06-09 14:17:36 background_processing_time 0.4568
2023-01-03 17:33:48 countCurrent 1428
2023-01-03 17:33:48 countHistory 4862102
2020-06-15 18:58:48 lastCachefile ./log/cache_mySQLDB_2020-06-15_18-05-08 import successful
2023-06-09 14:17:36 sql_processing_time 0.4008
2023-06-09 14:17:36 state connected
2020-10-21 18:37:41 userCommand select device,reading, count(*) from current group by device,reading;
2020-10-21 18:37:41 userCommandResult HzgAktorBad
Attributes:
DbLogType Current/History
asyncMode 1
bulkInsert 1
cacheLimit 1500
event-on-change-reading CacheUsage
room DbLog,LogFiles,System
showNotifyTime 0
showproctime 1
syncInterval 240
verbose 2
D.h. dort sind die folgenden Readings drin:
Die hier möchte ich für länger aufbewahren, also pro Stunde, Tag, Monat
HzgThermostat.*:desired-temp, HzgThermostat.*:measured-temp, HzgStatus.*:humidity
Damit ich weiß, wann die Heizung eingeschalten war, zeichne ich HzgAktor.*:level auf
Die Readings HzgThermostat.*:batteryLevel möchte ich nur für 1 Monat aufheben, danach können sie weg.
Die Readings Rolladen.*:pct, HzgThermostat.*:RSSI, HzgAktor.*:RSSI, _HzgAktorBuero00:RSSI werde ich entfernen.
Die Readings HzgHC.*:*.PerDay, HzgHC.*:countsPerDay, HzgHC.*:countsOverall, HzgHC.*:pulseTimeIncrement, HzgHC.*:pulseTimeEdge, HzgHC.*:pulseTimePerDay, HzgHC.*:pulseTimeOverall, HzgHC.*:pauseTimeIncrement, HzgHC.*:pauseTimeEdge, HzgHC.*:pauseTimePerDay, HzgHC.*:pauseTimeOverall sollen bleiben, damit einen Überblick über die Zeiten der Heizung habe.
So, jetzt zurück zum Thema:
Wann sollte ich die oben genannten Attribute einsetzen?
Ich habe mir gerade nochmal https://wiki.fhem.de/wiki/Event-on-change-reading (https://wiki.fhem.de/wiki/Event-on-change-reading) durchgelesen.
Somit würde ich bei den Thermostaten die Readings desired-temp, measured-temp und humidity mittels event-on-change-reading ein Event erzeugen lassen. Sollte sich der Wert nicht ändern, würde ich dann event-min-interval .*:3600 einsetzen, um mindestens jede Stunde einen Wert zu haben.
in allen anderen Fällen und Devices würde ich die Attribute dann löschen.
Jetzt habe ich noch eine letzte Frage zum HourCounter-Device...
Bei diesen Devices steht in der Datenbank jeden Tag um 00:00:00 nochmals der letzte Wert des Readings vom Vortag drin. Wenn man dann beispielsweise pulseTimeIncrement aufsummieren möchte, stimmt die Summe nicht. Wie kann ich das verhindern?
Viele Grüße
Wolfgang
Löschen und/oder Zusammenfassen in der DB sind ein anderes/eigenes Thema und eigentlich gut beschrieben.
Zitat von: rabehd am 09 Juni 2023, 15:06:33Löschen und/oder Zusammenfassen in der DB sind ein anderes/eigenes Thema und eigentlich gut beschrieben.
Das weiß ich, und soll hier auch nur zur Information / Hintergrundwissen meiner Frage dienen...
Zitat von: wowogiengen am 09 Juni 2023, 14:50:11Frage ist nun die:
- Wann machen diese Attribute wirklich Sinn?
Das frage ich mich schon viele Jahre, seit es diese Attribute gibt.
In meinen FHEMInstallationen habe ich die noch nie gebraucht oder vermisst.
Ich definiere die Einträge nicht in der DB-Definition, sondern in jedem Device mit dem Attribut "DbLogInclude". Das ist für mich übersichtlicher. Ich glaube diese Werte müssen auch als Event erlaubt sein.
Zitat von: rabehd am 10 Juni 2023, 10:15:57Ich glaube diese Werte müssen auch als Event erlaubt sein.
Grundsätzlich ist erstmal jeder event, den ein device erzeugt, "erlaubt". Dazu bedarf es der Attribute event-on... nicht.
Das ist richtig und Dein Zitat ist aus dem Zusammenhang gerissen.
Also nochmal: ich vermute, dass die Einträge im Attribut "DbLogInclude" nicht als Event verboten sein dürfen.
Zitat von: rabehd am 10 Juni 2023, 10:15:57Ich definiere die Einträge nicht in der DB-Definition, sondern in jedem Device mit dem Attribut "DbLogInclude". Das ist für mich übersichtlicher. Ich glaube diese Werte müssen auch als Event erlaubt sein.
Ja, es muss ein Event kommen, damit DbLogInclude aktiv wird.
VG Christian