[gelöst]: kein notify bei identischen Telegrammen - wie umgehen???

[Svenergy]

Hallo Christian,

zunächst vielen Dank für die Aufklärung und Annahme des Problems. Mit der hier gelieferten Erklärung/Beschreibung habe ich auch wieder etwas dazu gelernt und die Hintergründe etwas besser verstanden.

Meine Lösung, welche jetzt seit Samstag gut läuft, sieht wie folgt aus (und deckt sich mit deiner Empfehlung)
Der Sensor ist nun ohne SubTyp und ohne EEP angelernt.
Der Sensor hat zwei userReadings bekommen. (die Konvertierung der Daten wurde aus der 10_EnOcean.pm entnommen und entspricht der eines "MultiFuncSensors".
Sensordefinition jetzt:

Code Auswählen Erweitern

define Avidsen_VibSensor_MicrowaveEG_05856692 EnOcean 05856692
attr Avidsen_VibSensor_MicrowaveEG_05856692 IODev TCM_ESP3_0
attr Avidsen_VibSensor_MicrowaveEG_05856692 manufID 7FF
attr Avidsen_VibSensor_MicrowaveEG_05856692 room KuecheEG
attr Avidsen_VibSensor_MicrowaveEG_05856692 userReadings vibration_uR:D1.* {ReadingsVal("Avidsen_VibSensor_MicrowaveEG_05856692", "D1",0) ? "on" : "off"}, voltage_uR:sensor1.* {ReadingsVal("Avidsen_VibSensor_MicrowaveEG_05856692", "sensor1",0) * 0.02}

Sensor Readings jetzt:

Code Auswählen Erweitern

D0 0 2019-09-02 17:29:40
D1 0 2019-09-02 17:31:40
D2 0 2019-09-02 17:29:40
D3 1 2019-09-02 17:29:40
sensor1 135 2019-09-02 17:29:40
sensor2 0 2019-09-02 17:29:40
sensor3 0 2019-09-02 17:29:40
state 135 2019-09-02 17:29:40
vibration_uR off 2019-09-02 17:31:40
voltage_uR 2.7 2019-09-02 17:29:40

Dem Dummy habe ich behalten, bräuchte ihn aber eigentlich nicht mehr.

Der Notify wurde jetzt abgeändert und etwas umgebaut, sodass ich diesen auch für weitere Sensoren mit diesem userReading /ähnliche Funktion verwenden kann:

Code Auswählen Erweitern

Avidsen_VibSensor_MicrowaveEG_05856692:vibration_uR:.on {
my $Sensor_at = $NAME."_at";;
if (defined($defs{$Sensor_at})){
fhem "delete $Sensor_at";;;; }
fhem "define $Sensor_at at +00:02:00 setReading $NAME D1 0;; set mikro_dummy off";;
fhem "set mikro_dummy on";;
}

Der Ablauf bleibt erhalten und sieht wie folgt aus:
Der Sensor sendet ein Bewegung "on" - codiert in D1 = 1
die userReadings werden erzeugt
der notify wird ausgelöst und startet den at mit 2min
der Dummy wird auf "on" gesetzt.

sendet der Sensor innerhalb der 2min ein weiteres "on" Signal wird der at gelöscht und neu gestartet, keine weitere Änderung.
sendet der Sensor innerhalb der 2min kein neues Signal löst der at aus und setzt den Dummy auf "off" sowie das Reading D1 auf 0, was das userReading auf "off" schreibt

Die gewünschte Funktion ist damit perfekt umgesetzt: der Dummy bleibt auf "on" solange periodisch "on" Signale kommen und ist dann zeitnah "off" sobald der Sensor nichts mehr detektiert, es muss nicht erst gewartet werden bis der Heartbeat vom Sensor kommt. Eine schöne relative direkte Anzeige im Dummy.

Ich werde das Thema damit als gelöst kennzeichnen und bedanke mich erneut.

Viele Grüße Sven

[Svenergy]

Hallo Christian,

jetzt muss ich das Thema noch einmal ausgraben und erneut öffnen.

Nachdem bis gestern alles gut geklappt hat habe ich nun das Phänomen, dass der Sensor von allein als SubType "raw" definiert wird und damit keine Telegrammauswertung mehr erfolgt. Komisch finde ich das Verhalten vom FHEM dabei.

Heute Nacht wurde im Log dieses Verhalten das erste Mal geloggt.

Code Auswählen Erweitern

2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 135
2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 sensor1: 135
2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 sensor2: 0
2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 sensor3: 0
2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 D3: 1
2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 D2: 0
2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 D1: 0
2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 D0: 0
2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 vibration_uR: off
2019-09-03_03:20:32 Avidsen_VibSensor_MicrowaveEG_05856692 voltage_uR: 2.7
2019-09-03_03:48:45 Avidsen_VibSensor_MicrowaveEG_05856692 RORG: A5 DATA: 87000008 STATUS: 00 ODATA: 03FFFFFFFF5B00
2019-09-03_04:16:58 Avidsen_VibSensor_MicrowaveEG_05856692 RORG: A5 DATA: 87000008 STATUS: 00 ODATA: 03FFFFFFFF5900

Im Log sehe ich gerade, dass es heute Nacht 3:45 einen Restart vom FHEM gab:

Code Auswählen Erweitern

2019.09.03 03:45:06 0: Server shutdown
2019.09.03 03:45:18 1: Including fhem.cfg

Wenn ich jetzt den Subtype wieder lösche funktioniert der Sensor wieder ein Stück richtig. Nach einem Shutdown restart ist der SubType Raw wieder da.

Gibt es dazu eine Einstellung in den Grundsettings, welche diese Verhalten provozieren.

Grüße Sven

[krikan]

Hallo Sven!

10_EnOcean.pm setzt nach Blick in den Code bei fehlendem subType beim Restart immer "raw" als subType. Das ist meines Wissens nach nicht beeinflußbar. Sorry, dass mir das nicht vorher aufgefallen ist.

Ungetestete Lösungsansätze:
- subType nach Startup mit at oder ähnlichem löschen. -> gefällt mir nicht.
- versuchen einen ausgedachten und nicht unterstützen subType mit attr zu setzen, damit der als "unknown"-Fall ausgewertet wird -> habe Bedenken, ob es funktioniert und langzeitstabil ist
- userReadings auf Events für subType raw anpassen -> ok

Beim derzeitigen Modulstand würde ich den letzten Weg einschlagen.

-----
Die vom Anwender mWn nicht am Device erkenn- und beeinflußbare Unterdrückung von Sensornachrichten (Events/Readings) eines Gerätes betrifft nach Code-Durchsicht wohl -inklusive dem hier diskutierten subType- folgende subType's:

Code Auswählen Erweitern

smokeDetector.02
windSpeed.00
multiFuncSensor
doorContact
windowContact
digitalInput.03
-----

Gruß, Christian

[Svenergy]

Danke Christian,

ich kenn die Stelle des notwendigen Bits in den RAW-Daten. So werde ich mein userReading entsprechend anpassen. Ich hatte schon so eine Ahnung, das es darauf hinauslaufen wird, hatte aber die Hoffnung, dass ich darum herum komme 

Danke, dann wird es so werden. Code poste ich nachher wenn er funktioniert.

Grüße Sven

[Svenergy]

Jetzt muss ich noch einmal reinkrätschen!

aktueller Status des Readings

Code Auswählen Erweitern

state RORG: A5 DATA: 7D000008 STATUS: 00 ODATA: 03FFFFFFFF5800 2019-09-03 11:58:24

mein userReading

Code Auswählen Erweitern

attr Avidsen_VibSensor_MicrowaveEG_05856692 userReadings vibration_uR:state.* {"sven"}

kommt ein neues Signal, aktualisiert sich "state" im Reading, aber das userReading wird nicht aktualisiert. -> ich vermute der trigger ist falsch.

Denn ohne trigger funktioniert es.

Code Auswählen Erweitern

attr Avidsen_VibSensor_MicrowaveEG_05856692 userReadings vibration_uR {"sven2"}

Da ich das userReading apäter über einen at überschreibe muss ich zwingend einen trigger verwenden (hab ich am Wochenende so gelernt und erprobt).

gibt der state keinen trigger raus? oder fehlt etwas in der regEx?

Edit:
habe noch etwas dazu gefunden:
https://forum.fhem.de/index.php?topic=72103.0

Ist das schon die vollumfängliche Erklärung warum und die Bestätigung, dass es nicht gehen wird?

Grüße Sven

[Otto123]

es ist dein Thread - wieso hast Du das Gefühl reinzugrätschen ? 
state gibt es im allgemeinen nicht als Event. Dazu gibt es bei einigen Geräten addStateEvent
Aber ich kenne Deine Geräte hier nicht

Gruß Otto

[Svenergy]

zusammenfassend gibt es folgende Lösung (den Grund dafür habe ich nicht verstanden), die Lösung wurde heute den ganzen Tag lang getestet und tut was sie soll.

die Sensordefinition inklusive des userReadings, welches die Raw-Data durchparst und die richtigen Bits raus holt:

Code Auswählen Erweitern

defmod Avidsen_VibSensor_MicrowaveEG_05856692 EnOcean 05856692
attr Avidsen_VibSensor_MicrowaveEG_05856692 IODev TCM_ESP3_0
attr Avidsen_VibSensor_MicrowaveEG_05856692 manufID 06F
attr Avidsen_VibSensor_MicrowaveEG_05856692 room KuecheEG
attr Avidsen_VibSensor_MicrowaveEG_05856692 stateFormat vibration_uR
attr Avidsen_VibSensor_MicrowaveEG_05856692 subType raw
attr Avidsen_VibSensor_MicrowaveEG_05856692 userReadings vibration_uR:.* {my $t1 = ReadingsVal($NAME, "state","");;;; $t1 =~  /( DATA: )([0-9A-Fa-f]{8})/;;;; my $vib = (hex("0x".substr($2,6,2)) & 2) eq 2;;;; $vib ? "on":"off";;;;}, voltage_uR:.* {my $t1 = ReadingsVal($NAME, "state","");;;; $t1 =~  /( DATA: )([0-9A-Fa-f]{8})/;;;; my $volt = hex("0x".substr($2,0,2));;;; $volt *0.02;;;;}


beim userReading habe ich nicht verstanden, warum ich :.* als trigger verwenden kann, aber :state.* nicht funktioniert.

Das Log schaut dann so aus ( erst Telegramm und Reaktion, dann at und Rücksetzung):

Code Auswählen Erweitern

2019-09-03_17:27:32 Avidsen_VibSensor_MicrowaveEG_05856692 RORG: A5 DATA: 8700000A STATUS: 00 ODATA: 03FFFFFFFF5B00
2019-09-03_17:27:32 Avidsen_VibSensor_MicrowaveEG_05856692 vibration_uR: on
2019-09-03_17:27:32 Avidsen_VibSensor_MicrowaveEG_05856692 voltage_uR: 2.7
2019-09-03_17:29:32 Avidsen_VibSensor_MicrowaveEG_05856692 vibration_uR: off
2019-09-03_17:29:32 Avidsen_VibSensor_MicrowaveEG_05856692 voltage_uR: 2.7


der notify:

Code Auswählen Erweitern

defmod Avidsen_VibSensor_MicrowaveEG_05856692_notify notify Avidsen_VibSensor_MicrowaveEG_05856692:vibration_uR:.on {\
my $Sensor_at = $NAME."_at";;;;\
if (defined($defs{$Sensor_at})){\
fhem "delete $Sensor_at";;;;;;;; }\
fhem "define $Sensor_at at +00:02:00 setReading $NAME vibration_uR off;;;; set mikro_dummy off";;;;\
fhem "set mikro_dummy on";;;;\
\
}\

der notify löst sauber aus und bearbeitet das Reading sowie den Dummy.

Bevor ich dieses Thread wieder vorschnell als gelöst kennzeichne, würde ich gern um eure Meinung bitten.

Grüße Sven

[krikan]

Hallo Sven!

Bevor ich dieses Thread wieder vorschnell als gelöst kennzeichne, würde ich gern um eure Meinung bitten.

Denke das Ergebnis zählt. Wenn Du zufrieden bist und es funktioniert, ist doch alles gut. 
Wenn denn jemand bessere Ideen hat, dann natürlich her damit...

beim userReading habe ich nicht verstanden, warum ich :.* als trigger verwenden kann, aber :state.* nicht funktioniert.

Weil es kein Event gibt, das "state" im Event enhält. Schau mal in den EventMonitor.
(Infos dazu bspw: https://fhem.de/commandref.html#addStateEvent ; das Attribut gibt es bei EnO nicht!)

Gruß, Christian

[gadget]

Hallo,

ich hänge mich an diesen alten Thread mal dran, weil das IMHO in die gleiche Richtung geht. Ich habe mehrere Rauchmelder ( subtype smokeDetector.02 ), bei denen sich das ähnlich verhält. Solange es nicht brennt, werden die readings durch die zyklischen "ich bin noch hier"-Telegramme nicht refresht und es gibt auch keine Events. Lediglich das internal TCM_ESP3_0_TIME wird neu gesetzt. Ob signOfLive an oder aus ist, hat keinen Einfluss.
Ich muss da jetzt ziemlich rumfrickeln, weil ich den Status per MQTT an eine Visualisierung weiterreichen will. Da es bei mir nicht täglich brennt kommen dann aber auch keine MQTT Nachrichten.  Ich habe jetzt ein DOIF, das den Status des Enocean Device zyklisch UND bei Änderung in ein Dummy reinprügelt und erzeuge dann aus dem Dummy meine MQTT-Nachrichten. Schön ist das nicht. Ich wäre sehr dafür, das man das Verhalten anpassbar machen könnte, sprich: Events auf Wunsch auch dann erzeugen / Readings Updaten wenn sich der Zustand nicht ändert, aber ein frisches Enocean Telegramm eingetroffen ist.

[Otto123]

Hi,

ich würde an Deiner Stelle lieber einen neuen Thread machen. Und viel mehr Infos liefern, damit man sich das vorstellen kann.
Also list list list list siehe https://forum.fhem.de/index.php/topic,71806.0.html

Gruß Otto

[gadget]

Hallo,

ich wollte eigentlich nur dokumentieren, dass das Problem, das der Thread-Ersteller hatte, auch andere Bereiche betrifft. Einen (unschönen) Workaround habe ich ja.

Hier mal das List:

Code Auswählen Erweitern


Internals:
   DEF        01A33D53
   FUUID      5c6fe215-fe3f-6385-bd97-0b362eb115dd12dc
   IODev      TCM_ESP3_0
   LASTInputDev TCM_ESP3_0
   MSGCNT     881
   NAME       FRW_DG
   NR         458
   NTFY_ORDER 50-FRW_DG
   STATE      off
   TCM_ESP3_0_DestinationID FFFFFFFF
   TCM_ESP3_0_MSGCNT 881
   TCM_ESP3_0_PacketType 1
   TCM_ESP3_0_RSSI -46
   TCM_ESP3_0_ReceivingQuality excellent
   TCM_ESP3_0_RepeatingCounter 1
   TCM_ESP3_0_SubTelNum 7
   TCM_ESP3_0_TIME 2020-09-25 16:12:47
   TYPE       EnOcean
   READINGS:
     2020-09-14 17:13:17   alarm           off
     2020-09-14 17:13:17   battery         ok
     2016-11-13 17:39:10   buttons         released
     2016-11-13 17:39:08   channelA        AI
     2020-09-14 17:13:17   state           off
     2016-11-13 17:39:08   teach           RPS teach-in accepted EEP F6-02-01 Manufacturer: no ID
   helper:
     lastEvent  0
     timer:
       alarm:
         HASH(0x426bf60)
         alarm
         dead_sensor
         1
         5
Attributes:
   IODev      TCM_ESP3_0
   alias      RauchmelderDG
   devStateIcon off:secur_smoke_detector@green smoke-alarm:secur_smoke_detector@red
   eep        F6-02-02
   group      contact
   manufID    00D
   room       Rauchmelder
   signOfLife off
   signOfLifeInterval 14400
   stateFormat alarm
   subType    smokeDetector.02
   teachMethod RPS
   


Man sieht, dass sich die relevanten readings "state" und "alarm" seit Tagen nicht aktualisiert haben (vermutlich seit dem letzten fhem Neustart). Entsprechend wurden seither auch keine MQTT-Nachrichten an meine Visualisierung übermittelt (ich verwende die MQTT_GENERIC_BRIDGE). Der Rauchmelder hat sich aber eigentlich zuletzt vor 10 Minuten mit einem Telegramm gemeldet (Internal TCM_ESP3_0_TIME). Und jetzt wäre es halt hübsch, wenn das auch zu einem Event führen würde ....
Wie bereits weiter oben in diesem Thread beschrieben, hilft ja auch kein "event-on-update-reading .*"

Grüße, gadget.

[Otto123]

Sorry, erst jetzt hab ich es verstanden.

naja wenn kein Event dann kein Event - ich verstehe es so: Das Modul liefert den Event offenbar nicht, da hilft dann auch kein attr event-on.*
Du müsste der Modulentwickler ran?

Gruß Otto