Batteriestatus und Speicherung des letzten Wechsel

[MadMax-FHEM]

Ich hab was gefunden, mal sehen

Und weil ich dabei war auch gleich noch was gefunden (fand ich schon gleich komisch aber hatte ich ja nur übernommen [ohne Test ]):

Code Auswählen Erweitern

    my $msg = "set TelegramBot message \@\@User ";
muss eigentlich nur 1x escaped werden, zumindest hat es so bei einem Schnelltest geklappt:

Code Auswählen Erweitern

    my $msg = "set TelegramBot message \@User ";

Neue Version als Anhang...
Neue und nochmals korrigierte Version (20240215_02) angehangen, siehe Folgeantworten...

Gruß, Joachim

[Funsailor]

Hallo Joachim,
danke für die schnelle Hilfe, aber im Eifer des Gefechtes hast du die "Text_soon" Meldungen vergessen.
Nachdem ich dort die zweiten escape Zeichen entfernt habe bekome ich die Meldung

Die Batterien von OG_BueroThermostat sollten bald gewechselt werden!

Aufs Handy!! 

[MadMax-FHEM]

Ja, da hast du natürlich Recht!

Hab's geändert und oben neu angehangen...

Danke, Joachim

[Funsailor]

Hi Joachim,
der Batteriewechsel wurde leider nicht festgehalten.
Ich habe die Batterien entfernt und den Level gesetzt
setreading OG_BueroThermostat batteryLevel 1.3
In der Anzeige rgBatteryStatus warein leeres rotes Kästchen zu sehen...
Nachdem ich neue Batterien eingelegt habe, wird das voll Symbol angezeigt, der Batteriewechsel wird aber nicht festgehalten.....
Irgendwo habe ich dazu mal etwas gelsen, finde es aber nicht mehr.
Hast du einen Tipp?
Danke
Michael

Upps,
hatte bei den vorherigen Wechsel "angeknabberte" Batterien verwendet, die haben nur 2,6V gebracht und da wurde der Batteriewchsel scheinbar nicht erkannt...
Mit richtig vollen Batterien hat es funktioniert!

[MadMax-FHEM]

Ja, die Batteriewechselerkennung funktioniert nur von leer (1x) nok oder unter 25% (glaube ich) auf voll...

Ansonsten wäre es ja kein Wechsel wg. leerer Batterien...

Meine Freundin tendiert auch dazu zu wechseln, wenn auch nur Rot angezeigt wird, das ist oft auch zu früh für die Erkennung...

Bei Prozentangaben bzw. Spannungswerten könnte man einbauen, dass man sich den alten Wert merkt und wenn es dann deutlich mehr ist, auch von einem Wechsel ausgeht...

Bei nok/ok bleibt nichts anderes...

Gruß, Joachim

[Funsailor]

Hallo Joachim,
ich denke so wie es reagiert ist es OK.... Das ist bei mir beim Testen aufgetreten, normalerweise werden "volle" Batterien eingesetzt 😉

[weini]

Hallo zusammen!

Ich habe BatteryCheckUtils jetzt seit ein paar Wochen im Einsatz und muss sagen, dass sie echt Vorteile ggü. meiner alten DOIF Logik hat.
Was ich aber vermisse, ist eine "Grace Period", wenn der Status auf "low" geht. Ich nutze Außentemperaturfühler von Pearl (NC-7159), dich ich als CUL_TCM97001 mit model=NC_WS in FHEM einbinde.
Im Perl-Code have ich Zeile 295 so angepasst

Code Auswählen Erweitern

  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX" || $TYPE eq "CUL_TCM97001")),
dass neben den Max Devices auch diese Temperaturfühler verarbeitet werden.

Nun senden die aber die ersten Battery=low Warnungen schon, wenn die Batterie noch recht gut ist. Der Status springt nach ein paar Sekunden oder Minuten wieder auf "ok" zurück. Trotzdem löst natürlich die Alarmierung aus. In meiner alten DOIF Lösung hatte ich mir da mit einem simplen "wait" geholfen, so dass der Alarm erst ausgelöst wurde, wenn der Status für mindestens 5 Minuten auf "low" geblieben ist.

Wäre es möglich, etwas vergleichares in BatteryCheckUtils zu integrieren?
Alternativ würde ich ggf. den Status mit einem DOIF & wait selbst für die Alarmierung überwachen. Gehe ich damit besser auf das "BatterieStatus" oder auf das "BatterieStatusBot" Device los?

VG,
weini

[MadMax-FHEM]

Ich nutze Außentemperaturfühler von Pearl (NC-7159), dich ich als CUL_TCM97001 mit model=NC_WS in FHEM einbinde.
Im Perl-Code have ich Zeile 295 so angepasst
Code Auswählen Erweitern

