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:
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
10_CUL_HM.pm wurde gestern aktualisiert. vielleicht alte version zurückspielen?
nur ne idee...
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.
zeig ein vernünftiges "list HM_2AD459".
devices zu löschen, ist selten hilfreich.
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:
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
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.
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.
sniffe das "pairen" trotzdem mal.
sind die batterien ok?
mal die leerlaufspg. gemessen?
Zitat von: frank am 12 Mai 2020, 21:33:44
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.
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.
So, hier noch das Ergebnis des sniffens, wärend des Pairings (2AD459 ist das Device um das geht...):
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
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.
...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:
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:
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:
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:
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
Zitat...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?
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?
Hier nochmal ein bisschen mehr "snifflog":
2020.05.13 20:58:43.958 1: Logfile gelöscht
2020.05.13 20:58:53.793 4: CUL_Parse: CUL_0 A 0F 6F 8610 397B21 000000 0AB0F40800400B -68.5
2020.05.13 20:58:53.819 3: CUL_0: Unknown code A0F6F8610397B210000000AB0F4080040::-68.5:CUL_0, help me!
2020.05.13 20:59:09.090 4: CUL_Parse: CUL_0 A 0F 2E 8610 397B94 000000 0A24C6090040F5 -79.5
2020.05.13 20:59:09.268 3: CUL_0: Unknown code A0F2E8610397B940000000A24C6090040::-79.5:CUL_0, help me!
2020.05.13 20:59:11.732 4: CUL_Parse: CUL_0 A 1A 02 8400 2AD459 000000 2400B14C455130343939313331808101012B -52.5
2020.05.13 20:59:17.324 4: CUL_Parse: CUL_0 A 0F 15 8610 5A9457 000000 0AA8C20E640001 -73.5
2020.05.13 20:59:17.334 3: CUL_0: Unknown code A0F1586105A94570000000AA8C20E6400::-73.5:CUL_0, help me!
2020.05.13 20:59:23.988 4: CUL_Parse: CUL_0 A 0D 54 A610 2C2AF5 415FF0 06012400EA -85
2020.05.13 20:59:24.161 3: CUL_0: Unknown code A0D54A6102C2AF5415FF006012400::-85:CUL_0, help me!
2020.05.13 20:59:24.162 4: CUL_Parse: CUL_0 A 11 54 A002 415FF0 2C2AF5 041304EA91C5D602F5 -79.5
2020.05.13 20:59:24.265 3: CUL_0: Unknown code A1154A002415FF02C2AF5041304EA91C5D602::-79.5:CUL_0, help me!
2020.05.13 20:59:24.266 4: CUL_Parse: CUL_0 A 19 54 A003 2C2AF5 415FF0 1F203F5C97C2A2C02BB79A078A3AD45CEB -84.5
2020.05.13 20:59:24.369 3: CUL_0: Unknown code A1954A0032C2AF5415FF01F203F5C97C2A2C02BB79A078A3AD45C::-84.5:CUL_0, help me!
2020.05.13 20:59:24.371 4: CUL_Parse: CUL_0 A 0E 54 8002 415FF0 2C2AF5 003391ADBEF4 -80
2020.05.13 20:59:24.472 3: CUL_0: Unknown code A0E548002415FF02C2AF5003391ADBE::-80:CUL_0, help me!
2020.05.13 20:59:25.581 4: CUL_Parse: CUL_0 A 0C 83 A641 4327AF 415FF0 01A3C8ED -83.5
2020.05.13 20:59:25.719 3: CUL_0: Unknown code A0C83A6414327AF415FF001A3C8::-83.5:CUL_0, help me!
2020.05.13 20:59:25.720 4: CUL_Parse: CUL_0 A 11 83 A002 415FF0 4327AF 045D322C56605902F6 -79
2020.05.13 20:59:25.822 3: CUL_0: Unknown code A1183A002415FF04327AF045D322C56605902::-79:CUL_0, help me!
2020.05.13 20:59:25.845 4: CUL_Parse: CUL_0 A 19 83 A603 4327AF 415FF0 772B3B0241AEFA94F43D84CBED13CFE8ED -83.5
2020.05.13 20:59:25.945 3: CUL_0: Unknown code A1983A6034327AF415FF0772B3B0241AEFA94F43D84CBED13CFE8::-83.5:CUL_0, help me!
2020.05.13 20:59:25.964 4: CUL_Parse: CUL_0 A 0E 83 8002 415FF0 4327AF 0086824716F5 -79.5
2020.05.13 20:59:26.065 3: CUL_0: Unknown code A0E838002415FF04327AF0086824716::-79.5:CUL_0, help me!
2020.05.13 20:59:26.374 4: CUL_Parse: CUL_0 A 0C 84 A241 4327AF 415FF0 01A3C8ED -83.5
2020.05.13 20:59:26.477 3: CUL_0: Unknown code A0C84A2414327AF415FF001A3C8::-83.5:CUL_0, help me!
2020.05.13 20:59:26.506 4: CUL_Parse: CUL_0 A 11 84 A002 415FF0 4327AF 04A60763DB60E102F6 -79
2020.05.13 20:59:26.609 3: CUL_0: Unknown code A1184A002415FF04327AF04A60763DB60E102::-79:CUL_0, help me!
2020.05.13 20:59:26.646 4: CUL_Parse: CUL_0 A 19 84 A203 4327AF 415FF0 923481911E11568214CB9EF6FEA4D430EB -84.5
2020.05.13 20:59:26.749 3: CUL_0: Unknown code A1984A2034327AF415FF0923481911E11568214CB9EF6FEA4D430::-84.5:CUL_0, help me!
2020.05.13 20:59:26.783 4: CUL_Parse: CUL_0 A 0E 84 8002 415FF0 4327AF 00E66ED6EDF4 -80
2020.05.13 20:59:26.885 3: CUL_0: Unknown code A0E848002415FF04327AF00E66ED6ED::-80:CUL_0, help me!
2020.05.13 20:59:27.912 4: CUL_Parse: CUL_0 A 0F 4C 8610 5A91D0 000000 0AA8A6C76400F5 -79.5
2020.05.13 20:59:28.070 3: CUL_0: Unknown code A0F4C86105A91D00000000AA8A6C76400::-79.5:CUL_0, help me!
2020.05.13 20:59:44.047 4: CUL_Parse: CUL_0 A 0C 85 A641 4327AF 415FF0 01A400F2 -81
2020.05.13 20:59:44.204 3: CUL_0: Unknown code A0C85A6414327AF415FF001A400::-81:CUL_0, help me!
2020.05.13 20:59:44.205 4: CUL_Parse: CUL_0 A 11 85 A002 415FF0 4327AF 0416F733DDBDC102F4 -80
2020.05.13 20:59:44.308 3: CUL_0: Unknown code A1185A002415FF04327AF0416F733DDBDC102::-80:CUL_0, help me!
2020.05.13 20:59:44.311 4: CUL_Parse: CUL_0 A 19 85 A603 4327AF 415FF0 746AC79FBC7C0DFA966B0194D28DE2D1EE -83
2020.05.13 20:59:44.413 3: CUL_0: Unknown code A1985A6034327AF415FF0746AC79FBC7C0DFA966B0194D28DE2D1::-83:CUL_0, help me!
2020.05.13 20:59:44.430 4: CUL_Parse: CUL_0 A 0E 85 8002 415FF0 4327AF 0001D17226F5 -79.5
2020.05.13 20:59:44.532 3: CUL_0: Unknown code A0E858002415FF04327AF0001D17226::-79.5:CUL_0, help me!
2020.05.13 20:59:44.870 4: CUL_Parse: CUL_0 A 0C 86 A241 4327AF 415FF0 01A400EC -84
2020.05.13 20:59:44.972 3: CUL_0: Unknown code A0C86A2414327AF415FF001A400::-84:CUL_0, help me!
2020.05.13 20:59:45.003 4: CUL_Parse: CUL_0 A 11 86 A002 415FF0 4327AF 045C3D6E31FCC302F5 -79.5
2020.05.13 20:59:45.104 3: CUL_0: Unknown code A1186A002415FF04327AF045C3D6E31FCC302::-79.5:CUL_0, help me!
2020.05.13 20:59:45.134 4: CUL_Parse: CUL_0 A 19 86 A203 4327AF 415FF0 891F6CC6D0FED094130B7DF8DC66BAAFED -83.5
2020.05.13 20:59:45.236 3: CUL_0: Unknown code A1986A2034327AF415FF0891F6CC6D0FED094130B7DF8DC66BAAF::-83.5:CUL_0, help me!
2020.05.13 20:59:45.238 4: CUL_Parse: CUL_0 A 0F 73 8610 5A9456 000000 0AA4C40F6440D6 -95
2020.05.13 20:59:45.340 3: CUL_0: Unknown code A0F7386105A94560000000AA4C40F6440::-95:CUL_0, help me!
2020.05.13 20:59:45.341 4: CUL_Parse: CUL_0 A 0E 86 8002 415FF0 4327AF 007A399FCAF5 -79.5
2020.05.13 20:59:45.443 3: CUL_0: Unknown code A0E868002415FF04327AF007A399FCA::-79.5:CUL_0, help me!
2020.05.13 21:00:44.201 4: CUL_Parse: CUL_0 A 0F A6 8610 397B4F 000000 0A90BA0B0C40EE -83
2020.05.13 21:00:44.373 3: CUL_0: Unknown code A0FA68610397B4F0000000A90BA0B0C40::-83:CUL_0, help me!
2020.05.13 21:00:44.374 4: CUL_Parse: CUL_0 A 09 33 A112 415FF0 397B4F F0 -82
2020.05.13 21:00:44.476 3: CUL_0: Unknown code A0933A112415FF0397B4F::-82:CUL_0, help me!
2020.05.13 21:00:44.477 4: CUL_Parse: CUL_0 A 0A 33 8002 397B4F 415FF0 00EC -84
2020.05.13 21:00:44.578 3: CUL_0: Unknown code A0A338002397B4F415FF000::-84:CUL_0, help me!
Wenn ich den Taster ohne hmpairforsec drücke, passiert genau das gleiche. Nur wenn ich das Device aus FHEM lösche, oder FHEM runterfahre, fängt die LED an orange zu blinken, wenn ich auf den Taster drücke.
Werksreset funktioniert genau so wie es sollte: 5 sek. gedrückt halten => langsames rotes blinken => loslassen und wieder 5 sek. gedrück halten => schnelles rotes blinken => loslassen => rotes leuchten (ca. 1 sek.)
ZitatWenn ich den Taster ohne hmpairforsec drücke, passiert genau das gleiche. Nur wenn ich das Device aus FHEM lösche, oder FHEM runterfahre, fängt die LED an orange zu blinken, wenn ich auf den Taster drücke.
das würde genau zu meiner idee passen, dass fhem nach der anlernmessage vom device cmds an das device sendet, die dann das device "killen".
allerdings sind im log keine messages von fhem an das device zu sehen. genau genommen gar keine ausgehenden messages.
es sollten logzeilen mit cul_send existieren. wo sind diese?
gibt es eventuell 2 devices?
was zeigt "get hminfo param -d DEF"? ist die id 2AD459 mehrfach vorhanden?
Hier erstmal der output von hminfo:
param done:
param list
entity : DEF |
Aussen_Dach : 4EFC9D
Esszimmer_Lampe : 5F7CFF
Esszimmer_Rauchmelder : 25E1F9
Esszimmer_Schalter : 4EF557
Esszimmer_Tisch_Lampe : 530624
Fenster_Bad : 2C968F
Fenster_Esszimmer : 2CA5BA
Fenster_Kueche : 2ADEE9
Fenster_Wohnzimmer : 2C9B4C
Gartentor : 68F1B2
Handsender_Nadine : 2F0AD4
TeamVirtuell : 111111
Tuer_Flur : 3FC5D1
Tuer_Kueche : 2AD459
Wohnzimmer_Lampe : 53063B
Wohnzimmer_Schalter : 4EF80A
Wo sind die cul_send logzeilen...? Tja, was soll ich sagen, keine Ahnung... Ich bin zum sniffen des Pairings nach dieser Anleitung vorgegangen: https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen
Also:
attr global verbose 1
attr global mseclog 1
attr CUL_0 verbose 4
Warum dann von cul_send nichts im log erfasst wird, weiss ich nicht...
ich habe mal mit meinem cul getestet.
infos zum senden finde ich bei mir auch nur mit verbose=5 beim cul. komisch.
hast du ein 2. io für homematic, zb einen weiteren cul, zum monitoren? wenn ja setze nur beim 2. io verbose auf 4. ansonsten mit dem einzigen cul und verbose=5.
Sorry, hat ein bisschen gedauert... Ich habe mir in der Zwischenzeit einfach einen neuen fk bestellt. Diesen konnte ich auch problemlos anlernen (der alte geht nach wie vor nicht...), allerdings ist mir aufgefallen, dass der neue fk immer nach ein paar Tagen das Problem hat, dass er sich scheinbar aufhängt... Die LED leuchtet dann dauerhaft orange (ähnlich wie der alte fk beim anlernen). Batterien raus und wieder rein und dann läuft er wieder für ein paar Tage normal. Ich überlege mittlerweile, ob vielleicht mein CUL doch nen Klatsch haben könnte...?
Du hattest ja schon geschrieben, dass der CUL für HM eher suboptimal ist. Was sollte man alternativ verwenden ? HM-MOD-RPI-PCB ?
So, ich hab mir jetzt einfach mal ein HM-MOD-RPI-PCB Modul zugelegt. Das Ding laut Anleitung in FHEM eingerichtet und es läuft sofort. Erster Eindruck: Deutlich besser als mein alter CUL (den ich jetzt bestimmt schon 5 Jahre in Benutzung hatte). Woran mache ich das fest ? Z.B. habe ich ein Kommando, welches ich über Alexa schalte: "Deckenlampen ausschalten". Hierbei werden vier Deckenlampen über hm ausgeschaltet... Es war bislang eigentlich immer ein nachzügler dabei... Heißt: Eine von den vier Deckenlampen ist nicht direkt, sondern erst nach einigen Sekunden ausgeschaltet worden. Dieses Thema ist komplett verschwunden. Der neue fk, der sich hin und wieder scheinbar aufhängt, hat das seitdem ich das HM-MOD-RPI-PCB Modul nutze auch nicht mehr getan. Einzig der alte fk, weswegen ich das Thema eröffnet hatte, will auch mit dem neuen Modul nicht (gleiches verhalten). Ich denke mal der ist also einfach mal wirklich defekt.