Batteriestatus und Speicherung des letzten Wechsel

[_fhemuser_]

So ich bin einen kleinen Schritt weiter.

Ich habe deinen Code komplett aus der 99_myUtils.pm gelöscht und eine 99_BatterycheckUtils.pm angelegt und den Code mit den zusätzlichen Erweiterungen eingefügt und fhem restartet. Dann kommt jetzt nach Eingabe von {BatteryStatusFunction(1,"1:1")}

Code Auswählen Erweitern

2018.01.27 16:20:49 3: tele: set TelegramBot message @@12345678
Nach.: Die Batterien von 1 sollten bald gewechselt werden!
2018.01.27 16:20:49 3: TelegramBot_SendIt TelegramBot: Failed with :FAILED peer not found :@12345678::
2018.01.27 16:20:49 3: TelegramBot_Callback TelegramBot: resulted in NonBlockingGet: returned FAILED peer not found :@12345678: from SendIt
2018.01.27 16:20:49 3: set TelegramBot message @@12345678   Die Batterien von 1 sollten bald gewechselt werden! : FAILED peer not found :@12345678: also ein Problem mit dem Namen

[Amenophis86]

Du darfst nicht die ID nehmen, sondern musst deinen Telegram Username nehmen.

[_fhemuser_]

Es funktioniert endlich!

Ich habe wie am Anfang einen defaultUser im TelegramBot eingetragen und

Code Auswählen Erweitern

# TelegramBot
my $msg = "set TelegramBot message  ";

[Wzut]

Habe deinen Code gerade mal ein bisschen angepasst und kommentiert. Schau mal bitte drüber, ob ich es richtig verstanden habe:

ähh ja schaut noch fast so aus wie mein Vorschlag Aber doch noch ne kleine Anmerkung

Code Auswählen Erweitern

elsif($TYPE eq "MAX" and ReadingsVal($Device, "batteryLevel", "undef") eq "undef")
IMHO wird bei TYPE "MAX" niemals ein Reading  batteryLevel auftauchen daher hatte ich diese simple Abfrage
Noch ein Wort zu Telegram (und seinen möglichen Brüdern) Wie du an meinem Beispiel siehts schleppe ich den Dummy BatteryStatusBot nur noch mit weil er halt schon da ist , aber wirklich gebraucht wird er meiner Meinung nach nicht , alles wichtige lässt sich direkt aus  BatteryStatus ableiten mit Sicherheit auch bei den anderen möglichen Geräten. Da ich selbst kein Telegram oder ähnliches verwende hatte ich dafür einen Dummy angelegt damit die Zeilen  fhem($msg." ".$text_soon) auch greifen. Allerdinsg mit dem einen echten Event ( ,1 bei readingsSingleUpdate) könnte man auch das ganze Thema Benachrichtigung komplett aus deiner sub entfernen
und mit einem notify/DOIF direkt auf diesen Event triggern. Das hätte halt den Vorteil das du Batterie Monitoring und Benachrichtigungsverwaltung ganz sauber trennen könntest. Sorry wenn ich gedanklich jetzt fast alles aus der Urform auf den Kopf stelle, aber die Ideen kommen halt immer so nach und nach und immer getreu dem Motto "das Bessere ist der Feind des Guten"     

[Amenophis86]

@Wzut:
Bin für alle Vorschläge offen, daher kein Problem. Die Idee hinter BatteryStatusBot ist, dass Meldungen nicht doppelt verschickt werden. Soll heißen, wenn die Soon Meldung raus ist und nochmal ein Event erzeugt wird, welches Soon erzeugen würde, wird vorher geprüft, ob dafür schon eine Meldung raus ist. Dies wird bei dir ja auch nicht verhindert, oder? Dies könnte man machen, wenn man eine Meldung nur bei einem Event aus einer Externen Abfrage sendet. Im Code selbst wüsste ich jetzt nicht, wie es verhindert werden soll. Oder übersehe ich gerade etwas?

Ich hatte auch schon überlegt das Versenden der Meldung doch wieder raus zu nehmen und als Event drauf zu reagieren. Die Frage die sich damit eher stellt ist, wie allgemein soll der Code irgendwann werden. Eigentlich war es mal nur ein Code von MadMax-FHEM für seine Bedürfnisse. Bin mir da noch unschlüssig.

Da ich keine MAX Geräte habe, wusste ich nicht, ob es da auch welche mit batteryLevel gibt und habe somit die Prüfung als Vorsicht drinnen gelassen.

@_fhemuser_
Freut mich, dass es nun geht

_________________________

Habe im Testzweig gerade mal von setreading auf singleReadingUpdate umgestellt.

[Wzut]

Dies wird bei dir ja auch nicht verhindert, oder? 

doch mit $level == 25 , denn den gibt es nur 1x , beim nächste low wäre er dann ja schon runter auf 20

[Amenophis86]

Stimmt.
Nur nochmal zum Verständnis für mich. Bisher wissen wir, dass alle Geräte außer MAX mit dem reinen Reading Battery nicht zwischen low und ok wechseln. Das heißt bei diesen müssten wir direkt bei der ersten Meldung auf 0 setzen und damit die Meldung absetzen. Problem ist jetzt wieder, wenn ein Gerät doch wechselt, dann würde die Meldung ständig erscheinen. Beim Einsatz vom Dummy würde dies verhindert werden. Richtig so, oder habe ich etwas übersehen?

[Wzut]

