Batteriestatus und Speicherung des letzten Wechsel

Begonnen von Amenophis86, 12 Januar 2018, 19:23:20

Vorheriges Thema - Nächstes Thema

Amenophis86

Der User MadMax-FHEM hat dankenswerterweise hier seinen Code geteilt. Dieser soll den User informieren, sobald eine Batterie leer ist, oder sich dahingehend nähert. Weiterhin soll das skript auch automatisch einen Batteriewechsel erkennen und vermerken.

Aktuell gibt es zwei Versionen der Scripte. Beide sind auf github zu finden: https://github.com/Amenophis86/Batteryfunktion

  • Master-Zweig
  • no-BatteryStatusBot-Zweig

Der Master-Zweig ist aktuell am auslaufen und wird nicht weiter bearbeitet werden. Die Skripte sind aber noch vollfunktionsfähig.
Der no-BatteryStatusBot-Zweig wird aktuell weiter entwickelt. Hier der Stand für diesen:

1. [BatterieStatus] Ein Dummy, in welchem die aktuellen Prozente der Batterie festgehalten werden (dient der ReadingsGroup Ansicht)
2. [rgBatterieStatus] Eine ReadingsGroup, welche den aktuellen Status der Batterie als Icon darstellt
3. [BatterieWechsel] Ein Dummy, welcher automatisch für gewechselte Batterien ein Reading anlegt
4. Das Script verschickt eine Nachricht, sobald der Status einer Batterie 25% erreicht, oder leer meldet

Um das Script zu erhalten muss wie folgt vorgegangen werden:
1. Es kann entweder direkt die PM runtergeladen, im Order /FHEM/ eingefügt und ein reload 99_BatteryCheckUtils.pm ausgeführt werden, oder der Code kopiert und in die eigene 99_BatteryCheckUtils.pm eingefügt werden.
2. Werte entsprechend anpassen (Siehe weiter unten)
3. Einmalig die Funktion BatteryStart mittels {BatteryStart()}ausführen.


Aktuell sind folgende Änderungen direkt in der Funktion verfügbar:
BatteryStatusFunction:

###############################
# Here you can change the variables to fit your installation.
#
  my $text_now = "Die Batterien von $Device müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien von $Device sollten bald gewechselt werden!"; #Text for changing battery soon
  my $text_motorErrValve = "Der Motor kann sich nicht mehr bewegen!"; #Text for motorErr ValveErrorPosition only HM
  my $text_changed = "Batterie zuletzt gewechselt: "; #Text for last change
  my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
  my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information
 
###############################
# Here you can change the times for the temp-at and waittime for the reduction of 5% steps

  my $FivePercent_HM = 600;
  my $TempAt_HM = 43200;
  my $FivePercent_Max = 600;
  my $TempAt_Max = 43200;
  my $FivePercent_Xiaomi = 600;
  my $TempAt_Xiaomi = 43200;
  my $FivePercent_ZWave = 600;
  my $TempAt_ZWave = 600;
  my $FivePercent_LaCrosse = 600;
  my $TempAt_LaCrosse = 43200;
  my $FivePercent_Other = 600;
  my $TempAt_Other = 43200;

Dieser Teil kann und sollte angepasst werden. Im ersten Teil könnt ihr den Text ändern, welcher auch zugeschickt wird. Weiterhin müssen die Namen der Dummies aus der Funktion BatteryStart passen.

$FivePercent_:
Manche Device haben die Angewohnheit, dass sie zwischen low und ok wechseln. Daher prüft das Skript, wann der %-Wert der Battery zuletzt verändert wurde ($FivePercent_). Erst, wenn dieser Wert überschritten wurde wird der %-Wert weiter um 5% verringert. Natürlich gilt das nur für Device, welche lediglich mit dem Reading Battery und nicht mit BatterLevel arbeiten. Die vorgegeben Werte sind noch nicht erprobt und lediglich geschätzt.

$TempAt_:
Jedesmal, wenn ein Device low meldet wird ein temporäres At gestartet. Diese wird wieder gelöscht, sollte das Gerät zwischendurch wieder ein ok melden. Passiert dies nicht wird nach der angegeben Zeit (in Sekunden) das Event "dead" generiert. Damit wird die letzte Meldung der Berechnung abgegeben und das Gerät als leer bezeichnet.

