Batteriestatus und Speicherung des letzten Wechsel

[sepultura30]

Also zunächst mal: danke!

Dann: komisch ist, dass einige "Register-Readings" (gekennzeichnet durch R-...) OHNE Punkt und andere wiederum MIT Punkt da sind.

Normal war (ist denke ich immer noch): OHNE Punkt!

Daher mal ergründen (neuer Thread in Homematic) WARUM das bei dir so ist...
(evtl. mache ich mal ein Update und schaue, ob das bei mir dann auch so kommt / denke aber, dass man davon schon mehr gelesen hätte, wenn?)


Und dann werde ich selbst aus der Beschreibung bzgl. event-min-interval nicht so ganz schlau...
Nutze nur event-on-change-reading...

Aber könnte es sein, dass event-min-interval NUR auf state OHNE event-on-change-reading etc. dazu führt, dass eben nur noch Events für state kommen!?
https://wiki.fhem.de/wiki/Event-min-interval

Schon mal den Eventmonitor geöffnet!?

Oder ging es bei dir "nur" um die Berechnung?
(Bei so viel "Durcheinander" kann man schon mal was aus dem Auge verlieren   )

Gruß, Joachim

Hallo Joachim,

mir gings nur um die Berechnung, mehr nicht und ich habe dein Script noch erweitert, so das man nur einmal am Tag eine Nachricht per TelegramBot bekommt.

Grüße

Sandro

[MadMax-FHEM]

Da ich leider nicht im Kopf habe welches Gerät nun welche Batterie (und wieviele davon) braucht habe ich meinen Code und meine Batterie-Geräte etwas erweitert...

Und weil das was ich nutze ja hier mal Basis war dachte ich vielleicht auch hierfür interessant

Also ich habe jedem meiner Batterie-Geräte mittels userattr ein Attribut my_batteryType verpasst und dann eben das Attribut my_batteryType mit dem Batterie-Typ und Anzahl gesetzt.

Beispiel:

Internals:
   DEF        697334
   FUUID      5c573a6f-f33f-753d-961e-90a6d3d04ef7910a
   IODev      hmusb
   NAME       Briefkasten
   NOTIFYDEV  global
   NR         522
   NTFY_ORDER 50-Briefkasten
   STATE      open
   TYPE       CUL_HM
   chanNo     01
   READINGS:
     2020-01-05 21:17:54   Activity        dead
     2019-01-18 16:14:19   CommandAccepted yes
     2019-01-18 17:03:36   D-firmware      1.0
     2019-01-18 17:03:36   D-serialNr      PEQ0580746
     2019-01-18 16:14:20   PairedTo        0xAFFE11
     2019-01-18 16:13:40   R-cyclicInfoMsg on
     2019-01-18 16:13:40   R-eventDlyTime  0 s
     2019-01-18 16:13:40   R-msgScPosA     open
     2019-01-18 16:13:40   R-msgScPosB     closed
     2019-01-18 16:13:40   R-pairCentral   0xAFFE11
     2019-01-18 16:13:40   R-sabotageMsg   on
     2019-01-18 16:14:20   R-sign          off
     2019-01-18 16:13:40   R-transmDevTryMax 6
     2019-01-18 16:13:40   R-transmitTryMax 6
     2019-01-18 16:14:19   aesCommToDev    ok
     2019-01-18 16:14:19   aesKeyNbr       00
     2019-01-18 17:23:10   alive           yes
     2019-01-18 17:23:10   battery         ok
     2019-01-18 17:23:10   contact         open (to vccu)
     2019-01-18 17:23:10   recentStateType info
     2019-01-18 17:23:10   sabotageError   on
     2019-01-18 17:23:10   state           open
     2019-01-18 17:23:07   trigger_cnt     242
   helper:
     HM_CMDNR   179
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +697334,00,00,00
       rxt        2
       vccu       vccu
       p:
         697334
         00
         00
         00
       prefIO:
         hmusb
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     tmpl:
Attributes:
   IODev      hmusb
   IOgrp      vccu:hmusb
   actCycle   002:50
   actStatus  dead
   autoReadReg 4_reqStatus
   expert     1_allReg
   firmware   1.0
   icon       message_mail
   model      HM-SEC-SCO
   my_batteryType 1xAAA
   peerIDs    00000000,
   serialNr   PEQ0580746
   subType    threeStateSensor
   userattr   my_batteryType

