Hallo
Ich habe einen Fensterkontakt HM-SEC-SCo gepeered und gepaired mit HM-CC-TC / VCCU. Funktioniert soweit prächtig. Aber wenn man den HM-SEC-SCo nicht innerhalb von zwei Tagen betätigt, meldet der HM-CC-TC den Sensor blinkend bzw. tagsüber auch per Piepsen als 'vermisst'. :-(
Die Meldungen des HM-SEC-SCo Tür-/Fensterkontakt gehen immer zu beiden. Somit denke ich, dass mit peering / pairing soweit alles OK sein sollte:
2019-01-04_18:01:18 HM-SEC-SCo contact: open (to HM-CC-TC)
2019-01-04_18:01:18 HM-SEC-SCo open
2019-01-04_18:01:18 HM-SEC-SCo trigger_cnt: 38
2019-01-04_18:01:18 HM-SEC-SCo contact: open (to VCCU)
2019-01-04_18:13:05 HM-SEC-SCo contact: closed (to HM-CC-TC)
2019-01-04_18:13:05 HM-SEC-SCo closed
2019-01-04_18:13:05 HM-SEC-SCo trigger_cnt: 39
2019-01-04_18:13:05 HM-SEC-SCo contact: closed (to VCCU)
Aber das Alive geht scheinbar nur zum FHEM-Server/ActionDetector. Jedenfalls sehe ich nichts dergleichen.
Ich habe schon gesucht, aber scheinbar nicht richtig beschrieben. Ich kann nichts finden, denke aber, dass ich nicht der Einzige mit diesem Problem bin bzw. war.
Gibt es etwas, was ich konfigurieren /muss/kann damit der HM-SEC-SCo sich auch regelmäßig beim HM-CC-TC meldet? Beim HM-SEC-RHS funktionierts ja schließlich auch.
define HM-SEC-SCo CUL_HM XXXXXX
attr HM-SEC-SCo IODev HM_LAN1
attr HM-SEC-SCo IOgrp VCCU
attr HM-SEC-SCo actCycle 002:50
attr HM-SEC-SCo actStatus alive
attr HM-SEC-SCo autoReadReg 4_reqStatus
attr HM-SEC-SCo devStateIcon closed:fts_window_2w open:fts_window_2w_open
attr HM-SEC-SCo event-on-change-reading .*
attr HM-SEC-SCo expert 2_defReg+raw
attr HM-SEC-SCo firmware 1.0
attr HM-SEC-SCo model HM-SEC-SCo
attr HM-SEC-SCo peerIDs 00000000,201A1A03,
attr HM-SEC-SCo room Schlafen
attr HM-SEC-SCo serialNr MEQxxxxxxx
attr HM-SEC-SCo subType threeStateSensor
Danke und Gruß
Chalieman
ich wusste gar nicht, dass der tc auch bei fehlenden messages vom fk piept. das kannte ich bisher nur von fehlenden vd messages. dann piept er immer zur vollen stunde.
der sco sollte ca jede stunde eine statusmessage senden. vielleicht kann der tc nichts mit der message anfangen, da es damals noch keine sco gab.
was sagt denn ein "get hminfo configCheck"?
poste mal ein list vom sco.
Hallo und Danke
Nur um Missverständnissen vorzubeugen. Der TC Piepst zwar einmal die Stunde tagsüber ab 8h morgens. Aber erst, wenn der Sensor sich ca. zwei Tage nicht gemeldet hat. Das macht der auch bei anderen Sensoren, wie dem Drehgriff HM-SEC-RHS.
Somit glaube ich nicht, dass
Zitatder sco sollte ca jede stunde eine statusmessage senden
Irgendwann in den zwei Tagen sollte reichen.
Eine entsprechende Alive-Meldung habe ich ja bei ActionDetector:
2019-01-17_22:02:56 HM.ActionDetector status_SchlZimmer.SCo.Fenster: alive
Anbei der configCheck. Ich sehe dort weder den angesprochenen TC noch den entsprechenden SCo.
configCheck done:
missing register list
Diele.RHS.Fenster: RegL_04.KlZimmer.TC.WindowRec
Kueche.RHS.Fenster: RegL_00.,RegL_01.,RegL_04.Kueche.TC.WindowRec
peer not verified. Check that peer is set on both sides
Diele.TC.WindowRec p:Diele.RHS.Fenster
Diele.RHS.Fenster p:KlZimmer.TC.WindowRec
KlZimmer.RHS.Fenster p:KlZimmer.TC.Climate
peerNeedsBurst cannot be determined
Diele.RHS.Fenster:KlZimmer.TC.WindowRec
peerNeedsBurst not set
KlZimmer.RHS.Fenster:KlZimmer.TC.Climate
templist mismatch
Bad.TC.Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
Diele.TC.Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
KlZimmer.TC.Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
Kueche.TC.Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
SchlZimmer.TC.Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
WoZimmer.TC.Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directoryGruß, Charlieman
Sory, hatte das List vergessen:
Internals:
CHANGED
DEF 3C7EE3
HM_CUL2_MSGCNT 22
HM_CUL2_RAWMSG A0D45A6103C7EE3xxxxxx06010000::-64:HM_CUL2
HM_CUL2_RSSI -64
HM_CUL2_TIME 2019-01-22 12:45:43
HM_LAN1_MSGCNT 22
HM_LAN1_RAWMSG E3C7EE3,0000,3144CC81,FF,FFBD,45A6103C7EE3xxxxxx06010000
HM_LAN1_RSSI -67
HM_LAN1_TIME 2019-01-22 12:45:43
IODev HM_CUL2
LASTInputDev HM_LAN1
MSGCNT 44
NAME SchlZimmer.SCo.Fenster
NOTIFYDEV global
NR 472
STATE closed
TYPE CUL_HM
lastMsg No:45 - t:10 s:3C7EE3 d:xxxxxx 06010000
peerList SchlZimmer.TC.WindowRec,
protLastRcv 2019-01-22 12:45:43
protRcv 22 last_at:2019-01-22 12:45:43
protSnd 22 last_at:2019-01-22 12:45:43
protState CMDs_done
rssi_at_HM_CUL2 cnt:22 min:-72.5 max:-62 avg:-64.43 lst:-64
rssi_at_HM_LAN1 cnt:22 min:-74 max:-63 avg:-67.72 lst:-67
READINGS:
2019-01-21 17:17:43 Activity alive
2018-12-17 17:08:37 CommandAccepted yes
2018-12-17 18:19:53 D-firmware 1.0
2018-12-17 18:19:53 D-serialNr MEQXXXXXXX
2018-12-17 17:15:20 PairedTo 0xxxxxxx
2018-12-17 17:15:21 R-SchlZimmer.TC.WindowRec-expectAES off
2018-12-17 17:15:21 R-SchlZimmer.TC.WindowRec-peerNeedsBurst on
2016-01-28 21:25:47 R-cyclicInfoMsg on
2016-01-28 21:25:47 R-eventDlyTime 0 s
2018-12-17 17:06:25 R-pairCentral 0xxxxxxx
2016-01-28 21:25:47 R-sabotageMsg on
2016-01-28 21:25:47 R-sign on
2018-12-17 17:15:20 RegL_00. 00:00 02:01 09:01 0A:AC 0B:08 0C:15 10:01 14:06
2018-12-17 17:15:20 RegL_01. 00:00 08:01 20:9C 21:00 30:06
2018-12-17 17:15:21 RegL_04.SchlZimmer.TC.WindowRec 00:00 01:01
2018-12-17 17:08:37 aesCommToDev ok
2018-12-17 17:08:37 aesKeyNbr 00
2019-01-22 12:45:43 alive yes
2019-01-22 12:45:43 battery ok
2019-01-22 12:45:43 contact closed (to VCCU)
2019-01-21 17:17:43 peerList SchlZimmer.TC.WindowRec,
2018-12-17 16:58:33 powerOn 2018-12-17 16:58:33
2019-01-22 12:45:43 recentStateType info
2019-01-22 12:45:43 sabotageError off
2019-01-22 12:45:43 state closed
2018-10-30 09:18:58 trigDst_xxxxxx noConfig
2018-01-27 19:20:59 trigDst_SchlZimmer.TC noConfig
2016-04-10 09:01:30 trigDst_VCCU noConfig
2019-01-20 16:20:24 trigger_cnt 63
helper:
HM_CMDNR 69
mId 00C7
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3C7EE3,00,00,00
nextSend 1548157543.17832
prefIO
rxt 2
vccu VCCU
p:
3C7EE3
00
00
00
mRssi:
mNo 45
io:
HM_CUL2:
-60
-60
HM_LAN1:
-67
-67
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HM_CUL2
flg A
ts 1548157543.0795
ack:
HASH(0x1a7d2f0)
458002xxxxxx3C7EE300
rssi:
at_HM_CUL2:
avg -64.4318181818182
cnt 22
lst -64
max -62
min -72.5
at_HM_LAN1:
avg -67.7272727272727
cnt 22
lst -67
max -63
min -74
Attributes:
IODev HM_LAN1
IOgrp VCCU
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
devStateIcon closed:fts_window_2w open:fts_window_2w_open
event-on-change-reading .*
expert 2_defReg+raw
firmware 1.0
model HM-SEC-SCo
peerIDs 00000000,201A1A03,
room SchlZimmer
serialNr MEQXXXXXXX
subType threeStateSensor
die alten sc und rhs melden sich 1 mal am tag, wenn das register cyclicInfoMsg=on ist. hier macht es ja dann auch sinn, wenn nach 2 ausbleibenden messages alarm gegeben wird.
da sich der neue sco aber sogar jede stunde meldet, hat der tc vielleicht ein problem mit diesen messages.
sniffe mal diese messages vom sco, wie im wiki sniffen beschrieben.
die fehlermeldungen von hminfo solltest du beheben.
edit
oder kann der tc den sco nicht hören. vielleicht den sco mal umsetzen?
Hallo zusammen,
ich betreibe die gleiche Kombination wie charlieman und habe auch das gleiche Problem.
Aus dem Log des Fensterkontaktes entnehme ich folgendes:
2019-01-24_08:57:08 w5.schlafz.fenster battery: ok
2019-01-24_08:57:08 w5.schlafz.fenster contact: open (to w5.schlafz.Thermostat)
2019-01-24_08:57:08 w5.schlafz.fenster open
2019-01-24_08:57:08 w5.schlafz.fenster trigger_cnt: 179
2019-01-24_08:57:09 w5.schlafz.fenster battery: ok
2019-01-24_08:57:09 w5.schlafz.fenster contact: open (to ccu)
2019-01-24_08:57:09 w5.schlafz.fenster open
2019-01-24_08:57:09 w5.schlafz.fenster trigger_cnt: 179
2019-01-24_08:57:09 w5.schlafz.fenster battery: ok
2019-01-24_08:57:09 w5.schlafz.fenster contact: open (to ccu)
2019-01-24_08:57:09 w5.schlafz.fenster open
2019-01-24_08:57:09 w5.schlafz.fenster trigger_cnt: 179
2019-01-24_09:06:13 w5.schlafz.fenster battery: ok
2019-01-24_09:06:13 w5.schlafz.fenster contact: closed (to w5.schlafz.Thermostat)
2019-01-24_09:06:13 w5.schlafz.fenster closed
2019-01-24_09:06:13 w5.schlafz.fenster trigger_cnt: 180
2019-01-24_09:06:13 w5.schlafz.fenster battery: ok
2019-01-24_09:06:13 w5.schlafz.fenster contact: closed (to ccu)
2019-01-24_09:06:13 w5.schlafz.fenster closed
2019-01-24_09:06:13 w5.schlafz.fenster trigger_cnt: 180
2019-01-24_09:06:13 w5.schlafz.fenster battery: ok
2019-01-24_09:06:13 w5.schlafz.fenster contact: closed (to ccu)
2019-01-24_09:06:13 w5.schlafz.fenster closed
2019-01-24_09:06:13 w5.schlafz.fenster trigger_cnt: 180
2019-01-24_09:31:34 w5.schlafz.fenster alive: yes
2019-01-24_09:31:34 w5.schlafz.fenster battery: ok
2019-01-24_09:31:34 w5.schlafz.fenster contact: closed (to ccu)
2019-01-24_09:31:34 w5.schlafz.fenster sabotageError: off
2019-01-24_09:31:34 w5.schlafz.fenster closed
2019-01-24_10:26:48 w5.schlafz.fenster Activity: dead
2019-01-24_10:31:29 w5.schlafz.fenster alive: yes
2019-01-24_10:31:29 w5.schlafz.fenster battery: ok
2019-01-24_10:31:29 w5.schlafz.fenster contact: closed (to ccu)
2019-01-24_10:31:29 w5.schlafz.fenster sabotageError: off
2019-01-24_10:31:29 w5.schlafz.fenster closed
Um 08:57 und um 09:06 habe ich das Fenster geöffnet bzw. geschlossen. Das wird auch an den HM-CC-TC und an die vccu übertragen.
Die stündlichen Meldungen, wie von frank geschrieben, werden aber auch bei mir nur an die ccu geschickt. Also auch bei mir, nach 2 Tagen "Inaktivität" (also keine Fensteränderung) fängt um 08:00 Uhr das Gepiepse an.
Reichweitenproblem kann ich ausschließen, da sich beide Geräte im gleichen Raum befinden (Fensterkontakt und Thermostat), der CUL im Nebenraum empfängt alles.
An einer Lösung bin ich natürlich auch interessiert ;)
Gruß Rainer
hallo rainer,
zeig mal ein list von deinem sco.
Ok, hier der Nachtrag, das list:
Internals:
CUL_0_MSGCNT 151
CUL_0_RAWMSG A0DC5A61041E124xxxxxx06010000::-53.5:CUL_0:
CUL_0_RSSI -53.5
CUL_0_TIME 2019-01-24 16:58:15
DEF 41E124
FUUID 5c42f94d-f33f-1942-8a4c-498d9c27a3068f0d
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 151
NAME w5.schlafz.fenster
NOTIFYDEV global
NR 530
NTFY_ORDER 50-w5.schlafz.fenster
STATE closed
TYPE CUL_HM
lastMsg No:C5 - t:10 s:41E124 d:xxxxxx 06010000
peerList w5.schlafz.WindowRec,ccu_w5.schlafz.fenster,
protLastRcv 2019-01-24 16:58:15
protSnd 145 last_at:2019-01-24 16:58:15
protState CMDs_done
rssi_at_CUL_0 cnt:151 max:-47.5 min:-65.5 lst:-53.5 avg:-57.89
READINGS:
2019-01-24 16:56:51 Activity dead
2017-10-05 17:46:49 CommandAccepted yes
2018-02-11 12:45:16 D-firmware 1.0
2018-02-11 12:45:16 D-serialNr MEQxxxxxxx
2018-02-11 12:45:16 PairedTo 0xxxxxxx
2017-10-05 17:46:50 R-ccu_w5.schlafz.fenster-expectAES off
2017-10-05 17:46:50 R-ccu_w5.schlafz.fenster-peerNeedsBurst off
2017-10-05 17:46:49 R-cyclicInfoMsg on
2017-10-05 17:46:49 R-eventDlyTime 0 s
2017-10-05 17:46:49 R-pairCentral 0xxxxxxx
2017-10-05 17:46:49 R-sabotageMsg on
2017-10-05 17:46:49 R-sign on
2017-10-05 17:46:50 R-w5.schlafz.WindowRec-expectAES off
2017-10-05 17:46:50 R-w5.schlafz.WindowRec-peerNeedsBurst on
2018-02-11 12:45:16 RegL_00. 02:01 09:01 0A:xx 0B:xx 0C:xx 10:01 14:06 00:00
2018-02-11 12:45:16 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2018-02-11 12:45:17 RegL_04.ccu_w5.schlafz.fenster 01:00 00:00
2018-02-11 12:45:17 RegL_04.w5.schlafz.WindowRec 01:01 00:00
2017-10-05 17:46:49 aesCommToDev ok
2017-10-05 17:46:49 aesKeyNbr 02
2019-01-24 16:58:15 alive yes
2019-01-24 16:58:15 battery ok
2019-01-24 16:58:15 contact closed (to ccu)
2019-01-19 11:18:07 peerList w5.schlafz.WindowRec,ccu_w5.schlafz.fenster,
2018-04-29 12:18:48 powerOn 2018-04-29 12:18:48
2019-01-24 16:58:15 recentStateType info
2019-01-24 16:58:15 sabotageError off
2019-01-24 16:58:15 state closed
2019-01-24 09:06:13 trigger_cnt 180
helper:
HM_CMDNR 197
mId 00C7
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
lstRecType 10
newChn +41E124,00,01,00
nextSend 1548345495.94842
nxtSndMcnt C5
rxt 2
tgtDly 88
vccu ccu
lRcTm:
CUL_0 331410776
tnms 9785652
p:
41E124
00
01
00
prefIO:
CUL_0
mRssi:
mNo C5
io:
CUL_0:
-43.5
-43.5
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO CUL_0
flg A
ts 1548345495.86334
ack:
HASH(0x373a768)
C58002xxxxxx41E12400
rssi:
at_CUL_0:
avg -57.8907284768212
cnt 151
lst -53.5
max -47.5
min -65.5
tmpl:
Attributes:
IODev CUL_0
IOgrp ccu:CUL_0
actCycle 000:50
actStatus dead
autoReadReg 5_readMissing
devStateIcon closed:fts_door_right open:fts_door_right_open
expert 2_full
firmware 1.0
group Fenster
model HM-SEC-SCo
peerIDs 00000000,1EA3F603,xxxxxxxx,
room W5Schlafzimmer
serialNr MEQxxxxxxx
subType threeStateSensor
webCmd getConfig
Hope that helps.
Gruß Rainer
ich habe jetzt mal einen sec-sc mit einem cc-tc gepeert.
2019-01-24 22:44:10 .peerListRDate 2019-01-24 22:44:10
seit dem hat er sich nur 3x mit der täglichen statusmessage bei der zentrale/fhem gemeldet und am tc ist das geöffnete fenster zu sehen. bisher kein piepsen.
2019.01.25 20:13:59.602 0: HMLAN_Parse: hmlan1 R:E1DE620 stat:0000 t:4472C9B7 d:FF r:FFD8 m:7E B610 1DE620 1ACE1F 0601C80E
2019.01.25 20:13:59.634 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:4472CA38 d:FF r:FFCD m:7E 8002 1ACE1F 1DE620 00
2019.01.26 20:05:03.654 0: HMLAN_Parse: hmlan1 R:E1DE620 stat:0000 t:49912519 d:FF r:FFD7 m:7F B610 1DE620 1ACE1F 0601C80E
2019.01.26 20:05:03.775 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:49912593 d:FF r:FFD7 m:7F 8002 1ACE1F 1DE620 00
2019.01.27 19:56:07.820 0: HMLAN_Parse: hmlan1 R:E1DE620 stat:0000 t:4EAF8088 d:FF r:FFD6 m:80 B610 1DE620 1ACE1F 0601C80E
2019.01.27 19:56:07.940 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:4EAF8102 d:FF r:FFD6 m:80 8002 1ACE1F 1DE620 00
obwohl der fk keine messges an das thermostat sendet, bleibt der tc ruhig. da es burst messges vom fk an die zentrale sind, wertet der tc diese eventuell trotzdem aus.
wie sehen denn nun die gesnifften raw messages bei eurem sec-sco aus?
Hallo zusammen,
war mir nicht bewusst, dass ich auch sniffen sollte, sorry :-\ Habe ich jetzt mal aktiviert ... da geht ja jetzt 'ne ganze Menge in's Log ...
2 Fragen habe ich aber noch dazu:
1. Kann ich bei einem CUL auch die Logmeldungen einschränken auf bestimmte Devices? logIDs gibt es bei mir nicht (ist auch nur für HMLAN/HMUSB/HMUART lt. Wiki)
2. @frank: Du schreibst: "am tc ist das geöffnete fenster zu sehen", bei mir ist der "default" Zustand ein geschlossenes Fenster, damit schon mal den "Dauertest" gemacht?
Gruß Rainer
zu1) einschränken lassen sich die messages nur mit attr logids. eventuell hat die ts_culfw dieses feature. diese fw sollte eh standard für homematic sein.
ich denke 2-3 std sollte genügen, damit man auch 2-3 messages hat.
zu2) habe ich auf der todo liste.
zur zeit läuft der peerneedsburst=off test.
... dann sollte ich jetzt genug davon haben ... bin mal gespannt, was Du daraus lesen kannst. Könntest Du das auch übersetzen?
... die Kommunikation erfolgt auf jeden Fall nur mit dem CUL, das FFxxxx ist mein CUL-Device
2019.01.28 18:11:08.192 4: TSCUL_Parse: CUL_0 096415 A F001 10305788 00 0D 44 A610 41E124 FFxxxx 06010000 -61.5dB
2019.01.28 18:11:08.420 4: TSCUL_Parse: CUL_0 096643 A F103 10305884 01 0A 44 8002 FFxxxx 41E124 00 _CCAdly:4 _dhmSt:96
2019.01.28 19:06:51.783 4: TSCUL_Parse: CUL_0 294278 A F001 13649488 00 0D 45 A610 41E124 FFxxxx 06010000 -62.5dB
2019.01.28 19:06:51.946 4: TSCUL_Parse: CUL_0 294441 A F103 13649584 01 0A 45 8002 FFxxx 41E124 00 _CCAdly:4 _dhmSt:96
2019.01.28 20:01:19.549 4: TSCUL_Parse: CUL_0 416316 A F001 00140140 00 0D 46 A610 41E124 FFxxxx 06010000 -63dB
2019.01.28 20:01:19.741 4: TSCUL_Parse: CUL_0 416507 A F103 00140236 01 0A 46 8002 FFxxxx 41E124 00 _CCAdly:4 _dhmSt:96
Hoffe, es bringt neue Erkenntnisse.
Gruß Rainer
schlechte nachrichten würde ich sagen, denn diese regelmässigen messages werden bei dir nicht als burst gesendet.
zu sehen bei "A610". das A repräsentiert 4 bits/flags. das niedrigste bit zeigt burst. meine messages werden mit "B610" gesendet, also burst.
damit ist der sco quasi inkompatibel.
aber: ich sehe gerade, dass du ihn zusätzlich mit der vccu gepeert hast? setze R-ccu_w5.schlafz.fenster-peerNeedsBurst mal auf on.
als dauerlösung wahrscheinlich nicht zu empfehlen. burst belastet die batterien aller burst empfänger und vervielfacht die msgload.
edit: nach dem setzen von peerneedsburst=off sendet mein sc nun auch "A610".
dann müsste nun nach euren schilderungen mittwoch 8:00 uhr das geheule losgehen. :)
pünktlich um 8:00 uhr hat mein tc heute morgen gepiepst. damit ist eigentlich alles geklärt.
hast du das register gesetzt? kommen jetzt die "B610" messages?
Hi frank,
habe das Register gesetzt:
R-ccu_w5.schlafz.fenster-peerNeedsBurst on 2019-01-30 10:10:09
R-w5.schlafz.WindowRec-peerNeedsBurst on 2017-10-05 17:46:50
Trotzdem erscheint:
2019.01.30 10:42:36.524 4: TSCUL_Parse: CUL_0 232682 A F001 05203884 00 0D 9F A610 41E124 FFxxxx 06010000 -64dB
2019.01.30 10:42:36.693 4: TSCUL_Parse: CUL_0 232852 A F103 05203980 01 0A 9F 8002 FFxxxx 41E124 00 _CCAdly:4 _dhmSt:96
Ich lasse das verbose 4 vom CUL mal bis heute Abend mitlaufen, muss gleich zur Arbeit. Evtl. ändert sich noch etwas (glaube ich zwar nicht, aber wer weiß)?
Gruß Rainer
da wird sich wahrscheinlich nichts mehr ändern.
sign=off setzen, wäre vielleicht noch eine möglichkeit, da manche devices mit aes schon mal unterschiedliches verhalten zeigen.
Hallo nochmal,
trotzdem, dass sign=off ist, bleibt es bei "A610". Hast Du evtl. eine andere Firmware? Meine ist die 1.0 vom Fensterkontakt und die 2.1 vom HM-CC-TC.
Gruß Rainer