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

[Svenergy]

ich habe folgende Situation:

ich verwende einen Vibrationssensor von Avidsen der ein EnOcean-Telegramm (EEP A5-14-05, multiFuncSensor) sendet. Der Sensor prüft alle 2min (Zyklus einstellbar) ob noch Vibration/Bewegung vorhanden ist und sendet ein "Vibration:on" plus weitere Werte. Falls im Zyklus keine Bewegung vom Sensor erkannt wird gibt es keine Telegramme.
Alle 30min wird ein Heartbeat gesendet mit "Vibration:off".

Ich nutze diesen Sensor an der Mikrowelle, um deren Belegung zu detektieren. Da der Sensor in kurzen Abständen aber nur "On" detektiert und sendet, habe ich einen Dummy zur Anzeige des Status erstellt. Der Dummy wird durch ein notify auf "On" gesetzt und mit einem at auf "Off" nach 3min ohne neues "On" Signal.

Im FHEM bekomme ich beim ersten Telegramm einen sauberen notify mit funktionierender Kette. Das zweite "On"-Telegramm erzeugt aber kein notify mehr. Das zweite Telegramm ist in der Regel auch identisch mit den ersten, soll aber anzeigen, dass weiterhin Bewegung vorhanden ist. Erst wenn lange Zeit keine Bewegung war und zwischendurch ein offizielles Heartbeat mit "off" gesendet wurde, erfolgt ein neuer notify.

Ich habe gelesen, dass die Wiederholung von gleichen Telegrammen vom 00_TCM-Modul keine neuen Readings erzeugt -> ist das die Ursache für die fehlenden notifys oder liegt es an etwas anderem?

Mein FHEM Setup sieht wie folgt aus:

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 eep A5-14-05
attr Avidsen_VibSensor_MicrowaveEG_05856692 manufID 7FF
attr Avidsen_VibSensor_MicrowaveEG_05856692 room KuecheEG
attr Avidsen_VibSensor_MicrowaveEG_05856692 signOfLifeInterval 2400
attr Avidsen_VibSensor_MicrowaveEG_05856692 subType multiFuncSensor
define FileLog_Avidsen_VibSensor_MicrowaveEG_05856692 FileLog ./log/Avidsen_VibSensor_MicrowaveEG_05856692-%Y.log Avidsen_VibSensor_MicrowaveEG_05856692

der dummy:

Code Auswählen Erweitern

define mikro_dummy dummy
attr mikro_dummy room KuecheEG

Der notify:

Code Auswählen Erweitern

define mikro_notify notify Avidsen_VibSensor_MicrowaveEG_05856692:vibration:.on {\
if (defined($defs{'mikro_dummy_off'})){\
fhem "delete mikro_dummy_off";;;; }\
fhem "set mikro_dummy on";;;;\
fhem "define mikro_dummy_off at +00:03:00 set mikro_dummy off";;;;\
#fhem "setReading Avidsen_VibSensor_MicrowaveEG_05856692 vibration off";;;;\
}

ich hatte bereits versucht das Reading des Sensors mit dem notify manuell zu ändern, um so für neue Telegramme einen geänderten Status zu simulieren. Hat aber nichts gebracht.

Event-on-interval nutzt mir hier nichts, da der Trigger vom Sensor kommen muss. Erst wenn der Sensor nichts mehr sendet darf der Dummy auf "Off" gesetzt werde, solange muss ich jedes Telegramm auswerten.


Vielen Dank für jeden Hinweis.

Grüße Sven

[Otto123]

Hallo Sven,

ich kann zu der Hardware nichts sagen, aber Dein Satz:

sendet ein "Vibration:on" plus weitere Werte.

sagt mir Dein regEx ist falsch.

Code Auswählen Erweitern

Avidsen_VibSensor_MicrowaveEG_05856692:vibration:.on.*

Kannst Du aber prima selbst im Eventmonitor prüfen!

Gruß Otto

[Svenergy]

sorry hätte ein Logauszug hinzufügen sollen:

Code Auswählen Erweitern

