Batteriestatus und Speicherung des letzten Wechsel

[_fhemuser_]

Hallo,

gibt es jetzt zwei verschiedene Module für die Batterieprüfung?

Im ersten Posting ist 99_BatteryCheckUtils.pm und 2 Posts oberhalb 99_Battercheck.pm.

Eingerichtet werden beide gleich wie im ersten Post beschrieben oder gibt es Unterschiede?

Kann man noch zusätzlich den BatterieTyp mit übermitteln?

Ich habe bei allen Geräten eine Userattr BatteryTyp angelgt in dem der Batterietyp zB 2 x AA eingefügt ist.


Gruß
_fhemuser_

[Prof. Dr. Peter Henning]

Ich denke, eine Klarstellung ist nötig.

99_BatteryCheck.pm ist kein FHEM-Modul, sondern eine sehr nützliche Sammlung von Hilfsfunktionen, die verschiedene FHEM-Devices miteinander verknüpfen**.

Der Dateiname beginnt mit 99, das bedeutet, dass diese Sammlung beim Start von FHEM automatisch mit eingelesen wird.

Diese Hilfsfunktionen kann man auch in anderem Kontext verwenden, beispielsweise überwache ich meinen Batteriezoo seit etlichen Jahren mit readingsGroup (so, wie das hier auch gedacht ist) und monitoring (das sind beides FHEM-Module).

LG

pah


**:Das ist, die Nebenbemerkung sei mir nach zwei Büchern über das Thema erlaubt, der eigentliche Vorteil von FHEM gegenüber vielen anderen Systemen, die modernere Programmiersprachen verwenden.

[MadMax-FHEM]

Hallo,

gibt es jetzt zwei verschiedene Module für die Batterieprüfung?

Im ersten Posting ist 99_BatteryCheckUtils.pm und 2 Posts oberhalb 99_Battercheck.pm.

Eingerichtet werden beide gleich wie im ersten Post beschrieben oder gibt es Unterschiede?

Kann man noch zusätzlich den BatterieTyp mit übermitteln?

Ich habe bei allen Geräten eine Userattr BatteryTyp angelgt in dem der Batterietyp zB 2 x AA eingefügt ist.


Gruß
_fhemuser_

Wie pah ausgeführt hat: wir befinden uns in Code-Schnipsel

Da ich hier nur versuche "Fehler" zu beheben bzw. neue Device-Typen versuche einzupflegen und auch andere Erweiterungswünsche versuche einzubauen...
...habe ich halt einzwas aus git genommen und mich daran weiterversucht  

Ob es Unterschiede gibt und wenn welche: keine Ahnung, müsste man den TE fragen...

Ja, ich habe bei mir auch so ein Attribut für den Batterie-Typ
Ist aber alles sehr speziell und ich mache darüber auch eine autom. "Entnahme" aus meinem Batterie-Vorrat aber dabei muss eben alles zusammenpassen...

Ich kann das mit der Übermittlung mal versuchen einzubauen.
Wenn es kein userattr beim Device gibt, dann wird (wie jetzt auch) nix übermittelt, steht was drin, nehme ich genau den "Text" der da drin steht und packe ihn mit in die Nachricht, sollte machbar sein...

Gruß, Joachim

[_fhemuser_]

Entschulldigung, dass ich die Bezeichung für Codeschnipsel, Hilfsfunktionen und Module nicht korrekt dargestellt habe.

Ich habe die Hilfsfunktionen 99_BatteryCheckUtils.pm mal entfernt sowie alle dadurch angelegten Dummys und das Notify.

Dann die 99_Batterycheck.pm kopiert, 1-2 Änderungen am TelegramBot durchgeführt, damit es zu meinem System passt. Die 99_Batterycheck.pm geladen und mit {BatteryStart()} die Dummys und Notify neu angelegt.

Soweit passt alles. Alle Batterien sind voll und es gab noch keine Meldungen.

In jedem batteriebetriebenen Gerät steht unter UserReadings ', BatteryTyp {"CR2032"}', sowie evtl andere Berechnungen. zB erzeuge ich zusätzlich ein BatteryPer das die Prozentzahl enthält abhängig vom Gerätetyp. Mir gefiel das Durcheinander nicht, dass teilweise Prozente, teilweise OK, teilweise Spannungen, voll oder OK angezeigt werden. Dadurch konnte ich mit ReadingGroups und DOIF eine einfache Übersicht und Alarmierung erhalten.

