Routine für regelmässigen Batteriecheck

[Adimarantis]

Vielleicht gibt es da ja schon eine Lösung, aber ich stehe immer wieder vor folgendem Problem:
- Manche Devices gehen nie auf ein "battery low" sondern stellen einfach ihren Dienst ein
- Andere betreibe ich jetzt schon ein Jahr auf "battery low", aber die Battery hält einfach weiter und es wäre schade sie vorher zu wechseln

Daher habe ich mir folgenden kleinen Batterymonitor überlegt.

Vorgehensweise: Es werden alle Devices gesucht die ein "battery" reading haben (kann man mit setreading auch hinzufügen wenn es anders heisst, da der Inhalt eigentlich egal ist).
Dann wird geschaut ob der State innerhalb eines gewissen Zeitraums geupdated wurde. Im Beispiel 24 Stunden. Gibt es kein "state" wird das "battery" reading genommen.
Um Fehlalarme auszuschliessen kann man
- Räume exkludieren (bei mir AUTOCREATE wegen der ganzen Fremd-433Mhz-Devices vom rfxtrx433)
- Devices exkludieren (z.B. mein Homematic Repeater der ein Batteryreading hat obwohl er in der Steckdose steckt)
- Devices definieren die selten verwendet werden und einen anderen Threshold (hier 1 Woche) haben - z.B. billige Fenstersensoren, wenn das Fenster selten aufgemacht wird.

Sofern was gefunden wird, gibts eine Nachricht per Instant Messenger, sofern man das z.B. einmal am Tag aus einem DOIF aufruft.

Da könnte man natürlich jetzt noch ein Modul drumbauen, aber für den Anfang erstmal nur so.

Code Auswählen Erweitern

sub scanBattery() {
my $threshold=3600*24; #Look for 24h inactive
my $threshold2=3600*24*7; #Some devices are used less
my $roomex="AUTOCREATE";
my $devex="HM_Sys_sRP_Pl_XXXXX,XM_RC_4_B_XXXX";
my $raredev="TRX_DS10A_a023";
my $report="";
foreach my $dev ( sort keys %main::defs ) {
my $name=$defs{$dev}->{NAME};
my $bat=ReadingsVal($name,"battery",undef);
my $room=AttrVal($name,"room","undefined");
next if ( $roomex =~ /.*$room.*/);
next if ( $devex =~ /.*$name.*/);
$threshold=$threshold2 if ( $raredev =~ /.*$name.*/);
if (defined $bat) {
my $age = ReadingsAge($name, "state", undef);
#If no state reading check battery instead
$age = ReadingsAge($name, "battery", undef) if !defined $age;

if (defined $age) {
if ($age>$threshold) {
my $ap=int($age/3600);
if ($ap>48) {
$ap=int($ap/24);
$ap.="d";
} else {
$ap .="h";
}
my $alias=AttrVal($name,"alias","");
$report .= "$name($alias) - Battery $bat - inactive since $ap\n";
}
} else {
$report .= "$name - Warning: no data found \n";
}
}
}
if ($report ne "") {
$report="Battery report:\n".$report;
fhem("set SignalBot send \@Joerg $report");
}
}

Gibt es sowas schon?
Gibt es Interesse an einem Modul?
Weitere Ideen um die Abfrage zu verfeiner?

Gruß,
Jörg

[LuckyDay]

Modul readingsWatcher

für jedes Device Timeout individuell einstellbar -> kein festgetackerte  Reading , so wie dir Vorschlag "battery"
sinnloses Suchen über alle Device entfällt

nur so als Idee

[Adimarantis]

Danke schonmal dafür. Schaut grundsätzlich geeignet aus, hat den Nachteil, dass ich in jedem Device erstmal das entsprechende Attribut eintragen muss. Da vergisst man gerne mal eins - besonders wenn neue dazukommen.
Den "Nachteil" dass hier hardcodiert auf "battery" losgegangen wird, könnte man bei einem Modul auch konfigurierbar machen.
Einmal am Tag über alle Devices zu gehen, sollte auch keine grosse Belastung darstellen.

