[patch] DbLog: Modifiers in defaultMinInterval / DbLogExclude / DbLogInclude

[kaarsten]

Hallo Heiko,

ein weiteres DbLog-Problem das mich schon seit Jahren plagt ist die Gestaltung des `defaultMinInterval` Attributs (+ des `force` Modifiers). Ein Implementierungsvorschlag in Form eines Patches befindet sich im Anhang.

Ich habe folgende zwei Kritikpunkte:

• Das Attribut `defaultMinInterval` / `DbLogExclude` / `DbLogInclude` ist in der commandref schwer zu verstehen (doppelte/dreifache Verneinung mit logischem und):
  

  
  If a defaultMinInterval is set, the logentry is dropped if the defined interval is not reached and the value vs. lastvalue is equal. --> Doppelte Verneinung
  If the optional parameter "force" is set, the logentry is also dropped even though the value is not equal the last one and the defined interval is not reached. --> Dreifache Verneinung
  

• Es ist nicht möglich ein Mindestintervall zu definieren welches unabhängig von einer Werteänderung ist: "Speichere den Temperaturwert höchstens alle 5 Minuten"

Ich vermute dass sich das gewünschte Verhalten durch die globalen `event-*` Attribute umsetzen lässt, jedoch haben diese Attribute aus meiner Sicht die Aufgabe Events zu reduzieren/verändern/erzeugen. Die `defaultMinInterval` / `DbLogExclude` / `DbLogInclude` Attribute hingegen sind nur für die Speicherung in die Datenbank verantwortlich.

Aktuelle Situation
Durch das `defaultMinInterval` Attribut + `force` Modifier lassen sich derzeit also nur folgende Fälle abbilden:

Code Auswählen Erweitern


| Modifier | In Intervall, Wert gleich | In Intervall, Wert geändert | Außer Intervall, Wert gleich | Außer Intervall, Wert geändert |
|----------+---------------------------+-----------------------------+------------------------------+--------------------------------|
| <none>   | ignorieren                | speichern                   | speichern                    | speichern                      |
| force    | ignorieren                | ignorieren                  | ignorieren                   | speichern                      |


Vorschlag
Ich schlage vor die Modifier zu erweitern um alle logisch möglichen Kombinationen zu erlauben:

Code Auswählen Erweitern


| Modifier                  | In Intervall, Wert gleich | In Intervall, Wert geändert | Außer Intervall, Wert gleich | Außer Intervall, Wert geändert |
|---------------------------+---------------------------+-----------------------------+------------------------------+--------------------------------|
| intervalOnly              | ignorieren                | ignorieren                  | speichern                    | speichern                      |
| changeOnly                | ignorieren                | speichern                   | ignorieren                   | speichern                      |
| intervalOrChange / <none> | ignorieren                | speichern                   | speichern                    | speichern                      |
| intervalAndChange / force | ignorieren                | ignorieren                  | ignorieren                   | speichern                      |


Der Anwendungsfall "Speichere den Temperaturwert höchstens alle 5 Minuten" kann folglich durch die Verwendung des `intervalOnly` Modifiers umgesetzt werden. Konkret:

Code Auswählen Erweitern

attr misc.dblog defaultMinInterval .*::300::intervalOnly

Testfälle
Ich habe meine Implementierung getestet indem ich mit einem `at` device readings im regelmäßigen Intervall generiert habe:

• `always_one` wird jede Sekunde auf den Wert `1` gesetzt
• `mononic` wird jede Sekunde um den Wert `1` inkrementiert
• `mononic_rand` wird jede Sekunde mit einer Wahrscheinlichkeit von 5% um den Wert `1` inkrementiert

Code Auswählen Erweitern


