Hallo,
ich möchte gerne für eine Status-Abfrage mit dem Wert des vorherigen Readings arbeiten.
Dafür habe ich in meinem Device das Attribut "oldreading" mit dem gewünschten Reading gefüllt:
attr FritzBox_Status oldreadings tam1_newMsg
Meine Erwartung wäre nun, dass oldreadings quasi bei jedem lesen des Readings auf den vorherigen Wert gesetzt wird.
Wenn ich die Beispiele hier im Forum korrekt interpretiere, dann sollte in einem List des Devices ein Bereich "OldReadings" auftauchen.
Das passiert bei mir leider nicht.
Ich habe auch keine Fehler im Log-File.
Wird das OldReadings nur dann befüllt, wenn sich der Wert des zu "überwachenden" Attributes ändert?
Gruß
Dodger
Wo ist das list des Devices?
Woher hast du das mit der Liste von OldReadings?
Du kannst mittels OldReadingsVal etc. den "alten Wert" abfragen...
EDIT:
Zitat von: commandref
oldreadings
Dieses Attribut enthält eine durch Kommata getrennte Liste von Readings. regex sind erlaubt. Für jedes Reading aus der Liste speichert FHEM intern den vorherigen Wert wenn sich das Reading ändert. Zum Zugriff auf die Werte gibt es die OldReadings.* Routinen.
Was willst du denn tun/erreichen?
Und es geht um Readings, nicht um Attribute!
Gruß, Joachim
Die Info über das Verhalten habe ich aus diesem Post: https://forum.fhem.de/index.php?topic=91003.0
hier taucht das OldReadings im List des devices auf:
ZitatInternals:
NAME d_autoBliKitchen
NR 134
STATE 1
TYPE dummy
OLDREADINGS:
2018-09-09 22:08:28 state 1
READINGS:
2018-07-07 20:21:44 altitude_min 10
2018-07-07 20:21:23 azimuth_max 280
Der Teil fehlt bei mir im list.
Allerdings wird mir bei Eingabe von
{OldReadingsNum('FritzBox_Status','tam1_newMsg',0)}zumindest ein Rückgabewert geliefert.
Scheint also zu funktionieren, auch wenn das "Kapitel" "OLDREADINGS" nicht im List auftaucht.
Das List kann ich erst heute abend liefern, wenn ich wieder zu Hause bin.
Gruß
Dodger
Zitat von: Dodger am 20 Dezember 2021, 09:15:40
Die Info über das Verhalten habe ich aus diesem Post: https://forum.fhem.de/index.php?topic=91003.0
hier taucht das OldReadings im List des devices auf:Der Teil fehlt bei mir im list.
...
Scheint also zu funktionieren, auch wenn das "Kapitel" "OLDREADINGS" nicht im List auftaucht.
Ich weiß immer noch nicht wovon du sprichst?
Es gibt keinen Eintrag von OldReadings im list...
...also auch in dem verlinkten Beitrag komnnte ich nichts finden.
Poste doch mal den Ausschnitt, den du meinst...
Zitat von: Dodger am 20 Dezember 2021, 09:15:40
Allerdings wird mir bei Eingabe von
{OldReadingsNum('FritzBox_Status','tam1_newMsg',0)}
zumindest ein Rückgabewert geliefert.
Mehr gibt es auch nicht...
Siehe commandref...
(bzw. kenne ich auch nicht mehr und ist bei mir auch nicht mehr vorhanden, also die Möglichkeit alte Werte abzufragen bzw. halt den letzten vor dem aktuellen / Achtung: wenn der letzte Wert "derselbe" war wie der aktuelle siehst du auch keinen Unterschied! -> event-on-change-reading usw.)
Gruß, Joachim
Also, was ich gerne machen möchte:
In der Fritzbox gibt es einen Wert, der die Anzahl der neuen Nachrichten auf dem Anrufbeantworter anzeigt.
Ich hätte nun gerne eine Push- Nachricht, sobald sich dieser Wert verändert.
Daher wollte ich den Wert des neuen Reading mit dem Oldrrading vergleichen und wenn die Änderung größer 1 ist die Nachricht versenden.
Leider enthält Oldreading offensichtlich nicht den Wert des vorherigen readings sondern den Wert vor der letzten Änderung.
Beispiel:
Reading1: 0
Old: 0
Reading2: 1
Old: 0
Reading3: 1
Old: 0 ----> hier hätte ich erwartet, dass Old auf 1 geht
Reading4: 2
Old: 1
Reading 1-4 sind das gleiche Reading nur andere Zeitpunkte.
Der Vergleich Reading > Old triggern nun leider bei 2, 3 und 4, sollte aber nur bei 2 und 4 ansprechen.
Jetzt verständlich?
Gruß
Dodger
Hallo Dodger,
warum nutzt Du dafür nicht einfach ein notify oder doif?
Viele Grüße
Jürgen
Zitat von: juemuc am 20 Dezember 2021, 20:22:27
Hallo Dodger,
warum nutzt Du dafür nicht einfach ein notify oder doif?
Viele Grüße
Jürgen
Ganz genau.
Dann noch event-on-change-reading und es kommt nur ein Event, wenn sich der Wert ändert (zumindest sollte das so)...
Gruß, Joachim
Wie würde man das mit einem notify oder doif aufbauen?
Ich brauche doch den alten bzw. vorherigen Wert des readings um zu wissen, ob sich der Wert verändert hat....
event-on-change Reading gilt doch dann für das ganze device (Fritzbox), oder?
ZitatWird event-on-change-reading für ein einzelnes Reading gesetzt, werden zunächst alle übrigen Readings nicht mehr protokolliert, erzeugen also keine Events mehr.
Ich habe aber noch mehr readings aus diesem Device die ich für andere Zwecke nutze.
Zitat von: Dodger am 20 Dezember 2021, 20:43:33
Wie würde man das mit einem notify oder doif aufbauen?
Wie immer: Eventmonitor aufmachen (Filter setzen), auf das passende Event warten oder provozieren, die Zeile markieren und dann notify/DOIF/FileLog/... anlegen lassen. Anpassen und fertig.
https://wiki.fhem.de/wiki/Event_monitor
Zitat von: Dodger am 20 Dezember 2021, 20:43:33
Ich brauche doch den alten bzw. vorherigen Wert des readings um zu wissen, ob sich der Wert verändert hat....
Und nein, genau dazu ist ja event-on-change-reading da...
Zitat von: Dodger am 20 Dezember 2021, 20:43:33
event-on-change Reading gilt doch dann für das ganze device (Fritzbox), oder?
Ich habe aber noch mehr readings aus diesem Device die ich für andere Zwecke nutze.
Dann doch einfach mal in der commandref nachlesen!
Und es heißt event-on-change-READING und nicht event-on-change-DEVICE ;)
Gruß, Joachim
Irgendwie steh ich auf dem Schlauch....
Ein Notify hab ich schon, Triggern ist das Reading tam1_newMsg.
Das bedeutet aber, dass das Notify mit jedem Lesevorgang der Fritzbox getriggert wird.
Wo setze ich das event-on-change?
Im Fritzbox device oder im Notify?
Das Notify soll eigentlich nur ausgeführt werden, wenn tam1_newMsg vom vorheriger Reading kleiner ist als vom aktuellen Reading...
Das event-on-change nat. dort wo das Reading ist: commandref/Wiki lesen hilft...
Poste doch mal ein list von der FB und vom notify in code Tags...
Wie setzt du den Wert zurück?
Immer zurück auf 0?
Du kannst doch im notify den alten Wert abfragen, dann halt wieder das Attribut oldreadings und zur Abfrage OldReadingsVal/OldReadingsNum...
Gruß, Joachim
hier die Lists von der Fritzbox (auf das Wesentliche reduziert) und dem Notify:
Internals:
APICHECKED 1
FUUID 619b7d3b-f33f-c598-4c64-8d454bd1a06d9cc2
HOST fritz.box
INTERVAL 60
LUAQUERY 1
M3U_LOCAL ./www/images/FritzBox_Status.m3u
M3U_URL http://192.168.1.86:8083/fhem/images/FritzBox_Status.m3u
MODEL FRITZ!Box 7590
NAME FritzBox_Status
NR 122
REMOTE 1
SECPORT 49443
STATE WLAN: on gWLAN: off
TELNET 0
TR064 1
TYPE FRITZBOX
WEBCM 0
OLDREADINGS:
2021-12-20 17:31:56 tam1_newMsg 0
READINGS:
2021-12-21 06:54:58 tam1 Anrufbeantworter
2021-12-21 06:54:58 tam1_newMsg 1
2021-12-21 06:54:58 tam1_oldMsg 16
2021-12-21 06:54:58 tam1_state on
fhem:
LOCAL 0
definedHost undefined
is_double_wlan 1
lastHour 0
modulVersion $Date: 2020-06-06 13:11:54 +0200 (Sat, 06 Jun 2020) $
radioCount 40
sid 513667ebc2e99113
sidTime 1640066098
610:
brand AVM
id 1
model C4
userId 1
helper:
TimerCmd FritzBox_Status.Cmd
TimerReadout FritzBox_Status.Readout
Attributes:
INTERVAL 60
boxUser fritz9938
oldreadings tam1_newMsg
room FritzBox
Internals:
CFGFN
DEF FritzBox_Status:tam1_newMsg:.* {if($EVTPART1 > OldReadingsNum('FritzBox_Status','tam1_newMsg', 0))
{fhem("set Push_Message message " .strftime("%H:%M",localtime). ": Neue Nachricht auf dem Anrufbeantworter | Telefon | Handy");
}}
FUUID 61be40a1-f33f-c598-cc93-c431abb3730c5ba9
NAME push_AB
NOTIFYDEV FritzBox_Status
NR 129222
NTFY_ORDER 50-FritzBox_Status_notify_1
REGEXP FritzBox_Status:tam1_newMsg:.*
STATE inactive
TRIGGERTIME 1640018276.31466
TYPE notify
READINGS:
2021-12-20 17:38:45 state inactive
2021-12-20 17:37:56 triggeredByDev FritzBox_Status
2021-12-20 17:37:56 triggeredByEvent tam1_newMsg: 1
Attributes:
natürlich steht das Notify auf "inactive" weil es ja nicht funktioniert.
Nochmal zum zeitlichen Ablauf:
die Readings in der FB werden alle 60 Sekunden aktualisiert. Aus diesen Readings werden mehrere Zustände abgeleitet (z.B. Anwesenheit über MAC Adressen).
Das Reading "tam_newMsg" gibt die Anzahl der neuen Meldungen auf dem Anrufbeantworter wieder.
Wenn dort neue Nachrichten dazukommen, möchte ich eine Push-Message bekommen.
Ob neue NAchrichten dazugekommen sind, kann man ermitteln indem man prüft, ob der neue Wert größer ist als der alte.
Das Problem mit OldReadings:
der Wert wird nicht mit jedem Auslesen (60s) aktualisiert sondern nur, wenn sich das echte Reading ändert.
Somit schlägt die Prüfung im Notify alle 60s an, da OldReading auf 0 steht und Reading auf 1.
Gruß
Dodger
in der Fritzbox fehlt schon mal
attr FritzBox_Status event-on-change-reading tam1_newMsg
Im notify darauf reagieren.
Dort das oldreading abfragen und mit dem aktuellen Wert vergleichen.
Wenn aktuell größer als old, dann versende Deine Nachricht.
wie schon gesagt:
ZitatWird event-on-change-reading für ein einzelnes Reading gesetzt, werden zunächst alle übrigen Readings nicht mehr protokolliert, erzeugen also keine Events mehr.
Ich brauche aber auch die anderen Readings, weil die auch notifys auslösen.
Die würden ja dann nicht mehr funktionieren, da keine Events mehr ausgelöst werden...
ich habe mir jetzt über ein Dummy-device geholfen.
Finde ich zwar hässlich, funktioniert aber:
FritzBox_Status:tam1_newMsg:.* {if($EVTPART1 > ReadingsNum('tam1_newMsg_old','state', 0))
{fhem("set Push_Message message " .strftime("%H:%M",localtime). ": Neue Nachricht auf dem Anrufbeantworter | Telefon | Handy");
fhem("set tam1_newMsg_old $EVTPART1")}
else
{fhem("set tam1_newMsg_old $EVTPART1")}}
Zitat von: Dodger am 21 Dezember 2021, 07:32:38
wie schon gesagt:
Ich brauche aber auch die anderen Readings, weil die auch notifys auslösen.
Die würden ja dann nicht mehr funktionieren, da keine Events mehr ausgelöst werden...
Was hindert Dich daran, die anderen notwqendigen Readings auch anzufügen?
Zitat von: rabehd am 21 Dezember 2021, 09:10:55
Was hindert Dich daran, die anderen notwqendigen Readings auch anzufügen?
Exakt!
Einfach mal damit beschäftigen.
Es gibt ja auch noch "verwandte": event-on-update usw.
Klar, wenn öfter ein Event kommt, dann nimmt OldReading nat. den Wert an und wenn sich der nicht (im Wert) geändert hat, dann "siehst" du auch keinen Unterschied...
Hatte ich aber ja schon geschrieben...
Gruß, Joachim
wenn ich das event-on-change-reading richtig verstanden habe, dann gilt doch folgendes:
event-on-change-reading: Reading1, Reading2
Zeit: 1
Device:Reading1: 0
Device:Reading2: 0
Device:Reading3: 0
Zeit: 2
Device:Reading1: 0
Device:Reading2: 0
Device:Reading3: 0
-> keine Auslösung eines Events
Zeit: 3
Device:Reading1: 0
Device:Reading2: 0
Device:Reading3: 1
-> keine Auslösung eines Events, da Reading3 nicht in der event-on-change-reading Liste steht
Zeit: 3
Device:Reading1: 0
Device:Reading2: 1
Device:Reading3: 1
-> Auslösung eines Events. Alle notify die auf Device:Reading* triggern werden ausgelöst. Auch, wenn sich Reading1 und Reading3 nicht geändert haben
oder verstehe ich das falsch?
Gruß
Dodger
Wie geschrieben: entweder mehr in event-on-change aufnehmen oder mit den anderen event-on-... arbeiten...
Was übersichtlicher etc. ist musst du entscheiden, weil (noch) keiner außer dir weiß welche Events du wann/wie oft wozu etc. (noch) brauchst...
Aber: ich wiederhole mich...
Gruß, Joachim
Kann man alles nachlesen und auch ausprobieten, es gibt ja den Dventmonitor...
Gruß, Joachim
nochmal an meinem Beispiel mit OldReadings mit zeitlichem Verlauf:
OLDREADINGS:
2021-12-21 08:00:00 tam1_newMsg 0
READINGS:
2021-12-21 08:00:00 tam1_newMsg 0
OLDREADINGS:
2021-12-21 08:01:00 tam1_newMsg 0
READINGS:
2021-12-21 08:01:00 tam1_newMsg 1
OLDREADINGS:
2021-12-21 08:02:00 tam1_newMsg 0
READINGS:
2021-12-21 08:02:00 tam1_newMsg 1
OLDREADINGS:
2021-12-21 08:03:00 tam1_newMsg 0
READINGS:
2021-12-21 08:03:00 tam1_newMsg 1
OLDREADINGS:
2021-12-21 08:04:00 tam1_newMsg 1
READINGS:
2021-12-21 08:04:00 tam1_newMsg 2
OldReading wird nur aktualisiert, wenn sich der Readings Wert ändert.
Das Notify prüft aber, ob Readings > OldReadings ist.
Und somit würde es auch bei 08:02 und 08:03 auslösen, was es aber nicht soll.
Meine Erwartung von OldReadings wäre gewesen, dass es immer den Wert der Auslesung [n-1] enthält.
Damit würde der zeitliche Verlauf so aussehen:
OLDREADINGS:
2021-12-21 08:00:00 tam1_newMsg 0
READINGS:
2021-12-21 08:00:00 tam1_newMsg 0
OLDREADINGS:
2021-12-21 08:01:00 tam1_newMsg 0
READINGS:
2021-12-21 08:01:00 tam1_newMsg 1
OLDREADINGS:
2021-12-21 08:02:00 tam1_newMsg 1
READINGS:
2021-12-21 08:02:00 tam1_newMsg 1
OLDREADINGS:
2021-12-21 08:03:00 tam1_newMsg 1
READINGS:
2021-12-21 08:03:00 tam1_newMsg 1
OLDREADINGS:
2021-12-21 08:04:00 tam1_newMsg 1
READINGS:
2021-12-21 08:04:00 tam1_newMsg 2
und die Bedingung wäre nur bei dem tatsächlichen Wechsel des Readings wahr.
ZitatZeit: 3
Device:Reading1: 0
Device:Reading2: 1
Device:Reading3: 1
-> Auslösung eines Events. Alle notify die auf Device:Reading* triggern werden ausgelöst. Auch, wenn sich Reading1 und Reading3 nicht geändert haben
Falsch! Weißt Du überhaupt was ein Event ist?
Es wird das Event für/mit Reading2 (nach Deiner Konfiguration) ausgelöst.
Mach Dir ein Dummy mit mehreren Readings. Öffne in einem Fenster den EventMonitor mit Filter auf den Dummy. In einem anderen Fenster änderst Du Readings und event-on.* und dann beobachtest Du mal was im Eventmonitor passiert.
...
ZitatUnd somit würde es auch bei 08:02 und 08:03 auslösen, was es aber nicht soll.
Nur wenn Du die Bedingung so gesetzt hast. Und selbst wenn, wie wäre es mit einem IF im notify?
@Dodger: wo hast du denn deine Beispielwerte her?
Tatsächlich Eventmonitor und notify? Oder wie/woher? event-on-change nun gesetzt oder nicht?
Und bitte: nimm code-Tags...
EDIT: du kannst auch erst mal im notify nur loggen welche Werte es gibt. Parallel dazu den Eventmonitor beobachten. Dann mal mit event-on-... "experimentieren" und bei Fragen/Unstimmigkeiten eben genau die Logausgaben und Eventmonitor posten inkl. der (jeweils) dazu passenden event-on- Attribute...
EDIT: es ist unabhängig von deinem aktuellen "Problem" eine gute Idee notify möglichst "genau" zu machen und Events wo möglich einzuschränken. Damit nimmst du "Last" vom System...
Gruß, Joachim
Zitat von: rabehd am 21 Dezember 2021, 09:48:08
Mach Dir ein Dummy mit mehreren Readings.
Weg mit den dummy! Diese "Umpackerei" erhöht nur die Komplexität, und führt sonst zu nichts!
Vermutlich haben wir es hier mal wieder mit einem Reihenfolgeproblem zu tun, weil die "Event-Loop" bereits "vorbei" war, als was neues dazukam.
Ansonsten ist "FRITZBOX" uU. auch etwas "komisch", weil afaik "vorsorglich" alte Readings gelöscht werden.
Zitat von: rabehd am 21 Dezember 2021, 09:48:08
Weißt Du überhaupt was ein Event ist?
+1 für die Vermutung, dass hier wesentliche Teile des Grundverständnisses fehlen, wie FHEM "tickt".
Es bringt aber scheinbar nichts, wenn man den TE mit dem Hinweis auf den Event-Monitor "nervt"...
@Beta-User
Der Vorschlag mit dem Dummy war eigentlich nicht als Lösung gedacht, sondern um üver Events und event-on zu lernen. Hätte ich klarer formulieren müssen.
ZitatFalsch! Weißt Du überhaupt was ein Event ist?
Scheinbar nicht :-)
Ich hab nur das hier aus dem Wiki:
ZitatWird event-on-change-reading für ein einzelnes Reading gesetzt, werden zunächst alle übrigen Readings nicht mehr protokolliert, erzeugen also keine Events mehr.
ZitatNur wenn Du die Bedingung so gesetzt hast. Und selbst wenn, wie wäre es mit einem IF im notify?
Und genau daran scheitere ich. Offensichtlich komme ich nicht darauf, wie die richtige Bedingung wäre.
Ich kann ja nochmal meinen Use-Case schildern und vielleicht schreibt jemand mal rein, wie er es gelöst hätte:
die FritzBox wird alle 60s ausgelesen.
Jedes Auslesen triggert mehrerer notify die z.B. basierend auf der MAC Adresse den Status der Bewohner anzeigen.
Das Reading "MAC-Adresse" ändert sich nicht, sondern ist einfach nicht vorhanden, sobald das Handy nicht im im WLAN ist.
Jetzt möchte ich gerne eine Info haben, wenn auf dem Anrufbeantworter eine neue Nachricht eintrudelt.
Dafür gibt es ein Reading aus der FB, das die Anzahl der neuen Nachrichten enthält.
Dieses Reading wird alle 60s aktualisiert. Es enthält ganz oft den gleichen Wert (so viele Anrufe bekommen wir ja nicht :-))
Nur wenn der Wert nach oben geht, soll eine Push-Nachricht versendet werden.
Wie würde euer Code dazu aussehen?
Mein Verständnis: ein Event ist ein System-Ereignis, welches alle Elementen des Systems signalisiert:"hier ist etwas passiert".
Das event-on-change-reading würde z.B. sagen:"Achtung an alle System-Teilnehmer: in diesem Gerät hier hat eine Änderung stattgefunden".
Und alle System-Teilnehmer, die etwas mit dem Gerät zu tun haben, würden anfangen ihren Code abzuarbeiten.
Wenn ich mehrere Reading in event-on-change-reading aufnehme, dann kommt die genannte Meldung immer dann, wenn sich irgendeines der Readings ändert.
Das Problem ist nun: der Entfall der MAC Adressen würde ja kein event-on... triggern, oder?
Also würden die angeschlossenen Notify, die nach jedem read-out der FB getriggert werden um den Status der Adressen zu evaluieren nur noch starten, wenn ich einen neuen Anruf auf dem AB habe.
Fände ich suboptimal :-)
Das bezog sich tendenziell eher auf diesen Post:
Zitat von: Dodger am 21 Dezember 2021, 08:15:58
ich habe mir jetzt über ein Dummy-device geholfen.
Finde ich zwar hässlich, funktioniert aber:
FritzBox_Status:tam1_newMsg:.* {if($EVTPART1 > ReadingsNum('tam1_newMsg_old','state', 0))
{fhem("set Push_Message message " .strftime("%H:%M",localtime). ": Neue Nachricht auf dem Anrufbeantworter | Telefon | Handy");
fhem("set tam1_newMsg_old $EVTPART1")}
else
{fhem("set tam1_newMsg_old $EVTPART1")}}
Generell ist es aber so, dass kein Mensch durchblicken kann, wenn immer nur unvollständige Schnippsel geliefert werden (v.a. dann nicht, wenn der TE selbst keine Idee hat, wie die Zusammenhänge sind).
Zitat
Jedes Auslesen triggert mehrerer notify die z.B. basierend auf der MAC Adresse den Status der Bewohner anzeigen.
Das Reading "MAC-Adresse" ändert sich nicht, sondern ist einfach nicht vorhanden, sobald das Handy nicht im im WLAN ist.
Das kann man übrigens in ein notify zusammenfassen: https://forum.fhem.de/index.php/topic,123886.msg1192757.html#msg1192757 (https://forum.fhem.de/index.php/topic,123886.msg1192757.html#msg1192757)
Das erfasst auch "bin dann mal weg"...
ZitatWird event-on-change-reading für ein einzelnes Reading gesetzt, werden zunächst alle übrigen Readings nicht mehr protokolliert, erzeugen also keine Events mehr.
a) man kann mehrere angeben, und ggf. auch teilweise "wildcards" angeben.
b) es gibt "Wechselwirkungen" mit anderen Attributen aus der "eocr"-Familie (es sind 4, bitte _alle_ nachlesen!).
ZitatMein Verständnis: ein Event ist ein System-Ereignis, welches alle Elementen des Systems signalisiert:"hier ist etwas passiert".
Das event-on-change-reading würde z.B. sagen:"Achtung an alle System-Teilnehmer: in diesem Gerät hier hat eine Änderung stattgefunden".
Und alle System-Teilnehmer, die etwas mit dem Gerät zu tun haben, würden anfangen ihren Code abzuarbeiten.
Wenn ich mehrere Reading in event-on-change-reading aufnehme, dann kommt die genannte Meldung immer dann, wenn sich irgendeines der Readings ändert.
Jein.
a) Ein Event wird in der Regel durch die Module erzeugt. Es ist also die Entscheidung eines Maintainers, "die Allgemeinheit" zu informieren, dass etwas potentiell relevantes passiert ist.
b) "Event" ist eine Verkürzung. Tatsächlich kann eine "Event-Loop" aus vielen einzelnen solcher Meldungen bestehen. fhem.pl muss die alle abarbeiten, und zwar so, dass irgendwann auch der Ausgang erreicht wird => was "später" an einem bereits abgearbeiteten Device passiert, wird uU. nicht mehr von allen "Event-Handlern" berücksichtigt, weil die schon "durch" sind.
c) Mit den "eocr"-Attributen kann man die Entscheidung des Maintainers _ändern_, und Events (oder: einzelne Ereignisse aus dem Ereignis-Stapel) unterdrücken bzw. einzelne Aspekte manipulieren (z.B. auch den timestamp).
Das ist alles nicht sonderlich einfach zu verstehen, aber es ist wichtig, das mal akkurat durchzuarbeiten, damit man versteht, warum solche Empfehlungen wie "alles auf .*" einerseits "hilfreich" sind und andererseits totaler Unsinn...
PS: das obige notify sollte ich mal umbenennen, das sollte durch die Namensgebung "ganz nach vorne" kommen und eher "00_rr_xn_MAC_Check" heißen...
Zitat von: Beta-User am 21 Dezember 2021, 10:10:15
Generell ist es aber so, dass kein Mensch durchblicken kann, wenn immer nur unvollständige Schnippsel geliefert werden (v.a. dann nicht, wenn der TE selbst keine Idee hat, wie die Zusammenhänge sind).
:)
Das habe ich auch schon x-mal "haben wollen" ;)
Und zwar nicht irgendwelche "Scheindaten", sondern tatsächliche Daten (Evtnmonitor, Log etc.).
Weil genau da würde man auch ein (evtl. wobei ich das [nun] auch vermute) "komisches" Verhalten des Moduls erkennen.
Und evtl. dann doch weiterhelfen kann (trotz "komischem" Verhalten)...
Zitat von: Beta-User am 21 Dezember 2021, 10:10:15
a) man kann mehrere angeben, und ggf. auch teilweise "wildcards" angeben.
b) es gibt "Wechselwirkungen" mit anderen Attributen aus der "eocr"-Familie (es sind 4, bitte _alle_ nachlesen!).
Da schreibe ich mich ja schon fusselig dran ;)
Aber vielleicht hilft es ja, wenn mehrere das schreiben...
Gruß, Joachim
Trotz anderer Reaktionen während meines Schreiben:
Fang doch nochmal von vorn an.
Nimm Dir Dein Fritzbox-Device und überlege welche Readings für Dich für weitere Routinen wichtig sind.
Willst Du nur auf Änderungen reagieren (ggf. loggen), dann event-on-change.
Willst Du auch auf Aktuallisierungenreagieren, dann auch event-on-update.
Dann schaue im EventMonitor, ob die Events der Readings dort alle zum richtigen Zeitpunkt erscheinen.
Dann gehe das Thema neu an.
Du willst auf eine Änderungen der Anzahl Nachrichten reagieren.
In der Reaktion (notify) prüfst Du ob es im Verhältnis zu Old eine Erhöhung gibt. Nur bei ja tust Du etwas.
ZitatMein Verständnis: ein Event ist ein System-Ereignis, welches alle Elementen des Systems signalisiert:"hier ist etwas passiert".
Das event-on-change-reading würde z.B. sagen:"Achtung an alle System-Teilnehmer: in diesem Gerät hier hat eine Änderung stattgefunden".
Falsch!
nicht "hier ist etwas passiert", sondern hier wurde
das Reading geändert/aktualisiert!
Das ist aber gut im EventMonitor zu sehen. Ich würde auch sagen, wer ein notify über den EventMonitor erstellt, der sieht auch das die Reaktion nicht auf das Gerät passiert.
Zitat von: rabehd am 21 Dezember 2021, 10:23:31
Trotz anderer Reaktionen während meines Schreiben:
Fang doch nochmal von vorn an.
Nimm Dir Dein Fritzbox-Devie und überlege welche Readings für Dich für weitere Routinen wichtig sind.
Willst Du nur auf Änderungen reagieren (ggf. loggen), dann event-on-change.
Willst Du auch auf Aktualiiserungenreagieren, dann auch event-on-update.
Dann schaue im EventMonitor, ob die Events der Readings dort alle zum richtigen Zeitpunkt erscheinen.
Dann gehe das Thema neu an.
Du willst auf eine Änderungen der Anzahl Nachrichten reagieren.
Jep!
Zitat von: rabehd am 21 Dezember 2021, 10:23:31
In der Reaktion (notify) prüfst Du ob es im Verhältnis zu Old eine Erhöhung gibt. Nur bei ja tust Du etwas.
Das sollte zwar mit event-on-change-reading eigentlich nicht nötig sein (gut, um zu verhindern, dass bei einem Zurücksetzen auch eine Meldung kommt)...
...schaden tut es mal nicht,
Sollte das Modul tatsächlich ein "eigenartiges" Verhalten bzgl. Events/event-on-change haben, dann entweder den Modulautor ansprechen oder z.B. per userReadings etc. "nachhelfen"...
EDIT: aber wie schon zig mal geschrieben, ohne tatsächliche Daten aus dem Eventmonitor (und Log wie oben ganannt, also OldReadings-Abfragen in notify loggen) kann man ein "eigenartiges" Verhalten nur vermuten... Und: nicht weiter helfen als schon getan...
Gruß, Joachim