Event alarm: Trigger beim löschen des Readings

klaus.schauer · 24 September 2024, 10:48:08

Wie in https://forum.fhem.de/index.php?topic=139195.0 diskutiert, wird jetzt ein Event mit "alarm: reset" beim Löschen eines Readings "alarm" erzeugt. Bitte Änderungen vorab testen, danke.

Flachzange · 24 September 2024, 20:37:11

Hallo Klaus,

vielen Dank!

Zumindest bei dead_sensor durch signOfLife bleibt das reading jetzt einfach stehen, wird also auch nicht gelöscht. Beispiel-List:

Code Auswählen

Internals:
   DEF        0526285A
   FUUID      65be72ae-f33f-fd7e-3fec-e2c1cfa561bc84ac
   IODev      TCM_Remote_EG
   LASTInputDev TCM_Remote_Garage
   MSGCNT     4
   NAME       Kontakt_Garage_EG_Eingang_Geraete
   NR         738
   NTFY_ORDER 50-Kontakt_Garage_EG_Eingang_Geraete
   STATE      closed
   TCM_Remote_EG_DestinationID FFFFFFFF
   TCM_Remote_EG_MSGCNT 1
   TCM_Remote_EG_PacketType 1
   TCM_Remote_EG_RSSI -91
   TCM_Remote_EG_ReceivingQuality bad
   TCM_Remote_EG_RepeatingCounter 1
   TCM_Remote_EG_SubTelNum 3
   TCM_Remote_EG_TIME 2024-09-24 19:42:19
   TCM_Remote_Garage_DestinationID FFFFFFFF
   TCM_Remote_Garage_MSGCNT 4
   TCM_Remote_Garage_PacketType 1
   TCM_Remote_Garage_RSSI -74
   TCM_Remote_Garage_ReceivingQuality excellent
   TCM_Remote_Garage_RepeatingCounter 0
   TCM_Remote_Garage_SubTelNum 6
   TCM_Remote_Garage_TIME 2024-09-24 20:29:20
   TYPE       EnOcean
   eventCount 6
   Helper:
     DBLOG:
       alarm:
         logdb:
           TIME       1727202319.83086
           VALUE      dead_sensor
       state:
         logdb:
           TIME       1727202560.48001
           VALUE      closed
   READINGS:
     2024-09-24 19:16:15   IODev           TCM_Remote_EG
     2024-09-24 20:25:19   alarm           dead_sensor
     2024-09-24 20:29:20   state           closed
   helper:
     timer:
       alarm:
         HASH(0x563ced9db978)
         alarm
         dead_sensor
         1
         5
Attributes:
   IODev      TCM_Remote_EG
   creator    autocreate
   eep        D5-00-01
   manufID    7FF
   room       Garage,Kontakte
   signOfLife on
   signOfLifeInterval 1260
   subType    contact
   userattr   room_map structexclude

klaus.schauer · 24 September 2024, 21:14:20

Das war so nicht geplant, sorry Denkfehler. Noch ein Versuch.

Edit (2024-09-25): Neue Version des Moduls mit einer kleinen Änderung.

Flachzange · 25 September 2024, 20:38:41

Nach einem Tag Probebetrieb sieht es erstmal gut aus. Dadurch, dass jetzt auch das Löschen des Readings erfasst werden kann, kann man ungünstig gesetzte signOfLife-Intervalle ausfindig machen, beispielsweise, wenn 1 Minute nach dead_sensor dann doch wieder ein Telegramm empfangen wurde und das Reading gelöscht wird.

Danke nochmals!

Flachzange · 27 September 2024, 20:30:26

Ich teste noch und lass mir fleißig ausgeben, wenn ein Alarm zurückgesetzt wird. Ich hatte heute den Fall, dass ein "reset" nicht erfasst wurde. Es betraf das Profil occupSensor.01

Edit: War kein Einzelfall. Ist nun schon wiederholt bei unterschiedlichen Geräten aufgetreten

Flachzange · 28 September 2024, 20:35:59