define misc.dblog DbLog /opt/fhem/dbconfig .*:.*
attr misc.dblog DbLogSelectionMode Include
attr misc.dblog DbLogType History
attr misc.dblog asyncMode 0
attr misc.dblog bulkInsert 0
attr misc.dblog defaultMinInterval .*::60::changeOnly
define a1 at +*00:00:01 {\
my $monotonic = ReadingsVal("a1", "monotonic", 0) + 1;;\
my $monotonic_rand = ReadingsVal("a1", "monotonic_rand", 0) + (rand(100) < 5);;\
fhem("setreading a1 always_one 1");;\
fhem("setreading a1 monotonic $monotonic");;\
fhem("setreading a1 monotonic_rand $monotonic_rand");;\
}
attr a1 DbLogInclude always_one,monotonic,monotonic_rand
attr a1 suppressReading state


Es folgen die Datenbank-Einträge die jeweils mit dem angegebenen Modifier erzeugt werden:

• intervalOnly: Unabhängig vom Wert werden alle Events welche in einem 60s-Fenster nach dem ersten Event ausgelöst werden ignoriert
• changeOnly: Jede Wertänderung in `monotonic` und `monotonic_rand` wird gespeichert; `always_one` wird nie gespeichert; Ein zeitliches Intervall wird nicht berücksichtigt
• intervalOrChange: Genau so wie `changeOnly`, nur dass zusätzlich jede 60s ein `always_one` Wert gespeichert wird
• intervalAndChange: `always_one` wird nie gespeichert, da sich der Wert nie ändert; Die sich ändernden Werte `monotonic` und `monotonic_rand` werden nur alle 60s gespeichert

Code Auswählen Erweitern


####### attr misc.dblog defaultMinInterval .*::60::intervalOnly
fhem=# select * from history where device = 'a1' order by timestamp asc;
      timestamp      | device | type |       event        |    reading     | value | unit
---------------------+--------+------+--------------------+----------------+-------+------
2022-11-12 17:07:52 | a1     | AT   | monotonic_rand: 56 | monotonic_rand | 56    |
2022-11-12 17:08:24 | a1     | AT   | monotonic: 1123    | monotonic      | 1123  |
2022-11-12 17:08:43 | a1     | AT   | always_one: 1      | always_one     | 1     |
2022-11-12 17:08:53 | a1     | AT   | monotonic_rand: 58 | monotonic_rand | 58    |
2022-11-12 17:09:24 | a1     | AT   | monotonic: 1183    | monotonic      | 1183  |
2022-11-12 17:09:44 | a1     | AT   | always_one: 1      | always_one     | 1     |
2022-11-12 17:09:53 | a1     | AT   | monotonic_rand: 61 | monotonic_rand | 61    |
2022-11-12 17:10:25 | a1     | AT   | monotonic: 1244    | monotonic      | 1244  |
2022-11-12 17:10:45 | a1     | AT   | always_one: 1      | always_one     | 1     |
2022-11-12 17:10:54 | a1     | AT   | monotonic_rand: 64 | monotonic_rand | 64    |
2022-11-12 17:11:25 | a1     | AT   | monotonic: 1304    | monotonic      | 1304  |
2022-11-12 17:11:45 | a1     | AT   | always_one: 1      | always_one     | 1     |
(12 rows)


####### attr misc.dblog defaultMinInterval .*::60::changeOnly
fhem=# select * from history where device = 'a1' order by timestamp asc;
      timestamp      | device | type |       event        |    reading     | value | unit