Aber VORSICHT beim Anwenden von userattr!
Gerade, wenn man das für mehrere Geräte/Devices in fhem per devSpec setzt!
(also z.B. attr battery=..* userattr my_batteryType / d.h. das userattr für alle Devices setzen, die "irgendwas mit battery haben")
Ich mache das immer nur bei den Geräten wo ich das brauche und ich nenne "meine" Attribute auch immer my_Irgendwas...

Es ist "umständlicher" aber damit nehme ich so wenig Einfluss wie möglich.

Einfachere Alternative: userattr unter global erweitern. Dann gibt es das Attribut halt für alle Geräte...


So nun wozu das:

Ich habe dann eben zusätzlich die Abfrage des Batterie-Typs eingebaut (dort wo eben berechnet wird, wie der Zustand ist und gegebenenfalls eine Nachricht verschickt wird):

Code Auswählen Erweitern


$BatteryType = AttrVal($Device, "my_batteryType", "unknown");


und beim senden gebe ich dann eben neben dem Device-Namen ($Device) auch noch den notwendigen Batterie-Typ inkl. Anzahl mit (also das was halt im Attribut my_batteryType steht)...

Noch ungetestet (nächster Wechsel steht aber demnächst an, dann werde ich ja sehen), sollte aber funktionieren...

Gruß, Joachim

[kotaro]

Hallo,

leier bin ich erst jetzt auf dieses tolle Projekt gestoßen.
Dazu wollte ich mal fragen, ob ihr Homematic und Homematic IP-Gerät über HMCCU integriert habt?

habe mal durchgesehen, und die typischen Readings sind:

 
   
   
   
   
   

	HMIP	Homematic
HKT	0.OPERATING_VOLTAGE 0.LOW_BAT	4.BATTERY_STATE 0.LOWBAT
WT	0.OPERATING_VOLTAGE 0.LOW_BAT	2.BATTERY_STATE 0.LOWBAT
Tür/Fenster	0.OPERATING_VOLTAGE 0.LOW_BAT	0.LOWBAT
Wassersensor		0.LOWBAT

und folgende Internals:
HMIP
ccuif: HmIP-RF
HM:
ccuif: BidCos-RF

Also bei HMIP mit OPERATING_VOLTAGE ist wie der Name schon sagt, die akutelle Spannung gelistet, bei LOW_BAT gibt es ein true oder false...
bei Homematic mit BATTERY_STATE das gleiche --> Spannung, LOWBAT der Wert, ob true oder false

Vielleicht wisst ihr mehr?? in der Github-Datei von 2018 finde ich diese nicht hinterlegt.

[MadMax-FHEM]

Vielleicht wisst ihr mehr?? in der Github-Datei von 2018 finde ich diese nicht hinterlegt.

Dann wird das wohl noch nicht drin sein...

Aber du kannst "einfach" einen bestehenden Homematic-Teil (kopieren und einfügen und dann) abändern, also die Geräte die nur low/ok liefern bzw. die bei denen Spannungswerte kommen.

Ist ja für beide bei Homematic was vorhanden.

Ansonsten mal besser 2 lists, eines von einem mit "nur" low/ok und einem mit Spannungsanzeige...
...dazu nat. wichtig wieviel Spannung "voll" ist (verm. auch 3,0V bzw. 3,2V) und wo steht wann das Gerät "aus geht"...

Bei den bestehenden Homematic ist es wie folgt:

2x1,5V Batterie macht 3,0V (oder 3,2V weil es ist schon mal "mehr drin")
und im Register-Reading "R-lowBatLimitRT" steht wann "Ende ist", da müsstest du halt sehen wo man das bei "deinen" Geräten sehen kann...

Wenn du (erfolgreich) geändert hast, dann "zurück-teilen"

Mit den gelieferten lists kann es Amenophis86 versuchen einzupflegen...

Mittlerweile habe ich einige Änderungen bzgl. den Homematic-Fenstersensoren optisch vorgenommen, da diese sehr lange dazu neigen zwischen low und ok zu springen...
...muss ich auch mal posten, vielleicht kann es ja verwendet werden.

Gruß, Joachim

[Aladin222]

Hallo @all,

endlich Wochenende und ich kann mal schauen und testen
Leider bekomme ich die Benachrichtigung bei leeren Batterien nicht gebacken ....

list BatterieStatus

Code Auswählen Erweitern


