[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