---------------------+--------+------+--------------------+----------------+-------+------
2022-11-12 17:12:45 | a1     | AT   | monotonic: 1384    | monotonic      | 1384  |
2022-11-12 17:12:46 | a1     | AT   | monotonic: 1385    | monotonic      | 1385  |
2022-11-12 17:12:47 | a1     | AT   | monotonic: 1386    | monotonic      | 1386  |
2022-11-12 17:12:48 | a1     | AT   | monotonic: 1387    | monotonic      | 1387  |
2022-11-12 17:12:49 | a1     | AT   | monotonic_rand: 70 | monotonic_rand | 70    |
2022-11-12 17:12:49 | a1     | AT   | monotonic: 1388    | monotonic      | 1388  |
2022-11-12 17:12:50 | a1     | AT   | monotonic: 1389    | monotonic      | 1389  |
...
2022-11-12 17:12:58 | a1     | AT   | monotonic: 1397    | monotonic      | 1397  |
2022-11-12 17:12:59 | a1     | AT   | monotonic: 1398    | monotonic      | 1398  |
2022-11-12 17:13:00 | a1     | AT   | monotonic_rand: 71 | monotonic_rand | 71    |
2022-11-12 17:13:00 | a1     | AT   | monotonic: 1399    | monotonic      | 1399  |
2022-11-12 17:13:01 | a1     | AT   | monotonic: 1400    | monotonic      | 1400  |
...
2022-11-12 17:13:14 | a1     | AT   | monotonic: 1413    | monotonic      | 1413  |
2022-11-12 17:13:15 | a1     | AT   | monotonic: 1414    | monotonic      | 1414  |
2022-11-12 17:13:15 | a1     | AT   | monotonic_rand: 72 | monotonic_rand | 72    |
2022-11-12 17:13:16 | a1     | AT   | monotonic: 1415    | monotonic      | 1415  |
2022-11-12 17:13:17 | a1     | AT   | monotonic: 1416    | monotonic      | 1416  |
2022-11-12 17:13:18 | a1     | AT   | monotonic: 1417    | monotonic      | 1417  |
2022-11-12 17:13:19 | a1     | AT   | monotonic: 1418    | monotonic      | 1418  |
2022-11-12 17:13:20 | a1     | AT   | monotonic: 1419    | monotonic      | 1419  |
(72 rows)


####### attr misc.dblog defaultMinInterval .*::60::intervalOrChange
fhem=# select * from history where device = 'a1' order by timestamp asc;
      timestamp      | device | type |       event        |    reading     | value | unit
---------------------+--------+------+--------------------+----------------+-------+------
2022-11-12 16:59:46 | a1     | AT   | monotonic: 605     | monotonic      | 605   |
2022-11-12 16:59:47 | a1     | AT   | monotonic: 606     | monotonic      | 606   |
2022-11-12 16:59:48 | a1     | AT   | monotonic: 607     | monotonic      | 607   |
...
2022-11-12 17:00:03 | a1     | AT   | monotonic: 622     | monotonic      | 622   |
2022-11-12 17:00:04 | a1     | AT   | monotonic: 623     | monotonic      | 623   |
2022-11-12 17:00:05 | a1     | AT   | monotonic_rand: 29 | monotonic_rand | 29    |
2022-11-12 17:00:05 | a1     | AT   | monotonic: 624     | monotonic      | 624   |
2022-11-12 17:00:06 | a1     | AT   | monotonic: 625     | monotonic      | 625   |
...
2022-11-12 17:00:38 | a1     | AT   | monotonic: 657     | monotonic      | 657   |
2022-11-12 17:00:39 | a1     | AT   | monotonic: 658     | monotonic      | 658   |
2022-11-12 17:00:40 | a1     | AT   | always_one: 1      | always_one     | 1     |
2022-11-12 17:00:40 | a1     | AT   | monotonic: 659     | monotonic      | 659   |
2022-11-12 17:00:41 | a1     | AT   | monotonic: 660     | monotonic      | 660   |
...
2022-11-12 17:01:03 | a1     | AT   | monotonic: 682     | monotonic      | 682   |
2022-11-12 17:01:04 | a1     | AT   | monotonic: 683     | monotonic      | 683   |
2022-11-12 17:01:05 | a1     | AT   | monotonic_rand: 29 | monotonic_rand | 29    |
2022-11-12 17:01:05 | a1     | AT   | monotonic: 684     | monotonic      | 684   |
2022-11-12 17:01:06 | a1     | AT   | monotonic: 685     | monotonic      | 685   |
...
2022-11-12 17:01:14 | a1     | AT   | monotonic: 693     | monotonic      | 693   |
2022-11-12 17:01:15 | a1     | AT   | monotonic: 694     | monotonic      | 694   |
2022-11-12 17:01:15 | a1     | AT   | monotonic_rand: 30 | monotonic_rand | 30    |
2022-11-12 17:01:16 | a1     | AT   | monotonic: 695     | monotonic      | 695   |
2022-11-12 17:01:17 | a1     | AT   | monotonic: 696     | monotonic      | 696   |
...
2022-11-12 17:01:40 | a1     | AT   | monotonic: 719     | monotonic      | 719   |
2022-11-12 17:01:41 | a1     | AT   | monotonic: 720     | monotonic      | 720   |
2022-11-12 17:01:41 | a1     | AT   | always_one: 1      | always_one     | 1     |
2022-11-12 17:01:42 | a1     | AT   | monotonic: 721     | monotonic      | 721   |
2022-11-12 17:01:43 | a1     | AT   | monotonic: 722     | monotonic      | 722   |
(123 rows)

