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.

[klaus.schauer]

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

[Flachzange]

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]

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]

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.

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.

Diesbezü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]

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]

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]

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.

[Damu]

Habe 3 SAB05 Stellantriebe im Heizungsraum diese Regeln die 3 Räume im UG.
Denen hab ich Temperatur Sensoren pro Raum zugeteilt.
Hab in denn anderen Zimmern natürlich noch mehr Stellantriebe.
Diese Regeln aber meist ohne externe Sensoren.
Bin froh das jemand das mal versucht besser zu "Machen".
Kommt halt (bei mir) schon ab und zu vor das ein Stellantrieb nicht mehr richtig geht.
Hab das neue Attr bei mir mal auf 2 Gestellt.
Und werde testen.
Danke an alle.

[Flachzange]

Hallo Klaus,

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.

Ich bin sehr dankbar für die gute EnOcean-Integration in FHEM. Auch mein Anspruch ist es, dass das EnOcean-Modul möglichst gut ist. Wenn ich mich also stundenlang hinsetze und debugge, warum die Stellantriebe einen Alarm werfen, dann mache ich das nicht, weil ich mir etwas wünsche, sondern um dem Fehler auf den Grund zu gehen, damit das Modul noch besser ist. Ein "no response from actuator" signalisiert dem Nutzer nämlich ein grundlegendes Kommunikationsproblem (was es ja gar nicht ist). Etwas, was man nicht haben möchte und auch immer wieder hier im Forum hochgekommen ist.

Auch fehlt mir schlicht die Zeit und bei dem einen oder anderen Thema auch die Lust an immer weiter ausufernden Diskussionen im Forum.

Ich bin mir nicht sicher, worauf Du Dich beziehst. Das EnOcean-Forum ist praktisch tot und dieses Thema hier als ausufernd zu bezeichnen finde ich etwas weit hergeholt.

Ich habe mir gerade nochmal den Code angeschaut, dabei ist mir aufgefallen, dass es ja bereits ein Attribut "wakeUpCycle" gibt, welches für hvac.04 und hvac.06 herangezogen wird. Können wir das nicht einfach auf hvac.01 übertragen? Default ist auto und es bildet die Funktion ab, so wie es sie heute gibt. Wenn ich jetzt so einen Micropelt MVA004 habe, kann ich statisch auf 600 setzen und das Problem ist gelöst. Das neue Attribut signOfLifeSensitivity braucht es nicht.

Gruß
Chris

[klaus.schauer]

Im Profil hvac.04 und hvac.06 kann man "wakeUpCycle" als Anwender im Aktor setzen. Dafür gibt es dann ein entsprechendes Attribut.

[Flachzange]

Im Profil hvac.04 und hvac.06 kann man "wakeUpCycle" als Anwender im Aktor setzen. Dafür gibt es dann ein entsprechendes Attribut.

Was man doch eigentlich gar nicht braucht, da die bei hvac.01 implementierte Logik dieses manuell gesetzte Intervall ja "ermitteln" kann. Im Gegensatz zu der dynamischen Änderung funktioniert diese Logik in diesem Fall ja genau richtig.

[Damu]

Hab das mit signOfLifeSensitivity mal getestet.
Bei mir verbessert sich das verhalten etwas.
@Flachzange Chris hast Du das auch mal getestet?
Bei mir scheint es besser zu sein, würde daher begrüssen wenn signOfLifeSensitivity eingebaut wird.

[Flachzange]

Nein, ich hab signOfLifeSensitivity nicht getestet.

Ich habe meinen Gedanken umgesetzt, den Wert aus dem Attribute wakeUpCycle auch für die signOfLife-Überwachung und PID-Kalkulation zu nutzen. Das habe ich jetzt einige Zeit getestet und funktioniert bei mir.

Konkret für die Profile:

hvac.01 (MVA004): Konfiguriert man nichts, ist das Verhalten wie bisher. Durch die dynamische Intervalländerung kommt es zu Alarmen. Setzt man jetzt wakeUpCycle explizit so wird dieser Wert fix für die Überwachung/PID genutzt. 600 s sollten für die MVA004 eingestellt werden. Man könnte noch überlegen, ob man es beim autocreate berücksichtigt.