Ein Beispiel:
Unser HM Fensterkontakt hat nur das Reading Battery mit low und ok. Nun fängt die Batterie an zu schwächeln. In unregelmäßigen Abständen wird zwischen low und ok gewechselt.
$FivePercent_HM steht auf 600. Meldet das Gerät mal wieder low und die letzte Änderung des Readings Battery ist länger als 10 Minunten (600 Sekunden) wird der %-Wert für dieses Gerät um 5% verringert. Beim ersten Mal wechselt er also von 100 auf 95%. Das geht nun immer so weiter, bis der Wert 25% erreicht hat. Nun wird die Meldung im String $text_soon an den Nutzer gesendet.
Wechselt der Kontakt nicht mehr zwischen low und ok hin und her, sondern bleibt schlussendlich bei low und $TempAt_HM steht auf 43200 Sekunden (=12 Stunden) kommt nach 12 Stunden die Meldung aus dem String $text_now. Wichtig, diese Berechnung findet nur bei Geräten statt, welche NICHT das Reading BatteryLevel haben. Sobald dieses vorhanden ist, wird hieraus der Wert berechnet. Dazu kann die Variable $MaxBattery = 3.1 angepasst werden. Aktuell wird noch davon ausgegangen, dass alle Geräte mit BatterLevel mit 2xAA Batterien betrieben werden und somit der Wert bei neuen Batterien bei ca. 3.1V liegen müsste.


Nun wechselt der User die Batterie am Gerät. Dieses sendet wieder ok und das System erkennt, dass ein Batteriewechsel stattgefunden hat. Voraussetzung hierfür ist aktuell, dass der %-Wert kleiner oder gleich 25% gewesen sein muss. Sollte man Probleme haben und nicht unter diesen Wert kommen, kann man entweder das Skript entsprechend anpassen oder die attr event-on-... entsprechend ändern, dass das Reading Battery weiterhin ein Event erzeugt. Vermutlich müssen dann auch die Zeiten für $FivePercent_ angepasst werden.

Nachrichtenübermittlung:
################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
  my $msg = "set TelegramBot message \@\@User ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";

Es kann eingestellt werden auf welchem weg die Nachricht gesendet werden soll. Dazu muss der entsprechende Teil unkommentiert gesetzt werden. Vorbelegt ist Telegram. Hier muss lediglich das Wort "User" durch den TelegramNamen des Empfängers geändert werden.



BatteryStart:
#Define Dummys for script
my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information
my $ReadingsGroup = "rgBatterieStatus"; #Name of the ReadingsGroup
my $Room = "Z_System->BatteryCheck"; #room for the dummys
my $Notify = "NO.BatterieNotify"; #Name of the Notify for sending battery information

Hier werden die Namen für die Dummies und die ReadingsGroupe gesetzt. Wichtig ist, dass die Namen zu den Namen in der ersten Funktion passen. Weiterhin kann man einen Raum ($Room) hinterlegen in welchem automatisch alle Device erstellt werden. Unter $Notify wird der Name für die Notify-Funktion angegeben.


Aktuell werden folgende Typen individuell unterstützt:
- Homematic
- Z-Wave
- Xiamoi
- MAX!
- LaCrosse

Alle anderen Geräte mit der Meldung ok/low oder BatteryLevel werden erkannt und unterstützt, es kann jedoch nur eine Zeit für all diese Geräte gleichzeitig gesetzt werden. Wenn bedarf für weitere Geräte besteht dies bitte mitteilen.



Wichtig
Homematic Device dürfen nicht mit HM_ benannt sein, gleiches gilt für Z-Wave: ZWave_ und MAX: MAX_ da diese sonst ignoriert werden. Die Idee ist, dass diese neu angelegt wurden und daher noch keine Batterieprüfung nötig ist. Sollte jemand seine Geräte entsprechende benannt haben, so muss dieser Teil im Code auskommentiert werden:

# 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;
  }
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Wzut