####### attr misc.dblog defaultMinInterval .*::60::intervalAndChange
fhem=# select * from history where device = 'a1' order by timestamp asc;
      timestamp      | device | type |       event        |    reading     | value | unit
---------------------+--------+------+--------------------+----------------+-------+------
2022-11-12 17:03:48 | a1     | AT   | monotonic_rand: 35 | monotonic_rand | 35    |
2022-11-12 17:04:21 | a1     | AT   | monotonic: 880     | monotonic      | 880   |
2022-11-12 17:04:49 | a1     | AT   | monotonic_rand: 41 | monotonic_rand | 41    |
2022-11-12 17:05:22 | a1     | AT   | monotonic: 941     | monotonic      | 941   |
2022-11-12 17:05:50 | a1     | AT   | monotonic_rand: 44 | monotonic_rand | 44    |
2022-11-12 17:06:23 | a1     | AT   | monotonic: 1002    | monotonic      | 1002  |
2022-11-12 17:06:51 | a1     | AT   | monotonic_rand: 52 | monotonic_rand | 52    |
2022-11-12 17:07:24 | a1     | AT   | monotonic: 1063    | monotonic      | 1063  |
(8 rows)


Falls du diese Änderung für gut befindest werde ich an einer schlüssigen Beschreibung / Dokumentation für die commandref arbeiten.

Viele Grüße,
kaarsten

[betateilchen]

Popcorn für alle!

[RalfRog]

Popcorn für alle!

Soll heissen "gähn", schon etliche Mal durchgekaut? Oder anders?

Möchte nochmal ein große Lob an DS_Starter loswerden, dass DBLog und DBRep tolle und gut zu benutzende Module sind und er tollen Support leistet.

Ich stolpere auch jedesmal über die Beschreibung in der Commanref.
"Ist MinIntervall angegeben, wird der Logeintrag nicht geloggt, wenn das Intervall noch nicht erreicht und der Wert des Readings sich nicht verändert hat."
Mit anderen Worten "es wird geloggt wenn das Intervall abgelaufen ist oder der Wert sich geändert hat."

Meiner Beobachtung nach wird etwas abweichend davon: dann geloggt wenn das Intervall abgelaufen ist UND der Wert sich geändert hat (beides muss zutreffen).
Mein Solarmodul mit dem Attribut "DbLogInclude power:120,energyCum:900" schreibt nachts keine Werte ins Log, da sich die Werte für Power und Energie nicht ändern.
Also wird  "nicht geloggt wenn das Intervall noch nicht erreicht ODER der Wert des Readings sich nicht verändert hat" (eines von beidem muss zutreffen).

Möglicherweise interpretier ich es falsch.

Grüße Ralf

[DS_Starter]

