[gelöst] fhem stürzt unregelmäßig ab

[frank]

Am schlimmsten ist die unterschiedliche Implementierung des Batteriestatus, die einen zeigen den batteryLevel in Volt, die anderen können nur Ok.

nicht ganz, oder?
alle bat devices haben batstatus.
einige devices haben zusätzlich batlevel plus das zugehörige register lowbatlimit, das die schwelle für batstatus einstellt.

Und jetzt kommt die größte Unzulänglichkeit, wenn bei den Geräten die kein batteryLevel haben, die Batterie schwach ist und das Gerät dadurch offline ist, steht das Reading battery weiterhin auf "OK".

zum messen der batterie muss ein device zunächst mal wach sein und die messung sollte möglichst unter grösster belastung stattfinden, damit sie auch einigermassen aussagekräftig ist. für eine lange batterielaufzeit wird also per default (cyclicInfoMsg=off) der batteriewert nur beim "normalen" aufwachen eines sensors gemessen und als "beiwerk" mitgeliefert.
beim bm also gleichzeitig mit motion und cover.

dass ein homematic batdevice vom einlegen einer neuen batterie bis zum sterben durch leere batterie nie lowbat gemeldet hat, kann meiner meinung nach nur einen grund haben: cyclicInfoMsg wurde nicht eingeschaltet und das device ist zum ende der batterielaufzeit sehr lange nicht aufgewacht.

bei homematic batstatus sind meine erfahrungen eher umgekehrt => lowbat wird für meinen geschmack in der regel viel zu früh gemeldet. teilweise monate vor dem ausfall; ich habe auch schon von jahren gelesen.

Eine Überwachung der Batteriekapazität kann man damit in die Tonne treten. Also was bleibt, man prüft, ob das Reading 'battery' aktualisiert wurde, wenn nicht, muss man tätig werden.

nein, man muss nur grundsätzlich cyclicInfoMsg einschalten, da mit dieser message auch immer der batstatus gemeldet wird.
wenn dein readingswatcher mit 30min timeout bei dem bm ständig reagiert, hast du cyclicInfoMsg nicht gesetzt, gehst nicht oft genug am bm vorbei oder hast den timeout schlecht gewählt.

der homematic actiondetector würde in etwa das gleiche tun, wenn du ihn mit "attr actCycle 000:30" einschaltest, allerdings ohne das battery reading zu manipulieren. dafür gibt es on top das reading Activity, das ggf dead meldet.
ausserdem checkt hminfo das gesamte system nach dead devices und HMinfoTools generiert eine übersichtliche tabelle, in der dead devices eigentlich immer ganz oben zu finden sind. nur devices mit attack meldungen sind ggf noch höher angesiedelt.


#####################

hilfreich ist auch die kenntnis der zu erwartenden laufzeit, die eine batterie in einem device erreicht, bis sie lowbat meldet und/oder bis sie leer ist. so kann man eventuell auch ohne lowbat meldungen "rechtzeitig" wechseln. das ist zb auch interessant für die rauchmelder sec-sd-1, da diese leider immer gleichzeitig mit der ersten lowbat meldung piepen.

HMinfoTools unterstützt dies durch vorgefertigte batterie-wechsel-infos, die über einen klick auf das battery-icon ggf editiert und im attribut comment gespeichert werden können.

batChange: 2022-11-01 12:58:28 (oldBat: low since 2022-09-02 08:37:35)

batChange: => timestamp des klick-zeitpunktes
oldBat: => value und timestamp des battery readings zum zeitpunkt des klickens.
damit der zeitpunkt der ersten lowbat meldung einigermassen realistisch ist, müssen für das reading battery die attribute event-on-change-reading und timestamp-on-change-reading gesetzt sein.

#####

leider ist das nur die halbe wahrheit, denn es kann manchmal vorkommen, dass sich eine batterie nach einem lowbat wieder erholt und erneut ok meldet.
wenn es jemanden interessiert, wann die batterie wirklich das erste mal lowbat hatte und dieser zeitpunkt im attribut comment notiert werden soll, kann man mit den folgenden 2 notifys in allen devices, die ein battery reading haben, 2 zusätzliche readings anlegen lassen, wodurch die speicherung der aller ersten lowbat meldung möglich wird.

