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):
Zitat
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 SituationDurch das `defaultMinInterval` Attribut + `force` Modifier lassen sich derzeit also nur folgende Fälle abbilden:
| 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 |
Ich schlage vor die Modifier zu erweitern um alle logisch möglichen Kombinationen zu erlauben:
| 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:
attr misc.dblog defaultMinInterval .*::300::intervalOnlyTestfälleIch 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
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
####### 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
Popcorn für alle!
Zitat von: betateilchen am 12 November 2022, 20:45:27
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
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.
Zitat
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.
Zitat von: DS_Starter am 23 November 2022, 21:09:32
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.
Zitat von: DS_Starter am 23 November 2022, 21:09:32
DbLogInclude funktioniert im Endeffekt genau wie DbLogExclude,
Für mich sind beide Attribute komplett entbehrlich. Trotzdem bekommt man sie "zwangsweise".
Zitat von: DS_Starter am 23 November 2022, 21:09:32
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.
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" ;)
Ich bin kein Fan davon das Attribut DbLogInclude über DbLogExclude zu definieren.
ZitatDbLogInclude 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.
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.
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.
Ist aus meiner Sicht gut verständlich. Jedoch stecke ich da wohl zu tief drinnen, um das aus User-Sicht beurteilen zu können.
Zitat von: DS_Starter am 23 November 2022, 21:09:32
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:
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.... :P
Ich denke er hakt noch was.
Komme "heute" Abend noch mal drauf zurück
Zitat von: RalfRog am 24 November 2022, 00:12:29
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.
ZitatIch 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?
| 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.
Zitat von: OdfFhem am 24 November 2022, 02:44:15
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 (https://wiki.fhem.de/wiki/Event-min-interval). dort heisst es:
ZitatEin 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.
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.
Zitat von: kaarsten am 24 November 2022, 17:37:59
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 MatrixAnalog dazu DbLogExclude
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.
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.
Von mir den Daumen hoch :)
ZitatDie Verweise auf andere Attribute werden mit einem Link unterlegt sodass man dorthin verzweigen kann.
Das wichtige DbLogSelectionMode steht ja glücklicherweise direkt darüber
Top, das finde ich jetzt schon viel verständlicher. Danke fürs Zusammenfassen aller Vorschläge!
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 :)
Zitat
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.
Ist eingecheckt und morgen früh im Regelupdate.
LG