Batteriestatus und Speicherung des letzten Wechsel

Amenophis86 · 09 Februar 2018, 10:17:51

Habe noch einen Fehler gefunden:

Mach mal aus Zeile 676:

if($TYPE eq "Z-Wave" and ReadingsVal($Device, "battery", undef) =~ "%")

if($TYPE eq "ZWave" and ReadingsVal($Device, "battery", undef) =~ "%")

Der - ist da falsch. Der TYPE wird ohne - geschrieben und schau, ob es dann funktioniert.

mahowi · 09 Februar 2018, 12:35:05

Ich hab die Zeile geändert, leider mit dem selben Ergebnis:

Code Auswählen

2018.02.09 12:28:39.940 3: bz.ZW_HT, unknown Event battery: 69 %
2018.02.09 12:28:39.941 3: bz.ZW_WM, unknown Event battery: 100 %
2018.02.09 12:28:39.943 3: k.ZW_WM, unknown Event battery: 100 %
2018.02.09 12:28:39.947 3: wz.ZW_HT2, unknown Event battery: 91 %

Wenn ich das richtig sehe, prüfst Du ja bei battery auf "ok", "low" und "dead". Wenn keiner der 3 Werte zutrifft, kommt "unknown Event". Müsste für ZWave nicht battery wie batteryLevel behandelt werden?

Amenophis86 · 09 Februar 2018, 13:55:43

Fehler gefunden. Das unknown kam, weil es in den battery Zweig gesprungen ist, und beim elseif am Ende nicht raus genommen wurde. Habe ich behoben. Dann ist mir noch aufgefallen, dass neue Geräte nicht beim ersten Mal im BatteryStatus landen, habe ich jetzt auch eingebaut. Zumindest für Z-Wave, bei anderen muss ich noch testen. Und jetzt sollten die Werte von Z-Wave, wenn sie eine Zahl haben auch richtig verarbeitet werden. Zumindest passiert das so in meiner Testumgebung.

Edit:
Allerdings muss die ReadingsGroupe jetzt noch angepasst werden sehe ich gerade.

Edit2:
Habe die ReadingsGroup nun wie folgt angepasst und geändert:
Changed the readingsGroup:
76 - 100 = green 100% (Symbolwert)
51 - 75 = green 75% (Symbolwert)
26 - 50 = yellow 50% (Symbolwert)
11 - 25 = orange 25% (Symbolwert)
0 - 10 = red 0% (Symbolwert)

mahowi · 09 Februar 2018, 14:54:25

Super, das war's. Jetzt werden alle Geräte angezeigt.

Amenophis86 · 09 Februar 2018, 17:14:50

Top, dann ordentlich testen und bescheid sagen, wenn noch was ist.

Spezialtrick · 09 März 2018, 17:32:14

Hallo zusammen!

Bei mir taucht im Log leider immer wieder dieser Fehler auf:

Code Auswählen

reload: Error:Modul 99_Batterycheck deactivated:

Gibt es dafür Abhilfe?

Amenophis86 · 10 März 2018, 14:02:23

Ich gehe mal davon aus, dass du die Datei heruntergeladen hast und als eigene Datei integrieren wolltest. Es war mal als reine eigene Funktion gedacht, habe es aber jetzt mal zur eigenen PM-Datei umgebaut. Das heißt ich habe davor und danach noch einen Teil eingebaut. Nun kann die Datei aus dem no-BatteryStatusBot Zweig als eigene Datei heruntergeladen und integriert werden. Hat den Vorteile, dass es auch unter FHEM als editierbare Datei angezeigt wird.

helmut · 11 März 2018, 20:09:17

Zitat von: Amenophis86 am 10 März 2018, 14:02:23
Nun kann die Datei aus dem no-BatteryStatusBot Zweig als eigene Datei heruntergeladen und integriert werden.

Das habe ich eben getan und bekam als Fehlermeldung:

Code Auswählen

"rp2 fhem45"> rel 99_BatteryCheckUtil
Undefined subroutine &main::BatteryCheckUtil_Initialize called at fhem.pl line 2486.

Den Dateinamen "99_BatteryCheckUtil.pm" habe ich unbesehen uebernommen. Die
Initialisierungsroutine heisst aber "BatteryCheckUtils_Initialize". Ich nehme an, auch die Datei
soll ...Utils heissen. Deswegen habe ich die bei mir so umbenannt. Wenn Du es Dir anders
herum gedacht hast, gib bitte Bescheid.

