Absterben von HM-LC-SW1-BA-PCB

[Prof. Dr. Peter Henning]

Ich habe einen nagelneuen HM-LC-SW1-BA-PCB (Schaltaktor für Batteriebetrieb), Firmware 1.7, ordentlich gepaired und gepeered. Leider taucht das Problem auf, dass der sich nach einer (noch) nicht genau bestimmten Zeit verabschiedet: Alle Kommandos werden dann ignoriert, MISSING ACK

Nach derzeitiger Beobachtung ist dies nach ein paar Stunden der Fall, kann aber auch kürzer sein.

Drückt man in diesem Fall die Anlerntaste für 3 Sekunden, meldet er sich wieder bei der HMCCU - bis er nach einiger Zeit wieder abstirbt.

Dieses Verhalten ist reproduzierbar, und neu: Mit einem entsprechenden Gerät unter FW Version 1.6 trat das im jahrelangen Betrieb nicht auf.

Hat jemand eine Idee, woran das liegen kann ?

LG

pah

Hier das Listing

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        66C09C
   HMCFG_MSGCNT 393
   HMCFG_RAWMSG R5605DBBD,0021,02ADA021,01,FFCD,AD800266C09C0000410101C880374D76E6B4
   HMCFG_RSSI -51
   HMCFG_TIME 2018-08-20 08:29:09
   HMLAN_MSGCNT 332
   HMLAN_RAWMSG E66C09C,0000,02AB8EDA,FF,FFC2,AD800266C09C0000410101C880374D76E6B4
   HMLAN_RSSI -62
   HMLAN_TIME 2018-08-20 08:29:09
   IODev      HMCFG
   LASTInputDev HMCFG
   MSGCNT     725
   NAME       A.Hof.Tuer.A
   NOTIFYDEV  global
   NR         26807
   STATE      unlocked
   TYPE       CUL_HM
   lastMsg    No:AD - t:02 s:66C09C d:000041 0101C880374D76E6B4
   peerList   A.Hof.Tuer.Btn,
   protCmdDel 110
   protCondBurst unknown
   protEvt_AESCom-ok 91 last_at:2018-08-20 08:29:09
   protIOdly  6 last_at:2018-08-19 22:50:49
   protIOerr  5 last_at:2018-08-19 22:51:49
   protLastRcv 2018-08-20 08:29:09
   protResnd  48 last_at:2018-08-20 06:30:23
   protResndFail 46 last_at:2018-08-20 06:30:27
   protSnd    375 last_at:2018-08-20 08:29:09
   protState  CMDs_done
   rssi_HMCFG cnt:79 min:-68 max:-52 avg:-55.4 lst:-55
   rssi_HMLAN cnt:40 min:-67 max:-54 avg:-63.1 lst:-63
   rssi_at_HMCFG cnt:312 min:-72 max:-46 avg:-54.45 lst:-51
   rssi_at_HMLAN cnt:311 min:-79 max:-56 avg:-61.99 lst:-62
   READINGS:
     2018-08-19 22:44:06   Activity        alive
     2018-08-20 08:29:09   CommandAccepted yes
     2018-08-20 08:26:47   D-firmware      1.7
     2018-08-20 08:26:47   D-serialNr      OEQ2624669
     2018-08-20 08:28:50   PairedTo        0x000041
     2018-08-18 10:12:47   R-A.Hof.Tuer.Btn-lgActionType jmpToTarget
     2018-08-18 10:12:47   R-A.Hof.Tuer.Btn-shActionType jmpToTarget
     2018-08-20 08:26:52   R-pairCentral   0x000041
     2018-08-19 10:41:07   R-sign          on
     2018-08-20 08:28:50   RegL_00.          02:01 05:00 0A:00 0B:00 0C:41 12:69  00:00
     2018-08-20 08:28:50   RegL_01.         08:01 00:00
     2018-08-20 08:28:52   RegL_03.A.Hof.Tuer.Btn  02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
     2018-08-20 08:29:09   aesCommToDev    ok
     2018-08-20 08:29:09   aesKeyNbr       02
     2018-08-20 08:29:09   battery         low
     2018-08-20 08:29:09   deviceMsg       on (to HMCCU)
     2018-08-20 08:29:09   level           100
     2018-08-20 08:29:09   pct             100
     2018-08-20 08:28:51   peerList        A.Hof.Tuer.Btn,
     2018-08-18 09:37:00   powerOn         2018-08-18 09:37:00
     2018-08-20 08:29:09   recentStateType ack
     2018-08-20 08:29:09   state           on
     2018-08-20 08:29:09   timedOn         off
     2018-08-18 10:16:42   trigLast        A.Hof.Tuer.Btn:long
     2018-08-18 10:16:42   trig_A.Hof.Tuer.Btn Long_2
   helper:
     HM_CMDNR   173
     PONtest    0
     cSnd       1100004166C09C0201C80000,1100004166C09C0201C80000
     dlvlCmd    ++A01100004166C09C0201C80000
     mId        006C
     peerIDsRaw ,00004101,00000000
     regLst     ,0,1,3p
     rxType     2
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +66C09C,00,01,00
       nextSend   1534746549.50286
       prefIO     
       rxt        0
       vccu       HMCCU
       p:
         66C09C
         00
         01
         00
     mRssi:
       mNo        AD
       io:
         HMCFG:
           -45
           -45
         HMLAN:
           -62
           -62
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       HMCFG:
         avg        -55.4050632911392
         cnt        79
         lst        -55
         max        -52
         min        -68
       HMLAN:
         avg        -63.1
         cnt        40
         lst        -63
         max        -54
         min        -67
       at_HMCFG:
         avg        -54.4583333333333
         cnt        312
         lst        -51
         max        -46
         min        -72
       at_HMLAN:
         avg        -61.9935691318328
         cnt        311
         lst        -62
         max        -56
         min        -79
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN
   IOgrp      HMCCU:HMLAN
   actCycle   600:00
   actStatus  alive
   autoReadReg 4_reqStatus
   burstAccess 1_auto
   devStateIcon locked:locked.svg unlocked:unlocked.svg
   devStateStyle style="text-align:left;;font-weight:bold;;"
   eventMap   /on:unlocked/off:locked/
   expert     2_raw
   firmware   1.7
   group      DoorControl
   model      HM-LC-SW1-BA-PCB
   msgRepeat  1
   peerIDs    00000000,00004101,
   room       Kontrollraum
   serialNr   OEQ2624669
   subType    switch
   webCmd      