ich kann dir geistig jetzt nicht ganz folgen ... klar mein Bespiel war auf MAX bezogen aber auch bei anderen Geräten lässt sich die Abstufung des Levels und die damit verbunden Aktion einsetzen. D.h. eben nicht gleich beim ersten low auf 0 runter, warum auch das Gerät macht es bestimmt noch ne Weile mit der Batterie.
Allerdings sind war da wieder beim event-on Thema, z.B. wird der LaCrosse Sensor recht flott seine lows raushauen bei on-update, hier kann dann die Verwerfung von x Minuten/Stunden hilfreich sein. Setzt der User allerdings on-change ein klappt das alles nicht da ja keine weiteren Events nach dem ersten low kommen werden.

[Amenophis86]

Das war mein Gedankengang, dass die MEISTEN User (ich auch) mit on-change arbeiten. Hätte ich dazu schreiben müssen, sorry.

Dh wenn wir so arbeiten wollen, dann müssen wir auch zumindest mit on-update und der Dauer von ReadingsAge bezogen auf die einzelnen Device. <600 wäre zB bei LaCrosse vermutlich noch zu wenig.

[Wzut]

@Amenophis86, FYI : https://forum.fhem.de/index.php/topic,71413.msg761857.html#msg761857
Beim selbst gebauten Fensterdrehgriff Kontakt zeigte sich auch das sonst typische MAX! Verhalten.
Unklar ist jetzt ob das bei HM normal ist oder ob das eine Eigenart von papas AskSin Lib ist.

[Amenophis86]

Gut zu wissen, wobei ich aktuell das Projekt hinten anstellen musste. Wie sieht denn ein List dieses Gerät aus soll heißen was steht im Reading TYPE und model?

[Amenophis86]

Jetzt hat es mich natürlich doch wieder gereizt über den Code zu grübeln und ich weiß wieder was meine letztes Problem war. Ich finde die Idee von dir mit dem Runterzählen gut, brauchen natürlich für die einzelnen Geräte dann Erfahrungswerte, wie lange die Batterien zB noch halten um festzusetzen was wir beim ReadingsAge einsetzen und wie lange das At laufen soll bis die Dead-Meldung kommt.

Bei der Dead-Meldung sehe ich auch noch ein Problem. Wenn der User die Batterie wechselt, bevor die Dead-Meldung durch das At getriggert wurde, dann denkt das Skript, dass keine Batterie gewechselt wurde und sagt alles wieder ok. Das heißt die Laufzeit des At darf nicht zu lange gewählt werden. Das stelle ich mir schwierig vor, weil ich kann mir vorstellen, dass es sowohl vom Gerät, als auch von der Batterie abhängt, wie lange ein Gerät noch funktioniert obwohl auf low gewechselt wurde. Ich habe zB aktuell einen HM Fensterkontakt, der meldet mir seit bestimmt 6 Wochen, dass er low ist und läuft noch ohne Probleme.

[Wzut]

soll heißen was steht im Reading TYPE und model?

Code Auswählen Erweitern

STATE      closed
   TYPE       CUL_HM
 
GK_2_Buero type:threeStateSensor -
list:peer register         :value
   0:      cyclicInfoMsg    :on
   0:      pairCentral      :0x---------
   0:      transmDevTryMax  :6
   1:      eventDlyTime     :0 s
   1:      ledOnTime        :0.5 s
   1:      msgRhsPosA       :closed
   1:      msgRhsPosB       :open
   1:      msgRhsPosC       :tilted
   1:      sign             :off
   1:      transmitTryMax   :0
 
   model      HM-SEC-RHS
subType    threeStateSensor
Wobei ich denke das ist völlig egal, sobald man papas Eigenbau FW für Geräte nutzt und bei diesen Bat definert ist werden sie sich alle gleich verhalten:

Code Auswählen Erweitern

public:
  void init () {
    BaseHal::init();
    // init real time clock - 1 tick per second
    rtc.init();
    // measure battery every 1h
    battery.init(60UL*60,rtc);
    battery.low(22);
    battery.critical(19);
hier sollten wir mal abwarten was papa dazu meint , vllt ändert er ja auch noch seine lib so das ein einmal gesetztes low bis zum reset des Kontrollers erhalten bleibt.

zu dead : ich arbeite halt mit 12 Stunden , u.U. kann man die Zeit ja auch als Variable im Kopf definieren so das dies jeder nach seinem persönlichen Geschmack leicht selbst festlegen kann. 

[Amenophis86]

Code Auswählen Erweitern

STATE      closed
   TYPE       CUL_HM
   model      HM-SEC-RHS
subType    threeStateSensor
Wobei ich denke das ist völlig egal, sobald man papas Eigenbau FW für Geräte nutzt und bei diesen Bat definert ist werden sie sich alle gleich verhalten:
...
hier sollten wir mal abwarten was papa dazu meint , vllt ändert er ja auch noch seine lib so das ein einmal gesetztes low bis zum reset des Kontrollers erhalten bleibt.

Ok, habe mich mit der Lib noch gar nicht beschäftigt. Dachte nur, wir müssen dann für diese Geräte auch wieder eine Sonderlocke einführen weshalb ich wissen wollte, wie die sich melden.

zu dead : ich arbeite halt mit 12 Stunden , u.U. kann man die Zeit ja auch als Variable im Kopf definieren so das dies jeder nach seinem persönlichen Geschmack leicht selbst festlegen kann.

Das mit der Variable im Kopf war auch meine Überlegung und sehe ich bisher als einzige Möglichkeit. Wird wenig Sinn machen da etwas vorzugeben.

[DarkT]

Gibt es eine bestimmten Grund für diesen Code im Skript?

Code Auswählen Erweitern


# ignoring Devices that were just created by autocreate
  #if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  #{
  #  Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
  #  return;
  #}


Ich habe den jetzt auskommentiert, da meine Devices mit HM_ anfangen.
Diese "Sicherheitsüberprüfung" verstehe ich allerdings nicht und sie macht das Modul schwere verständlich für neue Benutzer.

lg darkT