Soll das nun eigentlich ein offizielles Modul werden?

Gruss Helmut

Amenophis86 · 12 März 2018, 06:43:31

Habe natürlich den Dateiname geändert in Util und in der Definition vergessen. Kann ich erst am Wochenende ändern. Danke für die Info.

Ein eigenes Modul wäre wesentlich komplexer, da traue ich mich a noch nicht ran und b keine Zeit für aktuell.

helmut · 12 März 2018, 10:35:43

Zitat von: Amenophis86 am 12 März 2018, 06:43:31
Kann ich erst am Wochenende ändern.

Gar kein Problem, das eilt nun wirklich nicht.

Zitat von: Amenophis86 am 12 März 2018, 06:43:31
Ein eigenes Modul wäre wesentlich komplexer, da traue ich mich a noch nicht ran und b keine Zeit für aktuell.

Das sehe ich ein; schoen waere es trotzdem. Wenn ich bei der Doku mit Korrekturlesen behilflich sein kann ...

Gruss Helmut

Spezialtrick · 12 März 2018, 17:08:16

Zitat von: Amenophis86 am 10 März 2018, 14:02:23
Ich gehe mal davon aus, dass du die Datei heruntergeladen hast und als eigene Datei integrieren wolltest. Es war mal als reine eigene Funktion gedacht, habe es aber jetzt mal zur eigenen PM-Datei umgebaut. Das heißt ich habe davor und danach noch einen Teil eingebaut. Nun kann die Datei aus dem no-BatteryStatusBot Zweig als eigene Datei heruntergeladen und integriert werden. Hat den Vorteile, dass es auch unter FHEM als editierbare Datei angezeigt wird.

Ich habe die Datei heruntergeladen und nach /opt/fhem/FHEM kopiert und für Pushover abgeändert. Dann Fhem neugestartet und

Code Auswählen

{BatteryStart()}

ausgeführt. Entsprechend wurde ein neuer Raum mit den vorgesehen Objekten angelegt. Leider habe ich keine Meldung für leer Batterien bekommen.

Aufgrund deiner Antwort habe ich nochmals alle gelöscht und die Datei aus dem "no-BatteryStatusBot" Zweig heruntergeladen und ebenfalls nach /opt/fhem/FHEM kopiert und auch für Pushover angepasst. Meldungen erhalte ich leider weiterhin nicht. Diese sollte aber doch erfolgen, wenn ich bei einem Sensor die Batterie entferne, oder?

Folgende Meldungen finden sich im Log:

Code Auswählen

2018.03.12 12:15:38 1: PERL WARNING: Subroutine BatteryCheckUtils_Initialize redefined at ./FHEM/99_BatteryCheckUtil.pm line 12, <$fh> line 9.
2018.03.12 12:15:38 1: PERL WARNING: Subroutine BatteryStatusFunction redefined at ./FHEM/99_BatteryCheckUtil.pm line 23, <$fh> line 9.
2018.03.12 12:15:38 1: PERL WARNING: Subroutine SetBatterieIcon redefined at ./FHEM/99_BatteryCheckUtil.pm line 888, <$fh> line 9.
2018.03.12 12:15:38 1: PERL WARNING: Subroutine BatteryStart redefined at ./FHEM/99_BatteryCheckUtil.pm line 932, <$fh> line 9.

2018.03.12 12:15:51 3: eval: my $EVTPART0='battery:';my $SELF='NO.BatterieNotify';my $TYPE='CUL_HM';my $NAME='Fl.Motion.Innen';my $EVTPART1='ok';my $EVENT='battery: ok';{BatteryStatusFunction($NAME, $EVENT)}

Amenophis86 · 12 März 2018, 19:09:09

@helmut:
Konnte den Fehler doch schon heute korrigieren. Du hast Recht, die Datei soll natürlich 99_BatteryCheckUtils.pm heißen. So wurde es nun auch auf github geändert. Habe auch noch die ReadingsGroup Standardname von rgBatteryStatus zu rgBatterieStatus gewechselt. Alles wurde mit ie geschrieben nur hier hatte ich die Änderung vergessen.

Habe auch schon drüber nachgedacht und sollte ich mehr Zeit finden, versuche ich vielleicht auch ein Modul draus zu machen. Sollte sich jemand anderes finde, der Zeit hat und möchte bin ich natürlich auch nicht abgeneigt zu helfen wo es geht.

