[Gelöst] HM-SEC-SC-2 und das Reading battery

[maxritti]

Guten Abend zusammen,

was könnte die Ursache sein, dass meine HM-SEC-SC-2 Devices kein Reading battery mehr haben?
Aufgefallen ist mir das bei einer Readinggroup, wo ich den Batteriestatus verschiedener Geräte überwache.

Sämtliche Tür/Fensterkontakte tauchten nicht mehr auf. Als ich mal eine Tür geöffnet habe, tauchte das Device in der ReadingsGroup auch wieder auf. Allerdings nur aufgrund des Wertes des Readings "Status".

Mache ich ein list auf ein HM-SEC-SC-2 taucht da auch kein Battery mehr auf.

Hat da einer eine Idee, was hier schief gelaufen sein kann?

Ich habe heute zwar einiges rumgebaut, da ich meine Rollosteuerung auf HM Rollokaktoren umgestellt habe.
Bin mir das allerdings keiner Schuld bewusst. Kann aber ein Änderung auch nicht zu 100% ausschliessen. 

[martinp876]

sollte eigentlich kommen.
Kannst du ein log der messages des SC schicken?

[maxritti]

Hi,

ich habe jetzt mal nach folgenden Artikel die Loglevel gesetzt und fhem sicherheitshabler mal neu gestartet.

http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen

Da bekam ich im Web bei den Events das hier wo ich eine Tür geöffnet habe.

Code Auswählen Erweitern

2014-02-23 15:48:31.262 readingsGroup rg_Batterie_TK EG_wz_TK_Terrasse.state: open
2014-02-23 15:48:31.263 CUL_HM EG_wz_TK_Terrasse open
2014-02-23 15:48:31.263 CUL_HM EG_wz_TK_Terrasse contact: open (to myHMLAN)

Im fhem-log steht das hier:

Code Auswählen Erweitern

2014.02.23 15:48:31.143 0: HMLAN_Parse: myHMLAN R:E219AB4   stat:0000 t:0A6C97BA d:FF r:FFCD     m:D2 A441 219AB4 9A234E 01C7C8
2014.02.23 15:48:31.145 0: HMLAN_Send:  myHMLAN I:+219AB4,00,00,
2014.02.23 15:48:31.244 0: HMLAN_Send:  myHMLAN S:+219AB4,00,01,FE1F
2014.02.23 15:48:31.245 0: HMLAN_Send:  myHMLAN S:S5F3807ED stat:  00 t:00000000 d:01 r:5F3807ED m:D2 8002 9A234E 219AB4 0101C800
2014.02.23 15:48:31.473 0: HMLAN_Parse: myHMLAN R:R5F3807ED stat:0002 t:00000000 d:FF r:7FFF     m:D2 8002 9A234E 219AB4 0101C800
2014.02.23 15:48:39.688 0: HMLAN_Send:  myHMLAN I:K
2014.02.23 15:48:39.696 0: HMLAN_Parse: myHMLAN V:03C1 sNo:JEQ0707500 d:1E9CFA O:9A234E t:0A6CB964 IDcnt:000A
2014.02.23 15:49:04.706 0: HMLAN_Send:  myHMLAN I:K
2014.02.23 15:49:04.713 0: HMLAN_Parse: myHMLAN V:03C1 sNo:JEQ0707500 d:1E9CFA O:9A234E t:0A6D1B20 IDcnt:000A
2014.02.23 15:49:29.709 0: HMLAN_Send:  myHMLAN I:K
2014.02.23 15:49:29.715 0: HMLAN_Parse: myHMLAN V:03C1 sNo:JEQ0707500 d:1E9CFA O:9A234E t:0A6D7CD0 IDcnt:000A
2014.02.23 15:49:54.717 0: HMLAN_Send:  myHMLAN I:K
2014.02.23 15:49:54.723 0: HMLAN_Parse: myHMLAN V:03C1 sNo:JEQ0707500 d:1E9CFA O:9A234E t:0A6DDE82 IDcnt:000A
2014.02.23 15:50:01.461 0: HMLAN_Parse: myHMLAN R:E1C5513   stat:0000 t:0A6DF85F d:FF r:FFB6     m:EA 8410 1C5513 9A234E 06013A00


Ich sehe da mal nicht wirklich viel von dem Fensterkontakt.

Daraufhin habe ich verbose mal auf 5 gesetzt.

Dann wieder im Eventviewer die Meldungen:

Code Auswählen Erweitern

Events:
2014-02-23 15:51:16.469 readingsGroup rg_Batterie_TK EG_wz_TK_Terrasse.state: open
2014-02-23 15:51:16.470 CUL_HM EG_wz_TK_Terrasse open
2014-02-23 15:51:16.470 CUL_HM EG_wz_TK_Terrasse contact: open (to myHMLAN)

Im fhemlog steht nun mehr:

Code Auswählen Erweitern

2014.02.23 15:51:16.347 5: HMLAN/RAW: /E219AB4,0000,0A6F1D60,FF,FFCE,D4A441219AB49A234E01C9C8

2014.02.23 15:51:16.347 0: HMLAN_Parse: myHMLAN R:E219AB4   stat:0000 t:0A6F1D60 d:FF r:FFCE     m:D4 A441 219AB4 9A234E 01C9C8
2014.02.23 15:51:16.347 5: myHMLAN dispatch A0CD4A441219AB49A234E01C9C8::-50:myHMLAN
2014.02.23 15:51:16.348 5: CUL_HM EG_wz_TK_Terrasse prep ACK for 1
2014.02.23 15:51:16.448 0: HMLAN_Send:  myHMLAN S:S5F3A8D40 stat:  00 t:00000000 d:01 r:5F3A8D40 m:D4 8002 9A234E 219AB4 0101C800
2014.02.23 15:51:16.449 5: CUL_HM EG_wz_TK_Terrasse protEvent:CMDs_done
2014.02.23 15:51:16.450 5: CUL_HM EG_wz_TK_Terrasse sent ACK:2
2014.02.23 15:51:16.450 5: Triggering EG_wz_TK_Terrasse (2 changes)
2014.02.23 15:51:16.450 5: Notify loop for EG_wz_TK_Terrasse open
2014.02.23 15:51:16.451 4: eventTypes: CUL_HM EG_wz_TK_Terrasse open -> open
2014.02.23 15:51:16.451 4: eventTypes: CUL_HM EG_wz_TK_Terrasse contact: open (to myHMLAN) -> contact: open (to myHMLAN)
2014.02.23 15:51:16.452 5: DbLog: logging of Device: EG_wz_TK_Terrasse , Type: CUL_HM , Event: open , Reading: state , Value: open , Unit:
2014.02.23 15:51:16.458 5: DbLog: logging of Device: EG_wz_TK_Terrasse , Type: CUL_HM , Event: contact: open (to myHMLAN) , Reading: contact , Value: open (to myHMLAN) , Unit:
2014.02.23 15:51:16.463 5: Triggering rg_Batterie_TK (1 changes)
2014.02.23 15:51:16.464 5: Notify loop for rg_Batterie_TK EG_wz_TK_Terrasse.state: <img class='icon signal_Fenster_Offen_on' src="/fhem/images/default/signal_Fenster_Offen.on.png" alt="open" title="open">
2014.02.23 15:51:16.464 4: eventTypes: readingsGroup rg_Batterie_TK EG_wz_TK_Terrasse.state: <img class='icon signal_Fenster_Offen_on' src="/fhem/images/default/signal_Fenster_Offen.on.png" alt="open" title="open"> -> EG_wz_TK_Terrasse.state: <img class='icon signal_Fenster_Offen_on' src="/fhem/images/default/signal_Fenster_Offen.on.png" alt="open" title="open">
2014.02.23 15:51:16.464 5: DbLog: logging of Device: rg_Batterie_TK , Type: READINGSGROUP , Event: EG_wz_TK_Terrasse.state: <img class='icon signal_Fenster_Offen_on' src="/fhem/images/default/signal_Fenster_Offen.on.png" alt="open" title="open"> , Reading: EG_wz_TK_Terrasse.state , Value: <img class='icon signal_Fenster_Offen_on' src="/fhem/images/default/signal_Fenster_Offen.on.png" alt="open" title="open"> , Unit:
2014.02.23 15:51:16.477 4: HTTP FHEMWEB:192.168.178.51:51772 GET /fhem/images/default/signal_Fenster_Offen.on.png
2014.02.23 15:51:16.829 5: HMLAN/RAW: /R5F3A8D40,0002,00000000,FF,7FFF,D480029A234E219AB40101C800

2014.02.23 15:51:16.829 0: HMLAN_Parse: myHMLAN R:R5F3A8D40 stat:0002 t:00000000 d:FF r:7FFF     m:D4 8002 9A234E 219AB4 0101C800
2014.02.23 15:51:18.106 0: HMLAN_Send:  myHMLAN I:K
2014.02.23 15:51:18.116 5: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707500,1E9CFA,9A234E,0A6F244E,000A

2014.02.23 15:51:18.116 0: HMLAN_Parse: myHMLAN V:03C1 sNo:JEQ0707500 d:1E9CFA O:9A234E t:0A6F244E IDcnt:000A

Nur ich fürchte, dass war nicht, dass was Du an Log sehen wolltest oder?

Da müsstest Du mir vielleicht noch den Schieber in die richtige Richtung geben.

[martinp876]

Hi
Di Messages sind das gesuchte.

wenn dein sec-sc-2 der 1C5513 ist sollte ein Batterie-reading zu sehen sein.
so der 219AB4 den SC-2 ist ist das Problem, dass er einfach keinen Status sendet (weil er keinen Grund hat).
Er würde also nur zyklisch bein Aufwachen etwas senden - so z.B. beim aufwachen, wenn CYCLIC_INFO_MSG gesetzt ist.

Gruss Martin

[maxritti]

1C5513 ist ein Motion Detector, mag sein, dass der dazwischen gefunkt hat. Und der hat das Readings battery.

219AB4 ist ein HM-SEC-SC also ohne "-2". Aber alle anderen 4 Fensterkontakte (die HM-SEC-SC-2 also mit "-2" sind) verhalten sich gleich.
Der ohne "-2" war auch der erste Kontakt, den ich zum spielen hatte. Die anderen kamen dann später.

Kann man das mit dem aufwachen bzw CYCLIC_INFO_MSG denn beeinflussen?
Vielleicht durch ein neues anlernen?

Wobei das doch komisch ist, dass der nichts meldet oder?
Was wäre denn, wenn die Batterie jetzt real leer würde?
Kommt dann solch ein CYCLIC_INFO_MSG?

[maxritti]

Gerade habe ich bei dem SC mal auf anlernen gedrückt.
Nun ist battery wieder da.

Aber kann es das sein?

[martinp876]

Gerade habe ich bei dem SC mal auf anlernen gedrückt.Nun ist battery wieder da.
Aber kann es das sein?

schon - da wacht der SC auch auf.

Kann man das mit dem aufwachen bzw CYCLIC_INFO_MSG denn beeinflussen?

absolut. Der SC sendet den Status (auch Batterie) in der Status-message. Wenn das Fenster auf geht kommt eine trigger-message ohne Batterie status.
Wir brauchen also eine Statusmessage. Abfragen kann man das Device nicht, also muss man warten, bis es erwacht, dann sendet es freiwillig den Status incl Batterie.
Und jetzt musst du cyclicInfo einschalten, damit genau dies passiert.

Was wäre denn, wenn die Batterie jetzt real leer würde?
Kommt dann solch ein CYCLIC_INFO_MSG?

wohl nicht, wäre auch von der Benamung ein wiederspruch. Und wenn die Batterie leer ist, kommt eh nichts mehr - das soll dann der ActionDetector abdecken. Ein Device kann immer nur ok oder low melden, nie leer.

Devices dieses Typs senden, wenn eingeschaltet alle 24h eine message. Ich hoffe das funktioniert - du solltest alle 24h einen Batterie-status bekommen (siehe timestamp des Readings). Das sollte  ausreichend sein, da eine low batterie eh noch mehrere Tage funktionieren sollte.
Wenn das nicht passiert muessen wir einmal prüfen, dass cyclic-info-message korrekt eingeschaltet ist - der zu schreibenden Wert ist nicht exact beschrieben. Also beobachten und zeichne auf (min 2 Tage)- ggf müssen wir den registerwert anpassen.

Gruss Martin

[maxritti]

Hi Martin,

vielen Dank für Deine Infos.
Ehrlich gesagt, ganz klar ist es mir nicht. Aber ich warte jetzt einfach mal ab.
Denn ich habe nun alle Devices mal durch Anlerntaste wieder ins Leben gerufen. Sehe also wieder alle Battery Statuswerte.

Keine Ahnung, warum die gestern mal verschwunden sind.

Sollten die noch mal verschwinden, krame ich das Posting hier wieder vor.

Gruß und noch einen schönen Sonntag.

[maxritti]

Push.
Da ist das Post wieder 

Gestern morgen gab es ja leider dieses Problem mit der 10_CUL_HM.pm
Nachdem ich aus der Datensicherung die alte Datei wiederhergestellt hatte lief soweit auch alles wieder.

Bis auf die ReadingsGroup.
Siehe dazu auch hier:

http://forum.fhem.de/index.php/topic,16503.msg157251.html#msg157251

Wobei sich da ja rausstellte, dass das wohl kein kein Bug im Dashbord war.
Denn heute nach einem neuerlichen Update tauchen bei mir nach wie vor keine Battery Werte meiner Tür- / Fensterkontakte auf.
Auch nach 24 Stunden warten nichts zu sehen.

Hier mal ein list eines Kontaktes:

Code Auswählen Erweitern

Internals:
   DEF        24F642
   IODev      myHMLAN
   NAME       EG_wz_TK_Carport
   NR         65
   STATE      ???
   TYPE       CUL_HM
   CHANGETIME:
   Helper:
     Dblog:
       Activity:
         Mydblog:
           TIME       1397113014.62922
           VALUE      unknown
       Addlog:
         Mydblog:
           TIME       1397152609.25932
           VALUE      invalid reading
   Readings:
     2014-04-10 08:56:54   Activity        unknown
     2014-04-09 10:37:31   D-firmware      2.4
     2014-04-09 10:37:31   D-serialNr      KEQ1097292
   Helper:
     mId        00B1
     rxType     12
     Io:
       newChn     +24F642,00,01,1E
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf   00
       qReqStat   
     Role:
       chn        1
       dev        1
Attributes:
   IODev      myHMLAN
   actCycle   028:00
   actStatus  unknown
   alias      Carport
   autoReadReg 4_reqStatus
   devStateIcon closed:fts_door_right open:fts_door_right_open
   expert     2_full
   firmware   2.4
   group      Uebersicht
   model      HM-SEC-SC-2
   peerIDs    00000000,
   room       Wohnzimmer
   serialNr   KEQ1097292
   subType    threeStateSensor


Ich hoffe dass Du martin hier was erkennen kannst, warum die Batteriewerte nicht von selber wieder ins Fhemweb kommen.

Vermutlich muss ich in der Tat mal cyclicInfo aktivieren.
Nur wie mache ich das?

[martinp876]

Die Konfiguration ist nicht zu sehen. Du musst also ein getConfig absetzen und anlernen drücken. dann attr expert auf 1 - danach sehen was drin steht.

Cyclic Info ist ein ganzes Byte - du kannst also auch gleich schreiben....

set EG_wz_TK_Carport regSet cyclicInfoMsg on
set EG_wz_TK_Carport getConfig
=> anlernen drücken

[Michi240281]

Ich hab die Tage von FB auf RPi umgezogen und danach haben auch alle batteriebetriebenen Devices kein battery reading mehr gehabt. Hab überall mal die Batterien rausgenommen, getConfig gemacht und Anlerntaste kurz gedrückt, danach war alles wieder ok! Was das mit dem Umzug zu tun hatte, weiß ich jedoch nicht, aber es kam irgendwie davon.

[martinp876]

haben den die Batteriemeldungen einen aktuellen Zeitstempel - je nach device bis zu 3 Tage alt

[maxritti]

Die Konfiguration ist nicht zu sehen. Du musst also ein getConfig absetzen und anlernen drücken. dann attr expert auf 1 - danach sehen was drin steht.

Cyclic Info ist ein ganzes Byte - du kannst also auch gleich schreiben....

set EG_wz_TK_Carport regSet cyclicInfoMsg on
set EG_wz_TK_Carport getConfig
=> anlernen drücken

Hi Martin,

das schaut gut aus.
Das Register cyclicInfoMsg ist jetzt on.

Danke dir

[hauwech]

Hallo zusammen,

ich hole den thread nochmal aus der Versenkung. Mein Fensterkontakt (ein HM-SEC-SC-2) meldet auch keinen Batteriestatus mehr, mein Kollege hat das gleiche Problem. Der letzte gemeldete Batteriestatus ist vom 11.04., das Datum deckt sich mit dem vorletzten Beitrag, weil ich den thread verfolgt habe. cyclicInfoMsg ist "on".
Mir ist aufgefallen, daß der FK den Status scheinbar nur auf "Anlernen" sendet, auch CMD's wie getConfig bleiben mehrere Tage auf pending, bis man auf Anlernen drückt. Das ist doch sicher nicht im Sinne des Erfinders, er sollte eigentlich einmal am Tag aufwachen und den Status senden, oder? Trigger open/closed werden aber gesendet.
Hier noch ein "list" des FK:

Code Auswählen Erweitern

Internals:
   DEF        24D474
   HMLAN1_MSGCNT 14
   HMLAN1_RAWMSG E24D474,0000,083C4AD9,FF,FFBA,ABA24124D474272DDE014EC8
   HMLAN1_RSSI -70
   HMLAN1_TIME 2014-04-16 09:48:04
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     14
   NAME       AnbauBadFenster
   NR         71
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:AB - t:41 s:24D474 d:272DDE 014EC8
   peerList   AnbauBadHeizung_WT_WindowRec,
   protCondBurst unknown
   protLastRcv 2014-04-16 09:48:04
   protSnd    7 last_at:2014-04-16 09:48:04
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-81.07 min:-100 max:-70 lst:-70 cnt:14
   Readings:
     2014-04-14 11:19:56   Activity        alive
     2014-04-11 16:36:21   CommandAccepted yes
     2014-04-11 16:36:20   D-firmware      2.2
     2014-04-11 16:36:20   D-serialNr      KEQ0950621
     2014-04-11 16:36:21   PairedTo        0x272DDE
     2014-04-11 16:36:23   R-AnbauBadHeizung_WT_WindowRec-expectAES off
     2014-04-11 16:36:23   R-AnbauBadHeizung_WT_WindowRec-peerNeedsBurst on
     2014-04-11 16:36:21   R-cyclicInfoMsg on
     2014-04-11 16:36:21   R-eventDlyTime  0 s
     2014-04-11 16:36:21   R-ledOnTime     0.5 s
     2014-04-11 16:36:21   R-msgScPosA     closed
     2014-04-11 16:36:21   R-msgScPosB     open
     2014-04-11 16:36:21   R-pairCentral   0x272DDE
     2014-04-11 16:36:21   R-sabotageMsg   on
     2014-04-11 16:36:21   R-transmDevTryMax 6
     2014-04-11 16:36:21   R-transmitTryMax 6
     2014-04-11 16:36:21   RegL_00:        02:01 09:01 0A:27 0B:2D 0C:DE 10:01 14:06 00:00
     2014-04-11 16:36:21   RegL_01:        08:00 20:60 21:00 22:64 30:06 00:00
     2014-04-11 16:36:23   RegL_04:AnbauBadHeizung_WT_WindowRec 01:01 00:00
     2014-04-11 16:37:06   alive           yes
     2014-04-11 16:37:06   battery         ok
     2014-04-16 09:48:04   contact         open (to HMLAN1)
     2014-04-11 16:37:06   cover           closed
     2014-04-14 11:19:56   peerList        AnbauBadHeizung_WT_WindowRec,
     2014-04-11 16:37:06   recentStateType info
     2014-04-16 09:48:04   state           open
   Helper:
     mId        00B1
     rxType     12
     Io:
       newChn     +24D474,00,01,1E
       nextSend   1397634484.43161
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1397634484.34105
       ack:
         HASH(0x2766868)
         AB8002272DDE24D4740101C800
     Rssi:
       At_hmlan1:
         avg        -81.0714285714286
         cnt        14
         lst        -70
         max        -70
         min        -100
Attributes:
   IODev      HMLAN1
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   burstAccess 1_auto
   devStateIcon open:fts_window_1w_open@red open closed:fts_window_1w@green
   expert     2_full
   firmware   2.2
   fp_Anbau   130,220,1,Fenster
   group      Fenster-Türen
   model      HM-SEC-SC-2
   peerIDs    00000000,2702B303,
   room       Übersicht
   serialNr   KEQ0950621
   subType    threeStateSensor

Das R-eventDlyTime für den HM-SEC-SC-2 ist aber auch neu, oder?

Gruß Roland

[martinp876]

Hallo Roland,

kannst du einmal ein getConfig machen und es aufzeichnen (rohmessages)? Ich will nur sicher gehen, dass das Register auch wirklich an ist. Bitte anlernen drücken in diesem Fall.

Wenn das Device keine zyklische Message schickt werden auch nie automatisch kommandos abgearbeitet - das ist klar. Auch die Batteriemeldung kommt nur bei Anlernen und in der automatischen message - sonst eben nicht.
Das letzte Lesen ist vom 11.4. (mindestens).
HMInfo

Das ist doch sicher nicht im Sinne des Erfinders, er sollte eigentlich einmal am Tag aufwachen und den Status senden, oder? Trigger open/closed werden aber gesendet.

ja.

Das R-eventDlyTime für den HM-SEC-SC-2 ist aber auch neu, oder?

möglich

Sollten kommandos "hängen" wird dies in HMInfo 'summiert' angezeigt. Auch Pending wird reported.

Gruss Martin