Batteriestatus und Speicherung des letzten Wechsel

[tomspatz]

SORRY 

voll die Tomaten auf den Augen, dabei versuche ich mich wirklich in den Code reinzudenken.

LG
Tom

[Benny33]

Moin zusammen,

jetzt habe ich den Batteriestatus auch mal installiert.
Im Logfile taucht aber zu oft der Batteriestatus auf.
Habe schon versucht mit verbose 2 dies zu minimieren.
Wie kann ich das minimieren?

Code Auswählen Erweitern

2018.10.21 07:59:21 3: HKT_Buegelzimmer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 07:59:49 3: HKT_WC, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 07:59:53 3: HKT_Schlafzimmer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 07:59:57 3: HKT_Pia, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:00:01 3: HKT_am_Ofen, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:00:10 3: HKT_Tuer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:00:27 3: HKT_Bad, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:01:25 3: HKT_am_Computer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:01:40 3: HKT_Buegelzimmer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:03 3: HKT_Schlafzimmer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:04 3: HKT_WC, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:18 3: HKT_am_Ofen, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:18 3: HKT_Tuer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:35 3: FK_Terassentuer, Batt ok
2018.10.21 08:02:50 3: HKT_Bad, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:58 3: HKT_Pia, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:03:28 3: Rauchm_Flur, Batt ok
2018.10.21 08:03:45 3: HKT_Buegelzimmer, 'battery: ok' ignored, has batteryLevel reading


Danke benny

[Amenophis86]

Wo genau hast du es auf lvl 2 gesetzt bzw welche Version nutzt du?
Hoffe, dass ich jetzt im Winter wieder etwas dazu komme.

[Benny33]

Da nichts funktionierte habe ich es mittlerweile in Batteriestatusbot, Batteriewechsel NO.BatterieNotify rgBatteriestatus.
Die Version ist vom 31.03.18.

Benny

[Amenophis86]

Das heißt du setzt es per Attr? Das ist falsch, du musst es im Script setzen. Ein paar Beiträge vorher hatten wir das schon. Mal.

Weiterhin war die Frage der Version nicht von wann sie ist, sondern welche. Es gibt aktuell zwei verschiedene Zweige der Entwicklung

[Benny33]

Ja hatte ich über attr gemacht.
Jetzt habe ich es gerade im script von my $Loglevel = 4 nach my $Loglevel = 2 geändert, mal sehen was passiert.
Die Version ist nicht die Master sondern no-BatterieStatusBot. bzw. 99_BatteryCheckUtils.pm

Benny

[Amenophis86]

Dann müsste es jetzt klappen, wenn nicht melden

[Migul47]

Hallo,

klappt super. Hat jemand schon die Readings von Netatmo eingebaut?

Danke

[Amenophis86]

Bisher noch nicht.

Ich habe mich heute auch mal wieder mit dem Modul beschäftigt. Das Hauptproblem ist das erkennen, wie lange/oft ein low gesendet wird, bis der kritische Status erreicht wurde. Das habe ich nun mehrfach getestet. Leider ist das Ergebnis nicht gut. Soll heißen es kommt einfach zu sehr auf die Batterien und das Gerät an. Bei manchen Batterietypen dauert es so lange, dann ist es von Gerät zu Gerät wieder verschieden. Selbst bei HM Geräten ist es teilweise nicht gleich...
Daher werde ich das Modul leider nochmal über den Haufen werfen und von vorne beginnen mit einer neuen Idee, wie es arbeiten sollte. Da bin ich gerade in der Überlegung und melde mich wieder, wenn es etwas Neues gibt. Das kann jedoch dauern, da ich immer nur selten und kurz dran arbeiten kann. Bis dahin werde ich auch keine Änderungen mehr vornehmen an den aktuellen Versionen.


Meine aktuelle Idee sieht wie folgt aus. Keine Probleme machen Geräte, welche einen genauen Wert übertragen. Allerdings macht alles mit reinem ok/low Probleme. Für diese Geräte werde ich vielleicht eine Art ActionDector einbauen, der nach dem ersten Mal low startet. Der soll regelmäßig prüfen, ob sich ein bestimmtes Reading geändert hat. Sollte das nach einer gewissen Zeit nicht mehr der Fall sein, dann meldet das Modul kritisch. Vielleicht klappt das ja besser.