Die Doku muss ich die Tage mal angehen, wann was wie aktuell genau gemacht wird. Auch hier, wer möchte darf gerne unterstützten. Bin min. die nächsten 2-3 Wochen ziemlich eingeschränkt.

@Spezialtrick:
Dafür brauche ich bisschen mehr Informationen. Es scheint sich um ein CUL_HM Device zu handeln. Dies hat

Code Auswählen

battery: ok gemeldet. War das Device vorher auf low und wenn ja auf wie viel Prozent in BatteryStatus Dummy bzw. rg.BatteryStatus?
Wenn du im Thread in bisschen weiter vorne schaust, dann erkennst du folgendes Problem. Viele Device wechseln oft zwischen low / ok, wenn sie kein BatteryLevel Reading haben. Um diesen "Fehler" zu beheben muss das Device für längere Zeit bzw. öfter den Status low melden. Dadurch senkt sich die % immer weiter ab. Sobald diese bei 25% angekommen ist wird die erste Meldung abgesetzt. Die letzte dann beim selbst generierten Event "dead".

Wzut · 12 März 2018, 19:45:32

Zitat von: Amenophis86 am 12 März 2018, 19:09:09
versuche ich vielleicht auch ein Modul draus zu machen.

Nix da , hier wird nichts versucht , hier wird entweder etwas gemacht oder sein gelassen ..... und das Wort "vielleicht" ist auf neudeutsch eh ein "no go"

Ich habe aber noch ne Info für dich zumThema low-ok-low . Die HM Selbstbau Geräte die auf papas AskSinPP Lib bassieren machen das genau so.
D.h. er schaut z.B. alle Stunde nach dem Zustand der Batterie und meldet diesen ohne den bisherigen zu speichern bzw. zu berücksichtigen.
Mein letzter Stand ist das er nochmal darüber nachdenken wollte ein einmal festgestelltes low dauehaft bis zum nächsten Reset (u.a. durch Batt Wechsel) zu halten.

Amenophis86 · 12 März 2018, 19:49:33

Zitat von: Wzut am 12 März 2018, 19:45:32
Nix da , hier wird nichts versucht , hier wird entweder etwas gemacht oder sein gelassen ..... und das Wort "vielleicht" ist auf neudeutsch eh ein "no go"

Mir ist aufgefallen, dass meine HM Fensterkontakte auch immer mal wieder zwischen low und ok wechseln. Habe jetzt mal eingestellt, dass alle battery Readings geloggt werden um mal eine grobe Übersicht zu bekommen.

Amenophis86 · 14 März 2018, 19:23:28

Ich habe heute überraschend Zeit gehabt und daher mich nochmal mit dem Skript beschäftigt. Auch bei mir wurde ein Wechsel nicht erkannt. Daher habe ich nochmal alles geprüft und noch den ein oder anderen Fehler gefunden. Diese habe ich soeben beseitigt, getestet und scheint jetzt wieder zu funktionieren. Daher empfehle ich jedem die neuste Version aus dem no-BatteryStatusBot-Zweig zu holen bzw. zu kopieren.

Weiterhin habe ich die Doku im ersten Post mal auf den neusten Stand gebracht. Sollte jemanden etwas fehlen oder nach den Änderungen heute Fehler auffallen, mir bitte mitteilen

Edit:
Ich habe jetzt auch mal eine Variable Loglevel eingebaut, da ja doch einige Logmeldungen geschrieben wurde, was man eigentlich nicht brauch im normalen Betrieb. So kann ich aber regelmäßig mit den Logs testen und ihr könnt es ausstellen.
Weiterhin habe ich noch kleine Bugfixes durchgeführt. Zum Beispiel wurden nicht alle Device erkannt und beim ersten Ausführen angelegt, wie es scheint. Dies sollte nun behoben sein.

Edit2:
Puh habe noch einige Fehler gefunden. Habe auch die Struktur verändern müssen, weil zB Z-Wave Device mit batteryLevel nicht richtig erkannt wurden. Habe mit heute extra zum testen nochmal ein Device angelegt und dabei die Fehler festgestellt. Mehr schaffe ich heute aber leider nicht. Sollten euch noch weitere Fehler auffallen, bitte mitteilen.

Es empfiehlt sich die aktuelle Version aus github zu holen, wer mit dem no-BatteryStatusBot Zweig arbeitet!!