Eine weitere Beobachtung: Ich habe Geräte, bei denen explizit signOfLife=off und ein beliebiges Interval gesetzt ist. Das betrifft bei mir hautpsächlich Geräte, die mal im Einsatz waren aber jetzt im dunkelen Keller geparkt sind. Richtigerweise wird für diese Geräte kein Alarm dead_sensor ausgegeben. Es wird jedoch manchmal ein reset-Event ausgelöst. Meine Vermutung: wenn diese Geräte mal wieder Licht gesehen haben und ein Telegramm senden, wird ein reset-Event ausgelöst, obwohl signOfLife=off ist.

klaus.schauer · 29 September 2024, 09:56:26

Ein Alarm kann von unterschiedlichen Routinen gesetzt werden, also nicht nur durch die signOfLife-Funktion.

Das Reading "alarm" wird, wenn es existiert, beim Empfang eines Datenpaketes gelöscht. Dies ist unabhängig von den Einstellungen der signOfLife-Funktion.

Flachzange · 10 Oktober 2024, 18:11:48

Zitat von: klaus.schauer am 29 September 2024, 09:56:26Ein Alarm kann von unterschiedlichen Routinen gesetzt werden, also nicht nur durch die signOfLife-Funktion.

Das Reading "alarm" wird, wenn es existiert, beim Empfang eines Datenpaketes gelöscht. Dies ist unabhängig von den Einstellungen der signOfLife-Funktion.

Ja, hatte ich verstanden, gleichzeitig gibt es für diese Kontakt-Sensoren auch keine anderen Alarm-Typen. Ich kann jedoch "Entwarnung" geben. Der Fall ist nicht mehr aufgetreten. Möglicherweise waren es sehr langlaufende signOfLife-Trigger.

Wohingegen

ZitatIch hatte heute den Fall, dass ein "reset" nicht erfasst wurde. Es betraf das Profil occupSensor.01

Edit: War kein Einzelfall. Ist nun schon wiederholt bei unterschiedlichen Geräten aufgetreten

reproduzierbar auftritt. Neben occupSensor.01 beobachte ich das auch bei lightTempOccupSensor.01.

klaus.schauer · 24 Oktober 2024, 20:38:45

Ich habe noch ein paar Stellen ohne reset-Trigger für Alarm gefunden und geändert.

Flachzange · 25 Oktober 2024, 00:02:34

Danke Klaus, würde ich testen, aber ich habe gerade aufgrund einer Modifikation von hier meine EnOcean.pm angepasst. Könntest Du da mal schauen und eine Rückmeldung geben? Dann könnt ich ggf. beides gleichzeitig testen. Dank Dir!

Gruß
Chris

klaus.schauer · 25 Oktober 2024, 09:05:35

Ich habe eine etwas andere Lösung eingebaut. Der Alarm kommt jetzt für die Micropelt Aktoren erst nach 2.2 * wakeUpCycle statt 1.1. Damit sollten die wechselnden Sendeintervalle keine Alarme mehr auslösen.

Bei mir ist noch ein Micropelt MVA002 in Betrieb, der sich gelegentlich erst nach 20 min meldet. Diesbezügliche Alarme haben mich bisher nicht beunruhigt. Aber so unterschiedlich sind eben die Erwartungen und Wünsche der Menschen.

Flachzange · 25 Oktober 2024, 14:39:59

Zitat von: klaus.schauer am 25 Oktober 2024, 09:05:35Ich habe eine etwas andere Lösung eingebaut. Der Alarm kommt jetzt für die Micropelt Aktoren erst nach 2.2 * wakeUpCycle statt 1.1. Damit sollten die wechselnden Sendeintervalle keine Alarme mehr auslösen.

Dank Dir, aber ich glaube das reicht nicht. Wenn ich es gerade richtig im Kopf habe, wechseln meine Aktoren sporadisch vom 10-Minuten-Intervall auf ein 2-Minuten-Intervall und zurück.

Zitat von: klaus.schauer am 25 Oktober 2024, 09:05:35Diesbezügliche Alarme haben mich bisher nicht beunruhigt. Aber so unterschiedlich sind eben die Erwartungen und Wünsche der Menschen.

Bei vielen Thermostaten im Haus hast Du dann auch automatisch viele Alarme, die eigentlich keine sind. Mein Wunsch ist, dass ich nur in Ausnahmefällen / Alarmen nach dem Rechten schauen muss. False positives machen es dann eben schwierig und man übersieht schnell, wenn dann mal wirklich ein Aktor ausgefallen ist.