Ich habe mir Gedanken gemacht die Beschreibung zu berbessern.
Meiner Meinung nach wäre folgender Text wahrscheinlich deutlicher ?

attr <device> DbLogInclude Regex:MinInterval[:force],[Regex:MinInterval[:force]] ...

Ist ein DbLog Device definiert, wird in allen Devices das Attribut DbLogInclude propagiert.

DbLogInclude funktioniert im Endeffekt genau wie DbLogExclude, ausser dass Readings welche auf den Regex matchen in das Logging
eingeschlossen statt ausgeschlossen werden.

Ist MinIntervall angegeben, wird der Event erst nach <MinIntervall> Sekunden erneut geloggt sofern der Wert des Readings
unverändert ist.
Falls sich der Wert des Readings gegenüber dem letzten Event geändert hat, wird der Event auch innerhalb von
<MinIntervall> geloggt.

Ist der optionale Parameter "force" hinzugefügt, wird der Logeintrag auch dann nicht geloggt, wenn sich der Wert des Readings
verändert hat. Siehe dazu auch die DbLog Attribute defaultMinInterval und DbLogSelectionMode.


---------------------------

Also ich finde die Beschreibung oben recht eindeutig und würde gern eure Meinung dazu wissen wollen wie es beim User ankommt.

Mein Solarmodul mit dem Attribut "DbLogInclude power:120,energyCum:900" schreibt nachts keine Werte ins Log, da sich die Werte für Power und Energie nicht ändern.

Ich vermute du hast event-on-change-reading im Quellendevice gesetzt hast. Dann wird kein Event erzeugt wenn der Wert gleichbleibt.

[betateilchen]

Ist ein DbLog Device definiert, wird in allen Devices das Attribut DbLogInclude propagiert.

Ja, selbst wenn man sie nie im Leben brauchen wird. Das nervt mich seit Jahren.

DbLogInclude funktioniert im Endeffekt genau wie DbLogExclude,

Für mich sind beide Attribute komplett entbehrlich. Trotzdem bekommt man sie "zwangsweise".

Also ich finde die Beschreibung oben recht eindeutig und würde gern eure Meinung dazu wissen wollen wie es beim User ankommt.

Das ist völlig nachvollziehbar, dass Du als zuständiger Entwickler das eindeutig findest.
Aber ein "normaler Anwender" wird das für eine sehr lange Zeit nicht so verstehen, wie Du Dir das eindeutig gedacht hast.

Da muss ich dem Vorredner durchaus recht geben.

[DS_Starter]

Also wenn jemand einen Vorschlag für einen besseren Text hat, bin ich da völlig unvoreingenommen.

DbLogInclude und DbLogExclude und dessen Text habe ich auch nur "geerbt" 

[kaarsten]

Ich bin kein Fan davon das Attribut DbLogInclude über DbLogExclude zu definieren.

DbLogInclude funktioniert im Endeffekt genau wie DbLogExclude,

Vorschlag:

Mit dem Attribut DbLogInclude kann definiert werden welche Readings in der Datenbank gespeichert werden sollen. Die Definition der zu speichernden Readings erfolgt über einen regulären Ausdruck. Alle Readings auf die mit dem regulären Ausdruck matchen werden in die Datenbank gespeichert. Alle Readings die nicht auf den regulären Ausdruck matchen werden nicht gespeichert.

Mit dem Zusatz :MinInterval kann weiter eingeschränkt werden unter welchen Bedingungen das Reading gespeichert wird. MinInterval gibt an, dass ein Wert nur dann gespeichert wird wenn er auf den regulären Ausdruck matcht und mindestens <MinInterval> Sekunden seit der letzten Speicherung verstrichen sind. Unabhängig des Intervalls wird das Reading zusätzlich gespeichert wenn sich der Wert des Readings verändert hat.