Internals:
   CFGFN     
   FUUID      5e64c2d8-f33f-9117-d425-0cc980ad08f16507
   NAME       BatterieStatus
   NR         2432
   STATE      ???
   TYPE       dummy
   READINGS:
     2020-03-08 11:03:04   BadTaster       100
     2020-03-08 11:03:04   Bad_UG          100
     2020-03-08 11:03:04   EZ_Taster       100
     2020-03-08 11:03:04   FensterKontaktBadOG 100
     2020-03-08 11:03:04   FensterKontaktBadUG 100
     2020-03-08 11:03:04   FensterKontaktEsszimmer 100
     2020-03-08 11:03:04   FensterKontaktGaeste 100
     2020-03-08 11:03:04   FensterKontaktKuecheL 100
     2020-03-08 11:03:04   FensterKontaktKuecheR 100
     2020-03-08 11:03:04   FensterKontaktSchlafz1 100
     2020-03-08 11:03:04   FensterKontaktSchlafz2 100
     2020-03-08 11:03:04   FensterKontaktTGriff 100
     2020-03-08 11:03:04   FensterKontaktTerrasse 100
     2020-03-08 11:03:04   FensterKontaktTimo 100
     2020-03-08 11:03:04   FensterKontaktWz 100
     2020-03-08 11:03:04   GaesteZimmer    100
     2020-03-08 11:03:04   HeizungBadOG    100
     2020-03-08 11:03:04   HeizungBadUG    100
     2020-03-08 11:03:04   HeizungSZ       100
     2020-03-08 11:03:04   HeizungWzL      100
     2020-03-08 11:03:04   HeizungWzR      30
     2020-03-08 11:03:04   Kueche          100
     2020-03-08 11:03:04   NUKIDevice355445389 100
     2020-03-08 11:03:04   SchlafZimmer    100
     2020-03-08 11:03:04   Schuppen        100
     2020-03-08 11:03:04   SturzTemp       100
     2020-03-08 11:03:04   Sturz_Taster    100
     2020-03-08 11:03:04   TerrasseTemp    100
     2020-03-08 11:03:04   Timo            100
     2020-03-08 11:03:04   WasserMelder    100
     2020-03-08 11:03:04   WohnZimmer      100
     2020-03-08 11:03:04   WzWandthermostat 100
Attributes:
   DbLogExclude .*
   room       Z_System->BatteryCheck


Somit sollte sich doch HeizungWzR melden ,oder ? Dazu stellt sich mir echt die Frage das der STATE "3 Fragezeichen" hat ...

list BatterieWechsel

Code Auswählen Erweitern


Internals:
   CFGFN     
   FUUID      5e64c2d8-f33f-9117-a952-1c4923ac9edc06cc
   NAME       BatterieWechsel
   NR         2433
   STATE      ???
   TYPE       dummy
Attributes:
   DbLogExclude .*
   room       Z_System->BatteryCheck

Ist für mich ok , da er noch keinen Batteriewechsel mitbekommen hat ...

in 99_BatterieCheckUtils

Code Auswählen Erweitern


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




list WEB_Pushover

Code Auswählen Erweitern


Internals:
   APP_TOKEN  ajhgjhghghgjhkj5kud
   CFGFN      /opt/fhem/FHEM/02_Messager.cfg
   DEF        agajhjhjgjhjhhkjktL1toHM
   FUUID      5cc3eb02-f33f-9117-0015-b7b9261af6482a0c
   FVERSION   70_Pushover.pm:v2.2.0-s20897/2020-01-06
   NAME       WEB_Pushover
   NR         452
   STATE      connected
   TYPE       Pushover
   USER_KEY   urMbkhkjsdhkjsddsgoHM
   VALIDATION_TIMER 1583684445.80531
   READINGS:
     2020-03-08 08:58:40   apiLimit        7500
     2020-03-08 08:58:40   apiRemaining    7494
     2020-03-08 08:58:40   apiReset        1585717200
     2020-03-08 11:20:45   available       1
     2019-06-03 07:32:03   devices         Aladin212iPad,Aladin212Iphone,ipad_pro,TimoIphone
     2019-04-27 07:39:20   group           0
     2020-03-08 08:58:40   lastAction      -
     2020-03-08 08:58:40   lastDevice      Aladin212iPad,Aladin212Iphone,ipad_pro,TimoIphone
     2020-03-08 08:58:40   lastMessage     Morgen wird  Abfuhrtermin Biotonne (BRAUN) abgeholt
     2020-03-08 08:58:40   lastRequest     fd57d46e-622b-4a31-9b86-8a31d4079775
     2020-03-08 11:20:45   lastResult      ok
     2020-03-08 08:58:40   lastTitle       Müll
     2020-03-08 11:20:45   state           connected
     2019-04-27 07:39:20   tokenState      valid
     2019-04-27 07:39:20   userState       valid