2019-08-30_12:06:18 Avidsen_VibSensor_MicrowaveEG_05856692 brightness: 0
2019-08-30_12:06:18 Avidsen_VibSensor_MicrowaveEG_05856692 contact: closed
2019-08-30_12:06:18 Avidsen_VibSensor_MicrowaveEG_05856692 vibration: on
2019-08-30_12:06:18 Avidsen_VibSensor_MicrowaveEG_05856692 voltage: 2.70
2019-08-30_12:06:18 Avidsen_VibSensor_MicrowaveEG_05856692 C: closed V: on E: 0 U: 2.70

Hallo Otto,

der erste notify funktioniert, nur jedes darauffolgende Telegramm erzeugt keine notifys mehr. Solange der Telegramminhalt der gleiche ist.

Grüße Sven

[Otto123]

Hallo Sven,

ok dein regEx ist in Ordnung, aber dieser Event (ich meine nicht Log sondern Eventmonitor)

Code Auswählen Erweitern

Avidsen_VibSensor_MicrowaveEG_05856692 vibration: on

Kommt wirklich mehrfach wenn Du ihn erwartest?

Gruß Otto

[Svenergy]

Hallo Otto,

meine Beobachtung sieht wie folgt aus:
lange keine Telegramme
erstes Telegramm vom Sensor wird empfangen, ausgewertet und ein notify ausgegeben
Logeintrag:

Code Auswählen Erweitern

2019.08.30 13:34:54 5: Triggering mikro_notify
2019.08.30 13:34:54 4: mikro_notify exec {
fhem "set mikro_dummy on";;;;
if (defined($defs{'mikro_dummy_off'})){
fhem "delete mikro_dummy_off";;;; }
fhem "define mikro_dummy_off at +00:02:00 set mikro_dummy off";;;;
fhem "setReading Avidsen_VibSensor_MicrowaveEG_05856692 vibration off";;;;
}
Eventmonitor:

Code Auswählen Erweitern

2019-08-30 13:34:54 dummy mikro_dummy on
2019-08-30 13:34:54 at mikro_dummy_off Next: 13:36:54
2019-08-30 13:34:54 Global global DEFINED mikro_dummy_off
2019-08-30 13:34:54 EnOcean Avidsen_VibSensor_MicrowaveEG_05856692 brightness: 0
2019-08-30 13:34:54 EnOcean Avidsen_VibSensor_MicrowaveEG_05856692 contact: closed
2019-08-30 13:34:54 EnOcean Avidsen_VibSensor_MicrowaveEG_05856692 vibration: on
2019-08-30 13:34:54 EnOcean Avidsen_VibSensor_MicrowaveEG_05856692 voltage: 2.70
2019-08-30 13:34:54 EnOcean Avidsen_VibSensor_MicrowaveEG_05856692 C: closed V: on E: 0 U: 2.70
2019-08-30 13:34:54 EnOcean Avidsen_VibSensor_MicrowaveEG_05856692 vibration: off
(dann schläft der Sensor erst einmal für eine definierte Zeit und prüft danach ob noch Bewegung vorhanden ist)
TCM-Time:

Code Auswählen Erweitern

TCM_ESP3_0_TIME
2019-08-30 13:37:36
zweites Telegramm vom Sensor wird vom TCM empfangen (erkennbar an der TCM_ESP3_0_time bei den internals vom Sensor)
es gibt dazu aber kein Log-Eintrag und auch kein Event im Eventmonitor
(Sensor ruht für 30min)
Heartbeat -Telegramm wird gesendet und auch empfangen , geloggt und Status zurückgesetzt
erneutes Bewegen des Sensors erzeugt ein neues Telegramm, welches wieder durch die gesamte Kette durchkommt, geloggt wird und einen entsprechenden Event erzeugt

mir fehlen die wiederholten Telegramme solange der Sensor in Bewegung ist.

in einem früheren Thread über TCM-Modul update habe ich gelesen, dass wiederholte Telegramme mit gleichem Inhalt keine Readings mehr erzeugen, somit auch keine Logs. Hängt das damit zusammen? Kann man das umgehen??

Grüße Sven

[krikan]

