Also ich denke, dass ich inhaltlich die event-on-*-Attribute verstehe (hoffentlich) und auch das Zusammenspiel mit event-min-interval. Aber mir ist noch nicht so klar, wann man am besten welche Attribute einsetzt bzw. nach welchen Kriterien man entscheidet, wo man welches Reading einträgt.
Generell will man ja die Anzahl der Events minimieren bzw. keine unnötigen Events generieren. Ich gehe dabei im Moment so vor:
1. Ich trage die relevanten Readings in event-on-change-reading ein.
Relevant sind:
- Readings, auf die ich per notify reagieren möchte
- Readings, die ich plotten möchte
- Readings, die ich per longpoll in der GUI live updaten möchte
2. Falls sich Werte wegen on-change ZU selten ändern, trage ich sie zusätzlich bei event-min-interval on, um alle x Minuten doch ein Event zu bekommen (zB zum Plotten).
3. Bei Geräten, bei denen ich keine Events brauche, trage ich nur bei event-on-update-reading einen leeren String ein (resultiert dann im Wert "1").
Nach welchen Kriterien geht ihr vor? Wann genau ist event-on-update-reading überhaupt sinnvoll?
Ich glaube das event-min-interval hast du nicht ganz richtig verstanden (aus der Doku):
Zitatevent-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.
D.h. es wird höchstens alle X Sekunden ein Event generiert.
Das von dir beschriebene Problem mit dem Plotten kannst du mit Logproxy in den Griff bekommen. Logproxy kann etwas weiter in die Vergangenheit gucken und so den Plot nach Vorne hin sozusagen verlängern.
Zitat von: peterchen89 am 21 April 2015, 12:38:56
Ich glaube das event-min-interval hast du nicht ganz richtig verstanden (aus der Doku):D.h. es wird höchstens alle X Sekunden ein Event generiert.
So viel ich weiß, ist das eben genau nicht so. Es verhält sich scheinbar unterschiedlich bei on-change und on-update. Es wird einmal verODERt und einmal verUNDet:
http://forum.fhem.de/index.php/topic,26694.msg196955.html#msg196955 (http://forum.fhem.de/index.php/topic,26694.msg196955.html#msg196955)
http://forum.fhem.de/index.php/topic,31856.msg247547.html#msg247547 (http://forum.fhem.de/index.php/topic,31856.msg247547.html#msg247547)
Zitat von: peterchen89 am 21 April 2015, 12:38:56
Das von dir beschriebene Problem mit dem Plotten kannst du mit Logproxy in den Griff bekommen. Logproxy kann etwas weiter in die Vergangenheit gucken und so den Plot nach Vorne hin sozusagen verlängern.
Ja, das kenne ich. Empfinde ich persönlich aber eher als Workaround. Dieses "etwas weiter" ist leider schlecht greifbar.
Zitat von: peterchen89 am 21 April 2015, 12:38:56
Ich glaube das event-min-interval hast du nicht ganz richtig verstanden (aus der Doku):D.h. es wird höchstens alle X Sekunden ein Event generiert...
Nein, er hat es richtig verstanden. :)
Wenn längere Zeit KEIN Event kommt, weil sich der Wert NICHT geändert hat (on-change), dann wird nach MIN-INTERVAL trotzdem ein Event generiert.
ZitatNach welchen Kriterien geht ihr vor? Wann genau ist event-on-update-reading überhaupt sinnvoll?
sobald man bei event-on-change/update explizit ein odere mehrere readings angibt, werden bei allen nicht aufgeführten readings die events abgeschaltet. daher mache ich grundsätzlich "
event-on-change-reading .*", um grundsätzlich die events zu minimieren, aber trotzdem alle infos speichern zu können. also alle readings erzeugen events bei änderung. wenn ich nun bei bestimmten readings aber immer ein event brauche, zb bei buttons oder zum überwachen der rssi-werte, setze ich für diese readings zusätzlich event-on-update.
ZitatWenn längere Zeit KEIN Event kommt, weil sich der Wert NICHT geändert hat (on-change), dann wird nach MIN-INTERVAL trotzdem ein Event generiert.
nicht ganz. sondern erst, wenn das reading neu gesetzt wird. also wenn ein reading alle 5 minuten gesetzt wird, es sich aber nicht ändert und min-interval auf 12 min eingestellt ist, sollte das event nach 15 minuten erscheinen.
Zitat
Generell will man ja die Anzahl der Events minimieren bzw. keine unnötigen Events generieren. Ich gehe dabei im Moment so vor:
1. Ich trage die relevanten Readings in event-on-change-reading ein.
Relevant sind:
- Readings, auf die ich per notify reagieren möchte
- Readings, die ich plotten möchte
- Readings, die ich per longpoll in der GUI live updaten möchte
2. Falls sich Werte wegen on-change ZU selten ändern, trage ich sie zusätzlich bei event-min-interval on, um alle x Minuten doch ein Event zu bekommen (zB zum Plotten).
Zu beachten ist noch das die Readings bei
event-min-interval nur ein Event auslösen, wenn sie auch in
event-on-change-reading oder
event-on-update-reading eingetragen sind.
Bei
event-on-change-reading wird event-min-interval
ignoriert wenn sie die Werte änder und sofort ein Event gefeuert
Bei
event-on-update-reading wird event-min-interval
nicht ignoriert wenn sie die Werte änder und wartet bis den Interval ab bis ein Event gefeuert wird
Frage: Wie kann ich Schwellenwerte für ein Reading setzen das nicht nur einen Wert beinhaltet.
Readings:
2015-12-06 04:45:18 battery ok
2015-12-06 04:45:18 dewpoint 11.9
2015-12-06 04:45:18 humidity 53
2015-12-06 04:43:30 state T: 21.9 H: 53 D: 11.9
2015-12-06 04:45:18 temperature 21.9 Ich möchte das state reading alle 15min per
event-min-interval ein event feuert auch wenn sich nichts ändert. Wenn sich zwischen den 15min aber der T Wert um 0.5 oder der H Wert um 5 ändert, soll mit
event-on-change-reading sofort ein Event gefeuert werden.
attr LaCr.Thermo01 event-min-interval state:900
attr LaCr.Thermo01 event-on-change-reading state:??????
Zitat von: Hollo am 21 April 2015, 13:16:28
Nein, er hat es richtig verstanden. :)
Wenn längere Zeit KEIN Event kommt, weil sich der Wert NICHT geändert hat (on-change), dann wird nach MIN-INTERVAL trotzdem ein Event generiert.
Ist zwar schon eine Weile her, aber hier (http://forum.fhem.de/index.php/topic,49515.msg412233.html#msg412233)gibts nochmal ne Antwort darauf:
Zitat von: rudolfkoenig am 18 Februar 2016, 13:12:19
Bevor hier was Falsches gelernt wird:
- event-min-interval sorgt dafuer, dass ein Event hoechstens alle X Sekunden (aber nicht haeufiger) durchgelassen wird, generiert aber selbst keine Events.
- event-on-change-reading laesst events nur bei Aenderung durch (optional mit mindest-delta).
- falls event-on-update-reading gesetzt ist, dann werden die nicht spezifizierten events nicht durchgelassen.
- das Wort "reading" ist in beiden Faellen irrefuehrend, da das Reading immer gesetzt wird, nur das Event wird nicht durchgelassen.
- mit _nicht_ durchlassen meine ich: Modul generiert Event, aber keiner kriegt es mit.
- falls event-on-change-reading zuschlaegt, filtert min-interval nicht (aber da bin ich mir nicht ganz sicher, der Code ist relativ verwirrend).
Das Setzen dieser Attribute erzeugt auch CPU-Last, ob es unter dem Strich weniger Last auf dem System ist, haengt vom Einzelfall ab.
Hallo zusammen.
Habe da nochmal eine Frage zu. Habe dies auch schonmal hier gestellt.
https://forum.fhem.de/index.php/topic,51554.msg463686.html#msg463686 (https://forum.fhem.de/index.php/topic,51554.msg463686.html#msg463686)
Nochma kurz zusammen gefasst. Energiemessteckdose soll geloogt werden. Von den Reading allerdings nur das state, da ja alle Parameter vorhanden sind. Wenn ich ins Log schaue, dann werden auch die kleinsten Änderungen mitgeloggt, welche aber bei Änderung von 0.1 Watt keinen Sinn machen, diese zu loggen.
Es soll nur das state geloggt werden, wenn es Änderungen in der Spannun bzw. im Strom gibt. Ich möchte das state aber nur loggen, wenn die Änderung der Leistung mehr wie 2 Watt sind oder Änderung in der Spannung von mehr wie 2 Volt.
Irgendwie bekomme ich das nicht hin.
Jemanmd eine Idee ???
Gruß und danke
Sascha
Du könntest zB mit dem Attribut stateFormat den Inhalt des state-Readings selbst definieren (zB ohne Nachkommastellen). Du müsstest das allerdings dann selbst in Perl-Code implementieren.
D.h. Die Nachkommastelle von der Leistung einfach abschneiden?!
Von Perl habe ich absolut keine Ahnung. Wie sollte das denn dann aussehen?
Gesendet von meinem SM-T560 mit Tapatalk
STATE ist nicht das gleiche wie state. ersteres ist ein internal letzteres ein reading.
mit stateFormat legst du fest wie STATE aussehen soll. das ist das was im frontend angezeigt wird. nicht das reading state das ein event erzeugt das geloggt wird.
du kannst dir ein user reading definieren und dort passend formatieren oder differenzen bestimmen und dann dieses loggen.
bei einem hm aktor müsstest du aber auch konfigurieren können ab welchem
schwellwert die werte überhaupt gesendet werden.
gruss
andre
Zitatbei einem hm aktor müsstest du aber auch konfigurieren können ab welchem
schwellwert die werte überhaupt gesendet werden.
Dies ist kein HM Aktor, sonder eine Funkmessteckdose NC-5426. STATE ist also nicht gleich state. Wann wird denn STATE aktualisiert ?
Ich logge im Moment das state aus den Readings, also direkt von der Steckdose.
Danke schonmal für eure Hilfe.
Sascha
Argh sorry, richtig, war Quatsch was ich gesagt habe... ::)
OK jetzt hab ich mir einige Forenbeiträge und alle 2-3 Wiki-Einträge zu dem Thema durchgelesen.
Entweder ich kapier es doch nicht oder die Funktion ist buggy.
Update + Min-Interval sollte doch nur ein Event auslösen wenn der Wert geändert wird und die Min-Interval (in Sekunden) erreicht ist.
Ich habe eine HM-ES-PMSw1-Pl Mess-Schalt-Steckdose. (Das Device hat 6 Unter-Channels)
Diese bombardierte mich mit Events im Log.
Das hab ich soweit im Griff. (mit attr suppressReading state) auf 4/6 Channels und einem event-on-change-reading state auf das Main-Device.
Interesse habe ich nur an den 2 Readings der verbleibenden 2 Channels für Aktueller Stromverbrauch in Watt (..._SenPwr) und dem Gesamtzähler (..._Pwr) des Stromverbrauches.
Den Wert des Gesamtzählers würde mir momentan 1x am Tag reichen. (86400 Sekunden)
_SenPwr passt.
_Pwr besitz die Attribute event-min-interval 86400 und event-on-update-reading state
^(event-on-update-reading energy habe ich auch schon probiert)
Aber er schreibt trotzdem alle 10-30 Sekunden.
Im Anhang sind die Screenshots vom Main-Device, vom Unter-Channel _SenPwr und vom Unter-Channel _Pwr.
und so sieht trotzdem das Ergebnis im Event Monitor aus:
2017-01-24 22:50:38 CUL_HM HM_32B1AE_Pwr 186526.3
2017-01-24 22:50:38 CUL_HM HM_32B1AE_SenPwr 365.75
2017-01-24 22:51:22 CUL_HM HM_Bewegungsmelder brightness: 58
2017-01-24 22:52:45 CUL_HM HM_32B1AE_Pwr 186539.3
2017-01-24 22:52:45 CUL_HM HM_32B1AE_SenPwr 403.01
2017-01-24 22:52:53 CUL_HM HM_32B1AE_Pwr 186540.1
2017-01-24 22:52:53 CUL_HM HM_32B1AE_SenPwr 371.79
2017-01-24 22:53:01 CUL_HM HM_32B1AE_Pwr 186540.9
2017-01-24 22:53:01 CUL_HM HM_32B1AE_SenPwr 367.02
2017-01-24 22:53:35 CUL_HM HM_32B1AE_Pwr 186544.4
2017-01-24 22:53:35 CUL_HM HM_32B1AE_SenPwr 367.36
2017-01-24 22:56:05 CUL_HM HM_32B1AE_Pwr 186559.8
2017-01-24 22:56:05 CUL_HM HM_32B1AE_SenPwr 389.38
2017-01-24 22:56:13 CUL_HM HM_32B1AE_Pwr 186560.6
2017-01-24 22:56:13 CUL_HM HM_32B1AE_SenPwr 369.61
2017-01-24 22:56:18 CUL_HM HM_32B1AE_Pwr 186561.1
2017-01-24 22:56:18 CUL_HM HM_32B1AE_SenPwr 380.72
2017-01-24 22:56:21 CUL_HM HM_32B1AE_Pwr 186561.4
2017-01-24 22:56:21 CUL_HM HM_32B1AE_SenPwr 371.49
2017-01-24 22:56:36 CUL_HM HM_32B1AE_Pwr 186563
2017-01-24 22:56:36 CUL_HM HM_32B1AE_SenPwr 391.87
2017-01-24 22:56:44 CUL_HM HM_32B1AE_Pwr 186563.8
2017-01-24 22:56:44 CUL_HM HM_32B1AE_SenPwr 370.62
Bitte immer lists in Codetags, statt Screenshots posten!!
Und dann bitte wirklich an den richtigen Stellen lesen. Der 1. Anlaufpunkt ist IMMER die offizielle Doku und die sagt zu event-min-interval
Zitat[...]comma-separated list of reading:minInterval pairs[...]
Also sowas:
attr <NAME> event-min-interval energy:86400
Vielen Dank für die schnelle Antwort und Hilfe.
Jetzt geht es wie gewünscht !
In diesem Fall hätte mir die Command-Ref hier tatsächlich helfen können da hier das Schlüsselwort "Paare" steht.
Irgendwie, aus wahrscheinlich schlechter Angewohnheit, schaue ich immer zuerst im Wiki nach.
Da dort die Probleme mehr erklärt werden. Und in diesem Fall fehlte genau zu event-min-interval die wiki-Seite.
Ab jetzt werde ich mehr möglicht zuerst in der CommandRef nachschauen.
Auch wenn mir die code- bzw. Befehlsdarstellung im wiki viel besser gefällt als in der commandRef.
Verbesserungsvorschlag ? ;)
Mit den Screenshots der Listings wollte ich keine Board-Etikette verletzen. Sorry !
Ich hab eigentlich genau wegen der Übersichtlichkeit kein Code-Tag verwendet.
Sieht doch Sche.... aus oder ?
DeviceOverview
HM_Mess-Schaltsteckdose_Pwr
187072.2
set HM_32B1AE_Pwr
get HM_32B1AE_Pwr
Internals
DEF
32B1AE02
NAME
HM_32B1AE_Pwr
NOTIFYDEV
global
NR
174
NTFY_ORDER
50-HM_32B1AE_Pwr
STATE
187058.7
TYPE
CUL_HM
chanNo
02
device
HM_32B1AE
Readings
R-averaging
1 s
2016-08-17 21:26:24
R-sign
off
2016-08-17 21:26:24
R-txMinDly
8 s
2016-08-17 21:26:24
R-txThrCur
100 mA
2016-08-17 21:26:24
R-txThrFrq
1 Hz
2016-08-17 21:26:24
R-txThrPwr
100 W
2016-08-17 21:26:24
R-txThrVlt
10 V
2016-08-17 21:26:24
RegL_01.
08:00 7A:01 7B:08 7C:00 7D:27 7E:10 7F:00 80:64 81:00 82:64 83:64 00:00
2017-01-24 21:38:02
boot
off
2017-01-25 18:11:46
current
1679
2017-01-25 18:11:46
eState
E: 187058.7 P: 369.12 I: 1679 U: 236.4 f: 50.02
2017-01-25 18:11:46
energy
187058.7
2017-01-25 18:11:46
energyCalc
209492.5
2017-01-25 18:11:46
energyOffset
22433.8
2016-09-17 20:40:15
frequency
50.02
2017-01-25 18:11:46
power
369.12
2017-01-25 18:11:46
state
187072.2
2017-01-25 18:13:56
voltage
236.4
2017-01-25 18:11:46
attr HM_32B1AE_Pwr
Messen
Attributes
alias
HM_Mess-Schaltsteckdose_Pwr
deleteattr
event-min-interval
state:86400
deleteattr
event-on-update-reading
state
deleteattr
model
HM-ES-PMSw1-Pl
deleteattr
room
Messen
deleteattr
Oder gibt es noch einen Trick die ganze Seite eines Device schön in einen Code-Tag zu packen ?
Wie schon geschrieben, ist ein list das, was man benötigt. Wenn man die angepinnten Beiträge gelesen hat, weiß man das auch.
list <name>
und dann das Ergebnis hier in Code-Tags posten. Das ist keine Bord-Etikette, es hilft aber dem Helfer, besser und schneller zu helfen.
Aah !
Das Kommando list kannte ich noch nicht.
Danke für die Info !
Also z.B. so:
Internals:
CHANGED
DEF 32B1AE02
NAME HM_32B1AE_Pwr
NOTIFYDEV global
NR 174
NTFY_ORDER 50-HM_32B1AE_Pwr
STATE 187265.1
TYPE CUL_HM
chanNo 02
device HM_32B1AE
Helper:
Dblog:
Boot:
Logdb:
TIME 1485290732.7691
VALUE off
Current:
Logdb:
TIME 1485290732.7691
VALUE 1435
Estate:
Logdb:
TIME 1485290732.7691
VALUE E: 186127.7 P: 302.13 I: 1435 U: 234.3 f: 50.01
Energy:
Logdb:
TIME 1485294511.2753
VALUE 186513.3
Energycalc:
Logdb:
TIME 1485290732.7691
VALUE 208561.5
Frequency:
Logdb:
TIME 1485290732.7691
VALUE 50.01
Power:
Logdb:
TIME 1485291193.76686
VALUE 366.15
State:
Logdb:
TIME 1485364436.85505
VALUE 187072.2
Voltage:
Logdb:
TIME 1485290732.7691
VALUE 234.3
Readings:
2016-08-17 21:26:24 R-averaging 1 s
2016-08-17 21:26:24 R-sign off
2016-08-17 21:26:24 R-txMinDly 8 s
2016-08-17 21:26:24 R-txThrCur 100 mA
2016-08-17 21:26:24 R-txThrFrq 1 Hz
2016-08-17 21:26:24 R-txThrPwr 100 W
2016-08-17 21:26:24 R-txThrVlt 10 V
2017-01-24 21:38:02 RegL_01. 08:00 7A:01 7B:08 7C:00 7D:27 7E:10 7F:00 80:64 81:00 82:64 83:64 00:00
2017-01-25 21:04:31 boot off
2017-01-25 21:04:31 current 1755
2017-01-25 21:04:31 eState E: 187265.1 P: 388.87 I: 1755 U: 238 f: 49.92
2017-01-25 21:04:31 energy 187265.1
2017-01-25 21:04:31 energyCalc 209698.9
2016-09-17 20:40:15 energyOffset 22433.8
2017-01-25 21:04:31 frequency 49.92
2017-01-25 21:04:31 power 388.87
2017-01-25 21:04:31 state 187265.1
2017-01-25 21:04:31 voltage 238
Helper:
getCfgListNo
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shadowreg:
Attributes:
alias HM_Mess-Schaltsteckdose_Pwr
event-min-interval state:86400
event-on-update-reading state
model HM-ES-PMSw1-Pl
room Messen
Ich möchte an dieser Stelle auf das Modul DOIFtools hinweisen.
Mit DOIFtools kann eine Event-Statistik erzeugt werden, die zeigt welches Gerät wieviele Events pro Stunde erzeugt und ob bereits einschränkende Attribute gesetzt sind.
Mit den Daten der Statistik können Geräte identifiziert werden, deren Events eingeschränkt werden können.
DOIFtools funktioniert auch, wenn DOIF selbst nicht genutzt wird.
https://wiki.fhem.de/wiki/DOIFtools#Erfassen_und_Auswerten_von_Statistikdaten
Ich wärme diesen alten Thread mal wieder auf, weil die Frage meiner Meinung nach gut hier rein passt und dieser Thread auch im Wiki verlinkt ist.
Wie ist nun der richtige Weg, wenn ich bei einigen Readings einen Treshold für event-on-change-reading definieren will, bei allen anderen nicht? Dies hier
attr Heizung event-on-change-reading .*,boiler_data_wWCurTmp:.3,sm_data_bottomtemp:.3
scheint nicht zu funktionieren, die Events kommen auch bei Änderungen, bei denen der Treshold unterschritten wird. Muss ich in dem Fall alle anderen Readings explizit aufführen?
".*" gehört wohl ans Ende der kommaseparierten Liste, da die Liste von links nach rechts ausgewertet wird.
Danke, genau so geht's, und nur so macht es auch Sinn, wenn man drüber nachdenkt.