Mit dem Zusatz :MinInterval:force können die zu speichernden Readings noch weiter reduziert werden. Dabei gibt MinInterval an, dass ein Wert nur dann gespeichert wird wenn er auf den regulären Ausdruck matcht und mindestens <MinInterval> Sekunden seit der letzten Speicherung verstrichen sind und sich der Wert des Readings verändert hat.

[DS_Starter]

Hallo kaarsten,

danke für den Input ... ich versuche es noch etwas zu straffen, zum Beispiel ist der Term ".. Reading zusätzlich... gespeichert ..." in der Form auch nicht korrekt bzw. zweideutig zu verstehen.

[DS_Starter]

Ist aus User-Sicht der folgende Text jetzt gut verständlich ?

attr <device> DbLogInclude Regex[:MinInterval][:force],[Regex[:MinInterval][:force]], ...

Unter der Voraussetzung des gesetzten Attributs DbLogSelectionMode=Include werden mit dem Attribut DbLogInclude die Readings definiert, die in der Datenbank gespeichert werden sollen.
Die Definition der zu speichernden Readings erfolgt über einen regulären Ausdruck.
Alle Readings die mit dem regulären Ausdruck matchen werden in der Datenbank gespeichert.

Der optionale Zusatz <MinInterval> gibt an, dass ein Wert nur dann gespeichert wird wenn er auf den regulären Ausdruck matcht, es sich nicht geändert hat und mindestens <MinInterval> Sekunden seit der letzten Speicherung vergangen sind.
Unabhängig des Intervalls wird das Reading gespeichert wenn sich der Wert des Readings verändert hat.

Mit dem optionalen Zusatz "force" wird erzwungen das angegebene <MinInterval> einzuhalten auch wenn sich der Wert des
Readings innerhalb von <MinInterval> seit der letzten Speicherung verändert hat.

[kaarsten]

Ist aus meiner Sicht gut verständlich. Jedoch stecke ich da wohl zu tief drinnen, um das aus User-Sicht beurteilen zu können.

[RalfRog]

Ich vermute du hast event-on-change-reading im Quellendevice gesetzt hast. Dann wird kein Event erzeugt wenn der Wert gleichbleibt.

Ne hatte ich nicht so gemacht, damit keine Lücken in den Logs entstehen. So sind die relevanten Attribute vom Shelly-Device gesetzt:

Code Auswählen Erweitern


DbLogExclude          .*
DbLogInclude           power:120,energyCum:900,statEnergyCumDayLast,statEnergyCumMonthLast,statEnergyCumYearLast
devStateIcon           .....bla
event-min-interval   power.*:120,energy.*:900

Der Shelly schickt nachts keine Ereignisse weil halt kein Strom mehr fließt, aber der Logik von event-min-interval  folgend müsste doch alle 120/900 ein power/energy Event kommen und damit theoretisch auch Nachts (wobei mir es recht ist das Nachts nix geloggt wird).


CommadRef: "Wird DbLog genutzt, wird in allen Devices das Attribut DbLogInclude (oder auch DbLogExclude) propagiert. "
--> find ich ganz gut, da man dann direkt am Device sieht wie man das Logging konfiguriert hat.

CommadRef: "Ist MinIntervall angegeben, wird der Logeintrag nicht geloggt, wenn das Intervall noch nicht erreicht und der Wert des Readings sich nicht verändert hat"
--> die Formulierung "nicht geloggt" wenn "nicht erreicht" und "nicht verändert" macht mit den Verneinungen einen Knoten im Hirn.
--> Ich habe mir die Logikmatrix gemalt und für mich ist die Formulierung "es wird geloggt" wenn das "Intervall errreicht" ist oder der "Wert sich verändert" hat leichter  (wie gesagt meine Beobachtung ist eher Intervall erreicht und Wertänderung)

Ansonsten fand ich den Text in der CommadRef weitgehend ok.

P.S.
Den Text muss ich in Ruhe lesen ist was spät jetzt....
Ich denke er hakt noch was.

Komme "heute" Abend noch mal drauf zurück