hvac.04 (z.B. Hora Smartdrive MX): Alarm-Timer hinzugefügt, so dass man auch bei Ausfall des Aktors / Telegrammverlust einen Alarm bekommt

hvac.06 (MVA005, MVA009): Konfiguriert man nichts, ist das Verhalten wie beim MVA004. Bisher waren es immer mindestens 600s, so wie von mir auch für hvac.01 angeregt. Das habe ich jetzt aber rausgenommen. Setzt man jetzt wakeUpCycle explizit so wird dieser Wert nicht nur für das Setzen des WakeUpCycles genutzt, sondern auch für die Überwachung.

signOfLifeSensitivity braucht es aus meiner Sicht nicht.

Code Auswählen Erweitern

8549,8574c8549,8581
<       my $wakeUpCycle = 600;
<       # calc wakeup cycle
<       if ($summerMode eq 'off') {
<         $summerMode = 0;
<         if ($timeDiff == 0 || $window eq 'open') {
<           $wakeUpCycle = 1200;
<         } elsif ($timeDiff < 120) {
<           $wakeUpCycle = 120;
<         } elsif ($timeDiff > 1200) {
<           $wakeUpCycle = 1200;
<         } else {
<           $wakeUpCycle = int($timeDiff);
<         }
<       } else {
<         $summerMode = 8;
<         # ignore all commands
<         if ($waitingCmds ne "summerMode") {
<           $waitingCmds = "no_change";
<           readingsDelete($hash, "waitingCmds");
<         }
<         if ($manufID eq '049') {
<           $wakeUpCycle = 28800;
<         } else {
<           $wakeUpCycle = 3600;
<         }
<       }
---
>       my $wakeUpCycle = AttrVal($name, "wakeUpCycle", "auto");#get wakeUpCycle from attribute
>      
>       if ($summerMode eq 'off') {
>         $summerMode = 0;
>         # calc wakeup cycle if auto
>         if (lc($wakeUpCycle) eq 'auto') {
>             if ($timeDiff == 0 || $window eq 'open') {
>               $wakeUpCycle = 1200;
>             } elsif ($timeDiff < 120) {
>               $wakeUpCycle = 120;
>             } elsif ($timeDiff > 1200) {
>               $wakeUpCycle = 1200;
>             } else {
>               $wakeUpCycle = int($timeDiff);
>             }
>         } else {
>             #take explicit wakeUpCycle from attribute
>         }
>       } else { #in summer mode ignore attribute settings for wakeUpCycle (it can stay as it is)
>         $summerMode = 8;
>         # ignore all commands
>         if ($waitingCmds ne "summerMode") {
>           $waitingCmds = "no_change";
>           readingsDelete($hash, "waitingCmds");
>         }
>         #ignore attribute settings for wakeupcycle in summermode
>         if ($manufID eq '049') {
>           $wakeUpCycle = 28800;
>         } else {
>           $wakeUpCycle = 3600;
>         }
>       }
>      
8583c8590
<       InternalTimer(gettimeofday() + $wakeUpCycle * AttrVal($name, "signOfLifeSensitivity", 1) * 1.1, "EnOcean_readingsSingleUpdate", $hash->{helper}{timer}{alarm}, 0);
---
>       InternalTimer(gettimeofday() + $wakeUpCycle * 1.1, "EnOcean_readingsSingleUpdate", $hash->{helper}{timer}{alarm}, 0);
8990a8998
>       
9002a9011,9023
>      
>       my $wakeUpCycleSec = $wakeUpCycleInv{$wakeUpCycle};
>       readingsSingleUpdate($hash, 'wakeUpCycle', $wakeUpCycleSec, 1);
>      
>       # set alarm timer
>       if (exists $hash->{READINGS}{alarm}) {
>         DoTrigger($name, "alarm: reset", 1);
>         readingsDelete($hash, "alarm");         
>       }
>      
>       RemoveInternalTimer($hash->{helper}{timer}{alarm}) if(exists $hash->{helper}{timer}{alarm});
>       @{$hash->{helper}{timer}{alarm}} = ($hash, 'alarm', 'no_response_from_actuator', 1, 3);
>       InternalTimer(gettimeofday() + $wakeUpCycleSec * 1.1, "EnOcean_readingsSingleUpdate", $hash->{helper}{timer}{alarm}, 0);
9271,9272c9292,9293
<       my $wakeUpCycle = 600;
<       # calc wakeup cycle
---
>       my $wakeUpCycle = AttrVal($name, "wakeUpCycle", "auto"); #get wakeUpCycle from attribute
>      
9275,9283c9296,9309
<         if ($timeDiff == 0 || $window eq 'open') {
<           $wakeUpCycle = 600;
<         } elsif ($timeDiff < 120) {
<           $wakeUpCycle = 120;
<         } elsif ($timeDiff > 7200) {
<           $wakeUpCycle = 7200;
<         } else {
<           $wakeUpCycle = int($timeDiff);
<         }
---
>         # calc wakeup cycle if auto
>         if (lc($wakeUpCycle) eq 'auto') {
>             if ($timeDiff == 0 || $window eq 'open') {
>               $wakeUpCycle = 600;
>             } elsif ($timeDiff < 120) {
>               $wakeUpCycle = 120;
>             } elsif ($timeDiff > 7200) {
>               $wakeUpCycle = 7200;
>             } else {
>               $wakeUpCycle = int($timeDiff);
>             }
>         } else {
>              #take explicit wakeUpCycle from attribute
>         }
9290a9317
>         #ignore attribute settings for wakeupcycle in summermode
9302c9329
<         InternalTimer(gettimeofday() + ($wakeUpCycle < 600 ? 600 : $wakeUpCycle) * 1.1, "EnOcean_readingsSingleUpdate", $hash->{helper}{timer}{alarm}, 0);
---
>         InternalTimer(gettimeofday() + $wakeUpCycle * 1.1, "EnOcean_readingsSingleUpdate", $hash->{helper}{timer}{alarm}, 0);
15242a15270,15273
>     }
>     elsif (AttrVal($name, "subType", "") eq "hvac.01" && $attrVal =~ m/^$wakeUpCycle$/) {
>     #do nothing for hvac.01 when value is set
>    
15254a15286
>         
16134a16167,16169
>     if (lc($wakeUpCycle) eq 'auto') {
>         $wakeUpCycle = ReadingsVal($name, 'wakeUpCycle', 300);
>     }
22111c22146
<       Transmission cycle of the actuator.
---
>       Transmission cycle of the actuator. For hvac.01 optional to specify maximum wake up interval.





Edit: Dateianhänge

[Damu]

Unter dem Textfeld "Dateianhänge und weitere Optionen"
Sollte doch gehen.

Danke werde mir das morgen mal anschauen.

[Flachzange]

Unter dem Textfeld "Dateianhänge und weitere Optionen"
Sollte doch gehen.

Ahhh 

Ich nutze immmer nur "Schnell Antworten", da sucht man danach vergeblich.

Danke!

[Damu]

Hab das mal eingebaut.
Habe bis jetzt zwei Alarm erhalten.
Ist als viel besser als vorher.
Wenn ich jetzt bei einem Thermokon SAB05 das wakeUpCycle auf 600 setze hab ich in den nächsen Reading das wakeUpCycle auch auf 600.
Ist das so richtig?
Habe auch drei neuere SAB+ verbaut. Einer ist an einem Radiator beim Eingang.
Der ist extrem Laut. (vorher hatte ich da ein Micropelt MVA004 oder MVA005.)
Welche Stellantriebe sind eigentlich leise?

[Flachzange]

Hab das mal eingebaut.
Habe bis jetzt zwei Alarm erhalten.
Ist als viel besser als vorher.

Kannst Du etwas genauer spezifizieren, was besser ist? In jedem Fall solltest Du jetzt nur noch Alarme erhalten, wenn wirklich ein Telegramm ausbleibt (und der Antrieb auch beim eingestellten Intervall funkt).

Am Ende obliegt es aber Klaus, ob er meinen Vorschlag annimmmt oder nicht.

Ich habe es jetzt durch die Verbesserungen von Klaus am generellen signOfLife-Handling geschafft meine Installation "alarmfrei" zu bekommen. Wenn sich jetzt Alarme häufen, weiß ich das etwas nicht stimmt.

Wenn ich jetzt bei einem Thermokon SAB05 das wakeUpCycle auf 600 setze hab ich in den nächsen Reading das wakeUpCycle auch auf 600.

Ja das ist die logische Konsequenz. Das Reading zieht sich seinen Wert direkt aus dem Attribut. Das Reading ergibt jetzt nur Sinn bei "auto". Bei hvac.04 gab es das Reading beispielsweise gar nicht, weil das Intervall fix war.

[Damu]

Hab nur schnell im log nachgeschaut.
Und die Readings etwas angeschaut.
Sendet der Thermostat nicht ein Wakeup (wann er das nächste mal aufwacht zum Senden/Empfangen?

[Flachzange]

Sendet der Thermostat nicht ein Wakeup (wann er das nächste mal aufwacht zum Senden/Empfangen?

Nein, aber das hatte ich damals auch intuitiv so vermutet. Das gibt aber das Protokoll gar nicht her. wakeUpCycle ist ein von Klaus berechneter Wert bei hvac.01 und hvac.06 auf Basis der vergangenen Kommunikation. Wenn der Antrieb den nächsten Aufwachzeitpunkt ankündigen würde, hätten wir nicht das Problem mit den false positives und könnten es ja genau abpassen. De facto ändert der Antrieb aber sein Aufwachintervall, ohne dass man es im Vorhinein weiß.

[klaus.schauer]

Für die drei Ventilaktor-Profile kann jetzt die Dauer des Überwachungsintervalls über das Attribut signOfLifeInterval festlegt werden. Falls signOfLifeInterval kleiner als das wakeUpCycle Intervall gewählt wird oder der Wert nicht gesetzt ist, wird der wakeUpCycle Wert verwendet. Die Überwachung ist standardmäßig eingeschaltet.

[Damu]

Zeile 23186:

<a href="#EnOcean-attr-customCmdAlarmOn">customCmdAlarmOn</a>, <a href="#EnOcean-attr-signOfLife">signOfLife</a> ([signOfLive] = on is default) and

sollte es da nicht "signOfLife" heisen?

[Damu]

Für die drei Ventilaktor-Profile kann jetzt die Dauer des Überwachungsintervalls über das Attribut signOfLifeInterval festlegt werden. Falls signOfLifeInterval kleiner als das wakeUpCycle Intervall gewählt wird oder der Wert nicht gesetzt ist, wird der wakeUpCycle Wert verwendet. Die Überwachung ist standardmäßig eingeschaltet.

Hab das mal eingebaut.
SignOfLife muss aber erst aktiviert (auf on gesetzt werden) off ist bei mir default.

[Flachzange]

Für die drei Ventilaktor-Profile kann jetzt die Dauer des Überwachungsintervalls über das Attribut signOfLifeInterval festlegt werden. Falls signOfLifeInterval kleiner als das wakeUpCycle Intervall gewählt wird oder der Wert nicht gesetzt ist, wird der wakeUpCycle Wert verwendet. Die Überwachung ist standardmäßig eingeschaltet.

Danke Klaus. Gute Lösung!

Habe es bei mir jetzt einige Tage getestet und es funktioniert für hvac.01 und hvac.04 wie beschrieben und erwartet. Für hvac.06 kann ich es mangels Hardware nicht bestätigen.

[Damu]

Bin auch am Testen. Danke.

Bei den Hvac.06 musste ich das Attribut wakeUpCycle löschen (hatte ich auf auto).
Sonst kam immer ein Pid Alarm (oder ähnlich).