in einem früheren Thread über TCM-Modul update habe ich gelesen, dass wiederholte Telegramme mit gleichem Inhalt keine Readings mehr erzeugen, somit auch keine Logs.

Hast Du dazu bitte einen Link. Das halte ich für "seltsam".

Gruß, Christian

[Svenergy]

Hallo Christian,

hier der Link:
https://forum.fhem.de/index.php/topic,97027.msg902168.html#msg902168

dritter Beitrag.

Grüße Sven

[krikan]

hier der Link:
https://forum.fhem.de/index.php/topic,97027.msg902168.html#msg902168

Wenn Reading in klaus.schauers Aussage auch das Event umfasst -was Deiner Beobachtung entspricht-, dann werden wohl tatsächlich im Default Sensornachrichten nicht als Event/Reading weitergeleitet.
Setze mal das Attribut signOfLife auf off; im Standard ist das bei multiFuncSensor auf on. Nach meinem Verständnis sollten dann wieder Events kommen, aber die Überwachung ausbleiben.

Diese Änderung ist an mir vorbeigegangen.
In https://fhem.de/commandref.html#EnOcean_signOfLife wird als default off genannt, beim subtype multiFuncSensor wird in der commandref hingegen on genannt. Ist in meinen Augen widersprüchlich.
Ehrlicherweise gefällt mir das automatische Wegfiltern von Events/Readings durch das Modul im default nicht, wenn dem wirklich so ist.

Gruß, Christian

[Svenergy]

Hallo Christian,

habe den SignOfLife=off Test durchgeführt. Hat aber keinen Einfluss auf die generelle Reaktion. Soweit ich jetzt testen konnte bekomme ich weiterhin keine Logeinträge/Readings und keine Events von diesem Sensor. Der TCM empfängt aber jedes Telegramm.

Grüße Sven

[krikan]

Habe jetzt mal in den Code von 10_EnOcean.pm geschaut, wenn ich den richtig verstehe, dann werden nur bei erstmaligen Eintreffen eines Datentelegramms nach FHEM-Start und bei Änderungen im Vergleich zum letzten Datentelegramm Events/Readings erzeugt. Das Attribut von signOfLife beeinflusst das nicht.

Im Prinzip sind damit nach meinem Verständnis im 10_EnOcean.pm-Code beim subType multiFuncSensor -durch den User unabänderbar- mit moduleigener Logik quasi in den Attributen event-on-change-reading und timestamp-on-change-reading alle Sensorwerte aufgenommen. Das Verhalten führt auch zu Besonderheiten bei den ReadingFN-Attributen bei dem subType.

Den Hintergrund für dieses Vorgehen (wenn ich denn mit meiner Trockenübung richtig liege), kenne ich leider nicht; bin auch unsicher, ob das so gewollt ist.

Gruß, Christian

[klaus.schauer]

Das Verhalten ist so gewollt, damit nur bei sich ändernden Statusmeldungen des Sensors Notifys ausgelöst werden. Die Überwachung der Funktionsfähigkeit erfolgt unabhängig davon über die "SignOfLife"-Logik. Die mir vorliegenden Testmuster senden auch periodische "off"-Signale. Da wohl wieder jeder Hersteller seine eigenen Spezialitäten.

[krikan]

Das Verhalten ist so gewollt, damit nur bei sich ändernden Statusmeldungen des Sensors Notifys ausgelöst werden.

Ok. Das ist dann eben anders als bei vielen anderen Sensoren (subTypes), wobei das für mich egal ist.

Gibt es denn einen Vorteil, das über eine eigene Modullogik abzubilden, statt bspw. per default bei dem subType multiFuncSensor die Attribute bei autocreate folgendermaßen zu setzen:

Code Auswählen Erweitern

attr <device> event-on-change-reading brightness,contact,vibration,voltage
?
Beim Attribut könnte der Anwender das vorbelegte Verhalten ändern, während das momentan mMn nicht möglich ist und die ReadungFN-Attribute für den subType teilweise ausgehebelt werden.

Einen Lösungsansatz für den Themenersteller erkenne ich beim momentanen Modulstand nicht.