batNotOkCtr zählt die events von low/critical und batNotOkFirstTime speichert den zeitpunkt des ersten events von low/critical.

Code Auswählen Erweitern

.*:battery:.(low|critical) {
fhem("sleep 0.1; setreading $NAME batNotOkCtr ".(ReadingsVal($NAME,"batNotOkCtr",0) +1));
}

Code Auswählen Erweitern

.*:batNotOkCtr:.(0|1) {
if(ReadingsVal($NAME,"batNotOkCtr",0) == 1) {
fhem("sleep 0.1; setreading $NAME batNotOkFirstTime ".ReadingsTimestamp($NAME,"batNotOkCtr","?"));
}
else {
fhem("sleep 0.1; setreading $NAME batNotOkFirstTime waiting...");
}
}

wenn HMinfoTools die 2 zusätzlichen readings findet, wird:
1. der timestamp aus dem reading batNotOkFirstTime für den oldBat eintrag im dialog verwendet.
2. der zähler batNotOkCtr wird beim schreiben des attr comment über den dialog wieder auf 0 gesetzt.
3. das battery-icon wird gelb dargestellt stat grün, wenn "battery=ok & batNotOkCtr > 0" ist, also nach einer batterieerholung.
4. der tooltip des battery-icons zeigt zusätzlich den wert des zählers batNotOkCtr an.

1. und 2. ist bereits mit der aktuellen version 2009 möglich
3. und 4. ab version 2010, die bei mir bereits läuft.

[CottonIJo]

Hallo frank, danke für die Mühe die Du dir machst technisches Wissen zu vermitteln und für die Hilfestellungen mehr Licht in das Dunkel zu bringen.

Ich werde Deine Empfehlungen in die betroffenen devices einbauen und beobachten ob sich die dann ergebenden Informationen nutzen lassen verlässlicher auf den Status des Batteriezustands reagieren zu können.
HMinfo nutze ich jetzt auch in dem von Dir empfohlenen Umfang.
Meine Sorgenkinder sind alle devices die kein Reading batteryLevel haben, den man als Grenzwert schön abfragen kann.
Ich kann mich aber Deiner Meinung bezüglich der Notwendigkeit von Attributen, um den Batteriezustand ermitteln zu können, nicht ganz anschließen.
Ich erwarte von einem Gerät, welches "OK" senden kann, dass es auch zustandsbedingt "nicht OK" sendet, sonst brauche ich die Meldung nicht.
Als Anwender erwarte ich nicht, dass ich hier Aufwand investieren muss damit es verwendbar funktioniert.
Auf Firmware-Seite kann es kein Hexenwerk sein von sich aus zyklisch eine Meldung an den Master (fhem oder CCUx) zu schicken.
Was ist das für ein Ansatz, lebenswichtige Attribute nur zu senden, wenn ich angestoßen werde oder eine Aktion angefordert wird?
Ich habe an jedem Kellerfenster unseres Hauses je einen Sensor am Rahmen und am Fenstergriff, im Winter werden die Fenster seltener als im Sommer geöffnet.
Ergo ist es mir schon mehrfach passiert, dass der Batteriestatus auf "OK" stand, die Batterie(n) aber leer war(en)
Weder in der Bedienungsanleitung von EQ3 noch im Wiki von fhem steht drin, dass empfohlen wird eine Batterieüberwachung in fhem zu implementieren.

Jetzt würde mich interessieren, bin ich der Einzige der nicht weiß, dass man und wie man hier selbst Abhilfe schaffen sollte (Attribute setzen) oder geht es Anderen ebenso?

Grüße Joachim

[frank]

Auf Firmware-Seite kann es kein Hexenwerk sein von sich aus zyklisch eine Meldung an den Master (fhem oder CCUx) zu schicken.

