Ich habe zwei HM-LC-BI1-FM im Abstand von 2 Metern im Keller montiert. Bei einem habe ich ein RSSI von ca. 73, bei dem 2. bekomme ich entweder ein MISSING ACK oder ein Time Out. Deinstallieren und neu anlegen hat nichts gebracht. Ich habe den Actor mit hmPairSerial in Betrieb genommen. Was gibts noch für Möglichkeiten? Oder sieht das nach Defekt aus?
Auch für Dich: mache ein "list Fenster_K_1" und kopiere die Ausgabe hier zwischen Codetags (zu erzeugen mit dem Button mit dem # über der Eingabebox). Das liest sich besser und ist vor allem vollständig.
Und ich finde keine Pairing-Information. Bitte wiederholen. Gerät nicht löschen oder resetten.
Habe 10 Aktoren in Betrieb, alle als ARR Bausatz.
Einer hat 20dB schlechtere RSSI Werte.
Ich habe technisch nichts gefunden und ihn an einer Stelle mit kürzerem Abstand zum CUL getauscht.
Vielleicht ist das eine Option für dich.
Gruß Helmut
Die RSSI Werte sind ja nicht schlecht für den HMUART den er hat. Wie Pfriemler schon geschrieben hat, mit einem "list Fenster_K_1" kann man mehr sagen woran es liegen könnte.
Zitat von: dl4fb am 12 November 2016, 23:44:11
Habe 10 Aktoren in Betrieb, alle als ARR Bausatz.
Einer hat 20dB schlechtere RSSI Werte.
Ich habe technisch nichts gefunden und ihn an einer Stelle mit kürzerem Abstand zum CUL getauscht.
Vielleicht ist das eine Option für dich.
Gruß Helmut
Hallo Helmut,
den HM-LC-BI1-FM gab es doch nie als Bausatz?
20 dB weniger klingt nach Antenne ab: -20 dB weniger ist nur noch ein hundertstel!
Gruß Otto
Das kommt mit einem list Fenster_K_1
Internals:
CFGFN
DEF 4F8792
HMLAN1_MSGCNT 2
HMLAN1_RAWMSG E4F8792,0000,2DFEC95B,FF,FFA3,18A4104F87921234560601C8004C
HMLAN1_RSSI -93
HMLAN1_TIME 2016-11-12 19:13:18
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 4
NAME Fenster_K_1
NOTIFYDEV global
NR 112
STATE MISSING ACK
TYPE CUL_HM
lastMsg No:18 - t:10 s:4F8792 d:123456 0601C8004C
myHmUART_MSGCNT 2
myHmUART_RAWMSG 0501004118A4104F87921234560601C8004C
myHmUART_RSSI -65
myHmUART_TIME 2016-11-12 19:13:18
protCmdDel 6
protLastRcv 2016-11-12 19:13:18
protResnd 12 last_at:2016-11-12 22:37:54
protResndFail 4 last_at:2016-11-12 22:37:59
protSnd 6 last_at:2016-11-12 22:37:41
protState CMDs_done_Errors:1
rssi_at_HMLAN1 max:-92 cnt:2 avg:-92.5 lst:-93 min:-93
rssi_at_myHmUART max:-65 cnt:2 avg:-65.5 lst:-65 min:-66
rssi_myHmUART cnt:1 max:-76 avg:-76 min:-76 lst:-76
Readings:
2016-11-12 19:13:12 D-firmware 2.8
2016-11-12 19:13:12 D-serialNr NEQ1320763
2016-11-12 19:13:47 RegL_00.
2016-11-12 19:13:18 deviceMsg on (to vccu)
2016-11-12 19:13:18 level 100
2016-11-12 19:13:18 motor stop:on
2016-11-12 19:13:18 pct 100
2016-11-12 19:13:18 recentStateType info
2016-11-12 22:37:59 state MISSING ACK
2016-11-12 19:13:18 timedOn off
Helper:
HM_CMDNR 28
cSnd 111234564F87920201C80000,111234564F87920201C80000
dlvl C8
dlvlCmd ++A0111234564F87920201C80000
getCfgList all
getCfgListNo ,3
mId 0005
rxType 1
Ack:
Dir:
cur stop
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +4F8792,00,00,00
nextSend 1478974398.63047
prefIO
rxt 0
vccu
p:
4F8792
00
00
00
Mrssi:
mNo 18
Io:
HMLAN1 -93
myHmUART -63
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rpt:
IO HMLAN1
flg A
ts 1478974398.27417
ack:
HASH(0x1c762b8)
1880021234564F879200
Rssi:
At_hmlan1:
avg -92.5
cnt 2
lst -93
max -92
min -93
At_myhmuart:
avg -65.5
cnt 2
lst -65
max -65
min -66
Myhmuart:
avg -76
cnt 1
lst -76
max -76
min -76
Tmpl:
Attributes:
IODev myHmUART
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
model HM-LC-BL1-FM
room CUL_HM
serialNr NEQ1320763
subType blindActuator
webCmd statusRequest:toggleDir:on:off:up:down:stop
Sorry, es ist arg lang geworden.
Moin,
Missig Ack ist kein Wunder, der ist nicht gepairt. Hatte aber pfriemler schon gesagt.
Was mir außerdem auffällt: Du hast zwei IOs hast Du auch eine VCCU die das koordiniert?
Also ich hatte Probleme beim anlernen, wenn einfach nur zwei IOs versuchen durcheinander mit dem neuen Gerät reden.
Gruß Otto
Meine VCCU ist im Anhang. Ich habe den HM-LC-BI1-FM in der VCCU mit "hmPairSerial" mMn gepairt
Das pairen hat aber nicht funktioniert. So sehe es aus (Beispiel von mir)
Internals:
DEF 152921
HMLAN1_MSGCNT 226
HMLAN1_RAWMSG E152921,0000,55BF3AF8,FF,FFB6,D284101529210000000601C800
HMLAN1_RSSI -74
HMLAN1_TIME 2016-11-13 07:33:14
HMUART1_MSGCNT 221
HMUART1_RAWMSG 0500004ED284101529210000000601C800
HMUART1_RSSI -78
HMUART1_TIME 2016-11-13 07:33:14
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 447
NAME RolloWZR
NOTIFYDEV global
NR 156
NTFY_ORDER 50-RolloWZR
STATE auf
TYPE CUL_HM
lastMsg No:D2 - t:10 s:152921 d:000000 0601C800
protLastRcv 2016-11-13 07:33:14
protResnd 14 last_at:2016-11-11 09:00:02
protSnd 116 last_at:2016-11-13 07:32:45
protState CMDs_done
rssi_HMLAN1 avg:-64.56 min:-72 max:-59 lst:-67 cnt:55
rssi_HMUART1 avg:-70.11 min:-98 max:-65 lst:-90 cnt:77
rssi_at_HMLAN1 avg:-66.47 min:-90 max:-62 lst:-74 cnt:226
rssi_at_HMUART1 avg:-65.45 min:-81 max:-59 lst:-78 cnt:221
Readings:
2016-11-13 07:32:45 CommandAccepted yes
2015-01-07 21:19:02 D-firmware 1.5
2015-01-07 21:19:02 D-serialNr IEQ0016968
2016-09-12 12:29:58 PairedTo 0x200DB8
2016-08-14 16:03:08 R-driveDown 22 s
2015-01-07 21:19:04 R-driveTurn 0.5 s
2016-08-14 16:02:52 R-driveUp 24 s
2015-01-07 21:19:03 R-intKeyVisib invisib
2015-01-07 21:19:03 R-pairCentral 0x200DB8
2016-09-05 20:43:27 R-refRunCounter 10
2015-01-07 21:19:04 R-sign off
2016-11-13 07:33:14 deviceMsg on (to broadcast)
2016-11-13 07:33:14 level 100
2016-11-13 07:33:14 motor stop:on
2016-11-13 07:33:14 pct 100
2016-06-06 06:22:35 powerOn 2016-06-06 06:22:35
2016-11-13 07:33:14 recentStateType info
2016-11-13 07:33:14 state on
2016-11-13 07:33:14 timedOn off
Helper:
HM_CMDNR 210
cSnd 11200DB81529210201000000,11200DB81529210201C80000
dlvlCmd ++A011200DB81529210201C80000
mId 0005
rxType 1
Ack:
Dir:
cur stop
rct up
Expert:
def 1
det 1
raw 0
tpl 0
Io:
newChn +152921,00,00,00
nextSend 1479018794.7081
rxt 0
vccu VCCU
p:
152921
00
00
00
Mrssi:
mNo D2
Io:
HMLAN1 -72
HMUART1 -78
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rssi:
Hmlan1:
avg -64.5636363636364
cnt 55
lst -67
max -59
min -72
Hmuart1:
avg -70.1168831168831
cnt 77
lst -90
max -65
min -98
At_hmlan1:
avg -66.4734513274336
cnt 226
lst -74
max -62
min -90
At_hmuart1:
avg -65.4524886877828
cnt 221
lst -78
max -59
min -81
Tmpl:
Attributes:
IODev HMLAN1
IOgrp VCCU
Level st_Rollo_EG
autoReadReg 4_reqStatus
devStateIcon auf:shutter_open zu:shutter_closed
eventMap on:auf off:zu
expert 1_allReg
firmware 1.5
model HM-LC-BL1-FM
peerIDs 00000000,
room Wohnzimmer
serialNr IEQ0016968
subType blindActuator
userattr Level Level_map structexclude
webCmd down:pct:up
Vielleicht setzt Du den HMLAN testweise zum pairen mal auf closed, der hat zu schlechten Empfang.
Gruß Otto
Nach dem Abschalten vom HMLAN hats geklappt. Auch das Anschalten danach führt nicht mehr zum "MISSING ACK". Ich dachte, ich hätte die VCCU so eingestellt, daß immer das IODev mit dem besten RSSI verwendet wird. Daher war ich etwas ratlos, warum es nicht funktionierte.
Dann poste doch nochmal ein list der VCCU, hattest Du zwar im vorletzen Post schon gewollt, aber es gab keinen Anhang.
Gruß Otto
Ok, diesmal mit Anhang ;-))
Hatte ich nicht schon mal gesagt, das Bilder Mist sind? Man sieht bloß die Hälfte. :'(
Aber das sieht zumindest gut aus, im normalen Betrieb wird das mit dem RSSI funktionieren. Das attribute IOgrp sollte automatisch gesetzt werden.
Ich bin mir momentan noch nicht sicher wie die Situation während dem Anlernen ist. Vielleicht muss man das besser mit nur einem IO machen. Vielleicht liest das ja Martin mit und kann dazu was sagen.
Mach zur Sicherheit man ein hminfo configCheck.
Gruß Otto
du kannst am Device im Attr IODev sehen, welches IO genutzt wurde. Wenn 2 eingetragen sind sollte (darf) nur eines reagieren.
Wählt die VCCU das richtige aus? Wenn nicht werde ich es untersuchen.
Wenn du ein preferred definiert hast sucht die VCCU nicht - so lange das preferred zu sehen ist.
Du hast kein preferred eingestellt - HMLAN war bei last leicht besser....
Tests duch einmal ob eines der Devices nicht korrekt empfängt. VCCU prüft nur rssi - das ist allerdings nicht alles.
leicht offtopic: Ich habe (als Vorbereitung eines möglichen Umstiegs vom HMLAN auf HMUART) alle preferred IO gelöscht, so dass die vccu selbst entscheidet. Auch bei regelmäßig benutzten Geräten stellt sich aber nicht unbedingt eine sichere eigene Wahl durch die vccu ein. Insbesondere bei etwa gleichen rssi laufen größere Aktionen regelmäßig schief - für Firmwareupdates etwa schalte ich den HMLAN extra auf "closed", weil ein Abbruch sonst vorprogrammiert ist. Dabei ist der HMLAN nicht einmal firmwareupdatefähig und sollte daher von vornherein ignoriert werden ...
Da ich aber beide IOs laufen lassen werde, bekommen meine Geräte nach und nach wieder ein preferred.
Zitat von: Pfriemler am 13 November 2016, 20:10:58
leicht offtopic: ...
eigentlich gar nicht, ich finde das ist genau hier der Topic 8)
Ich würde fast sagen zu behaupten: Bei viel Traffic also z.B. auch bei Gerät mit einigen Channels sollte man beim Pairing nur einen IO in Aktion haben. Oder eben in solchen Situationen wie hier beschrieben. Du beschreibst das noch bei Updates ...
Ich habe momentan noch eine zweite FHEM Instanz mit einem IO (die erste Instanz hat 2 IOs) aber unterschiedlicher HMID in Betrieb. Ich glaube da passieren beim Anlernen lustige Dinge... Sollte man unbedingt auch vermeiden. Das war jetzt vielleicht etwas offtopic ;)
Gruß Otto