[MadMax-FHEM]

Ich bin bei den optischen Fenstersensoren drüber gestolpert und hatte eingebaut auf "dead" zu warten/kucken...
...hat sich aber bei der Zeitumstellung als "doof" erwiesen...
Weil da irgendwie der ActionDetector ein wenig naja

Neueste Idee: ReadingsAge von powerOn < 2 Tage (oder auch noch neuer).

D.h. wenn von low - nach ok habe ich aktuell eingebaut ReadingsAge abzufragen...
Sollte ja immer noch das alte powerOn sein, außer es wurde tatsächlich gewechselt...
Weil gerade die optischen HM Sensoren öfter mal zwischen low - ok - low - ok usw. wechseln...
Mal sehen wie sich das tut...

Dumm, dass das halt nur bei Geräten mit diesem powerOn Reading tut.

Aber für die (zumindest bei mir) problematischen optischen HM-Sensoren sollte das helfen.

Bei den magnetischen hatte ich noch keine Probleme.
Da kommt low bleibt (zumindest bei mir bislang) low (zugegebenermassen ziemlich lange   ) und dann dead...

Bei denen wo ich die Prozente berechne klappt alles und auch bei ZWave etc. die schon gleich Prozent melden...

Für Geräte ohne das powerOn hab ich auch noch keine rechte Lösung...

EDIT: ups noch mal gelesen. Ganz andere Baustelle/Problem das du beschreibst   Ich mache es bei mir aktuell so, dass ich bei low eine Nachricht schicke "demnächst Batterien wechseln" (schon mal nach Batterien schauen/besorgen) und dann bei HM auf "dead" warte. Bei ZWave prüfe ich einmal am Tag ob das wakeup gekommen ist, das Intervall kann man abfragen (zumindest bei denen die ich habe) und dann einen ähnlichen Mechanismus wie ActionDetector habe... Wobei eigentlich bei allen Geräten die Prozente anzeigen keine großen Probleme da sind (bei mir), einzig die jeweilige Schwelle, also wann "bald wechseln" und "jetzt isses aber soweit weil tot" ist halt etwas "Einstellungssache"... Hmmm, das passt wohl besser hierher

Gruß, Joachim

[gloob]

Hallo,

Ich habe meine Xiaomi Sensoren über eine Hue Bridge eingebunden:

Code Auswählen Erweitern

defmod XiaomiSensor2_1 HUEDevice sensor 5  IODev=deCONZ
attr XiaomiSensor2_1 IODev deCONZ
attr XiaomiSensor2_1 room Zigbee
attr XiaomiSensor2_1 stateFormat {sprintf("Temperatur: %.1f Grad / Feuchte: %.1f Prozent / Luftdruck: %.1f hPa / Batterie: %d %%",ReadingsVal($name,"temperature",0),ReadingsVal($name,"humidity",0),ReadingsVal($name,"pressure",0),ReadingsVal($name,"battery",0))}
attr XiaomiSensor2_1 userReadings humidity {ReadingsVal("XiaomiSensor2_2","humidity","");;},\
pressure {ReadingsVal("XiaomiSensor2_3","pressure","");;}

setstate XiaomiSensor2_1 2018-11-12 10:53:41 .lastupdated 2018-11-12 10:53:41
setstate XiaomiSensor2_1 2018-11-12 10:53:41 battery 95
setstate XiaomiSensor2_1 2018-11-12 10:53:41 humidity 53.24
setstate XiaomiSensor2_1 2018-11-12 10:53:41 pressure 1002
setstate XiaomiSensor2_1 2018-11-12 10:53:41 reachable 1
setstate XiaomiSensor2_1 2018-11-12 10:53:41 temperature 22.75

Gibt es eine Möglichkeit die Senoren auch mit in die Batterieüberwachung aufzunehmen? Leider gibt es ein battery reading welches direkt als Prozent Werte gesetzt wird.

Man läuft somit immer in den Zweig:

Code Auswählen Erweitern


##############################################
# All other Devices with batteryLevel
##############################################
.
.
.
if($Loglevel >=1) {Log3(undef, 1,"$Device, unknown Event $Event");}

