Guten Abend
Ich habe einen Raspi mit HMLAN1, HMUART und VCCU im Netzwerk mit folgender Konfig:
define HMLAN1 HMLAN 192.168.0.123:1000
attr HMLAN1 hmId 000001
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr HMLAN1 room .fhem
define HMUART HMUARTLGW /dev/ttyAMA0
attr HMUART hmId 000001
attr HMUART room .fhem
define VCCU CUL_HM 000001
attr VCCU IOList HMUART,HMLAN1
attr VCCU expert 2_raw
attr VCCU model CCU-FHEM
attr VCCU room .fhem
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Ich nutze mehrere HM-LC-BL1-FM wobei einer aufgrund der Distanz keinen Kontakt zur HMUART hat.
Nach jedem Neustart des Raspi muss dieser HM-LC-BL1-FM neu gepairt werden weil die Verbindung nicht hergestellt wird.
Nun konnte ich das Problem lösen indem ich die Reihenfolge der Definition in der VCCU folgendermaßen gedreht habe:
attr VCCU IOList HMLAN1,HMUART
Hat jemand von Euch eine Idee weshalb das bei mir so ist ?
ZitatNach jedem Neustart des Raspi muss dieser HM-LC-BL1-FM neu gepairt werden
ganz sicher, nicht richtig!
was hast du bezüglich vccu in dem Device eingetragen? (HM-LC-BL1-FM )
Zeig mal bitte ein list der vccu und des HM-LC-BL1-FM
Mit dem Handy online, daher kurz gefasst...
Hallo zusammen - anbei die Daten bei derzeit funktionierendem System
get VCCU listDevice:
devices using VCCU
current IO / preferred
HMLAN1 / --- r1_Aktor
HMLAN1 / --- r3_Aktor
HMLAN1 / --- r3_Fuehler
HMLAN1 / --- r4_Aktor
HMLAN1 / --- r4_Fuehler
HMUART / --- r0_Fuehler
HMUART / --- r1_Fuehler
HMUART / --- r1_Griff
HMUART / --- r1_Sender
HMUART / --- r2_Antrieb
HMUART / --- r2_Fuehler
HMUART / --- r2_Griff
HMUART / --- r2_Steckdose
HMUART / --- r3_Sender
Internals VCCU:
DEF 000001
HMLAN1_MSGCNT 4
HMLAN1_RAWMSG E37E63B,0000,0BC19C00,FF,FF9A,44A24137E63B000001013D64
HMLAN1_RSSI -102
HMLAN1_TIME 2017-11-22 06:43:15
HMUART_MSGCNT 3
HMUART_RAWMSG 0500005544A24137E63B000001013D64
HMUART_RSSI -85
HMUART_TIME 2017-11-22 06:43:11
IODev HMUART
LASTInputDev HMLAN1
MSGCNT 7
NAME VCCU
NOTIFYDEV global
NR 36
NTFY_ORDER 50-VCCU
STATE HMLAN1:ok,HMUART:ok
TYPE CUL_HM
assignedIOs HMLAN1,HMUART
get r3_Aktor regTable:
r3_Aktor type:blindActuator -
list:peer register :value
0: confBtnTime :permanent
0: intKeyVisib :invisib
0: localResDis :off
0: pairCentral :0x000001
1: driveDown :25 s
1: driveTurn :0.5 s
1: driveUp :25 s
1: refRunCounter :0
1: sign :off
1: statusInfoMinDly :2 s
1: statusInfoRandom :1 s
1: transmitTryMax :6
Internals r3_Aktor:
DEF 575217
HMLAN1_MSGCNT 17
HMLAN1_RAWMSG RE0D0D414,0001,0A51EE17,FF,FFC0,3AA0105752170000010100000000
HMLAN1_RSSI -64
HMLAN1_TIME 2017-11-22 00:01:43
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 17
NAME r3_Aktor
NOTIFYDEV global
NR 791
NTFY_ORDER 50-r3_Aktor
STATE off
TYPE CUL_HM
lastMsg No:3A - t:10 s:575217 d:000001 0100000000
protLastRcv 2017-11-22 00:01:43
protSnd 17 last_at:2017-11-22 00:01:43
protState CMDs_done
rssi_HMLAN1 cnt:1 avg:-62 min:-62 max:-62 lst:-62
rssi_at_HMLAN1 max:-64 lst:-64 cnt:17 avg:-64 min:-64
Könnte es sein, dass die Reihenfolge in der fhem.cfg damit was zu tun hat ?
1. define HMLAN1 HMLAN 192.168.0.123:1000
2. define HMUART HMUARTLGW /dev/ttyAMA0
3. define VCCU CUL_HM 000001
attr VCCU IOList HMUART,HMLAN1
Zitat von: flywhiskygolf am 22 November 2017, 12:44:20
Könnte es sein, dass die Reihenfolge in der fhem.cfg damit was zu tun hat ?
Wenn du nicht daran herumgespielt hast, dann nicht ;D
Das macht FHEM alles selbst.
Ein List sieht aber anders aus.
list <device> und das ganze in Code Tags #-Button über den Smileys.
Siehe https://forum.fhem.de/index.php/topic,71806.0.html
Gruß
Hallo, danke für die Hilfe und hoffe nun ist es richtig ???
Internals:
DEF 000001
HMLAN1_MSGCNT 4
HMLAN1_RAWMSG E37E63B,0000,0BC19C00,FF,FF9A,44A24137E63B000001013D64
HMLAN1_RSSI -102
HMLAN1_TIME 2017-11-22 06:43:15
HMUART_MSGCNT 3
HMUART_RAWMSG 0500005544A24137E63B000001013D64
HMUART_RSSI -85
HMUART_TIME 2017-11-22 06:43:11
IODev HMUART
LASTInputDev HMLAN1
MSGCNT 7
NAME VCCU
NOTIFYDEV global
NR 36
NTFY_ORDER 50-VCCU
STATE HMLAN1:ok,HMUART:ok,
TYPE CUL_HM
assignedIOs HMLAN1,HMUART
READINGS:
helper:
HM_CMDNR 10
cfgChkResult No regs found for:
mId FFF0
rxType 1
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
ioList:
HMLAN1
HMUART
mRssi:
mNo
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
nb:
cnt 1
Attributes:
IODev HMUART
IOList HMLAN1,HMUART
expert 2_raw
model CCU-FHEM
room .fhem
subType virtual
webCmd virtual:update
Internals:
DEF 575217
HMLAN1_MSGCNT 28
HMLAN1_RAWMSG RE380B148,0001,0D01E89E,FF,FFBD,41A0105752170000010100000000
HMLAN1_RSSI -67
HMLAN1_TIME 2017-11-22 12:33:03
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 28
NAME r3_Aktor
NOTIFYDEV global
NR 791
NTFY_ORDER 50-r3_Aktor
STATE off
TYPE CUL_HM
lastMsg No:41 - t:10 s:575217 d:000001 0100000000
protLastRcv 2017-11-22 12:33:03
protSnd 28 last_at:2017-11-22 12:33:03
protState CMDs_done
rssi_HMLAN1 cnt:2 avg:-63 min:-64 max:-62 lst:-64
rssi_at_HMLAN1 max:-64 lst:-67 cnt:28 avg:-65.17 min:-67
READINGS:
2017-11-22 12:33:01 PairedTo 0x000001
2017-11-22 12:33:02 R-driveDown 25 s
2017-11-22 12:33:02 R-driveTurn 0.5 s
2017-11-22 12:33:02 R-driveUp 25 s
2017-11-22 12:33:01 R-pairCentral 0x000001
2017-11-22 12:33:02 R-sign off
2017-11-22 12:33:01 RegL_00. 02:01 0A:00 0B:00 0C:01 15:FF 18:00 00:00
2017-11-22 12:33:02 RegL_01. 08:00 09:00 0A:00 0B:00 0C:FA 0D:00 0E:FA 0F:05 10:00 30:06 57:24 56:00 00:00
2017-11-22 12:32:57 deviceMsg off (to VCCU)
2017-11-22 12:32:57 level 0
2017-11-22 12:32:57 motor stop:off
2017-11-22 12:32:57 pct 0
2017-11-22 12:32:57 recentStateType info
2017-11-22 12:32:57 state off
2017-11-22 12:32:57 timedOn off
helper:
HM_CMDNR 65
cSnd 0100000157521701040000000001,010000015752170103
cfgChkResult No regs found for:
r3_Aktor type:blindActuator -
list:peer register :value
0: confBtnTime :permanent
0: intKeyVisib :invisib
0: localResDis :off
0: pairCentral :0x000001
1: driveDown :25 s
1: driveTurn :0.5 s
1: driveUp :25 s
1: refRunCounter :0
1: sign :off
1: statusInfoMinDly :2 s
1: statusInfoRandom :1 s
1: transmitTryMax :6
mId 0005
peerIDsRaw ,00000000
rxType 1
supp_Pair_Rep 0
dir:
cur stop
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +575217,00,00,00
nextSend 1511350383.16474
rxt 0
vccu VCCU
p:
575217
00
00
00
mRssi:
mNo 41
io:
HMLAN1 -65
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rpt:
IO HMLAN1
flg A
ts 1511350383.08728
ack:
HASH(0x33549b8)
41800200000157521700
rssi:
HMLAN1:
avg -63
cnt 2
lst -64
max -62
min -64
at_HMLAN1:
avg -65.1785714285714
cnt 28
lst -67
max -64
min -67
shadowReg:
tmpl:
nb:
cnt 2
Attributes:
IODev HMUART
IOgrp VCCU
autoReadReg 5_readMissing
expert 2_raw
model HM-LC-BL1-FM
peerIDs 00000000,
room Garage
subType blindActuator
webCmd statusRequest:toggleDir:on:off:up:down:stop
IOgrp VCCU
mit dieser einstellung nimmt die vccu das io mit dem besten rssi. anscheinend hat die vccu bei einem restart keine daten, um den besten auszusuchen, sondern nimmt dann den ersten aus der liste.
bei allen stationären devices solltest du immer das beste io als prefered io setzen, dann wird immer dieses io benutzt, solange es verfügbar ist. also setze:
IOgrp VCCU:HMUART
bleibt die frage: warum du dauernd den pi restartest.