Gruß
_fhemuser_

[MadMax-FHEM]

In jedem batteriebetriebenen Gerät steht unter UserReadings ', BatteryTyp {"CR2032"}', sowie evtl andere Berechnungen. zB erzeuge ich zusätzlich ein BatteryPer das die Prozentzahl enthält abhängig vom Gerätetyp. Mir gefiel das Durcheinander nicht, dass teilweise Prozente, teilweise OK, teilweise Spannungen, voll oder OK angezeigt werden. Dadurch konnte ich mit ReadingGroups und DOIF eine einfache Übersicht und Alarmierung erhalten.

In dem angelegten dummy stehen dann auch pro Device die Prozente
(zumindest so der Plan   )
Allerdings bei low/ok Devices halt nur 0%/100%

Daraus "bedient" sich dann die readingsGroup...


userReadings BatteryTyp ODER userattr BatteryTyp?

Ich habe dafür (weil es ja eine Konfiguration ist, die man 1x pro Device macht) ein userattr, Beispiel:

Devicename userattr my_batteryType
Devicename my_batteryType 2xAA

Das mit userattr würde ich evtl. ins Modul einbauen.
Das userattr muss dann entweder global oder pro Device wo es gebraucht wird ergänzt werden (selbst!) und den Wert nat. auch selbst füllen...

Das dann in den Meldungstext einbauen kann ich ja dann machen: wenn es das Attribut gibt (Name wird zu Beginn der Datei festgelegt, wie andere Dinge auch), dann wird der Inhalt dazugebastelt, wenn nicht, dann nicht

Gruß, Joachim

[_fhemuser_]

In jedem batteriebetriebenen Gerät steht unter UserReadings ', BatteryTyp {"CR2032"}', sowie evtl andere Berechnungen. zB erzeuge ich zusätzlich ein BatteryPer das die Prozentzahl enthält abhängig vom Gerätetyp. Mir gefiel das Durcheinander nicht, dass teilweise Prozente, teilweise OK, teilweise Spannungen, voll oder OK angezeigt werden. Dadurch konnte ich mit ReadingGroups und DOIF eine einfache Übersicht und Alarmierung erhalten.

In dem angelegten dummy stehen dann auch pro Device die Prozente
(zumindest so der Plan   )
Allerdings bei low/ok Devices halt nur 0%/100%

Ähnlich habe ich das mit den userReadings bei den MAX Thermostaten gelöst:

Code Auswählen Erweitern

batteryPer {if
(ReadingsVal($NAME,"batteryState","") eq "ok") {return 100} elsif
(ReadingsVal($NAME,"batteryState","") eq "low") {return 1} else
{return -1}}, BatteryTyp {"2 x AA"}
Daraus "bedient" sich dann die readingsGroup...

userReadings BatteryTyp ODER userattr BatteryTyp?

Ich habe dafür (weil es ja eine Konfiguration ist, die man 1x pro Device macht) ein userattr, Beispiel:

Devicename userattr my_batteryType
Devicename my_batteryType 2xAA

Mir ist bislang der Unterschied zwischen userReadings und userattr gar nicht aufgefallen

Das mit userattr würde ich evtl. ins Modul einbauen.
Das userattr muss dann entweder global oder pro Device wo es gebraucht wird ergänzt werden (selbst!) und den Wert nat. auch selbst füllen...

Das dann in den Meldungstext einbauen kann ich ja dann machen: wenn es das Attribut gibt (Name wird zu Beginn der Datei festgelegt, wie andere Dinge auch), dann wird der Inhalt dazugebastelt, wenn nicht, dann nicht

Gruß, Joachim

Ich kann natürlich von userReadings auf userattr umstellen. Das würde wahrscheinlcih FHEM auch beschleunigen da weniger gerechnet und geändert wird.

Vielen Dank für die Hilfen.

Gruß
_fhemuser_

[MadMax-FHEM]

Readings (auch userReadings-Readings) sind (wie du ja selbst angemerkt hast   ) dynamische Werte...

Attribute (auch userattr-Attribute) sind eher statische Werte oder auch "Konfiguration" von Devices (so sehe ich das)...

Bei der Änderung von Attributen landen diese bei save in der cfg

Readings bei safe(statefile) im state-File

BatteryTyp {"2 x AA"}

Naja: es wird bei JEDEM Event des Devices getriggert (kein Trigger angegeben) und setzt jedesmal das Reading auf einen gleichbleibende Zeichenkette
Ist verm. nicht der Performance-Killer aber notwendig auch nicht