[OdfFhem]

aber der Logik von event-min-interval  folgend müsste doch alle 120/900 ein power/energy Event kommen

FHEM prüft die Event-Generierung nur, wenn ein Reading auch tatsächlich aktualisiert werden soll - z.B. angetriggert vom verantwortlichen Gerät mit oder ohne Wertänderung. event-min-interval sorgt demnach für keinerlei Events im 120/900-Takt, wenn der Shelly nur alle 30 Minuten Wertaktualisierungen übermittelt.

[kaarsten]

Ich habe mir die Logikmatrix gemalt und für mich ist die Formulierung "es wird geloggt" wenn das "Intervall errreicht" ist oder der "Wert sich verändert" hat leichter  (wie gesagt meine Beobachtung ist eher Intervall erreicht und Wertänderung)

Spricht etwas dagegen die Logikmatrix mit in die Commandref aufzunehmen?

Code Auswählen Erweitern


| Modifier | In Intervall, Wert gleich | In Intervall, Wert geändert | Außer Intervall, Wert gleich | Außer Intervall, Wert geändert |
|----------+---------------------------+-----------------------------+------------------------------+--------------------------------|
| <none>   | ignorieren                | speichern                   | speichern                    | speichern                      |
| force    | ignorieren                | ignorieren                  | ignorieren                   | speichern                      |


Damit wird auch klar welche Fälle mit dem Attribut derzeit nicht abgebildet werden können und ggf. in Kombination mit den event-* Attributen realisiert werden müssen.

[RalfRog]

FHEM prüft die Event-Generierung nur, wenn ein Reading auch tatsächlich aktualisiert werden soll - z.B. angetriggert vom verantwortlichen Gerät mit oder ohne Wertänderung. event-min-interval sorgt demnach für keinerlei Events im 120/900-Takt, wenn der Shelly nur alle 30 Minuten Wertaktualisierungen übermittelt.

Ich will jetzt hier nicht zu sehr Off-Topic werden. Meine Erkenntnisse stammen von hier https://wiki.fhem.de/wiki/Event-min-interval. dort heisst es:

Ein Event wird sofort ausgelöst wenn mindestens 3600 Sekunden (1h) seit dem letzten Event vergangen ist EGAL ob das aktualisierte Reading geändert wird oder gleich bleibt.

(bei nicht gesetzten event-on-update-reading und event-on-change-reading)

Aber ja du hast recht. Man (ich) unterschlägt gedanklich vermutlich allzu leicht, dass trotzdem vom Gerät eine Meldung (Trigger) mit gleichem Wert kommen muss.

[DS_Starter]

Hallo Ralf,

bevor du dir etwas falsches einprägst ... das von dir zitierte Detail im Wiki-Beitrag ist leider falsch.
Das Attribut event-min-interval erzwingt keineswegs einen Event. In der ComRef zu diesem Attr ist es exakt beschrieben:

event-min-interval
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind. Falls event-on-change-reading auch spezifiziert ist, dann werden sie mit ODER kombiniert, d.h. wenn einer der beiden Bedingungen wahr ist.

OddFhem hat mit seiner Darstellung recht.

Erzwingen kann man einen Logeintrag mit addLog im DbLog. FileLog hat auch einen Mechanismus über sein Attr addLog eingebaut.

[RalfRog]

Spricht etwas dagegen die Logikmatrix mit in die Commandref aufzunehmen?
...

Auch nicht schlecht.


attr <device> DbLogInclude Regex[:MinInterval][:force],[Regex[:MinInterval][:force]], ...

Mit dem Attribut DbLogInclude werden die Readings definiert, die in der Datenbank gespeichert werden sollen. Die Definition der zu speichernden Readings erfolgt über einen regulären Ausdruck und alle Readings die mit dem regulären Ausdruck matchen werden in der Datenbank gespeichert.

