Hallo zusammen,
ich habe FHEM auf meinem Raspberry Pi laufen. Habe mir damals einen CUL geholt, da ich vorhatte FS20 und HM-Produkte zu verwenden.
Habe bisher allerdings nur HM-Produkte im Einsatz, weswegen ich damals wohl auch einfach einen HM-USB-CFG hätte bestellen können.
Bisher funktionierte alles mit dem CUL, allerdings möchte ich jetzt eine HM-Lichtschranke (HM-Sec-Sco) verwenden, die mit AES-Verschlüsselung arbeitet.
Da das mit meinem CUL nicht funktioniert, benötige ich jetzt wohl eine dieser beiden Lösungen: HM-LAN-CFG, HM-USB-CFG
Könnt ihr mir bitte kurz auf die Sprünge helfen, wie ich z.B. den HM-USB-Stick einbinden würde?
Macht es Sinn den HM-USB-Stick neben dem CUL am RaspberryPi laufen zu lassen? (Die AES-Geräte dann über den HM-USB-Stick, den Rest weiter über den CUL.)
Macht es Sinn nur noch den HM-USB-Stick zu verwenden und den CUL aus der Konfiguration zu nehmen?
Macht es Sinn den HM-USB-Stick statt am Raspberry Pi an meiner Synology Diskstation zu verwenden?
Was müsste ich noch wissen?
Würde mich freuen, wenn ihr mir ein wenig helfen könntet.
Vielen Dank vorab!
auch aes geht mit dem cul.
eventuell brauchst du noch das perl modul Crypt::Rijndael.
Ach so. Hatte im Wiki gelesen, dass AES seit Juli 2015 mit einem CUL möglich ist.
Aber ich hatte angenommen, dass damit eine neue Hardware-Version des CUL gemeint war.
Danke für den Hinweis. Ich versuche mich mal daran...
Ist es auch möglich beim HM-Sec-Sco die AES-Verschlüsselung auszuschalten?
Wenn ja, geht das auch über die FHEM-Oberfläche?
Will noch einmal konkretisieren:
Habe gefunden, dass es bei den meisten HM-Produkten funktioniert.
Frage daher, ob jemand weiß, ob ich auch bei HM-Sec-Sco AES ausschalten kann?
Wäre interessant das zu wissen, bevor ich den Sensor bestelle.
ZitatFrage daher, ob jemand weiß, ob ich auch bei HM-Sec-Sco AES ausschalten kann?
na klar. zum umstellen ist aber zunächst aes nötig. sollte aber mit deinem cul und aktuellem fhem funktionieren.
ZitatKönnt ihr mir bitte kurz auf die Sprünge helfen, wie ich z.B. den HM-USB-Stick einbinden würde?
http://www.fhemwiki.de/wiki/HM-CFG-USB_USB_Konfigurations-Adapter
ZitatMacht es Sinn den HM-USB-Stick neben dem CUL am RaspberryPi laufen zu lassen? (Die AES-Geräte dann über den HM-USB-Stick, den Rest weiter über den CUL.)
jain. ich würde den cfg usb kaufen und den zu teuren cul verkaufen ( dann haste den stick locker wieder drin)
beachte die aes cul nachteile http://www.fhemwiki.de/wiki/AES_Encryption#Nachteile.2C_Einschr.C3.A4nkungen
mit vccu kannst du ohne aufwand auch mehrer ios nutzen.
ZitatMacht es Sinn nur noch den HM-USB-Stick zu verwenden und den CUL aus der Konfiguration zu nehmen?
wenn du beides hast schadet es nicht beide ios der vccu zur verfügung zu stellen. die vccu wählt dann das empfangstechnisch bessere io für die devices aus.
ZitatMacht es Sinn den HM-USB-Stick statt am Raspberry Pi an meiner Synology Diskstation zu verwenden?
absolut nicht! fhem auf nas ist eine krücke. das fängt bei fehlenden treibern für stick und cul an und hört bei nicht mehr schlafenden platten auf.
ZitatIst es auch möglich beim HM-Sec-Sco die AES-Verschlüsselung auszuschalten?
wieso auf sicherheit verzichten?
Vielen, vielen Dank für die ganzen Informationen. Ich gebe mich dann mal drann und versuche Eure Tipps umzusetzen...
schade, dass zur Ausschlaltung von AES nichts mehr geschrieben wurde.
ich habe das Problem, dass sich HM-SEC-SCo nicht richtig pairen lassen. In den Readings heißt es zwar PairedTo .... aber irgendwann ist der Eintrag weg und es steht da nur noch PairedTo 0x000000.
Ich habe gelesen, dass das eingeschlatete AES am Sensor das Problem ist. Also wäre Auschalten eine Option.
Ich verwende ein CUL und ein hmusb mit einer vccu. Auch da habe ich gelesen, dass es mit CUL und AES mit dem Crypt-Paket rijndael gehen sollte. Kann ich leider noch nicht bestätigen.
Mit dem hmusb müsste es allemal gehen. Leider aber auch das negativ. Kurzum, ich bekomme HM-SEC-SCo nicht stabil gepaired. :-( Alle Sensoren funktionieren allerdings und zeigen den jeweligen Status offen/geschlossen richtig an.
Und AES-Abschaltung am Fenstersensor habe ich mit set devicename sign off versucht. Klappt auch nicht. :(
ZitatUnd AES-Abschaltung am Fenstersensor habe ich mit set devicename sign off versucht. Klappt auch nicht.
wenn kein pairing, dann auch kein setzen.
im wiki pairen siehst du, woran man ein korrektes pairing erkennt.
poste mal je ein list von vccu, hmusb, cul und sco.
List von VCCU
Internals:
CUL_0_MSGCNT 1002
CUL_0_RAWMSG A1470845E330FE3000000843BBE00007D00320910FC::-105.5:CUL_0
CUL_0_RSSI -105.5
CUL_0_TIME 2016-03-03 15:48:41
DEF 8F55B3
IODev CUL_0
LASTInputDev hmusb
MSGCNT 2068
NAME myVCCU
NR 42
NTFY_ORDER 50-myVCCU
STATE hmusb:ok,CUL_0:ok,
TYPE CUL_HM
assignedIOs CUL_0,hmusb
hmusb_MSGCNT 1066
hmusb_RAWMSG E330FE3,0000,0A9281D0,FF,FFA4,70845E330FE3000000843BBE00007D00320910FC
hmusb_RSSI -92
hmusb_TIME 2016-03-03 15:48:41
lastMsg No:08 - t:02 s:8F55B3 d:1E5FB2 00
protLastRcv 2016-03-03 13:32:49
protSnd 2 last_at:2016-03-03 15:44:10
protState CMDs_done
rssi_at_CUL_0 avg:-24.5 min:-25 max:-24 lst:-24 cnt:2
Readings:
2016-03-03 13:32:49 CommandAccepted yes
2015-08-05 11:50:08 aesReqTo TH_FensterTuer
2016-02-23 19:53:50 recentStateType ack
2016-03-03 11:02:00 state hmusb:ok,CUL_0:ok,
[...]
2015-06-21 12:00:41 unknown_387E0E received
2015-06-20 09:04:06 unknown_387E37 received
2015-06-20 10:03:04 unknown_387E40 received
2015-06-21 11:26:01 unknown_387E49 received
2015-06-21 12:13:22 unknown_387E5F received
2015-07-15 17:28:37 unknown_387E76 received
2015-07-12 23:34:14 unknown_387E78 received
2015-06-21 12:40:26 unknown_387EB5 received
2015-07-15 14:23:51 unknown_387EBE received
2015-06-21 10:12:03 unknown_387EEA received
2015-07-05 14:13:41 unknown_387EF2 received
[...]
2016-02-22 20:55:02 unknown_999999 received
Helper:
HM_CMDNR 10
mId FFF0
rxType 1
Expert:
def 1
det 0
raw 0
tpl 0
Io:
nextSend 1457008369.98294
prefIO
vccu
ioList:
hmusb
CUL_0
Mrssi:
mNo 08
Io:
CUL_0 -22
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
vrt 1
Rssi:
At_cul_0:
avg -24.5
cnt 2
lst -24
max -24
min -25
Attributes:
IODev CUL_0
IOList hmusb,CUL_0
comment Virtueller Controller
model CCU-FHEM
room Server
subType virtual
webCmd virtual:update
List hmusb:
Internals:
DEF 192.168.178.43:1234
DeviceName 192.168.178.43:1234
FD 7
IFmodel LAN
NAME hmusb
NR 9
NTFY_ORDER 50-hmusb
PARTIAL
RAWMSG E1E9823,0000,0A96FC57,FF,FFBA,CF84101E98238F55B30601C800
RSSI -70
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 11 report:10
hmusb_MSGCNT 2840
hmusb_TIME 2016-03-03 15:53:35
msgKeepAlive dlyMax:9.654 bufferMin:-4
msgLoadCurrent 0
msgLoadHistory 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
msgParseDly min:-709 max:5108 last:249 cnt:2703
owner 8F55B3
owner_CCU myVCCU
uptime 002 49:21:07.159
Readings:
2016-03-03 11:02:00 D-HMIdAssigned 8F55B3
2016-03-03 11:02:00 D-HMIdOriginal 2CC7A3
2016-03-03 11:02:00 D-firmware 0.964
2016-03-03 11:02:00 D-serialNr LEQ0658848
2016-03-03 11:02:00 Xmit-Events ok:1 disconnected:1 init:1
2016-03-03 11:02:00 cond ok
2016-03-03 15:53:18 loadLvl low
2016-03-03 11:01:24 prot_disconnected last
2016-03-03 11:01:24 prot_init last
2016-03-03 11:02:00 prot_ok last
2016-02-24 20:48:50 prot_timeout last
2016-03-03 11:01:24 state opened
Helper:
assIdCnt 11
assIdRep 10
info 03C4,LEQ0658848,2CC7A3,8F55B3
setTime 44464
Cnd:
0 1
253 1
255 1
Dly:
cnt 2703
lst 249
max 5108
min -709
Ids:
1dae5d:
cfg +1DAE5D,00,00,00
chn 06
flg 0
msg
name HMRemote01
to 1457009342.41755
1e5fb2:
cfg +1E5FB2,00,00,00
chn 01
flg 0
msg
name WZ_DimmerTV
to 1457008374.18863
1e7906:
cfg +1E7906,00,00,00
chn 01
flg 0
msg
name Garagentor
to 1457011696.28854
1e8ae2:
cfg +1E8AE2,00,00,00
chn 00
flg 0
msg
name SD_Studio
to 1457003204.22215
1eb6b6:
cfg +1EB6B6,00,00,00
chn 80
flg 0
msg
name StatusMonitor
to 1457011910.10902
2076bb:
cfg +2076BB,00,00,00
chn 01
flg 0
msg
name SteckdoseMultimedia
to 1457008290.66756
249f03:
cfg +249F03,00,00,00
chn 01
flg 0
msg
name Haus_Bewegungsmelder_1
to 1457016434.75725
2919d1:
cfg +2919D1,00,00,00
chn 02
flg 0
msg
name GarageSwitch
to 1457012050.32023
33752b:
cfg +33752B,00,00,00
chn 08
flg 0
msg
name HMRemote03
to 1457009054.41307
387eea:
cfg +387EEA,00,00,00
chn 01
flg 0
msg
name KE_Fenster_2
to 1457016351.27992
39796b:
flg 0
K:
BufMin -4
DlyMax 9.654
Next 1457016823.05737
Start 1457016798.05737
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0xeee350)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLast 0
loadNo 10
scnt 3
apIDs:
Ref:
drft -2.99961005069341e-05
hmtL 177649992
kTs 0
offL 1456839148078
sysL 1457016773066
Attributes:
hmId 8F55B3
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room Server
List CUL:
Internals:
CMDS BbCFiAZEGMKUYRTVWXefmltux
CUL_0_MSGCNT 2669
CUL_0_TIME 2016-03-03 15:55:03
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
DEF /dev/ttyACM0@9600 1034
DeviceName /dev/ttyACM0@9600
FD 6
FHTID 1034
NAME CUL_0
NR 7
NR_CMD_LAST_H 94
PARTIAL
RAWMSG A0C75867020695800000000B82C23
RSSI -56.5
STATE Initialized
TYPE CUL
VERSION V 1.61 CUL868
initString X21
Ar
owner_CCU myVCCU
Matchlist:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2016-03-03 11:01:23 cmds B b C F i A Z E G M K U Y R T V W X e f m l t u x
2016-03-02 15:58:27 raw V 1.61 CUL868
2016-03-03 15:55:03 state Initialized
XMIT_TIME:
1457012852.74671
1457012879.99449
1457012911.1417
1457012911.65444
1457012911.74224
1457012912.5056
1457012956.54792
1457012957.40378
1457012957.49428
1457012958.00518
1457012958.11384
1457012976.16725
1457012976.26858
1457013030.43718
1457013258.80547
1457013258.90701
1457013671.60998
1457013804.67323
1457013981.26492
1457014030.78814
1457014030.89054
1457014033.99201
1457014172.81201
1457014223.41942
1457014224.3265
1457014224.77546
1457014225.20459
1457014308.48429
1457014315.40932
1457014350.40298
1457014379.06409
1457014417.7201
1457014454.83114
1457014455.3426
1457014455.43126
1457014456.19173
1457014456.24571
1457014456.26128
1457014456.4479
1457014581.86987
1457014582.3989
1457014582.48711
1457014582.99686
1457014601.59556
1457014602.32652
1457014602.41766
1457014602.94152
1457014633.0473
1457014633.56137
1457014687.52349
1457014688.06983
1457014688.69543
1457014757.7893
1457014758.28439
1457014758.7336
1457014759.16178
1457014795.90823
1457014826.82179
1457014858.73971
1457014902.78257
1457014948.74551
1457014949.25989
1457014949.34761
1457014950.15903
1457015080.08797
1457015080.80959
1457015080.90046
1457015081.69429
1457015107.79637
1457015108.31256
1457015108.88732
1457015319.23422
1457015319.96226
1457015320.05006
1457015320.55902
1457015449.24538
1457015450.50554
1457015450.59531
1457015451.12812
1457015451.25578
1457015499.32653
1457015499.87473
1457015500.41
1457015611.75332
1457015612.2513
1457015612.6834
1457015613.1154
1457015716.70803
1457015853.39847
1457015901.74688
1457015937.56963
1457015937.73929
1457016250.54843
1457016445.37806
Helper:
000000:
QUEUE:
1b51cb:
QUEUE:
1c78e2:
QUEUE:
206a75:
QUEUE:
2da5b1:
QUEUE:
33752b:
QUEUE:
34623b:
QUEUE:
3822a4:
QUEUE:
387e37:
QUEUE:
387e40:
QUEUE:
387e49:
QUEUE:
387e5f:
QUEUE:
387e76:
QUEUE:
387e78:
QUEUE:
387eb5:
QUEUE:
387ebe:
QUEUE:
387eea:
QUEUE:
387ef2:
QUEUE:
39796b:
QUEUE:
Attributes:
hmId 8F55B3
icon icoSYSTEM
rfmode HomeMatic
room Server
verbose 3
und List von dem sco, das offensichtlich nicht gepaired ist(, aber siehe unten weitere sco):
Internals:
CUL_0_MSGCNT 175
CUL_0_RAWMSG A0D1F8610387EEA00000006010000::-47:CUL_0
CUL_0_RSSI -47
CUL_0_TIME 2016-03-03 15:46:55
DEF 387EEA
IODev hmusb
LASTInputDev hmusb
MSGCNT 359
NAME KE_Fenster_2
NR 1298
NTFY_ORDER 50-KE_Fenster_2
STATE closed
TYPE CUL_HM
hmusb_MSGCNT 184
hmusb_RAWMSG E387EEA,0000,0A90E209,FF,FFC9,1F8610387EEA00000006010000
hmusb_RSSI -55
hmusb_TIME 2016-03-03 15:46:55
lastMsg No:1F - t:10 s:387EEA d:000000 06010000
protCmdDel 15
protLastRcv 2016-03-03 15:46:55
protNack 3 last_at:2016-03-03 15:42:07
protResnd 5 last_at:2016-03-03 15:40:50
protResndFail 1 last_at:2016-03-03 15:37:49
protSnd 35 last_at:2016-03-03 15:45:49
protState CMDs_done
rssi_at_CUL_0 avg:-43.13 min:-47 max:-41 lst:-47 cnt:175
rssi_at_hmusb avg:-50.99 min:-57 max:-49 lst:-55 cnt:184
Readings:
2016-03-03 15:45:48 Activity alive
2016-03-03 15:42:07 CommandAccepted no
2016-03-03 15:45:48 D-firmware 1.0
2016-03-03 15:45:48 D-serialNr MEQ0183971
2016-03-03 15:45:48 PairedTo 0x000000
2016-03-03 15:39:20 R-cyclicInfoMsg on
2016-03-03 15:40:45 R-eventDlyTime 0 s
2016-03-03 15:39:20 R-pairCentral 0x000000
2016-03-03 15:39:20 R-sabotageMsg on
2016-03-03 15:40:45 R-sign on
2016-03-03 15:45:48 RegL_00. 02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
2016-03-03 15:45:49 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2016-03-03 15:38:43 aesCommToDev fail
2016-03-03 15:33:33 aesKeyNbr 00
2016-03-03 15:46:55 alive yes
2016-03-03 15:46:55 battery ok
2016-03-03 15:46:55 contact closed (to broadcast)
2016-03-03 15:46:55 recentStateType info
2016-03-03 15:46:55 sabotageError off
2016-03-03 15:46:55 state closed
2016-03-03 15:46:51 trigger_cnt 7
Helper:
HM_CMDNR 31
PONtest 0
cSnd 018F55B3387EEA01040000000001,018F55B3387EEA0103
mId 00C7
peerIDsRaw ,00000000
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +387EEA,00,00,00
nextSend 1457016415.37583
rxt 2
vccu myVCCU
p:
387EEA
00
00
00
prefIO:
hmusb
Mrssi:
mNo 1F
Io:
CUL_0 -47
hmusb -53
Prt:
bErr 0
sProc 0
sleeping 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_cul_0:
avg -43.1314285714286
cnt 175
lst -47
max -41
min -47
At_hmusb:
avg -50.9945652173913
cnt 184
lst -55
max -49
min -57
Shadowreg:
Attributes:
IODev CUL_0
IOgrp myVCCU:hmusb
actCycle 000:50
actStatus alive
autoReadReg 5_readMissing
devStateIcon .*open:fts_window_2w_open .*closed:fts_window_2w
expert 2_full
firmware 1.0
group Fenstersensor
icon fts_window_2w
model HM-SEC-SCo
peerIDs 00000000,
room EG,KEZ
serialNr MEQ0183971
status EG_Fenster
subType threeStateSensor
userattr room_map status status_map structexclude
List weitere sco:
Internals:
CUL_0_MSGCNT 6
CUL_0_RAWMSG A0D2CA610387EBE8F55B306010000::-54:CUL_0
CUL_0_RSSI -54
CUL_0_TIME 2016-03-03 15:47:25
DEF 387EBE
IODev CUL_0
LASTInputDev hmusb
MSGCNT 12
NAME KE_Fenster_1
NR 1353
NTFY_ORDER 50-KE_Fenster_1
STATE closed
TYPE CUL_HM
hmusb_MSGCNT 6
hmusb_RAWMSG E387EBE,0000,0A91578E,FF,FFC1,2CA610387EBE8F55B306010000
hmusb_RSSI -63
hmusb_TIME 2016-03-03 15:47:25
lastMsg No:2C - t:10 s:387EBE d:8F55B3 06010000
protLastRcv 2016-03-03 15:47:25
protSnd 6 last_at:2016-03-03 15:47:25
protState CMDs_done
rssi_at_CUL_0 avg:-53.58 min:-54 max:-53.5 lst:-54 cnt:6
rssi_at_hmusb avg:-62.66 min:-63 max:-62 lst:-63 cnt:6
Readings:
2016-03-03 15:55:48 Activity alive
2016-03-02 16:48:52 CommandAccepted yes
2016-03-02 16:48:50 D-firmware 1.0
2016-03-02 16:48:50 D-serialNr MEQ0183927
2016-03-02 16:48:52 PairedTo 0x8F55B3
2016-03-02 16:48:52 R-cyclicInfoMsg on
2016-03-02 16:48:53 R-eventDlyTime 0 s
2016-03-02 16:48:52 R-pairCentral 0x8F55B3
2016-03-02 16:48:52 R-sabotageMsg on
2016-03-02 16:48:53 R-sign on
2016-03-02 16:48:52 RegL_00. 02:01 09:01 0A:8F 0B:55 0C:B3 10:01 14:06 00:00
2016-03-02 16:48:53 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2016-03-02 16:48:52 aesCommToDev ok
2016-03-02 16:48:52 aesKeyNbr 00
2016-03-03 15:47:25 alive yes
2016-03-03 15:47:25 battery ok
2016-03-03 15:47:25 contact closed (to myVCCU)
2016-03-03 15:47:25 recentStateType info
2016-03-03 15:47:25 sabotageError off
2016-03-03 15:47:25 state closed
2016-03-02 16:47:05 trigger_cnt 66
Helper:
HM_CMDNR 44
mId 00C7
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +387EBE,00,00,00
nextSend 1457016445.46201
rxt 2
vccu myVCCU
p:
387EBE
00
00
00
prefIO:
CUL_0
Mrssi:
mNo 2C
Io:
CUL_0 -52
hmusb -63
Prt:
bErr 0
sProc 0
sleeping 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO CUL_0
flg A
ts 1457016445.37577
ack:
HASH(0x20abbc8)
2C80028F55B3387EBE00
Rssi:
At_cul_0:
avg -53.5833333333333
cnt 6
lst -54
max -53.5
min -54
At_hmusb:
avg -62.6666666666667
cnt 6
lst -63
max -62
min -63
Attributes:
IODev CUL_0
IOgrp myVCCU:CUL_0
actCycle 000:50
actStatus alive
autoReadReg 5_readMissing
devStateIcon .*open:fts_door_right_open .*closed:fts_door_right
expert 2_full
firmware 1.0
group Fenstersensor
icon fts_door_right
model HM-SEC-SCo
peerIDs 00000000,
room EG,KEZ
serialNr MEQ0183927
subType threeStateSensor
Der aktuelle nicht gepaired sco war zuvor auch mit VCCU:CUL gepaired und plötzlich hat er diese Infos verloren. Also habe ich auch mal VCCU:hmusb als IOgrp eingetragen. Aber das hilft nichts.
Für mich ist das so, dass die IO-Devices sich nicht mit den Fenstersensoren sauber pairen wollen. Jetzt weiss ich, dass es beim pairen entweder oder gibt. Aber hier würde ich sagen, dass nur zeitweise ein richtiges pairing vorliegt. Also in den Registern PairedTo 0xblabla.
Ich hoffe, dass ich das nicht zu chaotisch dargestellt habe.
pairen bedeutet: die ID der zentrale (8F55B3) ins eeprom vom device schreiben.
also weder zeitweise richtig gepaired, noch fast gepaired, ..... => entweder steht die id drin oder nicht.
löschen nur über werkreset (selbst das nur, wenn kein eigener aes key gesetzt ist).
1. dein hmusb braucht fw 0.967 und aktuellen hmland.
2. fhem muss tagesaktuell sein.
3. dein gepairter sco ist auch gesichert. also muss mindestens ein io beim pairen aes gekonnt haben. da der cul die besten rssi hat, wird wohl die vccu den cul zum pairen benutzt haben.
4. als prefered io (IOgrp) am besten immer den io mit den besten rssi eintragen.
5. da der fk meistens schläft, musst du ihn nach dem hmpairforsec wecken, damit er die befehle empfangen kann. entweder knöpfchen drücken (funktioniert bei jedem device) oder fenster öffnen, da dieser fk auch lazy config kann.
6. einfach noch mal drüber pairen, bis es funktioniert.
7. immer ruhig bleiben. 8)
Danke Frank!
hmland und firmware-Update vom hmusb habe ich vorgenommen.
Danach weiss nicht wie oft ich das gleiche weiderholt habe, bis endlich der Sensor gepaired ist.
Ich verstehe, dass die ID entweder im Device geschrieben wurde, oder nicht. Damit ist auch festgelegt, ob das pairing vollzogen wurde, oder nicht. Trotzdem meine Frage:
Kann es eine Konstallation geben, wo das beschriebene Device wieder seine eingetragene IO-Device-ID verliert?
Mir kommt bzw. kam es so vor. Weil der Fenstersensor wie alle übrigen gepaired war. In meiner Fenstersensorsammlung gibt es noch einen weiteren, der das gleiche Fehlerbild hat. Da sitze ich noch dran.
Mein weiterer Eindruck ist, dass es einen deterministischen Weg gibt, der dieses pairen am Ende vollzieht. Ich habe einfach immer das gleiche wiederholt (hmPairForSec, Knopf drücken am Sensor) irgendwann ging es, aber warum? Vielleicht spielt auch die Zeit ein Rolle, weil nur die ist beim stupiden wiederholen nicht immer exakt gleich. Sonst sind die Schritte immer die gleichen gewesen. Ab und zu habe ich den Sensor auf die Werkseinstellungen zurückgesetzt. Oder ist doch alles nur Zufall. :-)
Bringt es was, wenn die ich Konfiguration sichere? könnte ich diese wieder zum Sensor spielen, wenn er "spinnt"? Vielleicht bin ich es der spinnt. :-)
zufall würde ich mal von deiner agenda streichen. ausserdem ist immer eine optimale funkverbindung grundvoraussetzung für eine korrekte kommunikation. besonders wenn aes im spiel ist, da hier noch mehr gefunkt wird.
ich denke du musst die kommunikationsprozedur mal in ruhe testen, zb mit getconfig. besonders mit batteriedevices die geweckt werden müssen. bei jedem wecken werden nämlich nicht alle anstehenden (pending) cmds abgeholt/ausgeführt, sondern immer häppchenweise. am besten mal im detailfenster des devices unter internals die protokolldaten beobachten. aber beachte, dass diese daten nicht automatisch aktualisiert werden, sondern erst nach einem aktualisieren der website.
wenn man viele cmds absetzt (eventuell über nervöses rumklicken) kann die cmdqueue sehr schnell, sehr lang werden. somit können zb vor dem pairen bereits cmds in der queue hängen, wodurch vielleicht alles ein wenig seltsam erscheint. am besten vor einem cmd, die queue leeren mit set clear msgEvents. erst bei cmds_done wurde die kommunikation erfolgreich beendet.
wie gesagt, kann ein pairing eigentlich nur durch reset am device verloren gehen. um das device von fhem zu resetten, muss es erst gepairt sein.
sichern ist immer gut. 8)
sichern ist zwar gut, aber Im Nachhinein ist mir eingefallen, dass mir das wenig bringt, wenn das pairing sich aufgelöst hat. Weil dann doch auch kein Rückspielen des Backups möglich ist, oder?
Ich glaube nämlich, dass ich in meinem Sicherungswahn mal alle Devices gesichert habe. :)
Man braucht schon etwas Geduld mit diesen Spielzeugen. :-)
genau, ohne pairing keine kommunikation, also auch kein einspielen der sicherung. die sicherung ist ja auch eher für konfigurationsänderungen und peerings gedacht.
das pairing bleibt ja erhalten, wenn man es nicht absichtlich löscht. ;)
wenn du deine zentralen hmid änderst (zb durch wechsel der zentrale, indem vorher mit eq3 sw gespielt wurde), bringt dir das alte pairing natürlich auch nichts mehr, da das device nur mit der gespeicherten hmid kommuniziert.
die hmid habe ich nicht geändert. Lediglich die Firmware von CUL und nun auch hmusb habe ich aktualisert.
Da ich auch nicht an Zufällen glaube, kann ich zumindest berichten, was jetzt auch das zweite Device vermutlich zum pairen überredet hat. Ein shutdown restart von fhem (?).
Als ich die unzähligen Versuche des ersten Fenstersensors auch zum Erfolg gebracht habe, hatte ich davor auch ein Restart gemacht. Bilde ich mir das nur ein? ;)
Ich bin jedenfalls froh, dass alle Sensoren wieder gepaired sind. :) Danke für die Unterstützung.
Kann mich nun den restlichen kleinen Baustellen in der hminfo configCheck widmen.
Wenn in den internals CMDs_processing steht, soll ich da besser nix machen und nur bei pending mal auf den Device-Knopf drücken?
Weil mir das zufällige Pairing der Devices davor keine Ruhe läßt, habe ich ein Device resettet (Werkseinstellungen). Dann "set myVCCU hmPairForSec 300" und anschließend Knopf auf dem Fenstersensor. Es folgt minutenlang (>10) CMDs_processing. Irgendwann kommt pending und das schiebe ich wieder mit Knopfdruck an. ....
Ich bekomme den Sensor nicht gepaired. Ich hätte aber gerne einen Anlernprozess, der kontrolliert durchgeht. Das habe ich nicht. Die anderen Fenstersensonsoren waren irgendwann gepaired, aber warum und was endlich zur Erfolg geführt hat, ist mir ein Rätsel. Das stimmt mich einfach nicht zuversichtlich. Ich habe das Gefühl, dass fhem mich im Griff hat, aber nicht umgekehrt. 😎
ZitatWenn in den internals CMDs_processing steht, soll ich da besser nix machen und nur bei pending mal auf den Device-Knopf drücken?
bei prozessing sind beide noch aktiv, also noch ein moment warten und dann den
browser aktualisiren.
lies meine beiträge nochmal
sorgfältig durch. ;)
Hallo Frank,
ich habe zu diesem Thema alle Deine Beiträge aufmerksam gelesen. Damit habe ich auch einiges erfolgreich erledigen können. Refresh des Browsers und keine nervösen Finger :) habe ich alles beherzigt. Die Queue geleert mit clear msgEvents und dann auch Processing abgewartet. Auch das Wecken durch einfaches öffnen des Fensters usw. Vielleicht mache ich auch noch einen systematischen Fehler, der mir diese Sensoren einfach nicht reibungslos pairen lässt. Ich habe bisher eine Vielzahl von devices problemlos an fhem anbinden können. Soviel Probleme wie mit diesen Sensoren hatte ich nicht.
ich hätte gerne beliebig reproduzierbare Ergebnisse und keine "Zufallsresultate". Dafür lese ich auch gerne alle notwendigen Beiträge. :D
Pairing hat nun geklappt. :o
Warum? Kann ich nicht wirklich sagen.
Als IODevice nutze ich ein CUL und ein HMUSB. In IOgrp war beim Fenstersensor der CUL als bevorzugt eingetragen, weil der leicht bessere RSSI-Werte hat. Alle Komponenten befinden sich in einem Radius von 3 Meter voneinander entfernt. In der Konstellation habe ich mehrmals (mindestens 15 Mal) den Anlernprozess vergeblich gestartet.
Die Stadien CMDs_processing dauerten bis zu 30 Minuten, um dann wechselweise nach CMDs_pending zu gehen wo ich dann wieder auf den Knopf gedrückt habe usw., usw. Alles vergeblich. Auch das leeren der msgQueue, Resetten des Sensors, etc. etc.
Dann habe ich in der IOgrp einfach den "schlechteren" HMUSB eingetragen (--> Save) und den Anlernvorgang wieder angestoßen. Der Vorgang war in Sekundenschnelle erledigt. Fenstersensor ist gepaired. In der IOgrp steht natürlich automatisch der CUL drin (wg bessere RSSI). Hat die kurzzeitige Änderung des IOgrp den Erfolg gebracht? Oder war es Zufall? :)
Wenn ich mehr Zeit hätte, würde ich einen neuen Sensor mir vorknöpfen, aber das muss ich ein andermal machen.
Ich hatte die selben Probleme wie du aber ich bin nicht so geduldig hab 3-4 mahl den Anlern knopf gedrückt wen es nicht geklappt hat Batterie raus kurz warten und wieder von vorne ging eigentlich ganz gut...
Gruss Markus
ZitatDann habe ich in der IOgrp einfach den "schlechteren" HMUSB eingetragen (--> Save) und den Anlernvorgang wieder angestoßen. Der Vorgang war in Sekundenschnelle erledigt. Fenstersensor ist gepaired. In der IOgrp steht natürlich automatisch der CUL drin (wg bessere RSSI). Hat die kurzzeitige Änderung des IOgrp den Erfolg gebracht? Oder war es Zufall?
das ist sicherlich das problem.
grundsätzlich hat der cul nachteile bei der kommunikation mit homematic gegenüber hmlan, hmusb, da das timing der messages von fhem nicht kontrollierbar ist. wenn nun auch noch aes im spiel ist, wird das timing durch die umfangreichere kommunikation sicherlich immer kritischer.
im homematicbereich ist ein thread angepinnt, der eine verbesserte fw bietet. damit sollten die probleme entschärft werden können.
du kannst beim pairen auch direkt entscheiden mit dem hmusb zu pairen, indem du gleich "set hmusb pairforsec" benutzt. dann wird allerdings nicht automatisch das attr iogrp gesetzt. das müsstest du dann manuell ändern.
sofern es die rssi zulassen, würde ich allen homematic devices den hmusb als prefered io zuordnen, zumindestens diejenigen mit eingeschaltetem aes, oder andere problemkinder. dann übernimmt der cul nur, falls der hmusb verhindert ist. das empfangen der messages wird sowieso von allen io's gemacht.