Wo der readingsWatcher klar die Nase vorne hat, ist mit den individuellen timeouts.
Jetzt könnte man mein Script natürlich auch dazu umbauen, automatisiert allen "battery"-Devices das Attribut zu verpassen
Wäre natürlich auch eine Erweiterung für den readingsWatcher:

Code Auswählen Erweitern

set readingswatcher addDeviceWithName <devicename pattern> <timeout>
oder

Code Auswählen Erweitern

set readingswatcher addDeviceWithReading  <reading pattern> <timeout>

Dann würde ich einfach regelmässig ein

Code Auswählen Erweitern

set readingswatcher addDeviceWithReading battery 86400
ausführen (was natürlich bestehenden Definitionen nicht überschreiben sollte).

[Amenophis86]

Wir hatten mal was angefangen ist aber eingeschlafen bzw ich habe aktuell keine Zeit und es wird jemand gesucht der es weiterentwickelt https://forum.fhem.de/index.php/topic,82637.0.html

[Adimarantis]

Wow, das ist ja ziemlich ausgefeilt.
Grundsätzlich paar schöne Ideen drin.
Mir scheint allerdings der Ansatz ein anderer zu sein: Zuverlässig mitbekommen, wenn ein Device auf "low" Battery geht (und eben nicht nur mal kurz) - richtig?

In meinem Fall ist mir das eher egal - ich möchte die Batterien soweit möglich aufbrauchen (Umwelt und so...) und kann bei den Batterie-Devices einen Ausfall normalerweise auch mal kurzfristig ertragen - möchte es aber dennoch zeitnah mitbekommen.

[Damian]

Reicht dafür nicht ein Einzeiler?

Code Auswählen Erweitern

defmod di_batteriecheck DOIF {[18:00];;my $s=[?@:"":battery:ReadingsAge($name,"battery",0) > 3600*24,"keine"];;if ($s ne "keine") {fhem("push Folgende Sensoren sind ausgefallen $s")}}

Statt battery kann man auch eine Regex für Readingsnamen angeben, wenn das battery-Reading in verschiedenen Darstellungen vorkommt.

[Damian]

Und so sieht es z. B. aus mit Regex für verschiedene Readings:

Code Auswählen Erweitern

