Verwendungder Attribute event-on*

[wowogiengen]

Hallo,
ich habe mal eine Frage zur Verwendung der Attribute

Code Auswählen Erweitern

event-on-change-reading
event-on-update-reading
und evtl.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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 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

[rabehd]

Löschen und/oder Zusammenfassen in der DB sind ein anderes/eigenes Thema und eigentlich gut beschrieben.

[wowogiengen]

Lö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...

[betateilchen]

Frage 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.

[rabehd]

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.

[betateilchen]

Ich 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.

[rabehd]

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.

[ch.eick]

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.

Ja, es muss ein Event kommen, damit DbLogInclude aktiv wird.

VG Christian