Bei Gelegenheit baue ich das mit dem Attribut und Batterie-Typ mal ein...
EDIT: muss ja keiner nutzen

Gruß, Joachim

[enno]

Moin Joachim,

Bei Gelegenheit baue ich das mit dem Attribut und Batterie-Typ mal ein...
EDIT: muss ja keiner nutzen

Finde ich eine gute Idee, ich habe diese Informationen zur Zeit noch in den Readings, aber in userattr-Attribute ist ja schnell geändert.

Gruss
  Enno

[_fhemuser_]

Ich habe alle Einträge unter userReadings geändert, die Readings gelöscht und als userattr angelegt 

Dabei ist mir aufgefallen, dass etliche Geräte noch fehlen. Sie werden wahrscheinlich erfasst, sobald Daten gesendet werden.

Einige Geräte sind "doppelt" vorhanden. ZB die HUE Bewegungssensoren werden als 3 Geräte eingerichtet um die Helligkeit, Bewegung und Temperatur zu übertragen. Wie kann man solche Einträge verhindern?

Dann habe ich noch einige Funkschalter die nur selten benutzt werden und bei denen die Batterie entfernt ist. Wie können diese ausgeschlossen werden? Eine Blacklst oder Whitelist gibt es ja bei den Dummy und Notify nicht.

Gruß
_fhemuser_

[MadMax-FHEM]

Einige Geräte sind "doppelt" vorhanden. ZB die HUE Bewegungssensoren werden als 3 Geräte eingerichtet um die Helligkeit, Bewegung und Temperatur zu übertragen. Wie kann man solche Einträge verhindern?

Dann habe ich noch einige Funkschalter die nur selten benutzt werden und bei denen die Batterie entfernt ist. Wie können diese ausgeschlossen werden? Eine Blacklst oder Whitelist gibt es ja bei den Dummy und Notify nicht.

Naja um möglichst andere Anwender nicht zu "stören" (also Verhalten möglichst lassen wie es ist für alle aktuellen Nutzer), wäre mein Vorschlag ebenfalls ein weiteres userattr zu spendieren?
Sowas wie: doNotAccount (oder so) / wobei: Namen kann jeder selber wählen und dann entsprechend oben in die Datei eintragen

Wenn das Attribut existiert bzw. besser wenn es gesetzt ist: 1 dann wird das Device nicht beachtet...

Eine Whitelist/Blacklist ginge auch: oben in der Datei ein Array mit den Devicenamen (die beachtet werden sollen: whitelist / oder eben nicht beachtet werden sollen: blacklist)

Was wäre besser?
EDIT: Attribut ist einfacher

Gruß, Joachim

[_fhemuser_]

Naja um möglichst andere Anwender nicht zu "stören" (also Verhalten möglichst lassen wie es ist für alle aktuellen Nutzer), wäre mein Vorschlag ebenfalls ein weiteres userattr zu spendieren?
Sowas wie: doNotAccount (oder so) / wobei: Namen kann jeder selber wählen und dann entsprechend oben in die Datei eintragen

Wenn das Attribut existiert bzw. besser wenn es gesetzt ist: 1 dann wird das Device nicht beachtet...

Eine Whitelist/Blacklist ginge auch: oben in der Datei ein Array mit den Devicenamen (die beachtet werden sollen: whitelist / oder eben nicht beachtet werden sollen: blacklist)

Was wäre besser?

Gruß, Joachim

Ich finde eine Lösung ohne an der 99_Batterycheck.pm Änderungen im Betrieb duchzuführen besser. Wenn es ein Dateiupdate gibt, müssten alle manuellen Änderungen wieder durchgeführt werden. Dabei fällt bestimmt einiges heraus.

Also eine automatische Erkennung wie es das Notify macht wäre optimal. Dh ich favorisiere die Lösung mit den userattr. Da das Attribut neu gesetzt werden muss, kann man den Namen nehmen den du in die Datei schreibst.

Ich durchblicke die ganze Funktion im Hintergrund noch nicht. Es scheint dass über das Notify, das auf .*:battery.* horcht, die Routine(sub) {BatteryStatusFunction($NAME, $EVENT)} aufgerufen wird. Diese befindet sich in der 99_Batterycheck.pm.
Die Rückgabewerte werden in den Dummys abgelegt und falls erforderlich auch über Telegram eine Nachricht versendet.