Code Auswählen Erweitern

  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX" || $TYPE eq "CUL_TCM97001")),
dass neben den Max Devices auch diese Temperaturfühler verarbeitet werden.

Danke, nehme ich bei Gelegenheit mit auf...

Nun senden die aber die ersten Battery=low Warnungen schon, wenn die Batterie noch recht gut ist. Der Status springt nach ein paar Sekunden oder Minuten wieder auf "ok" zurück. Trotzdem löst natürlich die Alarmierung aus. In meiner alten DOIF Lösung hatte ich mir da mit einem simplen "wait" geholfen, so dass der Alarm erst ausgelöst wurde, wenn der Status für mindestens 5 Minuten auf "low" geblieben ist.

Wäre es möglich, etwas vergleichares in BatteryCheckUtils zu integrieren?

Muss ich mir ansehen.

Alternativ würde ich ggf. den Status mit einem DOIF & wait selbst für die Alarmierung überwachen. Gehe ich damit besser auf das "BatterieStatus" oder auf das "BatterieStatusBot" Device los?

Wenn dann verm. BatterieStatus, dort stehen ja die aktuellen Batteriestände der "gematchten" Devices "in Kopie" drin.

In BatterieStatusBot wird sich ja bereits gemerkt, ob es eine Nachricht gab...

Soweit ich das jetzt auswendig im Kopf habe...


Frage: lieber schon mal eine Nachricht beim ersten "low" und dann keine erneute Nachricht (für eine bestimmte Zeit) oder erst eine Nachricht, wenn eine bestimmte Zeit "stabil" low war/ist?

Gruß, Joachim

[weini]

Frage: lieber schon mal eine Nachricht beim ersten "low" und dann keine erneute Nachricht (für eine bestimmte Zeit) oder erst eine Nachricht, wenn eine bestimmte Zeit "stabil" low war/ist?

Aus meiner Sicht klar die zweite Variante. Der Außenfühler geht z. B. auch gerne mal kältebedingt auf "low", läuft dann aber noch Monate lang.

[MadMax-FHEM]

Aus meiner Sicht klar die zweite Variante. Der Außenfühler geht z. B. auch gerne mal kältebedingt auf "low", läuft dann aber noch Monate lang.

Ja, dachte ich mir

Ich schau mal...

Gruß, Joachim

[Prof. Dr. Peter Henning]

Könnt Ihr bitte mal schreiben, wo der genannte Code auf diesen X Seiten steckt? Oder das mal zusammengefasst hier posten?

LG

pah

[TomLee]

Hallo,

les nur mit einem halb geschlossenen Auge mit, nur acht Beiträge vorher steht schon der Hinweis das die letzte Änderung oben_angehangen_wurde, oben ist dann auch gleich 2 Beiträge davor.

Thomas

[MadMax-FHEM]

Könnt Ihr bitte mal schreiben, wo der genannte Code auf diesen X Seiten steckt? Oder das mal zusammengefasst hier posten?

LG

pah

Problem: ich habe mal irgendwo meinen Code gepostet oder erläutert wie ich das mache...

Wurde vom TE übernommen und liegt unverändert (soweit ich das gesehen habe) auf git...

Allerdings kamen dann Erweiterungen und Anpassungen (auch von mir) und damit ist es schwer (für mich) im ersten Post zu editieren usw.

Was also am besten tun?

EDIT: werde zunächst mal die Erweiterung des neuen Typs einpflegen und evtl. auch bzgl. den "Wackelsensoren" schauen und dann hier (ganz unten) posten...

Gruß, Joachim

[MadMax-FHEM]

So, ich hab hier mal eine neue Version angehangen mit dem neuen Geräte-Typ und der grace period...

Oben in der Datei kann (wie die anderen Einstellungen auch) die grace period angegeben werden:

  my $GracePeriod = 0; # seconds that a low status has to be notified until it is taken granted

Ablauf:

1. mal überhaupt -> status wird gemerkt

danach:

bei ok -> passiert nichts (außer dass ok gemerkt wird)

bei low -> low wird gemerkt bzw. geprüft, ob bereits GracePeriod abgelaufen


Wichtig: es müssen immer wieder ok/low Events kommen sonst kommt die Meldung nie (klar ), wenn GracePeriod > 0. D.h. mit event-on-change-reading aufpassen...

Die Batterieanzeige low und Nachricht kommen frühestens beim nächsten "low Event" der NACH GracePeriod Sekunden kommt. Also nicht genau nach GracePeriod Sekunden.
Ich hoffe es funktioniert und ist ok so...

Ist/bleibt GracePeriod auf 0, so sollte das Verhalten wie vorher sein...

Gruß, Joachim

[weini]

Wow, das war schnell!
Ich teste und gebe Feedback.

VG,
weini