klaus.schauer · 25 Oktober 2024, 19:51:23

Dann machen wir es eben noch anders. Bei der Vielzahl der EnOcean-Attribute kommt es auf ein weiteres nicht mehr an. Und jeder kann nach seiner Fasson selig werden.

Mit dem neuen Attribut signOfLifeSensitivity kann die Alarmperiode auf x wakeUpCycle gesetzt werden. Um die Schwankung der Periodendauer von 2 min auf 10 min abzudecken, also den Wert 5. Der Standardwert ist 1. Die Funktion gilt für das Profil hvac.01 generell.

Die Erklärungen in der commandref werden später entsprechend eingearbeitet.

Flachzange · 27 Oktober 2024, 09:53:09

Hi Klaus,

ich möchte hier nicht aus einer Mücke einen Elefanten machen, aber gefühlt ist das doch nur ein Workaround. Klar, es ist leicht nur diesen einen Faktor anzupassen, aber irgendwie adressiert es doch den Sachverhalt nicht richtig. Durch den Faktor schaffe ich es zwar größere Sprünge zwischen Telegrammzeiten abzufangen, es führt aber dazu, dass im Standard-Fall (hier: 10 Minuten) der Timer viel zu lange laufen würde.

Vielleicht habe ich es auch noch nicht verstanden, daher nochmal mein Verständnis:

1) WakeUpCycle dient der Überwachung der batteriebetriebenen Heizkörper-Stellantriebe (battery powered actuators).
2) Da die Aktoren nicht aktiv gepollt werden können, muss man auf eine Nachricht vom Aktor warten
3) Über die Differenz zwischen den Nachrichten ergibt sich der wakeUpCycle
4) Letztendlich ist es also eine Art automatisches signOfLife wie bei Sensoren, nur dass es hier je nach Aktor noch verschiedene Spezial-Situationen geben kann, z.B. Sommer-Modus oder Fenster offenen (die jedoch statisch berücksichtigt werden)
5) Wenn jedoch ein Aktor dynamisch das Kommunikationsintervall anpasst, merkt FHEM das immer erst ein Intervall zu spät. Bei einer Verkürzung des Intervalls kein Problem, bei einer Verlängerung wird jedoch ein Alarm ausgelöst.

Die Problemstellung ist also: Wie adressiere ich das dynamische Kommunikationsintervall?

Mein Lösungsvorschlag war: Man nehme statisch das längste bzw. Standard-Intervall des Aktors. Ich verstehe, dass es blöd ist, dies für jeden Aktor/Hersteller statisch und individuell zu hinterlegen Gleichzeitig war in meinem Fall eh schon ein Standard-Intervall von 10 Minuten hinterlegt.

Daher nochmal eine abgewandelte Idee: Anstatt mit einem Attribut für den WakeUpCycle-Faktor zu spielen, nutzt man einfach das existierende signOfLife-Attribut. Da kann man dann ja das Standard- bzw. Maximal-Intervall hinterlegen. Und wenn man dann mal ehrlich ist benötigt man die automatische Berechnung des WakeUpCycles eigentlich gar nicht. Lediglich für den Fall, dass das Kommunikationsintervall statisch ist, kann es dazu benutzt werden dieses signOfLife-Intervall automatisch zu bestimmen, aber diese Funktion habe ich ja bei den Sensoren auch nicht.

Gruß
Chris

klaus.schauer · 27 Oktober 2024, 21:49:31

Das (automatisch berechnete) wakeUpCycle-Intervall dient dem PID-Regler als Referenz für dessen interne Berechnungsintervalle. Die Überwachung der Kommunikation stand dabei nie im Vordergrund und ist ein willkommener Zusatznutzen.

Für das signOfLife-Mücke-zu-Elefanten-Problem fällt mir keine perfekte Lösung ein. Ich werde deshalb keine Änderungen vornehmen.

Es ist mein Anspruch ein möglichst gutes EnOcean-Modul nicht nur für meine persönlichen Anforderungen bereitzustellen. Alle Wünsche kann und will ich nicht abdecken. Auch fehlt mir schlicht die Zeit und bei dem einen oder anderen Thema auch die Lust an immer weiter ausufernden Diskussionen im Forum.