Gru0, Christian

[Svenergy]

Vielen Dank für die Aufklärung.

Die periodischen "off"-Signale kommen leider nur alle 30-40 Minuten, das ist für Online-Überwachung nicht gut geeignet.

Ich habe in der 10_EnOcean.pm einen entsprechenden If-clause gefunden, der dieses Verhalten erzeugt. Wenn ich diesen auskommentiere funktioniert der Sensor wie gewollt. Gibt es hierzu Bedenken im weiteren Verhalten der gesamten Logik? (Außer, dass jeder update diesen Schritt wieder zurücksetzt)

Code Auswählen Erweitern

if (!exists($hash->{helper}{lastEvent}) || $hash->{helper}{lastEvent} ne $data) {
     

Grüße, Sven

[Svenergy]

Alternativ - habe das gerade getestet - könnte ich den Subtype löschen. Dann wird das Telegramm ja als "unknown device" ausgewertet, was D1 - D4 Readings erzeugt. Das Bit/byte welches die Info der Vibration enthält ändert D1 von 0 auf 1 und umgedreht. Dieses Reading kommt immer an und erzeugt auch immer einen Event. Für den notify denke ich doch völlig ausreichend - irgendwelche Einwände?

Code Auswählen Erweitern

D0 0 2019-08-30 22:34:26
D1 0 2019-08-30 22:34:26
D2 0 2019-08-30 22:34:26
D3 1 2019-08-30 22:34:26

(die mitgelieferten Werte wie Spannung der Batt usw sind zwar interessant, aber aktuell nicht weiter von Bedeutung für mich.)

Der Vorteil, wenn ich das so sagen darf, ich muss nicht gut durchdachte Module manipulieren.

Ich weiß, das ist schon wieder herumgebastel ohne Hintergrundwissen. Aber mir reicht, wenn ich die Funktion realisiert bekomme, fast egal wie. Hauptsache das FHEM geht dabei nicht kaputt.

Grüße Sven

[krikan]

Hallo Sven!

Beide Lösungsansätze sind mMn gangbare Wege ohne sie getestet zu haben. Bessere fallen mir auch nicht ein.

Habe die manuelle Anpassungsvariante von 10_EnOcean angeschaut und erkenne auf den ersten Blick keine Schwierigkeiten. Das bedeutet aber nichts; im Fazit musst Du testen. Hauptproblem bei manuellen Anpassungen von 10_EnOcean.pm hast Du erkannt: Updateproblematik. Du kannst per Attribut exclude_from_update das Modul vom update ausschließen. Damit drohen jedoch potentiell Probleme, die Du selbst lösen musst. Dafür kann keiner Support leisten. Vorteil ist, dass Du mit wenig Änderung das gewünschte Ergebnis bekommst und der subType mit seinen Funtionen erhalten bleibt. Sollten zuviele Events kommen, kannst Du das flexibel mit den ReadingFn-Attributten ganz normal eingrenzen.

Durch Löschen des subType solltest Du aber mMn mit weniger Gefahren zum Ziel kommen. Die Rohsensorwerte/Readings kannst Du per userReadings in verständliche Readings umwandeln. Die notwendige Logik findest Du in 10_EnOcean.pm nach der von Dir genannten if-clause. Begrenzung der Events ist auch hier per ReadingFn-Attribute mögliche. Die nicht vorhandene signOfLife-Funktion kannst Du simpel mit einem watchdog/sequence nachbilden oder darauf spezialisterte Module (bspw. monitoring) nutzen.

Eventuell ändert klaus.schauer den Code ja auch noch, so dass wieder alle Events durchkommen und der Anwender die Events fexibel mit ReadingFn-Attributen festlegen/begrenzen kann. Ich stecke nicht so tief in der Materie/Logik/Code, dass ich alle Vor-/Nachteile des derzeitigen Handlings beurteilen kann.

Bitte halte uns über Deine Vorgehensweise und Erfahrungen auf dem Laufenden. Falls Du userReadings einsetzt und das funktioniert, wäre sicherlich auch der entsprechende Code interessant.

Gruß, Christian

[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