defmod di_batteriecheck DOIF {[18:00];;set_State([?@:"":"^[Bb]attery$":ReadingsAge($name,$reading,0) > 3600*24,"keine"]}

Und hier ein Einzeiler für jemanden, der den Inhalt von Battery-Readings abfragen möchte:

Code Auswählen Erweitern

defmod di_battery DOIF {[18:00];;set_State([?@"":"^[Bb]attery$":$_ ne "ok"],"keine")}

Die Devicenamen der betroffenen Devices stehen jeweils im Status der DOIFs, sonst steht dort "keine"

[MadMax-FHEM]

Wow, das ist ja ziemlich ausgefeilt.
Grundsätzlich paar schöne Ideen drin.
Mir scheint allerdings der Ansatz ein anderer zu sein: Zuverlässig mitbekommen, wenn ein Device auf "low" Battery geht (und eben nicht nur mal kurz) - richtig?

In meinem Fall ist mir das eher egal - ich möchte die Batterien soweit möglich aufbrauchen (Umwelt und so...) und kann bei den Batterie-Devices einen Ausfall normalerweise auch mal kurzfristig ertragen - möchte es aber dennoch zeitnah mitbekommen.

Dafür, also für die Ausfallerkennung, gibt es bei Homematic den Actiondetector.
Für andere Devices mache ich es ähnlich wie du
Bei ZWave z.B. warte ich 2 (oder 3x) die eingestellte "Meldezeit", die steht dort in einem Reading...

Allerdings ist z.B. bei den Homematic HKTs besser nicht bis zu einem Ausfall zu warten, da vorher oft die Spannung für den Motor nicht mehr reicht und sie in Fehlerstellung gehen/bleiben...

Ich verwende auch gerne Batterien "bis zum Ende"...

@Damian: das mit dem Einzeiler/Mehrzeiler mag schon gehen, ist auf alle Fälle schlank. So hatte ich mit einem notify auch mal angefangen. Aber nicht alle haben ein ok/nOK/low, sondern z.B. Prozentwerte oder Spannungswerte, die man zu Prozent umrechnen kann, um eben schon eine "Vorwarnung" geben zu können. Aber auch verschiedene Typen haben unterschiedliche "Min-Werte" usw. Zusätzlich ist noch etwas eingebaut, um eben einen hin-/her-Wechsel zwischen ok/nOK nicht zu ständigen Nachrichten zu veranlassen. Und ich habe noch eingebaut zu prüfen, ob ich passende Batterien habe und wenn nicht, wird schon bei der "Vorwarnung" mitgegeben, dass Batterien vom Typ XYZ besorgt werden müssten (ich habe einen dummy mit meinem "Batterielager" und ein userattr mit Batterietyp  ). Ebenso wird berechnet, wie lange die Batterien gehalten haben usw. Ist (leider) nicht in der veröffentlichten Version drin aber verstreut im verlinkten Thread...

EDIT: allerdings muss ich zugeben, dass der Code "schwer gewachsen" ist und wenn Anfragen bzgl. neuer Device-Typen kamen, wurde schon eher mal ein weiterer "Balkon" dran gebaut als den Code "besser" zu machen... Da kann man so einiges "vereinheitlichen" und somit deutlich "kürzen"...

Gruß, Joachim

[Damian]

ja, jeder muss da für sich eine passende Lösung finden. Meine primitiven Einzeiler, decken nur die typischen Anforderungen ab, hier insb. nach Readings suchen, die länger nicht mehr upgedatet wurden.

[Adimarantis]

@MadMax: Guter Hinweis mit den HM Motor Devices - zumindest bei den HM_CC_RT_DN habe ich das schon beobachtet.
Weiss jemand wie der Fehlerzustand in FHEM aussieht (HMCCU)? Das müsste ich auch noch abfragen. (hab gerade keins parat das ausgefallen ist). Würde mal vermuten, dass da dann ein Fehler in hmstate oder activity steht. Kurzfristig ausfallen, darf es für mich - aber ich wills zeitnah merken.

@Damian: Ist dieses Patternmatching über alle Devices ein DOIF Feature? Auf jeden Fall wieder was gelernt - schaut super elegant aus.
Aber wie du schon sagst - da hat wohl jeder seine eigenen Anforderungen und ein "one size fits all" wird schwer zu bauen sein.
Mit deiner Abfrage, wandert das ganze wohl vom myUtils einfach in ein DOIF - was ich übrigens ohnehin oft mit kleinen Perl Routinen mache.
An dieser Stelle Danke für das geniale Modul.

Auch an alle anderen Danke für die Anregungen.

[Damian]

@Damian: Ist dieses Patternmatching über alle Devices ein DOIF Feature? Auf jeden Fall wieder was gelernt - schaut super elegant aus.

Ja. Es ist eine DOIF-spezifische Syntax zum Thema Aggregation: https://fhem.de/commandref_DE.html#DOIF_aggregation

Durch die Möglichkeit Regex-Angaben sowohl für Devices als auch für Readings anzugeben, ergeben sich zwei ineinander geschachtelte Schleifen, die das ganze FHEM durchforsten. Es ist also ein ziemlich mächtiges Feature, mit dem man sparsam (nicht bei jedem Event) umgehen sollte, da es etwas Performance kostet - auch wenn es intern per Perl-grep-Befehl performant realisiert wurde.

[Adimarantis]

Hi Damian,

also ich habe das jetzt mal versucht, aber ich kriege es nicht zum laufen.
Es kommt immer:

Code Auswählen Erweitern

condition c01: syntax error, line 1, at EOF

Aber zumindest so kann ich schon mal die Liste der Devices holen. Ich will dann ja noch weiter filtern (z.B. Räume aussschliessen - oder geht das auch irgendwie?), daher brauche ich es wohl sowieso erstmal als Variable im Body des DOIF

Code Auswählen Erweitern

([12:00])
  {
    my $s='[?@:"":"^[Bb]attery$":ReadingsAge($name,"state",0) > 3600*24,"keine"]';
  }

[Damian]

Warum hast du den Ausdruck in Anführungszeichen gesetzt?

Ich würde es, wie schon vorgeschlagen, im Perl-Modus machen:

Code Auswählen Erweitern

DOIF {
[12:00];
my $s=[?@:"":"^[Bb]attery$":ReadingsAge($name,"state",0) > 3600*24,"keine"];
# weiterer Perlcode ....
}

Es gibt auch eine reine Perl-Routine, die ein Array liefert (siehe Doku zu DOIF-Aggregation)

[MadMax-FHEM]

@MadMax: Guter Hinweis mit den HM Motor Devices - zumindest bei den HM_CC_RT_DN habe ich das schon beobachtet.
Weiss jemand wie der Fehlerzustand in FHEM aussieht (HMCCU)? Das müsste ich auch noch abfragen. (hab gerade keins parat das ausgefallen ist). Würde mal vermuten, dass da dann ein Fehler in hmstate oder activity steht. Kurzfristig ausfallen, darf es für mich - aber ich wills zeitnah merken.

Ja die HM_CC_RT_DN habe ich auch und damit auch gemeint

Leider gibt es (zumindest CUL_HM) wenig Möglichkeiten...

Es gibt dort im Clima-Kanal motorErr.

Das Problem (was ich festgestellt habe) ist, dass es (bei mir) meist bei der Entkalkungsfahrt auftritt bzw. wenn es dabei auftritt gibt es eben keinen Fehler.

Der Motor ist (im schlimmsten Fall) nur zu schwach bzw. eben die Batterie, dass wieder zugedreht wird und dann heizt er einfach...

Wenn es während "normalbetrieb" passiert, dann gibt es wohl einen Fehler bei motorErr...

Ob es das o.ä. bei HMCCU gibt: keine Ahnung...

Habe dazu schon überlegt zusätzlich einen (billigen) Tempsensor direkt an den HK zu pappen.
Wenn eigentl. nicht geheizt wird aber trotzdem (deutlich) hohe Temp dort angezeigt wird -> evtl. ein Problem...

[OT]
mir sind andere HKTs schon mal echt "abgeraucht" (billige von Conrad damals, so um die 2005+ [15EUR inkl. Batterie   Wollte mal sehen, ob das gut ist sowas zu haben] ohne Funk und so).
Hab nicht gleich gemerkt, dass der HK heizt wie blöd (ein Raum in dem ich ganz selten bin/war), da gingen sogar die HKTs kaputt -> zu heiß...
Batterie ging zur Neige -> Error-Valve-Pos (nehme ich an oder eben "abgebrochene" Entkalkungsfahrt)...
Hat so fast 2 Tage gedauert bis ich das gemerkt habe...
Das und auch dass man da immer am "Knöpfchen-Kino" einstellen musste hat mich dazu bewegt HKTs zu nehmen, die den Batteriezustand melden (und per PC einstellbar/"programmierbar" sind).
[/OT]

Daher wechsle ich dort schon relativ früh...
...oder wenn ich mal länger nicht da bin, dann verschiebe ich die Entkalkungsfahrt(en immer wieder autom.)...

EDIT: spätestens, wenn bei motorErr lowBat kommt

Gruß, Joachim