Der optionale Zusatz <MinInterval> gibt an, dass ein Wert dann gespeichert wird wenn mindestens <MinInterval> Sekunden seit der letzten Speicherung vergangen sind.

Unabhängig vom Ablauf des Intervalls wird das Reading gespeichert wenn sich der Wert des Readings verändert hat. Mit dem optionalen Zusatz "force" kann erzwungen werden das angegebene Intervall <MinInterval> einzuhalten auch wenn sich der Wert des Readings seit der letzten Speicherung verändert hat.

Hinweis1: Attribut DbLogSelectionMode muss entsprechend gesetzt sein (siehe dort). Mit Attribut defaultMinInterval kann ein Default vorgegeben werden.
Hinweis2: Wird DbLog genutzt, wird in allen Devices das Attribut DbLogInclude und  DbLogExclude propagiert.

Dann vielleicht noch die Matrix
Analog dazu DbLogExclude

[DS_Starter]

Die kleine Matrix ist für das Verständnis durchaus hilfreich, allerdings wird außerhalb des Intervalls immer gespeichert, ob sich der Wert geändert hat oder nicht.
Ich fasse alles nochmal zusammen.

[DS_Starter]

Hier die Zusammenfassung:


attr <device> DbLogInclude Regex[:MinInterval][:force],[Regex[:MinInterval][:force]], ...

Mit dem Attribut DbLogInclude werden die Readings definiert, die in der Datenbank gespeichert werden sollen.
Die Definition der zu speichernden Readings erfolgt über einen regulären Ausdruck und alle Readings die mit dem regulären
Ausdruck matchen werden in der Datenbank gespeichert.

Der optionale Zusatz <MinInterval> gibt an, dass ein Wert dann gespeichert wird wenn mindestens <MinInterval> Sekunden
seit der letzten Speicherung vergangen sind.

Unabhängig vom Ablauf des Intervalls wird das Reading gespeichert wenn sich der Wert des Readings verändert hat. Mit dem
optionalen Modifier "force" kann erzwungen werden das angegebene Intervall <MinInterval> einzuhalten auch wenn sich der Wert
des Readings seit der letzten Speicherung verändert hat.

| Modifier |              innerhalb Intervall             | außerhalb Intervall |
|             | Wert gleich           | Wert geändert   |                             |
|----------+--------------------+-------------------+----------------------|
| <none> | ignorieren            | speichern          | speichern              |
| force     | ignorieren             | ignorieren         | speichern              |

Hinweise:
Das Attribut DbLogInclude wird in allen Devices propagiert wenn DbLog verwendet wird.
Das Attribut DbLogSelectionMode muss muss entsprechend gesetzt sein um DbLogInclude zu aktivieren.
Mit dem Attribut defaultMinInterval kann ein Default vorgegeben werden.


-------------------

Für DbLogExclude  passe ich es dann sinngemäß auch an. Die Verweise auf andere Attribute werden mit einem Link unterlegt sodass man dorthin verzweigen kann.

[RalfRog]

Von mir den Daumen hoch 

Die Verweise auf andere Attribute werden mit einem Link unterlegt sodass man dorthin verzweigen kann.

Das wichtige DbLogSelectionMode steht ja glücklicherweise direkt darüber

[kaarsten]

Top, das finde ich jetzt schon viel verständlicher. Danke fürs Zusammenfassen aller Vorschläge!

[DS_Starter]

Ist zwar länger geworden als ich es vermutet hätte, aber wenn es nun verständlich ist übernehme ich den Text gerne. 
Denke dass ich die ComRef in DbLog bis zum WE überarbeitet habe.

Danke euch 

Das wichtige DbLogSelectionMode steht ja glücklicherweise direkt darüber

Naja, es gibt ja auch die Direkthilfe bei der Auswahl der Attribute im FHEMWEB. Dann ist der Link dennoch hilfreich.

[DS_Starter]

Ist eingecheckt und morgen früh im Regelupdate.

LG