OldReadings liefert keinen Wert

Begonnen von Dodger, 20 Dezember 2021, 07:38:20

Vorheriges Thema - Nächstes Thema

rabehd

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?
Auch funktionierende Lösungen kann man hinterfragen.

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Dodger

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

MadMax-FHEM

#18
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Dodger

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.

rabehd

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.
...
Auch funktionierende Lösungen kann man hinterfragen.

rabehd

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?
Auch funktionierende Lösungen kann man hinterfragen.

MadMax-FHEM

#22
@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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

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"...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rabehd

@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.
Auch funktionierende Lösungen kann man hinterfragen.

Dodger

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

Beta-User

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
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!).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

#27
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

rabehd

#29
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.

Auch funktionierende Lösungen kann man hinterfragen.