[Amenophis86]

Ja, die Möglichkeit gibt es. Aktuell komme ich aber aus Zeitmangel nicht dazu es einzubauen. Das heißt entweder forken oder mir einen Patch erstellen. Sorry

[Green Hornet]

Hallo,

Ich habe meine Xiaomi Sensoren über eine Hue Bridge eingebunden:

Code Auswählen Erweitern

defmod XiaomiSensor2_1 HUEDevice sensor 5  IODev=deCONZ
attr XiaomiSensor2_1 IODev deCONZ
attr XiaomiSensor2_1 room Zigbee
attr XiaomiSensor2_1 stateFormat {sprintf("Temperatur: %.1f Grad / Feuchte: %.1f Prozent / Luftdruck: %.1f hPa / Batterie: %d %%",ReadingsVal($name,"temperature",0),ReadingsVal($name,"humidity",0),ReadingsVal($name,"pressure",0),ReadingsVal($name,"battery",0))}
attr XiaomiSensor2_1 userReadings humidity {ReadingsVal("XiaomiSensor2_2","humidity","");;},\
pressure {ReadingsVal("XiaomiSensor2_3","pressure","");;}

setstate XiaomiSensor2_1 2018-11-12 10:53:41 .lastupdated 2018-11-12 10:53:41
setstate XiaomiSensor2_1 2018-11-12 10:53:41 battery 95
setstate XiaomiSensor2_1 2018-11-12 10:53:41 humidity 53.24
setstate XiaomiSensor2_1 2018-11-12 10:53:41 pressure 1002
setstate XiaomiSensor2_1 2018-11-12 10:53:41 reachable 1
setstate XiaomiSensor2_1 2018-11-12 10:53:41 temperature 22.75

Gibt es eine Möglichkeit die Senoren auch mit in die Batterieüberwachung aufzunehmen? Leider gibt es ein battery reading welches direkt als Prozent Werte gesetzt wird.

Man läuft somit immer in den Zweig:

Code Auswählen Erweitern


##############################################
# All other Devices with batteryLevel
##############################################
.
.
.
if($Loglevel >=1) {Log3(undef, 1,"$Device, unknown Event $Event");}

Hallo,

gibt es bezüglich Batterieüberwachung der Xiaomi Devices über HUE Bridge schon etwas neues?

[Amenophis86]

Sry, von meiner Seite liegt das Projekt aktuell auf Eis. Hat verschiedene Gründe. Manche Module haben noch nicht auf die neuen Readings umgestellt und ich wollte nicht für jede Sonderlocke etwas programmieren und dazu bin ich beruflich aktuell ziemlich eingespannt. Muss mal sehen wann ich das Projekt weiter voran treibe. Du kannst aber mal ein List deines Device hier posten vielleicht kann ich dir sagen was du am Code ändern musst, dass es geht.

[Green Hornet]

Trotzdem Danke das du es dir evtl. mal anschaust. 
Batterie Reading wird in Prozent angegeben.

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        sensor 9  IODev=Raspbee_1
   FUUID      5c6800b9-f33f-9f3a-e63d-b58a53a621998bcf
   ID         S9
   INTERVAL   
   IODev      Raspbee_1
   NAME       GA.Bm_Motion
   NR         735
   STATE      nomotion
   TYPE       HUEDevice
   lastupdated 2019-02-20 18:56:44
   lastupdated_local 2019-02-20 19:56:44
   manufacturername LUMI
   modelid    lumi.sensor_motion.aq2
   name       Bewegungsmelder Garage
   on         1
   reachable  1
   swversion  20170627
   type       ZHAPresence
   uniqueid   00:15:8d:00:02:cb:47:43-01-0406
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1550689004.86648
           VALUE      nomotion
   READINGS:
     2019-02-20 19:56:44   battery         95
     2019-02-20 19:56:44   reachable       true
     2019-02-20 19:56:44   state           nomotion
   helper:
     devtype    S
     reachable  0
     update_timeout 1
     setList:
Attributes:
   IODev      Raspbee_1
   alias      Bewegungsmelder Garage
   group      Bewegungsmelder
   icon       motion_detector@blue
   room       Garage