Event alarm: Trigger beim löschen des Readings

[klaus.schauer]

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]

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 Erweitern

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]

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

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

[Flachzange]

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]

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]

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]

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]

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.

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

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

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