#1
schön :)
aaaber schau nochmal nach den Blumen ( ich habe sie rausgeworfen da ich keine habe )
syntax error at ./FHEM/99_myUtils.pm line 371, near "XiaomiFlowerSens Devices ############################################# elsif" syntax error at ./FHEM/99_myUtils.pm line 436, near "}" Can't use global @_ in "my" at ./FHEM/99_myUtils.pm line 443, near "= @_" Global symbol "$Value" requires explicit package name (did you forget to declare "my $Value"?) at ./FHEM/99_myUtils.pm line 444. syntax error at ./FHEM/99_myUtils.pm line 472, near "}" Can't redeclare "my" in "my" at ./FHEM/99_myUtils.pm line 481, near "" syntax error at ./FHEM/99_myUtils.pm line 515, near ") }"
da fehlt oben das # vor  XiaomiFlowerSens Devices

und bei HM muss die VCCU noch raus ... meine hat keine Batterie :)
Wenn du eh noch LaCrosse machen möchtest schaue ich mal nach einem Block für MAX!

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

#2
Für MAX! Geräte muss oben noch eine Zeile dazu denn sie haben kein Attribut model :
my $TYPE = InternalVal($Device, "TYPE", "undef"); # MAX!
und dann ein copy & paste  Block

  ##############################################
  # MAX! Devices
  ##############################################
  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low")
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem("set $myTelegramBot message $text_soon");
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }


EDIT :
# ignoring Devices that were just created by autocreate
  if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave")  || $DeviceNameParts[0] eq "MAX")

 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

MadMax-FHEM

Toll wie das weiter geht!

Vielen Dank an Amenophis86 für's "Verbreiten"!

Kleine Anmerkung:

  # actually only devices HM-TC-IT-WM-W-EU and HM-CC-RT-DN have battery level and min-level

bezieht sich halt auf meinen "Flohzirkus" ;)

Wenn es weitere Geräte von HM gibt, die ebenfalls Spannungswerte liefern, dann eben den entsprechenden Typen hier hinzufügen.
Ansonsten sollten sie aber zumindest als "normale" Batterie-Geräte mit "ok/nok/low" aufgenommen werden.

Vielleicht schaffe ich es auch die Batteriehaltbarkeit mit aufzunehmen, also eine Statistik der letzten Batteriewechsel und dann eben die Lebensdauer etc.

Oder kann da eines der bestehenden Statistik-Module verwendet werden?

Gruß und viel Spaß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Amenophis86

Zitat von: Wzut am 12 Januar 2018, 20:05:20
schön :)
aaaber schau nochmal nach den Blumen ( ich habe sie rausgeworfen da ich keine habe )
Danke geändert. Ich habe sie bei mir auskommentiert und beim einkommentieren wohl ein Zeichen zu viel weggenommen.

Zitat
und bei HM muss die VCCU noch raus ... meine hat keine Batterie :)
Die taucht bei mir nicht auf. Dürfte sie auch nicht, weil sie eigentlich auch kein battery/Level Reading haben dürfte. Daher frage ich mich, wieso sie bei dir erscheint?

Deinen Max Block habe ich eingefügt.

Ich habe das ganze mal auf mein github gelegt. Habe das gerade zum ersten Mal gemacht und wenig Ahnung davon, aber das könnte es einfacher machen mit den Änderungen etc. und ich habe ein kleines Projekt mit dem ich üben kann. Hier ist der Link: https://github.com/Amenophis86/Batteryfunktion
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Wzut

Zitat von: Amenophis86 am 13 Januar 2018, 10:52:36
Daher frage ich mich, wieso sie bei dir erscheint?
--- snipp ---
Deinen Max Block habe ich eingefügt.
a. das hatte ich mich auch gefragt , werde mal auf die Suche gehen, ist ja jetzt nicht so ein tragischer Fehler

b. Mit MAX! erigibt sich leider ein anderes Problem ... ich habe z.Z. zufällig ein unbenutzes Device mit alter Batterie -> Daueranzeige seit Wochen low
und eines bei dem die Batterie so langsam an ihr Lebensende kommt. Und genau hier liegt das Problem mit den MAX! Geräten das ich so auch schon im MAX! Forum beschrieben hatte. Leider wechseln die Geräte nicht irgendwann von ok auf low und bleiben dann auf low, sondern das low verschwindet nach ein paar Minuten wieder.
Am Anfag kommt die low Meldung 1 -2 am Tag , dann im Abstand von Stunden und irgendwann bleibt sie wirklich dauerhaft auf low. Das ist dann der Zeitpunkt wo ich die Batterien tausche und mir das Wechseldatum von Hand ins Comment Attibut schreibe. Ich dachte noch oh tolll das kannst du dir in Zukunft sparen, ist aber leider nicht so, denn dadurch das die Meldung sich von selbst zurücksetzt geht der Codeschnipsel von einem manuellen Batterie Tausch aus, was aber ja nicht stimmt.
Mal schauen ob mir da was sinnvolles zu einfällt, ala Logging der Zeitstempel und deren Auswertung.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