ist es ja auch nicht. per default ist es aber nun mal ausgeschaltet.
vermutlich weil die devices auch ohne zentrale genutzt werden können und in diesem fall eine zyklische meldung nur unnötig batterielaufzeit kostet.

das einschalten von cyclicInfoMsg wird auch im wiki empfohlen, und nicht nur an einer stelle. 
https://wiki.fhem.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt#Batteriestatus_aktivieren
https://wiki.fhem.de/wiki/HomeMatic_Type_threeStateSensor
https://wiki.fhem.de/wiki/Trick_der_Woche#Juni_2014


mit der 98_HMinfo.pm von hier https://forum.fhem.de/index.php/topic,120857.msg1243902.html#msg1243902 ist es auch möglich das "attr hminfo sumERROR" mit dem eintrag "batNotOkCtr:0" zu erweitern, damit in HMinfoTools.js auch devices einen fehler zeigen, bei denen das reading batNotOkCtr > 0 ist.
also auch devices, die aktuell batstatus=ok haben, aber bereits mindestens einmal low hatten (batterie hat sich nach einem low nochmal erholt)

[CottonIJo]

@frank, ok, bin bezüglich fhem wieder etwas schlauer geworden.
Noch eine Frage zu cyclicInfoMsg beim HM-RC-4-3 (Fernbedienung)
Das Reading gibt es bei dem device wohl nicht.
Dies führt dazu, dass trotz actCycle = 002:00 das device bis zu einem Tastendruck dead bleibt.

Somit bleibt eine gewisse Ungenauigkeit der aktuellen Kapazität der Batterie?
Oder gibt es hier einen Parameter den man hilfsweise setzen könnte?

Code Auswählen Erweitern


Internals:
   CFGFN      ./FHEM/include/fhem_dachgeschoss.cfg
   DEF        6AAE22
   FUUID      5d188579-f33f-8c2a-cff1-0e60579bc9bcbaa9
   IODev      myHmUART
   LASTInputDev RM_HmUART_UG
   MSGCNT     15
   NAME       20_DG_SZ_Remote_Control2
   NR         993
   NTFY_ORDER 48-20_DG_SZ_Remote_Control2
   RM_HmUART_UG_MSGCNT 8
   RM_HmUART_UG_RAWMSG 05000047F1A2406AAE224C3DF44212
   RM_HmUART_UG_RSSI -71
   RM_HmUART_UG_TIME 2022-11-03 07:19:30
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 20_DG_SZ_Remote_Control2_Btn_01
   channel_02 20_DG_SZ_Remote_Control2_Btn_02
   channel_03 20_DG_SZ_Remote_Control2_Btn_03
   channel_04 20_DG_SZ_Remote_Control2_Btn_04
   disableNotifyFn 1
   eventCount 7
   lastMsg    No:F1 - t:40 s:6AAE22 d:4C3DF4 4212
   myHmUART_MSGCNT 7
   myHmUART_RAWMSG 05010041F1A2406AAE224C3DF44212
   myHmUART_RSSI -65
   myHmUART_TIME 2022-11-03 07:19:30
   protLastRcv 2022-11-03 07:19:30
   protRcv    8 last_at:2022-11-03 07:19:30
   protSnd    2 last_at:2022-11-03 07:19:30
   protState  CMDs_done
   rssi_at_RM_HmUART_UG cnt:8 min:-77 max:-70 avg:-73.12 lst:-71
   rssi_at_myHmUART cnt:7 min:-79 max:-65 avg:-71.14 lst:-65
   READINGS:
     2022-11-03 09:25:07   Activity        dead
     2022-11-04 11:17:37   Batt_timestamp_SZ_Remote_Control2 2022-11-03 07:19:30
     2019-06-30 12:10:04   CommandAccepted yes
     2019-06-30 12:10:03   D-firmware      1.1
     2019-06-30 12:10:03   D-serialNr      PEQ0781061
     2022-11-03 07:19:30   IODev           myHmUART
     2022-03-14 08:05:58   PairedTo        0x4C3DF4
     2019-06-30 12:10:05   R-pairCentral   0x4C3DF4
     2022-03-14 08:05:58   RegL_00.        00:00 02:01 0A:4C 0B:3D 0C:F4 18:00
     2022-03-13 10:51:43   alive           yes
     2022-11-03 07:19:30   battery         ok
     2022-11-04 11:17:37   cfgState        ok
     2022-11-03 07:19:30   commState       CMDs_done
     2022-03-13 10:51:43   powerOn         2022-03-13 10:51:43
     2022-03-13 10:51:43   recentStateType info
     2022-11-03 07:19:30   state           CMDs_done
   helper:
     HM_CMDNR   241
     lastMsgTm  1667456370.19748
     mId        00D4
     peerFriend -
     peerOpt    -:remote
     regLst     0
     rxType     28
     supp_Pair_Rep 0
     tmplChg    0
     ack:
     cmds:
       TmplKey    :no:1667306714.58214
       TmplTs     1667306714.58214
       cmdKey     0:1:0::20_DG_SZ_Remote_Control2:00D4:01:
       cmdLst:
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +6AAE22,00,00,00
       nextSend   1667456370.49369
       rxt        2
       vccu       VCCU
       p:
         6AAE22
         00
         00
         00
       prefIO:
         RM_HmUART_DG
     mRssi:
       mNo        F1
       io:
         RM_HmUART_UG:
           -71
           -71
         myHmUART:
           -61
           -61
     peerIDsH:
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         myHmUART
       flg        A
       ts         1667456370.19748
       ack:
         HASH(0x29a36a8)
         F180024C3DF46AAE2200
     rssi:
       at_RM_HmUART_UG:
         avg        -73.125
         cnt        8
         lst        -71
         max        -70
         min        -77
       at_myHmUART:
         avg        -71.1428571428572
         cnt        7
         lst        -65
         max        -65
         min        -79
     shadowReg:
     tmpl:
Attributes:
   IOgrp      VCCU:RM_HmUART_DG
   actCycle   002:00
   actStatus  dead
   alias      20_DG_SZ_Remote_Control2
   autoReadReg 5_readMissing
   comment    Btn_02 - Taste ganz oben
"long" - Rollladen ganz auf
"short" - Rollladen 10%-Schritt hoch

Btn_01 - Taste 2. von oben
"long" - Abschattung 45%
"short" - Rollladen "stop"

Btn_04 - Taste 3. von oben
"long" - Abschattung 20%
"short" - Rollladen "stop"

Btn_03 - Taste ganz unten
"long" - Rollladen ganz zu
"short" - Rollladen 10%-Schritt runter
   event-on-change-reading .*
   expert     defReg,rawReg
   firmware   1.1
   group      Remote-Control
   icon       it_remote
   model      HM-RC-4-3
   room       20_Dachgeschoss->Schlafzimmer
   serialNr   PEQ0781061
   subType    remote
   userReadings Batt_timestamp_SZ_Remote_Control2 {ReadingsTimestamp("20_DG_SZ_Remote_Control2","battery","")}
   webCmd     getConfig:clear msgEvents


Grüße Joachim

[frank]

bei der fb gibt es wohl keine möglichkeit zum einstellen.
eventuell sendet diese aber per default trotzdem regelmässig, da sie angeblich den mode wakeup unterstützt. allerdings bleibt die frage, in welchem abstand diese meldungen kommen könnten.
das müsstest du wohl selber testen.

dann wären die eingestellten 2 std für den actiondetector vielleicht nur zu kurz gewählt.
den längsten zyklus, den ich kenne, haben die rauchmelder mit etwa 3 tagen. da setzt cul_hm den actioncycle automatisch auf 99 std.

wie oft wird sie denn benutzt?
falls sie in der regel 1x die woche benutzt wird, könntest du zb 168 std setzen. falls trotzdem mal dead kommt, wäre das eine erinnerung zum knöpfchen drücken.
eine woche sollten batterien mindestens nach der ersten low meldung noch funktionieren, eher mehr denke ich. es sei denn sie sind tief in einer handtasche vergraben und werden aus versehen durch andere gegenstände permanent gedrückt. 

[CottonIJo]

Danke, probier ich aus.