Attributes:
   DbLogExclude .*
   alias      Pushover
   icon       pushover


[MadMax-FHEM]

So wie ich das lese erst ab/unter 25%:

4. Das Script verschickt eine Nachricht, sobald der Status einer Batterie 25% erreicht, oder leer meldet

Du hast aber ja 30%

Ein Device hat solange die drei Fragezeichen, solange noch kein set Device irgendwas erfolgt ist...
...wird evtl. hier auch nie passieren (nutze nicht genau diese "Implementierung" sondern immer noch "meine eigene" [die mal Basis war] / daher: bzgl. "gehen die 3 Fragezeichen weg" nur Vermutung hier )

Gruß, Joachim

[Aladin222]

Hi  MadMax ,

Danke für deine Rückmeldung ... ja das List ist neu ...hatte nochmal neu eingebunden !
Der Batteriestand ist 0 ...
Dauert ja ein wenig bis er auf 25% fällt ... komisch ist nur , es funktioniert nun !
Nachdem der Batteriestand weiter fiel ,kam nun auch die Push ... also war es gut alles nochmal neu zu definieren

Danke !

[Betonklotz]

Hallo,

habe das Modul im Grunde sauber installiert (kleine Anmerkung für Seite 1: evtl. noch ein prüfen der Rechte ergänzen, das hatte ich in der Eile vergessen...), bekomme aber im Log immer alle paar Sekunden Meldungen in der Art

Code Auswählen Erweitern


EG_Schlafzimmer_Heizung_HM2E7xxx, 'battery: ok' ignored, has batteryLevel reading
EG_BadRobert_Heizung_HM535xxx, 'battery: ok' ignored, has batteryLevel reading
EG_Wohnzimmer_Heizung_HM535xxx, 'battery: ok' ignored, has batteryLevel reading

Was habe ich falsch gemacht, bzw. wie kann ich es unterdrücken? Was braucht ihr ggf. zur Eingrenzung des Fehlers? Und finde ich (z.B. in einer readingsgroup) das Datum wann die Batterien zuletzt gewechselt wurden (=müsste bei mir ja das aktuelle Datum oder sein)?

Gruß, Robert

[FunkOdyssey]

Das ist doch okay.
Kannst du nicht das Loglevel ändern? Ganz oben im Quellcode.

[MadMax-FHEM]

Hallo,

habe das Modul im Grunde sauber installiert (kleine Anmerkung für Seite 1: evtl. noch ein prüfen der Rechte ergänzen, das hatte ich in der Eile vergessen...), bekomme aber im Log immer alle paar Sekunden Meldungen in der Art

Code Auswählen Erweitern


EG_Schlafzimmer_Heizung_HM2E7xxx, 'battery: ok' ignored, has batteryLevel reading
EG_BadRobert_Heizung_HM535xxx, 'battery: ok' ignored, has batteryLevel reading
EG_Wohnzimmer_Heizung_HM535xxx, 'battery: ok' ignored, has batteryLevel reading

Was habe ich falsch gemacht, bzw. wie kann ich es unterdrücken? Was braucht ihr ggf. zur Eingrenzung des Fehlers? Und finde ich (z.B. in einer readingsgroup) das Datum wann die Batterien zuletzt gewechselt wurden (=müsste bei mir ja das aktuelle Datum oder sein)?

Gruß, Robert

Für ersteres "Problem" kenne ich den aktuellen Code zu wenig...


Den Tausch siehst du (zumindest ist das bei meiner "Basis-SW" so) erst NACH einem Wechsel.
Also: Batterie war mal "low" etc. und ist dann wieder "ok" etc.

Was helfen könnte (sollte) bei einem Gerät welches "nur" battery ok/low hat ein:

Code Auswählen Erweitern

setreading Gerätename battery low

dann sollte die Nachricht kommen...
...und beim nächsten Update vom Gerät (das muss halt zyklisch senden) wird ja dann wieder "ok" gesetzt (weil die Batterie ja tatsächlich ok ist   )...

Gruß, Joachim

