Hallo zusammen,
ich habe ein kleines (Komfort)Problem, bei dem ich Hilfe benötige.
Ich habe Funkstellantriebe für meine Heizkörper vom Typ Stella E, die in FHEM unter Attriebuten als subType hvac.01 und eep A5-20-01 angezeigt werden.
Ich möchte gern den Batteriestatus überwachen. Leider werden im reading "battery" nur die Zustände "ok" und "low" angezeigt. "low" wird aber bereits angezeigt, wenn der Ladezustand der Batterie < 100% ist, bzw. nach ca. 2 Monaten. allderdings dauert es dann immer noch ca. 1 Jahr, bis die Batterie wirklich leer ist.
Ich habe versucht nach dieser Anleitung https://forum.fhem.de/index.php/topic,62869.msg1243213.html#msg1243213 (https://forum.fhem.de/index.php/topic,62869.msg1243213.html#msg1243213) zu ermitteln, wann die Batterie nahezu leer ist, funktioniert nur leider nicht.
Es gibt dort das reading alarm: no_response_from_actuator. Lässt sich dieses eventuell zusammen mit dem Datum dazu nutzen, um eine Meldung herauszugeben, wenn die Batterie leer ist? Bei voller Batterie ist dieses reading nicht vorhanden.
Ich habe hier im Forum etwas über das reading "energyStorage" gelesen. Das steht aber immer auf empty und hilft da anscheinend auch nicht wirklich weiter.
Kann mir da eventuell jemand helfen?
Danke im vorraus.
Gruß
postman
edit: ich habe auch noch einige Fensterkontakte TF-FKB, ebenfalls Enocean. Bei denen wird der Batteriestatus gar nicht angezeigt obwohl dieser ein entsprechendes "Spannungas-Telegramm" sendet. Siehe beiliegendes PDF
Ich nutze das Battery-Reading de facto nicht, weil es eben nicht einheitlich umgesetzt ist bzw. verfügbar ist. Vielmehr nutze ich Watchdogs, die mich informieren, wenn periodische Nachrichten ausbleiben oder wenn Befehle nicht "angekommen" bzw. nicht bestätigt werden. Dazu braucht Du zwei Attribut-Bereiche:
1) signOfLife und signOfLifeInterval
2) observe (und was dazu gehört)
=> commandref
Das passende DOIF im Perl-Modus sieht bei mir dann so aus:
{
if ([":alarm:.dead_sensor"] ) {
if ( get_Exec('$DEVICE') == 0 ) {
set_Exec('$DEVICE', 3600, 'if(::ReadingsAge("$DEVICE","alarm",undef) > 3599) {fhem("msg $DEVICE antwortet auch 60 Minuten nach erstem Ausfall nicht");} else {}');
}
}
if ([":alarm:.no_response_from_actuator"] ) {
if ( get_Exec('$DEVICE') == 0 ) {
set_Exec('$DEVICE', 3600, 'if(::ReadingsAge("$DEVICE","alarm",undef) > 3599) {fhem("msg $DEVICE antwortet auch 60 Minuten nach erstem Ausfall nicht");} else {}');
}
}
}
Wird also durch "signoflife" oder direkt "no_response_from_actuator" gesetzt, wird nochmal 60 Minuten gewartet, bis ich eine Info erhalte, dass der Sensor/Aktor weg ist. Damit erkennst Du auch ziemlich gut, wenn Geräte eine instabile Funkverbindung haben.
Das ist nur historisch bedingt in zwei unterschiedlichen Zweigen getrennt. Man kann es natürlich auch direkt in einer Abfrage unterbringen.
Aber viele Wege führe nach Rom.
Hallo Flachzange,
danke, das werde ich mal versuchen.
Gruß
Hallo Flachzange,
leider habe ich das mit Deinem Vorschlag nicht hinbekommen, ich verstehe die Perlsyntax leider nicht wirklich.
Daher habe ich es jetzt so gelöst:
define Meldung DOIF ([HZArbeit:state:sec]>43200 and [HZArbeit:operationMode] eq "setpoint") ({DebianMail(xxx.yyy@zzz.de','FHEM Nachricht: Heizung', 'Arbeitzimmer Heizung Batterie leer.')},set AzHZBat low) DOELSEIF ([HZArbeit:state:sec]>129600 and [HZArbeit:operationMode] eq "summerMode") ({DebianMail('xxx.yyy@zzz.de','FHEM Nachricht: Heizung', 'Arbeitzimmer Heizung Batterie leer.')},set AzHZBat low) DOELSE (set AzHZBat ok)
Das AzHZBat ist ein Dummy, der bei "OK" einen grünen Punkt und ansonsten einen roten Punkt zeigt. Nachteil, es muss für jeden Thermostaten ein eigenes DOIF erstellt werden, sonst gibt es ein ziemliches Durcheinander.
Gruß
Hallo Flachzange,
hat so immer noch nicht funktioniert. Habe es nun noch einmal geändert:
Internals:
CFGFN
DEF ([HZArbeit:alarm] ne"" and [HZArbeit:operationMode] eq "setpoint") ({DebianMail('xxx.zzz@yyy.de','FHEM Nachricht: Heizung', 'Arbeitzimmer Heizung Batterie leer.')},set AzHZBat low) DOELSEIF ([HZArbeit:alarm] ne "" and [HZArbeit:operationMode] eq "summerMode") ({DebianMail(xxx.zzz@yyy.de','FHEM Nachricht: Heizung', 'Arbeitzimmer Heizung Batterie leer.')},set AzHZBat low) DOELSE (deletereading AZHZMeldung e_HZArbeit_alarm,set AzHZBat ok)
Attributes:
checkReadingEvent 0
do always
timerWithWait 1
wait 5400:9000
Setze ich das Attribut "wait" für das erste do, wird es entsprechend zeitversetzt ausgeführt. werden vor der Ausführung neue Batterien eingelegt, steht alles wieder auf OK.
Gruß
Eigene DOIFs und Dummy geht natürlich, aber sehr elegant ist das nicht
Zur Erläuterung des DOIFs aus meinem Post. Beschränken wir uns auf einen Zweig.
#Trigger auf alarm-Event
if ([":alarm:.no_response_from_actuator"] ) {
#Prüfung, ob bereits ein Wait-Timer für das triggerende Device gesetzt ist. Falls ja, nichts machen, weil wir den Alarm dann ja schon kennen. Falls nein, wait timer setzen.
if ( get_Exec('$DEVICE') == 0 ) {
#setzt wait timer auf 60 Minuten. Callback-Funktion nach Ablauf prüft, ob das Alarm-Reading älter ist als der Wait-Timer. Ansonsten würden auch neuere Alarm-Ereignisse eine Nachricht auslösen. Wenn das Reading "Alarm" zwischenzeitlich wieder gelöscht wurde, läuft der Wait-Timer einfach ab.
set_Exec('$DEVICE', 3600, 'if(::ReadingsAge("$DEVICE","alarm",undef) > 3599) {fhem("msg $DEVICE antwortet auch 60 Minuten nach erstem Ausfall nicht");} else {}');
}
}
Das DOIF benötigt keine weiteren Attribute.
Ne, elegant ist das nicht, geb ich ja zu.
Ich werde das mal an einem Testsystem machen. Ich habe noch einen Thermostaten als Ersatz liegen.
Mal sehen, wie weit ich komme.