Ich hoffe, der Titel ist nicht irreführend.
Seit längerem nutze ich parallel sowohl einen eQ3-HM-LGW (HMLANGW) als auch einen HM-CFG-USB (HMUSB) über einen Raspberry Pi. FHEM läuft auf einem Cubietruck.
Beide HM-Gateways sind mittels VCCU verknüpft. Grundsätzlich funktioniert auch alles, so wie es soll. Hatte schon zu Anfangszeiten der Konstellation testweise je ein Gateway ausgesteckt und die Schaltung funktionierte über das andere. Soweit so gut.
Jetzt habe ich die Tage festgestellt, dass die Konstellation aktuell nicht so arbeitet wie ich es erwarte. Mache Empfänger schalten gar nicht, wenn das eQ3-HM-LGW per VCCU:HMLANGW priorisiert wird oder keine derartige Priorisierung vorliegt. Wird HMUSB priorisiert, dann schaltet der betreffende Schalter. RSSI ist für diesen Empfänger eindeutig besser für das HMLANGW. Ein anderer Schalter, der im gleichen Raum wie das HMLANGW ist, schaltet bei Priorisierung von HMLANGW zwar immer, aber doch sehr oft trotzdem über das HMUSB, obwohl dazwischen eine Stahlbetondecke liegt und folglich auch hier der RSSI deutlich schlechter ist.
Seltsam ist, dass das offensichtlich bis heute morgen funktioniert hat, dann aber erst im laufe des Vormittags nicht mehr. Ich hatte gestern Abend einige Testläufe mit meiner Gartenbewässerung, wo ein Hauptventil eben über die HM-Schiene sicher geschalten werden soll. Ging alles wunderbar. Aber heute Vormittag hat erst dann alles wieder funktioniert, nachdem ich eben das HMUSB wie beschrieben priorisiert habe.
Vielleicht hat jemand einen Tipp?
ist der lgw zeitweise im overload?
zeig mal ein "get hminfo msgStat" und protoEvents.
Danke für die Rückmeldung Naja, es sind einige Schalter, teils mit Energieüberwachung und Rauchmelder gekoppelt. Aber dann wäre das ja schon länger so und nicht erst seit heute Vormittag ohne jegliche Änderung.
Der
HM-LC-SW1-BA-PCB
der gerade die meisten Schwierigkeiten macht ist allerdings der
HM_507161
mgStat:
msg statistics
|-------------------------------------------------------->*
receive | 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
HMUSB :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|238| 0| 0| 0| 0| 0| 0| 0| 0| 0
HMLANGW :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|138| 0| 0| 0| 0| 0| 0| 0| 0| 0
send
HMUSB :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 88| 0| 0| 0| 0| 0| 0| 0| 0| 0
HMLANGW :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0
receive burst
HMUSB :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0
HMLANGW :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 24| 0| 0| 0| 0| 0| 0| 0| 0| 0
send burst
HMUSB :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 19| 0| 0| 0| 0| 0| 0| 0| 0| 0
HMLANGW :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0
| 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
|-------------------------------------------------------->*
receive | Mon| Tue| Wed| Thu| Fri| Sat| Sun|# 24h
HMUSB :| 0| 0| 0| 0| 0| 0| 0|# 238
HMLANGW :| 0| 0| 0| 0| 0| 0| 0|# 138
send
HMUSB :| 0| 0| 0| 0| 0| 0| 0|# 88
HMLANGW :| 0| 0| 0| 0| 0| 0| 0|# 3
receive burst
HMUSB :| 0| 0| 0| 0| 0| 0| 0|# 7
HMLANGW :| 0| 0| 0| 0| 0| 0| 0|# 24
send burst
HMUSB :| 0| 0| 0| 0| 0| 0| 0|# 19
HMLANGW :| 0| 0| 0| 0| 0| 0| 0|# 2
| Mon| Tue| Wed| Thu| Fri| Sat| Sun|# 24h
protoEvents:
protoEvents send to devices done:
name :State |CmdPend |Snd |SndB |Rcv |RcvB |Resnd #CmdDel |ResndFail |Nack |IOerr
HM_33C21B : done | - | 2 | - | 12 | - | - # - | - | - | -
HM_3E57B1 : done | - | 2 | - | 12 | - | - # - | - | - | -
HM_4AA1BC : done | - | 3 | - | 12 | - | - # - | - | - | -
HM_4CAE58 : done | - | 2 | - | 11 | - | - # - | - | - | -
HM_507161 : done | - | 71 | 19 | 50 | - | 1 # 1 | 1 | - | -
HM_50722A : done_Errors:1 | - | 1 | 2 | - | - | 1 # 1 | 1 | - | -
HM_673520 : - | - | - | - | - | - | - # - | - | - | -
HM_67352F : - | - | - | - | - | - | - # - | - | - | -
HM_673533 : - | - | - | - | - | - | - # - | - | - | -
HM_72A624 : - | - | - | - | - | - | - # - | - | - | -
HM_72A627 : done | - | 1 | - | 1 | - | - # - | - | - | -
HM_72A73A : - | - | - | - | - | - | - # - | - | - | -
HM_72A781 : - | - | - | - | - | - | - # - | - | - | -
Licht_Da : done | - | 2 | - | 1 | - | - # - | - | - | -
Licht_Ki : done | - | 2 | - | 1 | - | - # - | - | - | -
Licht_Ku : done | - | 3 | - | 1 | - | - # - | - | - | -
=========================================================================================================================================
sum 0 |0 |89 |21 |101 |0 |2 #2 |2 |0 |0
CUL_HM queue length:0
requests pending
----------------
autoReadReg :
recent : HM_507161
status request :
autoReadReg wakeup :
status request wakeup: HM_673520 HM_67352F HM_673533 HM_72A624 HM_72A73A HM_72A781
autoReadTest : HM_3E57B1 HM_67352F HM_72A73A HM_72A624 HM_33C21B Licht_Ki Licht_Da HM_507161 HM_4CAE58 HM_50722A HM_72A627 HM_72A781 Licht_Ku HM_673533 HM_4AA1BC HM_673520
IODevs:HMLANGW:opened condition:ok
msgLoadCurrent: 7
HMUSB:opened pending=0 condition:ok
msgLoadCurrent: 41
da ist ja noch nicht viel zu sehen. restart? oder hminfo neu definiert?
zeig mal ein list vom HM_50716, wenn dieser gerade "zickt", und vom lgw.
Noch schlimmer: Ein Update von FHEM gemacht....
Aber das Phänomen bleibt. Hier ist das List vom HM_507161
Internals:
Internals:
DEF 507161
FUUID 5c4e008f-f33f-10de-a8e1-400ae66cb2ba54de
HMLANGW_MSGCNT 32
HMLANGW_RAWMSG 0500004B4480025071612807650101000052
HMLANGW_RSSI -75
HMLANGW_TIME 2021-06-28 14:33:53
HMUSB_MSGCNT 75
HMUSB_RAWMSG E507161,0000,6527937F,FF,FFB0,4C80025071612807650101C8005C
HMUSB_RSSI -80
HMUSB_TIME 2021-06-28 16:20:21
IODev HMLANGW
LASTInputDev HMUSB
MSGCNT 107
NAME HM_507161
NOTIFYDEV global
NR 1421
NTFY_ORDER 50-HM_507161
STATE MISSING ACK
TYPE CUL_HM
chanNo 01
lastMsg No:4C - t:02 s:507161 d:280765 0101C8005C
protCmdDel 3
protLastRcv 2021-06-28 16:20:21
protRcv 57 last_at:2021-06-28 16:20:21
protResnd 4 last_at:2021-06-28 16:20:28
protResndFail 3 last_at:2021-06-28 16:20:33
protSnd 80 last_at:2021-06-28 16:20:25
protSndB 26 last_at:2021-06-28 16:20:28
protState CMDs_done_Errors:1
rssi_HMLANGW cnt:2 min:-92 max:-91 avg:-91.5 lst:-92
rssi_HMUSB cnt:5 min:-82 max:-75 avg:-77.4 lst:-82
rssi_at_HMLANGW cnt:32 min:-77 max:-75 avg:-75.87 lst:-75
rssi_at_HMUSB cnt:75 min:-91 max:-76 avg:-79.32 lst:-80
READINGS:
2021-06-28 16:20:21 CommandAccepted yes
2021-06-28 14:27:33 D-firmware 1.7
2021-06-28 14:27:33 D-serialNr NEQ1580830
2021-06-28 16:13:48 IODev HMLANGW
2021-06-28 14:31:56 PairedTo 0x280765
2021-06-11 11:16:43 R-pairCentral 0x280765
2017-06-29 22:01:56 R-sign off
2021-06-28 14:31:56 RegL_00. 00:00 02:01 05:00 0A:28 0B:07 0C:65 12:50
2021-06-28 14:31:35 RegL_01. 00:00 08:00
2021-06-28 16:20:21 battery ok
2021-06-28 14:33:57 cfgState ok
2021-06-28 16:20:33 commState CMDs_done_Errors:1
2021-06-28 16:20:21 deviceMsg on (to VCCU)
2021-06-28 16:20:21 level 100
2021-06-28 09:05:02 levelMissed desired:100
2021-06-28 16:20:21 pct 100
2021-06-27 19:29:19 powerOn 2021-06-27 19:29:19
2021-06-28 16:20:21 recentStateType ack
2021-06-28 16:20:21 rssi_HMLANGW -92
2021-06-28 14:33:53 rssi_HMUSB -82
2021-06-28 14:33:53 rssi_at_HMLANGW -75
2021-06-28 16:20:21 rssi_at_HMUSB -80
2021-06-28 16:20:33 state MISSING ACK
2021-06-28 16:20:21 timedOn off
2021-06-28 16:20:25 trigLast fhem:02
helper:
HM_CMDNR 77
cSnd 112807655071610201C80000,112807655071610201C80000
cfgStateUpdt 0
dlvl C8
dlvlCmd ++A0112807655071610201C80000
mId 006C
peerFriend peerSens,peerVirt
peerIDsRaw ,00000000
peerIDsState complete
peerOpt 3:switch
regLst 0,1,3p
rxType 2
supp_Pair_Rep 0
ack:
cmds:
TmplKey :no:1624882511.77033
TmplTs 1624882511.77033
cmdKey 1:1:0::HM_507161:006C:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
pair noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt HM_33C21B_SenF,HM_33C21B_SenI,HM_33C21B_SenPwr,HM_33C21B_SenU,HM_3E57B1_SenF,HM_3E57B1_SenI,HM_3E57B1_SenPwr,HM_3E57B1_SenU,HM_4AA1BC_SenF,HM_4AA1BC_SenI,HM_4AA1BC_SenPwr,HM_4AA1BC_SenU,HM_4CAE58_SenF,HM_4CAE58_SenI,HM_4CAE58_SenPwr,HM_4CAE58_SenU,Rauchmelder_Team,VCCU
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
flgs 0
newChn +507161,00,00,00
nextSend 1624890021.79827
rxt 0
vccu VCCU
p:
507161
00
00
00
prefIO:
HMLANGW
mRssi:
mNo 4C
io:
HMLANGW:
HMUSB:
-80
-80
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
prs 1
rssi:
HMLANGW:
avg -91.5
cnt 2
lst -92
max -91
min -92
HMUSB:
avg -77.4
cnt 5
lst -82
max -75
min -82
at_HMLANGW:
avg -75.875
cnt 32
lst -75
max -75
min -77
at_HMUSB:
avg -79.32
cnt 75
lst -80
max -76
min -91
shadowReg:
tmpl:
Attributes:
IODev HMLANGW
IOgrp VCCU:HMLANGW
alias Haupthahn_Garten
autoReadReg 4_reqStatus
devStateIcon off:time_manual_mode on:sani_water_hot@red
dummy 0
expert defReg,rawReg
firmware 1.7
group Bewässerung
icon sani_water_tap
ignore 0
model HM-LC-SW1-BA-PCB
msgRepeat 1
peerIDs 00000000
room Außen,CUL_HM,Pflanzen
rssiLog 1
serialNr NEQ1580830
subType switch
webCmd statusRequest:toggle:on:off
und HMLANGW:
Internals:
AssignedPeerCnt 8
CNT 206
Clients :CUL_HM:
DEF 192.168.178.170
DEVCNT 206
DevState 99
DevType LGW
DeviceName 192.168.178.170:2000
FD 4
FUUID 5c4e0081-f33f-10de-f69d-b11956bd1493fc57
LastOpen 1624882520.81863
NAME HMLANGW
NOTIFYDEV global
NR 65
NTFY_ORDER 50-HMLANGW
PARTIAL
RAWMSG 040233
RSSI -45
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model eQ3-HM-LGW
msgLoadCurrent 26
msgLoadHistory 6/0/0/0/0/7/-7/1/0/-7/0/6
msgLoadHistoryAbs 19/13/13/13/13/13/6/13/12/12/19/19/13
owner 280765
owner_CCU VCCU
Helper:
CreditTimer 486
FW 66561
Initialized 1
SendCnt 14
AckPending:
LastSendLen:
3
3
Log:
IDs:
PendingCMD:
RoundTrip:
Delay 0.00528621673583984
loadLvl:
lastHistory 1624889745.33338
MatchList:
1:CUL_HM ^A......................
Peers:
3E57B1 +3E57B1,00,00,00
507161 +507161,00,00,00
50722A +50722A,00,00,00
673520 +673520,00,00,00
72A624 +72A624,00,00,00
72A627 +72A627,00,00,00
72A73A +72A73A,00,00,00
72A781 +72A781,00,00,00
READINGS:
2021-06-28 14:15:37 D-HMIdAssigned 280765
2021-06-28 14:15:40 D-HMIdOriginal FFFFFF
2021-06-28 14:15:26 D-LANfirmware 1.1.5
2021-06-28 14:15:41 D-firmware 1.4.1
2021-06-28 14:15:26 D-serialNr PEQ1715998
2021-06-28 14:15:26 D-type eQ3-HM-LGW
2021-06-28 14:15:46 cond ok
2021-06-28 16:17:19 load 26
2021-06-28 14:15:46 loadLvl low
2021-06-28 14:15:20 state opened
helper:
keepAlive:
CNT 113
DEVCNT 112
DevState 99
DevType LGW-KeepAlive
DeviceName 192.168.178.170:2001
FD 196
LastOpen 1624882526.20126
NAME HMLANGW:keepAlive
NR 1891
PARTIAL
STATE opened
TEMPORARY 1
TYPE HMUARTLGW
XmitOpen 0
Helper:
NextKeepAlive 1624889857.40609
Log:
Resolve 1
IDs:
READINGS:
2021-06-28 14:15:26 state opened
Attributes:
hmId 280765
icon hm_ccu
lgwPw bEEewJ+THm
room CUL
im list ist aber im internal das richtige io ausgewählt:
IODev HMLANGW
allerdings ist der rssi zum aktor nicht gut, kleiner -90.
ausserdem gibt es einen relativ grossen unterschied (~15) in die andere richtung.
beim hmusb sind beide richtungen etwa gleich.
demnach hat das lgw möglicherweise ein funk problem, oder nur zufall, da es nur 2 werte gibt.
ist der unterschied auch bei anderen devices?
wenn du den hmusb als prefered io wählst, wird es bei diesem aktor wahrscheinlich besser.
IODEV hat ja keine Bedeutung bei VCCU. Und den HMUSB priorisiert habe ich jetzt und dann geht es auch. Aber zum einen wundert mich, warum der Wechsel nicht automatisch stattfindet, wenn HMLANGW Probleme macht. Zum anderen, was passiert, wenn der HMUSB ausfällt? Hab das HMLANGW jetzt umgestellt an eine andere Stelle und mal ausgesteckt. Als nächstes versuche ich dann einen anderen Raum.
im internal IODev steht immer das io, das die vccu aktuell nutzt.
zeig doch mal "get hminfo rssiG full", um zu sehen, ob der lgw überall schlechtere rssi beim senden zeigt.
Bitte schön:
Komme heute nicht dazu, aber morgen versuche ich nochmal aufzuschlüsseln, was hier was ist.
rssiG done:
Device receive from last avg min_max count
HM_33C21B HMLANGW HM_33C21B -81.0 -80.5 -83.0< -76.0 22
HM_33C21B HMUSB HM_33C21B -69.0 -70.6 -77.0< -68.0 186
HM_33C21B HM_33C21B HMUSB -65.0 -65.0 -65.0< -65.0 1
HM_3E57B1 HMLANGW HM_3E57B1 -41.0 -43.6 -51.0< -39.0 206
HM_3E57B1 HMUSB HM_3E57B1 -74.0 -73.0 -78.0< -69.0 205
HM_3E57B1 HM_3E57B1 HMUSB -67.0 -67.0 -67.0< -67.0 1
HM_4AA1BC HMLANGW HM_4AA1BC -75.0 -72.6 -76.0< -67.0 179
HM_4AA1BC HMUSB HM_4AA1BC -78.0 -77.6 -81.0< -75.0 182
HM_4AA1BC HM_4AA1BC HMUSB -69.0 -69.0 -69.0< -69.0 1
HM_4CAE58 HMLANGW HM_4CAE58 -39.0 -38.6 -42.0< -36.0 187
HM_4CAE58 HMUSB HM_4CAE58 -74.0 -72.0 -80.0< -67.0 185
HM_4CAE58 HM_4CAE58 HMUSB -67.0 -67.0 -67.0< -67.0 1
HM_507161 HMLANGW HM_507161 -81.0 -77.9 -82.0< -75.0 60
HM_507161 HMUSB HM_507161 -70.0 -79.9 -93.0< -68.0 120
HM_507161 HM_507161 HMLANGW -86.0 -84.0 -95.0< -81.0 18
HM_507161 HM_507161 HMUSB -79.0 -78.4 -85.0< -75.0 32
HM_72A624 HMLANGW HM_72A624 -66.0 -66.0 -66.0< -66.0 1
HM_72A624 HMUSB HM_72A624 -76.0 -76.0 -76.0< -76.0 1
HM_72A627 HMLANGW HM_72A627 -55.0 -55.0 -55.0< -55.0 1
HM_72A627 HMUSB HM_72A627 -57.0 -57.0 -57.0< -57.0 1
HM_72A73A HMLANGW HM_72A73A -76.0 -76.0 -76.0< -76.0 1
HM_72A73A HMUSB HM_72A73A -52.0 -52.0 -52.0< -52.0 1
Licht_Da HMUSB Licht_Da -76.0 -76.0 -76.0< -76.0 2
Licht_Da Licht_Da HMUSB -73.0 -73.0 -73.0< -73.0 1
Licht_Ki HMUSB Licht_Ki -63.0 -63.0 -63.0< -63.0 2
Licht_Ki Licht_Ki HMUSB -63.0 -63.0 -63.0< -63.0 1
Licht_Ku HMUSB Licht_Ku -52.0 -52.0 -52.0< -52.0 2
Licht_Ku Licht_Ku HMUSB -51.0 -51.0 -51.0< -51.0 1
OK
leider keine weiteren sende-rssi vom lgw vorhanden.
Da hast Du recht. Aber jetzt habe ich heute morgen extra die Waschmaschine (im gleichen Raum wie das HMLANGW) ein- und ausgeschaltet. Der Schalter ist der
HM_4CAE58
Hier sind jetzt für den HMLANGW die Werte identisch. Und was soll ich sagen? Nach der Umpositionierung und Aus- und Einstecken gestern reagiert offensichtlich auch der Problemfall von gestern wieder wie erwartet: Obwohl HMUSB priorisiert ist ist die LASTinputDev das HMLANGW, also genau so wie erwartet. Wenn das jetzt so bleibt, hat sich das Problem gelöst.
Danke Dir aber für die Hilfe.
rssi done:
Device receive from last avg min_max count
HM_33C21B HMLANGW HM_33C21B -81.0 -81.3 -83.0< -76.0 191
HM_33C21B HMUSB HM_33C21B -68.0 -70.2 -77.0< -67.0 446
HM_33C21B HM_33C21B HMUSB -65.0 -65.0 -65.0< -65.0 1
HM_3E57B1 HMLANGW HM_3E57B1 -40.0 -42.1 -51.0< -39.0 490
HM_3E57B1 HMUSB HM_3E57B1 -71.0 -72.5 -80.0< -69.0 487
HM_3E57B1 HM_3E57B1 HMUSB -67.0 -67.0 -67.0< -67.0 1
HM_4AA1BC HMLANGW HM_4AA1BC -77.0 -75.5 -81.0< -67.0 436
HM_4AA1BC HMUSB HM_4AA1BC -84.0 -78.5 -95.0< -75.0 438
HM_4AA1BC HM_4AA1BC HMUSB -69.0 -69.0 -69.0< -69.0 1
HM_4CAE58 HMLANGW HM_4CAE58 -39.0 -38.8 -42.0< -36.0 451
HM_4CAE58 HMUSB HM_4CAE58 -73.0 -72.1 -80.0< -67.0 444
HM_4CAE58 HM_4CAE58 HMLANGW -39.0 -39.0 -39.0< -39.0 2
HM_4CAE58 HM_4CAE58 HMUSB -67.0 -67.0 -67.0< -67.0 1
HM_507161 HMLANGW HM_507161 -80.0 -78.2 -82.0< -75.0 65
HM_507161 HMUSB HM_507161 -71.0 -79.5 -93.0< -68.0 126
HM_507161 HM_507161 HMLANGW -91.0 -84.8 -95.0< -81.0 20
HM_507161 HM_507161 HMUSB -67.0 -77.4 -85.0< -67.0 35
HM_673520 HMLANGW HM_673520 -68.0 -68.0 -68.0< -68.0 2
HM_673520 HMUSB HM_673520 -57.0 -57.0 -57.0< -57.0 2
HM_67352F HMLANGW HM_67352F -73.0 -73.0 -73.0< -73.0 1
HM_67352F HMUSB HM_67352F -57.0 -57.0 -57.0< -57.0 1
HM_673533 HMLANGW HM_673533 -75.0 -75.0 -75.0< -75.0 1
HM_673533 HMUSB HM_673533 -78.0 -78.0 -78.0< -78.0 1
HM_72A624 HMLANGW HM_72A624 -66.0 -66.0 -66.0< -66.0 1
HM_72A624 HMUSB HM_72A624 -76.0 -76.0 -76.0< -76.0 1
HM_72A627 HMLANGW HM_72A627 -67.0 -61.0 -67.0< -55.0 2
HM_72A627 HMUSB HM_72A627 -56.0 -56.5 -57.0< -56.0 2
HM_72A73A HMLANGW HM_72A73A -76.0 -76.0 -76.0< -76.0 1
HM_72A73A HMUSB HM_72A73A -52.0 -52.0 -52.0< -52.0 1
HM_72A781 HMLANGW HM_72A781 -49.0 -49.0 -49.0< -49.0 1
HM_72A781 HMUSB HM_72A781 -37.0 -37.0 -37.0< -37.0 1
Licht_Da HMUSB Licht_Da -76.0 -76.0 -76.0< -76.0 2
Licht_Da Licht_Da HMUSB -73.0 -73.0 -73.0< -73.0 1
Licht_Ki HMUSB Licht_Ki -63.0 -63.0 -63.0< -63.0 3
Licht_Ki Licht_Ki HMLANGW -101.0 -101.0 -101.0<-101.0 1
Licht_Ki Licht_Ki HMUSB -63.0 -63.0 -63.0< -63.0 1
Licht_Ku HMLANGW Licht_Ku -64.0 -66.0 -69.0< -64.0 4
Licht_Ku HMUSB Licht_Ku -65.0 -56.7 -65.0< -52.0 6
Licht_Ku Licht_Ku HMUSB -51.0 -51.0 -51.0< -51.0 1
OK
ZitatObwohl HMUSB priorisiert ist ist die LASTinputDev das HMLANGW, also genau so wie erwartet.
ich denke deine erwartung ist nicht ganz richtig.
im internal LASTinputDev steht das io, welches die letzte meldung vom device als
erstes fhem mitgeteilt hat.
das wird nicht durch die vccu bestimmt, und hat auch nichts mit dem rssi zu tun.
hierfür ist eher die hardware und software der schnittstellen und io's verantwortlich.
die vccu kümmert sich
nur um das sende-io (von fhem zum device), welches im internal IODev steht.
ZitatHier sind jetzt für den HMLANGW die Werte identisch.
gut, dann hat das funkmodul vom lgw scheinbar keinen defekt.
ZitatNach der Umpositionierung und Aus- und Einstecken
eventuell gab es an der alten position funkstörungen.
Ok, ich muss zugeben, dass mir das ganze Thema FHEM viel zu komplex ist. Aber jetzt wo Du das sagst klingt es logisch: Empfangen wird ja eigentlich bei fast allen Devices einfach immer von da wo das Signal zuerst ankommt. Es kann ja schlecht ein Empfängsmodul gezielt Quellen ignorieren, denke ich.
Und tatsächlich steht auch das HMLANGW sicher nicht optimal im Keller neben der Fritzbox und dem NAS - hat aber über Monate funktioniert und ist daher (noch) nicht an einen optimalen Platz gewandert. Seltsam war halt, dass es die Störung gab als niemand zuhause war und daher sich auch nichts im Umfeld geändert hat.
Könnte es nicht dennoch etwas sein, was sich intern im HMLANGW "verfangen" hat und erst durch das Trennen vom Strom wieder gelöst hat? Ein Restart über FHEM hatte ja nicht geholfen.
moin,
nach meinen erfahrungen können ursachen von funkproblemen sehr vielfältig sein.
auch ohne anwesende personen können sich rssi werte verändern.
im aktor hast du ja bereits attr rssiLog gesetzt.
also mal alle 4 readings plotten. am besten mit linienstil points.
meine problematischte funkstrecke ist 15m vom wohnzimmer in die garage, davon 10m im freien.
in dieser strecke stehen noch regentonnen, mit stark schwankendem inhalt.
bei 3 unterschiedlichen io gibt es keinen, der immer zuverlässig zum aktor senden kann, obwohl
einer von den dreien eigentlich immer ok ist.
empfangen ist kein problem, da immer nmindestens einer etwas empfängt. aber leider ist das io, welches am besten empfängt, nicht immer auch zuverlässig beim senden.
eine regel zum automatischen umschalten der io habe ich bisher leider noch nicht entdeckt.
Sowas muss es wohl sein. "Regentonne" klingt erst mal gut, die steht tatsächlich direkt neben dem betreffenden Aktor - aber es hat zu der Zeit auch nicht geregnet. Ich tippe da eher bei mir auf die Geräte im Umfeld des HMLANGW. Gerade beim NAS kann da schon mal was aktiviert werden und stören, ohne dass jemand gerade anwesend ist.
Ist halt etwas enttäuschend gewesen, dass die automatische Umschaltung auf das andere GW nicht funktioniert durch das VCCU. Aber klar, ist alles nicht so einfach wie es sich der Laie vielleicht vorstellt.