[noansi]

Hallo Peter,

2018-08-20 08:29:09   battery         low

eventuell ist es das battery reading. Das steht auf low.

Möglicherweise schaltet die 1.7 Firmware dann nach einer gewissen Zeit auf absolutes Stromsparen, um die Batterie nicht bis zum Tod mit möglichem Auslaufen leer zu saugen?

Du hast das default lowBatLimitBA von 10.5V eingestellt.

Das Limit kannst Du bis runter auf 5V beim HM-LC-SW1-BA-PCB einstellen.

Ich habe nur Firmware 1.6 und kann daher das Verhalten leider nicht testen oder nachvollziehen.
Ich habe nur einen mit Firmware 1.6, bei dem es auf low (weil knapp unter 5V versorgt) steht und der macht trotzdem weiter.

Gruß, Ansgar.

[Prof. Dr. Peter Henning]

Den Verdacht hatte ich auch schon, betreibe deshalb seit gestern einen zweiten neuen Schalter - wird derzeit bei ansonsten Default-Einstellungen mit 14 V versorgt. Bisher kein Ausfall.

Edit: Doch, jetzt ist das Ding weg. Register ist auf 10.5 V, Spannungsversorgung war mit 14 V.

Edit Edit: Auch wenn man bei einer Spannungsversorgung das lowBat-Register auf 5 stellt, (und damit die batteryLow condition vermeidet), verabschiedet sich das Gerät nach ein paar Stunden 



Bei FW 1.6 habe ich das Problem ebenfalls nicht gehabt.
LG

pah

[greenBelt]

Einen anderen Seiteneffekt hatte ich mit dem Jalousieaktor HM-LC-Ja1PBU-FM. Dieser zeigte nach einem Jahr Betrieb exakt dieses Verhalten sodass nach dem erneuten Anlernen einige Stunden später ein Missing Ack in FHEM kam. Die Ursache konnte ich bisher nicht ermitteln. Habe letztendlich diesen Aktor gegen EnOcean (Eltako) getauscht. Da sich in dem Schalterverbund noch weitere Homematic Aktoren befinden gehe ich von einem Kommunikationsproblem aus. Daher verwende ich nun im Mix EnOcean bei meinen Jalousieaktoren.

Als mögliche Ursache vermute kann es auch ein Qualitätsproblem sein. Nach einem Jahr Bauteilalterung (in meinem Fall) sollte zwar nicht sein ist aber denkbar

Gruß,
Klaus

[Pfriemler]

Das ist ja alles ganz großer Mist.
Zurückschicken und ELV um Nachbesserung bitten.
Das Setup ist elektronisch sonst einwandfrei? Keine Versorgungsspikes?

[Prof. Dr. Peter Henning]

Ich habe jetzt parallel 2 x FW 1.7 und 1 x 1.6 im Test - bei den 1.7ern tritt das Problem reproduzierbar auf, mit unterschiedlichen Spannungsversorgungen.

Der erste Verdacht - lowBatt - hat sich nicht bestätigt.

Im Moment stelle ich fest, dass bei ledMode = on erst einmal keine Ausfälle auftreten. Warten wir mal den Tag ab.

LG

pah

[rr725]

Seit Jahren habe ich mehrere mit 1.6 installiert, mit 2*2 1,2v Akkus. Immer zeigten sie low batt an. Nie ein Problem gehabt.
Seit ein paar Tagen zickte einer von ihnen herum. Weder auf einer ccu, noch in fhem bekam ich ihn zum laufen.schaltete man via Taste an dem Modul, hat die Ccu und fhem den Status auch geändert, jedoch von der CDU, oder fhem kam ein Fehler.
Testweise hatte ich das Teil auf Werkseinstellungen resettet und neu angelernt. Problem blieb bestehen.
5v Netzteil angeschlossen. Werksreset, neu anlernen. Problem blieb bestehen.

Mittels 5v Netzteil Reset durchgeführt. Mit den Teilen in Richtung ccu (ca. 1m Abstand) anlernen- funktioniert.
Netzteil ab, wieder mit Akkus verbunden, läuft. An die alte Stelle verbracht,  nur das Modul etwas näher in Richtung ccu.
Alles gut. Evtl. hab ich dort in der Ecke seit neuestem eine Störquelle. Egal. Abwarten.....

[Prof. Dr. Peter Henning]

Hmmm.

Den 1.6er hatte ich seit 2015 im Außenbereich in Betrieb, vor vier Wochen ist er dann mit dem "Missing Ack" ausgestiegen. Daraufhin nach dem Urlaub ausgebaut, weil ich ihn für defekt hielt, und durch einen neuen 1.7er ersetzt - mit den beschriebenen Problemen.

Allerdings ist der 1.6er inzwischen mirakulös wieder zum Leben erwacht - und ist gegenwärtig im Vergleichstest mit den beiden 1.7ern. Und machte darin überhaupt keine Mucken, hat sich (im Gegensatz zu den 1.7ern) nicht einmal verabschiedet. Allerdings erfolgte dieser Test bisher im Innenbereich, also fast um die Ecke zum HMLAN.

Der 1.7er im Außenbereich verabschiedete sich bis heute früh nach wie vor in unregelmäßigen Abständen komplett. An ein Problem der Stromversorgung glaube ich nicht ganz - kann das aber noch nicht ausschließen, weil an diesen 5V auch das Panikschloss für die Hoftür hängt.

Der (Test-) 1.7er im Innenbereich lief einen halben Tag gut (lowBatt Register auf 10.5 V, Versorgung mit 14 V). Dann habe ich ihn (nach Strafandrohung meiner Liebsten...) vom Wohnzimmer in den Keller verlegt, woraufhin er sich nach einer Stunde verabschiedete (das war die Meldung drei Posts früher).

Ich habe im Außenbereich seit 2015 noch einen weiteren 1.6er laufen, einziger Unterschied: ledMode=on. Keine Ausfälle, keine Probleme.

Derzeit laufen die beiden 1.7er und der (alte) 1.6er testweise im Außenbereich (soll eigentlich heißen: In größerer Entfernung vom HMLAN), alle mit 5V und ledMode=on.

Sehn wir mal.

LG

pah

[FunkOdyssey]

Wo habt ihr denn die Firmware 1.7 für diesen Batterie-Aktor her?
Auf der eQ3-Homepage finde ich hierzu nichts.

[Prof. Dr. Peter Henning]

Ist drin gewesen, habe die Dinger vor 2 Wochen bei ELV neu bestellt.

LG

pah

[Prof. Dr. Peter Henning]

Ich antworte mir mal selbst:

Ob man es glaubt oder nicht, seit ich bei den beiden 1.7ern ledMode=on gesetzt habe, (heute morgen 8:00) ist keiner mehr "abgestorben".

Ich muss übrigens noch korrigieren: Der vierte Schaltaktor ist kein 1.6er und seit 2015 in Betrieb, sondern einer mit Firmware 1.5 und im Dauereinsatz seit 2014. Der macht am wenigstens Probleme...


LG

pah

[connormcl]

LED mode  auf on ist aber natürlich ein Batteriefresser... damit ist das Ding ja nicht mehr sinnvoll einsetzbar.

Was sagt denn ELV?

[Pfriemler]

LED mode  auf on ist aber natürlich ein Batteriefresser... damit ist das Ding ja nicht mehr sinnvoll einsetzbar.

Bei einem Aktor, der die meiste Zeit darauf wartet, für ein paar Sekunden aktiviert zu werden, ist das völlig unerheblich. Tür- und Garagentoröffner im Privatbereich etwa.

Übrigens befeuere ich seit Monaten einen -Ba mit ledMode off störungsfrei ... leider mit FW 1.5 ...

[Prof. Dr. Peter Henning]

Nee nee, das ist nicht schön.

24 Stunden hat es jetzt gehalten mit ledMode=on - und heute morgen sind die beiden 1.7er wieder mausetot.

Der eine ließ sich im 2. Versuch wieder wecken - der andere nicht.

LG

pah

[rr725]

Hm...da kam doch letztens ein Update des cul_hm Modul. Ich habe meine Batterie Aktoren mittlerweile auf ein raspberrymatic migriert.
Dort funktionieren sie wieder tadellos und zuverlässig. Ein klein wenig habe ich das cul_hm Modul im Verdacht. Nun kann ich aber nicht mehr sagen welche Aktion zum Erfolg führte. Weg von fhem und hin zu raspberrymatic, Reset auf Werkseinstellungen, etwas näher zum cul.