[Betonklotz]

Hallo,

@FunkOdyssey: grrrr, sehe ich erst jetzt. Frage mich warum das nicht im Block "bitte ändern/prüfen" mit drin ist. Aber im Grunde werden nur Logs 1 & 3 genutzt, d.h. wichtige Sachen wie "Batterie" ist leer steht dann nicht mehr im Log.
@Joachim: danke dir.

@all: muss mir den Quellcode aber eh mal ansehen, das Script triggert zusätzlich auch auf meine USV.

Code Auswählen Erweitern


USV, unknown Event battery.runtime: 3418

==> werde das Script mal als Vorlage am Wochenende nutzen und mir darauf basierend was basteln.

Danke und Gruß,

Robert

[jeti]

Hallo zusammen,
ich habe das script gefunden, klasse Arbeit!
Natürlich habe ich es gleich eingesetzt. Soweit sieht es auch gut aus. Meine Z-Wave Thermostate werden korrekt erkannt und das Batterie Level dementsprechend ermittelt.
Nun zu meinem Problem:
meine Zigbee (über MQTT) also vom TYPE MQTT2_DEVICE haben jeweils das reading "battery" und werde auch erkannt, nur wird der battery Wert (0-100) nicht korrekt ermittelt und bei allen "0" angezeigt.
Eigentlich sollte das doch out of the box funktionieren?
Anbei eines meiner MQTT2_DEVICES.

Wo kann hier der Fehler liegen?

Danke und Gruß

[FunkOdyssey]

Ich habe in letzter Zeit viele kleine Änderungen im Code vorgenommen.
Im Code wird viel das batteryLevel abgefragt. Und gelegentlich nur das battery-Reading mit den Strings ok, low, etc.

Viele meiner Geräte wie bspw. ZWave und Zigbee nutzen neuerdings das Reading batteryPercent.
Homematic wird wohl weiterhin eine Sonderlösung bleiben. Und LaCrosse und MAX! haben auch kein batteryPercent-Reading.

Theoretisch könnte man den Code weiter generalisieren und die Unterscheidungen nach Gerätetyp entfernen, wenn das Reading batteryPercent existiert.
Wenn sich das in FHEM nun durchsetzt, so dürfte die Batterieüberwachung irgendwann viel einfacher werden.
Ich bin aber froh, dass es diesen Code gibt.

Soll das hier https://github.com/Amenophis86/Batteryfunktion/tree/no-BatteryStatusBot eigentlich noch weiterentwickelt werden?
Im Thread sehe ich viele neue Beispiele, die noch nicht implementiert wurden.

[jeti]

Ich finde das Script sehr wertig und eine Weiterentwicklung würde mich sehr freuen

[MadMax-FHEM]

Ich habe in letzter Zeit viele kleine Änderungen im Code vorgenommen.
Im Code wird viel das batteryLevel abgefragt. Und gelegentlich nur das battery-Reading mit den Strings ok, low, etc.

Viele meiner Geräte wie bspw. ZWave und Zigbee nutzen neuerdings das Reading batteryPercent.
Homematic wird wohl weiterhin eine Sonderlösung bleiben. Und LaCrosse und MAX! haben auch kein batteryPercent-Reading.

Theoretisch könnte man den Code weiter generalisieren und die Unterscheidungen nach Gerätetyp entfernen, wenn das Reading batteryPercent existiert.
Wenn sich das in FHEM nun durchsetzt, so dürfte die Batterieüberwachung irgendwann viel einfacher werden.

Es gibt/gab ja auch mal Versuche das zu vereinheitlichen: https://forum.fhem.de/index.php/topic,87575.msg800017.html#msg800017

Ich glaube auch, dass es ins "Best Practice" für Modulentwickler eingeflossen ist...
...und einige auch schon umgestellt haben...
...andere wiederum nicht...
...und leider halten sich manche neue Module auch nicht dran (ist ja kein Zwang)...

Ich bin aber froh, dass es diesen Code gibt.

Soll das hier https://github.com/Amenophis86/Batteryfunktion/tree/no-BatteryStatusBot eigentlich noch weiterentwickelt werden?
Im Thread sehe ich viele neue Beispiele, die noch nicht implementiert wurden.

Ja vielen Dank noch mal an Amenophis86 den Code übernommen und so weit gebracht zu haben!!

Leider weiß ich bzgl. aktuellem Stand nichts...

Gruß, Joachim