helmut

Zitat von: Amenophis86 am 13 Januar 2018, 10:52:36
https://github.com/Amenophis86/Batteryfunktion

Ein Fluechtigkeitsfehler steht in Form einer doppelten runden schliessenden Klammer in Zeile 51.

Das Projekt interessiert mich wegen des Zusatznutzens von "BatterieWechsel" und gegebenenfalls
"Batteriehaltbarkeit". Allerdings werde ich es fuer meine Zwecke anpassen da ich mich zur Zeit
per E-Mail und Signal mittels eines Notifys fuer Batterien mit Zustand "low" benachrichtigen lasse.

Signal durch Telegram zu ersetzen waere durchaus eine Ueberlegung wert; auf die Benachrichtigung
per E-Mail will ich aber nicht verzichten.

Gruss Helmut
Intelligenz ist die Fähigkeit, Arbeit zu vermeiden, aber dafür zu sorgen, daß die Arbeit gemacht wird.
(Linus Torvalds)

Amenophis86

@Wuzt ich überlege auch mal
@helmut einbauen, dass man auf verschiedenen Wegen verschickt ist ja nicht so schwer. Gerade mit dem msg Befehl zB. Aber auch im Script könnte man eine Auswahl setzen.

Den Fehler schaue ich mir später an, bin die Tage unterwegs.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Amenophis86

#8
@Wzut:
Zum Verständnis nochmal für mich. MAX wechselt immer wieder den Status zwischen low und ok und bleibt dann irgendwann bei low. Wie lange das dauert ist nicht klar, oder? Von der Idee her müsste man quasi eine Verzögerung für MAX einbauen, also einen Zwischenspeicher in dem der letzte Wechsel auf low steht und die Meldung, so wie ein Batterie tausch erst einstellen, wenn ein gewisser Zeitstempel überschritten wurde. Dabei sehe ich folgende Probleme:
1. Wenn jemand direkt beim ersten low die Batterie wechselt würde das Script das nicht erkenne
2. Wie lange muss man warten bis es bei low bleibt

Hast du mal mit dem Maintainer des MAX Moduls gesprochen woran es liegt, dass der Status gegen Ende immer wechselt? Sendet das Gerät immer wieder andere Signale und wieso wird es nicht direkt dort abgefangen? Habe mal in den Quellcode geschaut, aber werde nicht schlau draus. Fehlt mir wohl die Doku der MAX Signale zu.

Edit:
@Wzut: Habe gerade deinen Beitrag im alten Thema gefunden, da hast du es ja ganz gut beschrieben. Bleibt die Frage, wie wir das Problem lösen. Ich tendiere zum warten, bis die Meldung dauerhaft bleibt.

@helmut:
Fehler habe ich korriegiert, vielen Dank. Bezüglich der verschiedenen Nachrichten sehe ich wie gesagt drei Möglichkeiten:
1. Einfach den Befehle für das Senden der Nachricht vorab definieren und die verschiedenen Geräte zu unterstützten
2. Eine eigene Routine für das Senden schreiben, finde ich sehr aufwendig und unnötig
3. Den msg befehl einbauen
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

helmut

Zitat von: Amenophis86 am 14 Januar 2018, 19:56:37
@helmut:
Fehler habe ich korriegiert, vielen Dank. Bezüglich der verschiedenen Nachrichten sehe ich wie gesagt drei Möglichkeiten:
1. Einfach den Befehle für das Senden der Nachricht vorab definieren und die verschiedenen Geräte zu unterstützten
2. Eine eigene Routine für das Senden schreiben, finde ich sehr aufwendig und unnötig
3. Den msg befehl einbauen

Nachdem ich mir den ausgesprochen maechtigen msg Befehl genauer angesehen habe halte ich
die dritte fuer die beste Loesung.