[edit]
Kann vielleicht in FHEM eine Konfiguration hinterlegt werden bei denen Änderunge zb für die gracetime eingetragen werden. Damit müsste die Datei bei einem Update nicht geändert werden.
[/edit]

Gruß
_fhemuser_

[MadMax-FHEM]

Kann vielleicht in FHEM eine Konfiguration hinterlegt werden bei denen Änderunge zb für die gracetime eingetragen werden. Damit müsste die Datei bei einem Update nicht geändert werden.

Naja, man könnte einen "Config-dummy" anlegen und dort alle Angaben hinterlegen...

Jetzt schaue ich erst mal bzgl. der beiden Attribute: batteryType und doNotAccount

Gruß, Joachim

[TK67]

Hallo,
habe da noch eine Ergänzung für die sub BatteryStart()
Dient zur Vorbelegung von Geräten mit "batteryPercent" beim ersten Start.
Habe den Block nach dem Block #Set Readings for device with reading batteryLevel eingefügt:

Code Auswählen Erweitern

#Set Readings for device with reading batteryPercent
 my @bat_p = devspec2array("batteryPercent=.*");
 for(my $x=0;$x<@bat_p;$x++)
 {
my $stat_p = ReadingsVal($bat_p[$x],"batteryPercent","undef");
if($stat_p ne "undef")
{
BatteryStatusFunction($bat_p[$x],"batteryPercent: $stat_p");
}
 }
 
Gruß TK67

[MadMax-FHEM]

Hallo,
habe da noch eine Ergänzung für die sub BatteryStart()
Dient zur Vorbelegung von Geräten mit "batteryPercent" beim ersten Start.
Habe den Block nach dem Block #Set Readings for device with reading batteryLevel eingefügt:

Code Auswählen Erweitern

#Set Readings for device with reading batteryPercent
 my @bat_p = devspec2array("batteryPercent=.*");
 for(my $x=0;$x<@bat_p;$x++)
 {
my $stat_p = ReadingsVal($bat_p[$x],"batteryPercent","undef");
if($stat_p ne "undef")
{
BatteryStatusFunction($bat_p[$x],"batteryPercent: $stat_p");
}
 }
 
Gruß TK67

Hab ich eingebaut

Ebenso die beiden userattr

Folgendes muss bei jedem Device (wo benötigt/gewünscht) getan werden (oder 1x in global erweitert werden):

Code Auswählen Erweitern

attr Device userattr batteryType doNotAccount
Beide userattr oder nur eins davon...

Danach können die Attribute dann beim Device gesetzt werden, z.B.:

Code Auswählen Erweitern

attr Device doNotAccount 1
attr Device batteryType 2xAA

Die Namen der Attribute können geändert werden, dazu dann entsprechend in der Datei oben anpassen.
Bei doNotAccount ist egal was gesetzt wird, sobald es "da" ist, wird das Device "ignoriert" (oder sollte ich 1 und 0 nehmen?)

Wird das Attribut batteryType gesetzt, wird was immer dort drin steht zusätzlich ausgegeben...

Beispiel:

Die Batterien vom Typ 2xAA von Device sollten bald gewechselt werden!

Gruß, Joachim

[TK67]

Danke Joachim, das ging ja richtig fix 

Habe noch ein paar kleine Ergänzungen:
Meine Hue Bewegungsmelder und der Hue Dimmschalter haben jeweils battery und batteryPercent als Readings, dies führte teilweise zu unplausiblen Zuständen.
Habe deshalb die Zeile im Block HM Devices with battery

Code Auswählen Erweitern

if($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef")ergänzt

Code Auswählen Erweitern

if($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef" && $TYPE ne "HUEDevice")

Damit auch meine Withings Geräte eingebunden werden im Block ZWave and HUEDevice Devices and FBDECT ergänzt:

Code Auswählen Erweitern

elsif($BatteryType[0] eq "batteryPercent"  && ($TYPE eq "ZWave" || $TYPE eq "HUEDevice" || $TYPE eq "FBDECT" || $TYPE eq "MQTT2_DEVICE"))
mit

Code Auswählen Erweitern

elsif($BatteryType[0] eq "batteryPercent"  && ($TYPE eq "ZWave" || $TYPE eq "HUEDevice" || $TYPE eq "FBDECT" || $TYPE eq "MQTT2_DEVICE" || $TYPE eq "withings"))

Wäre nett wenn du das auch noch anhängen kannst.


Gruß TK67