hm-sec-sc-2 kein Pairing nach Batteriewechsel

[Snocksman]

Hallo zusammen, ich musste bei einem meiner hm-sec-sc-2 die Batterien wechseln und scheinbar hat er dabei sein pairing verloren (beim öffnen / schließen der Tür leuchtet die LED nur noch kurz orange, aber nicht mehr grün). Nicht so schlimm, habe ihn zurückgesetzt, den CUL auf "set hmpairforsec 60" gesetzt und wollte den hm-sec-sc-2 durch drücken der Taste neu pairen... Problem: die LED blinkt nur ganz kurz orange und dann scheint sich das Device aufzuhängen (tut gar nichts mehr). Also nochmal zurückgesetzt und das Device in FHEM gelöscht. den CUL wieder auf pairing geschaltet und die pairing Taste am Device gedrückt (jetzt blinkt die LED auch orange, wie es sein sollte... allerdings hört sie nicht auf, bis der pairing Prozess irgendwann abbricht (LED leuchtet am Ende rot auf). FHEM legt das Device zwar an, es ist aber nicht sauber gepaired... Die LED leuchtet beim öffnen der Tür nach wie vor nur orange und in FHEM steht im Device: open (to broadcast). Das ganze habe ich jetzt schon X-mal wiederholt, ohne Erfolg.

Was kann das sein ? Bis zum Batteriewechsel hat das Device Problemlos funktioniert... 

Hier nochmal ein auszug des Logs, beim pairing / anlegen des Devices:

Code Auswählen Erweitern

2020.05.11 23:55:56 2: autocreate: define HM_2AD459 CUL_HM 2AD459
2020.05.11 23:55:56 2: autocreate: define FileLog_HM_2AD459 FileLog ./log/HM_2AD459-%Y.log HM_2AD459
2020.05.11 23:55:56 4: Skipping save, as autosave is disabled
2020.05.11 23:55:56 3: Device HM_2AD459 added to ActionDetector with 028:00 time
2020.05.11 23:55:56 4: Device HM_2AD459 is alive
2020.05.11 23:55:56 4: CUL_HM drop msg for HM_2AD459 with unknown model


[knopf_piano]

10_CUL_HM.pm wurde gestern aktualisiert. vielleicht alte version zurückspielen?
nur ne idee...

[Snocksman]

Ich hatte seit ca. 14 tagen kein Update mehr gemacht... Das kanns also eigentlich nicht sein. Habe jetzt gerade zum Test aber dann mal ein Update durchgeführt, da die 10_CUL_HM.pm ja aktualisiert wurde, das hat aber auch keine Besserung gebracht.

[frank]

zeig ein vernünftiges "list HM_2AD459".
devices zu löschen, ist selten hilfreich.

[Snocksman]

Das mit dem löschen des Devices war ja nur mal ein Versuch, aber kein Problem... Ich habe die Sicherung der Config, in der das Device noch vorhanden ist, wieder eingespielt.

Und hier ein list des Devices:

Code Auswählen Erweitern

Internals:
   CUL_0_MSGCNT 9
   CUL_0_RAWMSG A0C0384412AD459000000010200::-74:CUL_0
   CUL_0_RSSI -74
   CUL_0_TIME 2020-05-12 17:51:15
   DEF        2AD459
   FUUID      5c47a7a0-f33f-d11a-c587-b19fec36dbd15f58
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     9
   NAME       Tuer_Kueche
   NOTIFYDEV  global
   NR         44
   NTFY_ORDER 50-Tuer_Kueche
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:03 - t:41 s:2AD459 d:000000 010200
   protCmdDel 3
   protLastRcv 2020-05-12 17:51:15
   protRcv    9 last_at:2020-05-12 17:51:15
   protResndFail 1 last_at:2020-05-12 17:50:58
   protSnd    1 last_at:2020-05-12 17:50:53
   protState  CMDs_done_Errors:1
   rssi_at_CUL_0 cnt:9 min:-74 max:-55.5 avg:-66 lst:-74
   READINGS:
     2020-05-12 17:50:53   Activity        alive
     2020-05-12 17:50:53   D-firmware      2.4
     2020-05-12 17:50:53   D-serialNr      LEQ0499131
     2020-05-12 17:51:13   alive           yes
     2020-05-12 17:51:15   battery         ok
     2020-05-12 17:51:15   contact         closed (to broadcast)
     2020-05-12 17:51:08   powerOn         2020-05-12 17:51:08
     2020-05-12 17:51:13   recentStateType info
     2020-05-12 17:51:13   sabotageError   off
     2020-05-12 17:51:15   state           closed
     2020-05-12 17:51:15   trigger_cnt     2
     RegL_00.:
       VAL       
   helper:
     HM_CMDNR   3
     PONtest    0
     cSnd       ,01A5547F2AD45900040000000000
     getCfgList all
     getCfgListNo ,4
     mId        002F
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     4
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +2AD459,00,00,00
       nextSend   1589298676.06466
       prefIO     
       rxt        0
       vccu       
       p:
         2AD459
         00
         00
         00
     mRssi:
       mNo        03
       io:
         CUL_0:
           -72
           -72
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_CUL_0:
         avg        -66
         cnt        9
         lst        -74
         max        -55.5
         min        -74
Attributes:
   IODev      CUL_0
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon closed:fts_door open:fts_door_open
   expert     2_full
   firmware   2.4
   model      HM-SEC-SC-2
   peerIDs    00000000,
   room       Alarmanlage,Küche
   serialNr   LEQ0499131
   subType    threeStateSensor

[frank]

2020-05-12 17:50:53 hast du wohl den "countdown" (anlernmessage) ausgelöst.
hast du auch vorher am cul hmpairforsec gestartet?

2020-05-12 17:51:08 gab es powerOn.
sind die batterien und kontakte sauber? wackelkontakt?

ab jetzt nichts mehr löschen oder resetten, immer "drüberpairen".

der cul ist natürlich suboptimal, da kein timing möglich ist. es sei denn, du nutzt die tsculfw.

sniffe mal das pairen, wie im wiki beschrieben.

[Snocksman]

Das mit dem drüberpairen ist ja das koriose... Solange das Device in FHEM angelegt ist, scheint sich der Tür-/Fensterkontakt beim pairing aufzuhängen... Wenn ich die Pairingtaste drücke, blinkt die LED nur einmal ganz kurz orange auf und danach ist der Tür-/Fensterkontakt tot... Es regt sich gar nichts mehr (auch nicht, wenn ich z.B. die Tür öffne, die LED bleibt dunkel). Erst wenn ich kurz die Batterien aud dem Device nehme, kommt es zurück ins Leben (Das ist wahrscheinlich auch das Power on, was du gesehen hast...).

Lösche ich das Device jetzt z.B., oder fahre FHEM herunter und drücke den Pairing Knopf, blinkt die LED mehrere Sekunden orange (so wie es sein sollte) und leuchtet schließlich rot (weil ja nichts zum pairen da ist).

Das mal so ein Kontakt beim Batteriewechsel das Pairing verloren hat, hatte ich in der Vergangenheit ja schon mal und hab den dann auch einfach drüber gepaired, das ging immer völlig Problemlos. Auch mit dem CUL hatte ich bislang noch nie größere Probleme (Ja, irgend ein Schalter braucht hin und wieder mal was länger zum schalten, aber im großen und ganzen war bislang alles ok.

[frank]

sniffe das "pairen" trotzdem mal.

sind die batterien ok?
mal die leerlaufspg. gemessen?

[Pfriemler]

sind die batterien ok?
mal die leerlaufspg. gemessen?

Mal den Kurzschlussstrom gemessen (kurzzeitig!) Batteriekontakte geprüft? Denkbar, dass das Gerät sich aufhängt, wenn die Batteriespannung unter einen kritischen Wert fällt. Bei Pairungbereitschaft ist das Funkmodul mehr auf Empfang, das LED-Blinken zieht nicht so viel. Erst Daten ausgetauscht werden, werden 20-30 mA dauerhaft fällig. Dreckige Kontakte oder überalterte Batterien könnten da ein Problem sein.

[Snocksman]

Batterien habe ich gerade nochmal aus einem anderen Device genommen (dort hatte ich diese vor einer Woche gewechselt), das brachte aber keine Besserung. Das mitsniffen werde ich morgen nochmal in Angriff nehmen, aber ich glaube mittlerweile, daß der Tür-/Fensterkontakt einfach defekt ist... Ich war gerade mal ganz mutig, habe mir einen zweiten Tür-/Fenterkontakt geschnappt, diesen auf Werkseinstellungen zurückgesetzt und wieder mit FHEM gepaired; das ging ohne Probleme... Direkt nochmal mein "Problemkind" geschnappt und der möchte sich nach wie vor nicht mit FHEM pairen.

[Snocksman]

So, hier noch das Ergebnis des sniffens, wärend des Pairings (2AD459 ist das Device um das geht...):

Code Auswählen Erweitern

2020.05.13 17:11:32.472 4: CUL_Parse: CUL_0 A 0F 15 8610 397B21 000000 0AB0F608004002 -73
2020.05.13 17:11:32.523 3: CUL_0: Unknown code A0F158610397B210000000AB0F6080040::-73:CUL_0, help me!
2020.05.13 17:11:35.566 4: CUL_Parse: CUL_0 A 0F F2 8610 5A91D0 000000 0AA8A5C76400F6 -79
2020.05.13 17:11:35.701 3: CUL_0: Unknown code A0FF286105A91D00000000AA8A5C76400::-79:CUL_0, help me!
2020.05.13 17:11:35.702 4: CUL_Parse: CUL_0 A 1A 02 8400 2AD459 000000 2400B14C4551303439393133318081010131 -49.5


[frank]

Code Auswählen Erweitern

2020.05.13 17:11:35.702 4: CUL_Parse: CUL_0 A 1A 02 8400 2AD459 000000 2400B14C4551303439393133318081010131 -49.5

die letzte msg ist die anlernmessage vom fk, wenn du den taster drückst.
was kommt denn danach? weil jetzt wird es ja erst interessant.

was zeigt denn beim fk "get deviceInfo long"?

und zum vergleich die selbe info vom fk, der gestern so gut funktionierte. und am besten auch ein list.

[Snocksman]

...danach kommt vom fk leider gar nichts mehr... Nach dem drücken der Anlerntaste blinkt die LED ganz kurz orange, die Zeile CUL_Parse: CUL_0 A 1A 02 8400 2AD459 000000 2400B14C4551303439393133318081010131 -49.5 erscheint im log und danach ist der fk tot, solange bis ich die Batterien kurz raus nehme.

hier vom "Problemkind":

get deviceinfo long:

Code Auswählen Erweitern

Device name:Tuer_Kueche
   org ID    :00B1  Model=HM-SEC-SC-2
   alias ID :002F  Model=HM-SEC-SC
   mode    :config - activity:alive
   protState : unknown pending: none

list:

Code Auswählen Erweitern

Internals:
   CUL_0_MSGCNT 12
   CUL_0_RAWMSG A0C0D84412AD459000000010C00::-74:CUL_0
   CUL_0_RSSI -74
   CUL_0_TIME 2020-05-13 18:49:36
   DEF        2AD459
   FUUID      5c47a7a0-f33f-d11a-c587-b19fec36dbd15f58
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     12
   NAME       Tuer_Kueche
   NOTIFYDEV  global
   NR         48
   NTFY_ORDER 50-Tuer_Kueche
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:0D - t:41 s:2AD459 d:000000 010C00
   protLastRcv 2020-05-13 18:49:36
   protRcv    12 last_at:2020-05-13 18:49:36
   rssi_at_CUL_0 cnt:12 min:-94.5 max:-67 avg:-77.41 lst:-74
   READINGS:
     2020-05-13 17:19:52   Activity        alive
     2020-05-13 17:11:35   D-firmware      2.4
     2020-05-13 17:11:35   D-serialNr      LEQ0499131
     2020-05-12 21:42:54   R-pairCentral   set_0xA5547F
     2020-05-13 17:19:54   alive           yes
     2020-05-13 18:49:36   battery         ok
     2020-05-13 18:49:36   contact         closed (to broadcast)
     2020-05-13 17:19:54   powerOn         2020-05-13 17:19:54
     2020-05-13 17:19:54   recentStateType info
     2020-05-13 17:19:54   sabotageError   off
     2020-05-13 18:49:36   state           closed
     2020-05-13 18:49:36   trigger_cnt     12
   helper:
     HM_CMDNR   13
     PONtest    0
     mId        002F
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     4
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +2AD459,00,00,00
       nextSend   1589388576.1858
       prefIO     
       rxt        0
       vccu       
       p:
         2AD459
         00
         00
         00
     mRssi:
       mNo        0D
       io:
         CUL_0:
           -72
           -72
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_CUL_0:
         avg        -77.4166666666667
         cnt        12
         lst        -74
         max        -67
         min        -94.5
Attributes:
   IODev      CUL_0
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon closed:fts_door open:fts_door_open
   expert     2_full
   firmware   2.4
   model      HM-SEC-SC-2
   peerIDs    00000000,
   room       Alarmanlage,Küche
   serialNr   LEQ0499131
   subType    threeStateSensor

und hier noch von dem funktionierenden fk von gestern:

get deviceinfo long:

Code Auswählen Erweitern

Device name:Fenster_Esszimmer
   org ID    :00B1  Model=HM-SEC-SC-2
   alias ID :002F  Model=HM-SEC-SC
   mode    :config - activity:alive
   protState : unknown pending: none

list:

Code Auswählen Erweitern

Internals:
   DEF        2CA5BA
   FUUID      5c47a7a0-f33f-d11a-feb8-795d7e2d8f982508
   IODev      CUL_0
   NAME       Fenster_Esszimmer
   NOTIFYDEV  global
   NR         52
   NTFY_ORDER 50-Fenster_Esszimmer
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   READINGS:
     2020-05-13 17:19:52   Activity        alive
     2019-01-24 13:55:38   CommandAccepted yes
     2019-01-24 13:55:37   D-firmware      2.4
     2019-01-24 13:55:37   D-serialNr      LEQ0754674
     2019-01-24 13:55:38   PairedTo        0xA5547F
     2019-01-24 13:55:38   R-cyclicInfoMsg off
     2019-01-24 13:55:38   R-eventDlyTime  0 s
     2019-01-24 13:55:38   R-pairCentral   0xA5547F
     2019-01-24 13:55:38   R-sabotageMsg   on
     2019-01-24 13:55:38   R-sign          off
     2019-01-24 13:55:38   RegL_00.        00:00 02:01 09:00 0A:A5 0B:54 0C:7F 10:01 14:06
     2019-01-24 13:55:38   RegL_01.        00:00 08:00 20:60 21:00 22:64 30:06
     2019-01-24 13:55:55   alive           yes
     2020-05-12 21:47:07   battery         low
     2020-05-12 21:47:07   contact         closed (to CUL_0)
     2019-01-24 13:55:19   powerOn         2019-01-24 13:55:19
     2019-01-24 13:55:55   recentStateType info
     2019-01-24 13:55:55   sabotageError   off
     2020-05-12 21:47:07   state           closed
     2020-05-12 21:47:07   trigDst_A5547F  noConfig
     2020-05-12 21:47:07   trigger_cnt     199
   helper:
     HM_CMDNR   114
     mId        002F
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     4
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +2CA5BA,00,00,00
       prefIO     
       rxt        0
       vccu       
       p:
         2CA5BA
         00
         00
         00
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
Attributes:
   IODev      CUL_0
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon open:fts_window_2w_open_lr closed:fts_window_2w
   expert     2_full
   firmware   2.4
   model      HM-SEC-SC-2
   peerIDs    00000000,
   room       Alarmanlage,Esszimmer
   serialNr   LEQ0754674
   subType    threeStateSensor

[frank]

...danach kommt vom fk leider gar nichts mehr...

als nächstes muss auch fhem die cmds zum pairen senden.
zeig einfach mal die nächsten msgs.
eventuell empfängt der fk etwas, was ihn killt.

und was passiert, wenn du den taster drückst ohne vorher hmpairforsec auszulösen?

[frank]

und der werkreset am fk über taster drücken funktioniert so, wie in der bedienungsanleitung beschrieben?
also erst langsames blinken, dann schnelles blinken.

hattest du mal einen reset über fhem gemacht?