Gruss Helmut
Intelligenz ist die Fähigkeit, Arbeit zu vermeiden, aber dafür zu sorgen, daß die Arbeit gemacht wird.
(Linus Torvalds)

Wzut

@Amenophis86 , ich denke das etwas komische Verhalten der MAX! Geräte ist den e3q Entwicklern anzulasten und nicht M.Gehre als Autor der Module ( er ist hier auch nicht mehr aktiv um noch mal Rückfragen zu können)
Klar wenn der User sehr schnell auf die Batterie Warnung reagiert dann klappt das so in der jetzigen Form nicht,
allerdings Hand aufs Herz : wer springt sofort auf und wechselt ? Zumal die Meldung unmittelbar an der Warngrenze wieder relativ schnell verschwinden.

Noch eien andere Sache ist mir aufgefallen : Der Dummy BatterieWechsel sollte sich ja so nach und nach mit den Daten getauschter Batterien füllen, das tut er aber z.Z. nur bedingt ( bei MAX u.a. so nicht )
Ursache ist IMHO ein kleiner Tippfehler, du hast den Eintrag in die Readings unterschiedlich behandelt, mal mit Device Namen und mal ohne :
fhem("setreading $BatteryChanged $text_changed");
fhem("setreading $BatteryChanged $Device $text_changed");





Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

MadMax-FHEM

Original war es:

fhem("setreading $BatteryChanged $text_changed"); ;)

Evtl. kann man bei MAX! etwas mit ReadingsAge arbeiten, dazu müsste man wissen, wie lange es hin und her "flipt" bis es "stabil" bleibt...

Voraussetzung ist dann (aber das habe ich generell), dass für die Batteriewerte/Readings kein event-on-change-reading gesetzt ist...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Amenophis86

Habe mir die Doku von Max mal angesehen, da gibt es nicht viel zu Batterien. Daher legt es wohl wirklich alleine am Gerät was einfach nur low oder ok übermittelt. Denke es wird nur über ReadingsAge gehen, wie MadMax schon sagt. @wzut: kannst du grob sagen, welcher Zeitabstand zum Warten Sinn macht?

Bezüglich des Fehlers muss ich nochmal schauen, danke für den Hinweis.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Amenophis86

Zitat von: Wzut am 15 Januar 2018, 11:26:29
Noch eien andere Sache ist mir aufgefallen : Der Dummy BatterieWechsel sollte sich ja so nach und nach mit den Daten getauschter Batterien füllen, das tut er aber z.Z. nur bedingt ( bei MAX u.a. so nicht )
Ursache ist IMHO ein kleiner Tippfehler, du hast den Eintrag in die Readings unterschiedlich behandelt, mal mit Device Namen und mal ohne :
fhem("setreading $BatteryChanged $text_changed");
fhem("setreading $BatteryChanged $Device $text_changed");


Hattest du den Fehler im Code im 1. Post gesehen, oder auf github? Hab gerade mal auf github geschaut und finde den von dir angesprochenen Fehler nicht.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Wzut

#14
Ja , was sage ich zum Interval .... ich versende keine Mails bei Bat low sondern lasse mir diese Art von Meldung schon seit Jahren im TV Bild unten anzeigen.
Daher weiß ich nur was so am Abend los ist und weniger am Tag/Nacht
Fensterkontakte : Hatte ich noch nie eine low Meldung, die scheinen verdamt lang zu halten.
HT & WT : Da kommt zuerst 1 - 2 am Abend die low Meldung für 10 Min - 30 Min , meist ist dann ein paar Tage Sendepause. Danach habe ich sie jeden Abend.
Wenn sie gar nicht mehr verschwindet erbarme ich mich i.d.R. sie dann zeitnah zu tauschen, d.h. ich glaube wenn die Meldung mal 24 Stunden dauerhaft da war geht sie auch nicht mehr von alleine weg. Ich lege jetzt mal ein eigenes Filelog für die Batterien an dann kann ich in ein paar Wochen/Monaten bestimmt mehr dazu sagen.
Was man allerdings sofort machen könnte ist schon beim ersten auftreten der low Meldung die Restanzeige auf nur noch 50% setzen und die "müsste bald gewechselt" Meldung absetzen.
     
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher