Hallo zusammen,
für einen Bekannten möchte ich eine FHEM-Installation auf einem neuen RPi3 vorbereiten.
Da es den HM-CFG-LAN nicht mehr gibt, habe ich als Alternative einen HM-LGW-O-TW-W-EU-2 besorgt.
Leider ist es mir bislang nicht möglich, (brandneue) Geräte zu pairen.
Ich habe es zunächst mit einem Schalter (HM-LC-SW2-FM) probiert und erhalte - selbst nach mehrfachen Pairingversuchen und auch nach Resets - Fehlermeldungen wie diese:
2020-01-30_13:47:31 HM_6F4BCE powerOn: 2020-01-30 13:47:31
2020-01-30_13:47:31 HM_6F4BCE CMDs_done
2020-01-30_13:47:32 HM_6F4BCE CMDs_pending
2020-01-30_13:47:53 HM_6F4BCE ResndFail
2020-01-30_13:47:53 HM_6F4BCE CMDs_done_Errors:1
2020-01-30_13:47:53 HM_6F4BCE MISSING ACK
2020-01-30_13:47:56 HM_6F4BCE CMDs_pending
2020-01-30_13:47:56 HM_6F4BCE CMDs_pending
2020-01-30_13:47:56 HM_6F4BCE CMDs_pending
2020-01-30_13:47:56 HM_6F4BCE CMDs_pending
2020-01-30_13:47:56 HM_6F4BCE CMDs_pending
2020-01-30_13:48:16 HM_6F4BCE ResndFail
2020-01-30_13:48:16 HM_6F4BCE CMDs_done_Errors:1
2020-01-30_13:48:16 HM_6F4BCE RESPONSE TIMEOUT:RegisterRead
2020-01-30_14:17:53 HM_6F4BCE CMDs_pending
2020-01-30_14:18:12 HM_6F4BCE ResndFail
2020-01-30_14:18:12 HM_6F4BCE CMDs_done_Errors:1
2020-01-30_14:18:12 HM_6F4BCE MISSING ACK
Es funktioniert weder am Gateway direkt, noch an der VCCU.
Hat jemand eine Idee, woran das liegen könnte?
Vielen Dank im Voraus.
list vom Gateway:
Internals:
AssignedPeerCnt 1
CNT 14
Clients :CUL_HM:
DEF 192.168.178.24
DEVCNT 23
DevState 99
DevType LGW
DeviceName 192.168.178.24:2000
FD 4
FUUID 5e19b827-f33f-4dd6-9509-4a2257861abfdb55
LastOpen 1580387597.817
NAME LANgateway
NOTIFYDEV global
NR 19
NTFY_ORDER 50-LANgateway
PARTIAL
RAWMSG 050000511D84704DE7FE00000000E22C
RSSI -81
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model eQ3-HM-LGW
msgLoadCurrent 6
msgLoadHistory 0/0/0/0/0/0/0/2/2/2/-/-
msgLoadHistoryAbs 6/6/6/6/6/6/6/6/4/2/0/-/-
owner CAFE00
Helper:
CreditTimer 205
FW 66561
Initialized 1
SendCnt 31
AckPending:
LastSendLen:
3
3
Log:
IDs:
PendingCMD:
RoundTrip:
Delay 0.00410699844360352
loadLvl:
lastHistory 1580390602.84448
MatchList:
1:CUL_HM ^A......................
Peers:
6F4BCE +6F4BCE,00,00,00
READINGS:
2020-01-30 13:33:22 D-HMIdAssigned CAFE00
2020-01-30 13:33:22 D-HMIdOriginal FFFFFF
2020-01-30 13:33:17 D-LANfirmware 1.1.5
2020-01-30 13:33:22 D-firmware 1.4.1
2020-01-30 13:33:17 D-serialNr PEQ2247964
2020-01-30 13:33:17 D-type eQ3-HM-LGW
2020-01-30 13:33:22 cond ok
2020-01-30 13:48:13 load 6
2020-01-30 13:33:22 loadLvl low
2020-01-30 13:33:17 state opened
helper:
keepAlive:
CNT 61
DEVCNT 60
DevState 99
DevType LGW-KeepAlive
DeviceName 192.168.178.24:2001
FD 8
LastOpen 1580387597.82207
NAME LANgateway:keepAlive
NR 31
PARTIAL
STATE opened
TEMPORARY 1
TYPE HMUARTLGW
XmitOpen 0
Helper:
NextKeepAlive 1580390690.30591
Log:
Resolve 1
IDs:
READINGS:
2020-01-30 13:33:17 state opened
Attributes:
hmId CAFE00
lgwPw VAKGCBW6L!
room 00_SYSTEM
list der VCCU:
Internals:
DEF CAFE00
FUUID 5e160464-f33f-4dd6-d9eb-4424aa97b5714e60
NAME VCCU
NOTIFYDEV global
NR 21
STATE LANgateway:UAS,
TYPE CUL_HM
assignedIOs LANgateway
chanNo 01
READINGS:
2020-01-30 13:47:50 IOopen 0
2020-01-30 13:47:50 state LANgateway:UAS,
helper:
HM_CMDNR 50
mId FFF0
peerFriend
peerOpt v:virtual
regLst
rxType 1
expert:
def 1
det 0
raw 0
tpl 0
io:
prefIO
vccu VCCU
ioList:
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
tmpl:
Attributes:
IOgrp VCCU
model CCU-FHEM
room 00_SYSTEM
subType virtual
webCmd virtual:update
Hi,
die VCCU ist noch nicht komplett, da fehlt mindestens attr IOList
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Und bitte noch ein list HM_6F4BCE ?
Gruß Otto
Hallo Otto,
danke für deine Antwort.
die IOgrp war zunächst drin.
Hier noch das Listung des Schalters.
Internals:
CFGFN
DEF 6F4BCE
FUUID 5e32d05d-f33f-4dd6-ecfb-389b7256637bbb50
IODev LANgateway
LANgateway_MSGCNT 2
LANgateway_RAWMSG 0501002703A4106F4BCECAFE000601000029
LANgateway_RSSI -39
LANgateway_TIME 2020-01-30 13:47:31
LASTInputDev LANgateway
MSGCNT 2
NAME HM_6F4BCE
NOTIFYDEV global
NR 51
STATE MISSING ACK
TYPE CUL_HM
channel_01 HM_6F4BCE_Sw_01
channel_02 HM_6F4BCE_Sw_02
lastMsg No:03 - t:10 s:6F4BCE d:CAFE00 0601000029
protCmdDel 11
protLastRcv 2020-01-30 13:47:31
protRcv 3 last_at:2020-01-30 13:47:31
protResnd 21 last_at:2020-01-30 16:19:31
protResndFail 7 last_at:2020-01-30 16:19:36
protSnd 9 last_at:2020-01-30 16:19:17
protState CMDs_done_Errors:1
rssi_LANgateway cnt:1 min:-41 max:-41 avg:-41 lst:-41
rssi_at_LANgateway cnt:3 min:-39 max:-36 avg:-37 lst:-39
READINGS:
2020-01-30 13:47:25 D-firmware 2.8
2020-01-30 13:47:25 D-serialNr QEQ1073549
2020-01-30 13:51:43 RegL_00.
2020-01-30 13:47:31 powerOn 2020-01-30 13:47:31
2020-01-30 16:19:36 state MISSING ACK
helper:
HM_CMDNR 10
PONtest 0
cSnd 01CAFE006F4BCE020E,01CAFE006F4BCE020E
mId 00CB
peerFriend
peerOpt -:switch
regLst 0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +6F4BCE,00,00,00
nextSend 1580388451.82844
prefIO
rxt 0
vccu
p:
6F4BCE
00
00
00
mRssi:
mNo 03
io:
LANgateway:
-31
-31
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rpt:
IO LANgateway
flg A
ts 1580388451.59055
ack:
HASH(0x2834af0)
038002CAFE006F4BCE00
rssi:
LANgateway:
avg -41
cnt 1
lst -41
max -41
min -41
at_LANgateway:
avg -37
cnt 3
lst -39
max -36
min -39
tmpl:
Attributes:
IODev LANgateway
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
model HM-LC-SW2-FM
room CUL_HM
serialNr QEQ1073549
subType switch
webCmd getConfig:clear msgEvents
Einen Schalter kannst Du auch mit
set LANgateway hmPairSerial QEQ1073549
pairen.
Musst Du zweimal machen, mit etwas Abstand!
Schau mal ob er damit pairt.
Gruß Otto
Zitat von: Otto123 am 30 Januar 2020, 15:35:04
die VCCU ist noch nicht komplett, da fehlt mindestens attr IOList
Ist jetzt auch drin.
Attributes:
IODev LANgateway
IOList LANgateway
IOgrp VCCU
icon it_wifi
model CCU-FHEM
room 00_SYSTEM
subType virtual
webCmd virtual:update
Zitat von: Otto123 am 30 Januar 2020, 16:51:16
set LANgateway hmPairSerial QEQ1073549
Das hat funktioniert! Ich brauchte das Kommando sogar nur 1x absetzen.
Allerdings kam die Rückmeldung des Schalters erst nach geraumer Zeit, und zunächst war nur Channel 1 erreichbar.
Zwischenzeitlich habe ich es mit einem Thermostat HM-TC-IT-WM-W-EU probiert.
An der VCCU hat's scheinbar nicht geklappt, obwohl ich schon gut 30 Minuten gewartet habe. Ich probier's jetzt am LAN Gateway
Obwohl das Pairing des Thermostaten (noch) nicht richtig funktioniert (R-pairCentral ist noch nicht gesetzt, und CMDs pending), scheint das Ding trotzdem zu kommunizieren.
Ist das normal?
Event-Monitor für den Thermostaten
2020-01-30 18:08:58 CUL_HM HM_687208_Climate desired-temp: 17.0
2020-01-30 18:08:58 CUL_HM HM_687208_Climate humidity: 49
2020-01-30 18:08:58 CUL_HM HM_687208_Climate measured-temp: 23.0
2020-01-30 18:08:58 CUL_HM HM_687208_Climate T: 23.0 desired: 17.0
2020-01-30 18:09:18 CUL_HM HM_687208_Weather humidity: 49
2020-01-30 18:09:18 CUL_HM HM_687208_Weather T: 23.0 H: 49
2020-01-30 18:09:18 CUL_HM HM_687208_Weather temperature: 23.0
list vom Thermostaten
Internals:
CFGFN
DEF 687208
FUUID 5e330cb1-f33f-4dd6-e813-08a473630cf2b413
IODev LANgateway
LANgateway_MSGCNT 8
LANgateway_RAWMSG 0500003F04847068720800000000E528
LANgateway_RSSI -63
LANgateway_TIME 2020-01-30 18:11:38
LASTInputDev LANgateway
MSGCNT 8
NAME HM_687208
NOTIFYDEV global
NR 198
STATE CMDs_pending
TYPE CUL_HM
channel_01 HM_687208_Weather
channel_02 HM_687208_Climate
channel_03 HM_687208_WindowRec
channel_06 HM_687208_remote
channel_07 HM_687208_SwitchTr
lastMsg No:04 - t:70 s:687208 d:000000 00E528
protCmdPend 14 CMDs pending
protCondBurst off
protLastRcv 2020-01-30 18:11:38
protRcv 9 last_at:2020-01-30 18:11:38
protSnd 1 last_at:2020-01-30 18:04:58
protSndB 1 last_at:2020-01-30 18:04:58
protState CMDs_pending
rssi_at_LANgateway cnt:9 min:-73 max:-40 avg:-52.44 lst:-63
READINGS:
2020-01-30 18:04:49 Activity alive
2020-01-30 18:04:49 D-firmware 1.4
2020-01-30 18:04:49 D-serialNr PEQ1258998
2020-01-30 18:05:23 powerOn 2020-01-30 18:05:23
2020-01-30 18:05:23 recentStateType info
2020-01-30 18:05:03 state CMDs_pending
cmdStack:
++A001CAFE0068720800040000000000
++A001CAFE006872080103
++A001CAFE0068720801040000000001
++A001CAFE006872080203
++A001CAFE0068720802040000000001
++A001CAFE0068720800040000000007
++A001CAFE0068720802040000000008
++A001CAFE0068720802040000000009
++A001CAFE006872080303
++A001CAFE0068720803040000000001
++A001CAFE006872080603
++A001CAFE0068720806040000000001
++A001CAFE006872080703
++A001CAFE0068720807040000000001
helper:
HM_CMDNR 4
PONtest 0
mId 00AD
peerFriend
peerOpt -:thermostat
regLst 0
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +687208,00,00,00
nextSend 1580404298.43164
prefIO
rxt 0
vccu
p:
687208
00
00
00
mRssi:
mNo 04
io:
LANgateway:
-59
-59
prt:
awake 0
bErr 0
brstWu 0
sProc 2
q:
qReqConf 00
qReqStat
role:
dev 1
prs 1
rssi:
at_LANgateway:
avg -52.4444444444444
cnt 9
lst -63
max -40
min -73
shRegW:
07 02
tmpl:
Attributes:
IODev LANgateway
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-TC-IT-WM-W-EU
msgRepeat 1
room CUL_HM
serialNr PEQ1258998
subType thermostat
webCmd getConfig:clear msgEvents
Kommunizieren sind meist zwei Richtungen: Du sagst was und ich höre zu, ich sage was zu tun ist und Du führst es aus.
Der erste Teil funktioniert immer, der zweite Teil erfordert eine Autorisierung: Warum solltest Du tun was ich sage?
--> Pairing
Gruß Otto
Okay, soweit ist das klar.
Bleibt die Frage, warum die Authorisierung nicht funktioniert.
Beim Switch hat es mit hmPairForSec funktioniert, wenn auch zeitlich verzögert.
Beim 1. Thermostaten funktioniert es unvollständig (kein R-pairCentral) und
beim 2. Thermostaten geht gar nichts.
Woran kann es liegen bzw was könnte ich tun, um dem Fehler auf die Spur zu kommen?
Könnte es evtl am Software-Modul liegen?
Bemerkenswert ist, dass es mit einem HM-MOD-RPI-PCB auch nicht funktioniert hat. Das habe ich aber auf meine mangelhaften Lötfähigkeiten geschoben; die Lötstellen liegen schon arg eng beieinander.
Aber dass es mit dem (gekauften) HM-LAN Gateway auch solche Schwierigkeiten gibt, hatte ich nicht erwartet.
Dann liegt es nicht an Deinen Lötfähigkeiten ... ;)
ZitatBeim 1. Thermostaten funktioniert es unvollständig (kein R-pairCentral) und
beim 2. Thermostaten geht gar nichts.
hmPairSerial funktioniert nur beim Switch - das war meine Empfehlung. Jetzt redest Du von hmPairForSec?
Kein R-pairCentral ist nicht unvollständig - das ist nicht gepairt.
Gar nicht bedeutet es gibt keine config Nachricht. Dann würde ich davon ausgehen: das Gerät ist kaputt.
Woher sind deine HM Geräte? Neu gekauft? Gebraucht gekauft? Werksreset gemacht? Hat funktioniert - oder war am Ende rot?
Zitat von: Otto123 am 30 Januar 2020, 22:20:13
Dann liegt es nicht an Deinen Lötfähigkeiten ... ;)
Das ist ja wenigstens mal eine gute Nachricht :)
Zitat
hmPairSerial funktioniert nur beim Switch
Ich wusste nicht, dass
hmPairSerial nur beim Switch geht.
Bis dato hatte ich aber sowieso immer nur
hmPairForSec verwendet.
Zitat
Woher sind deine HM Geräte? Neu gekauft? Gebraucht gekauft? Werksreset gemacht?
Alle Geräte brandneu, direkt von elv. Thermostaten als Bausatz (ohne Löten, nur zusammenstecken). Werkreset wurde mehrfach durchgeführt, auch mehrere Pairingversuche, sowohl an der VCCU, als auch direkt am LAN-Gateway.
Die
aktuelle Diskussion betrifft eine Neuinstallation für einen Dritten. Ihm hatte ich das empfohlen, weil ich selbst so gute Erfahrungen gemacht hatte.
Sämtliche Hardware ist neu.
(Ich habe für mich selbst seit ca 4 Jahren eine Installation mit vielen HM-Geräten und HM-CFG-LAN, die bis jetzt reibungslos funktioniert. Das Pairing aller Geräte wurde immer mit hmPairForSec durchgeführt, und es ging immer sofort. Unter anderem habe ich mehrere der hier diskutierten Thermostate im Einsatz.)
Also sagen wir mal so: hmPairSerial funktioniert ohne Knöpchen drücken und ist bequem wenn das Ding verbaut ist. Bei Geräten die nicht von sich aus senden (die meisten Sensoren Fernbedienung usw) geht meiner Meinung nach hmPairSerial nicht.
Um die Thermostaten zu pairen, müssen sie angebaut sein und eine Anlernfahrt gemacht haben! Steht hier zumindest immer mal zum lesen, ich selbst heize mit Kamin und habe keine Heizkörperthermostate. ;)
Bitte schau Dir die VCCU nochmal an und mache die komplett, das Pairing muss mit ihr genauso funktionieren wie direkt mit dem IO. Am Ende ist es ja nichts anderes.
Definiere bitte hmInfo und mach einen configCheck, das gibt wertvolle Hinwiese zu möglichen Fehlern.
Gruß Otto
Guten Morgen Otto,
zunächst erneut vielen Dank für deine geduldigen Antworten.
Zur Klarstellung: Es geht hier um die Wandthermostate. Aber du hast Recht: Heizkörperthermostate brauchen eine Anlernfahrt. Bei mir habe ich beide Typen problemlos im Einsatz; letztere für die Radiatoren im Keller, erstere für die Fußbodenheizung im Rest des Hauses.
Die VCCU müsste jetzt komplett sein. hminfo hatte ich auch schon definiert.
Hier nochmals ein list von beiden.
list VCCU
Internals:
DEF CAFE00
FUUID 5e160464-f33f-4dd6-d9eb-4424aa97b5714e60
IODev LANgateway
LANgateway_MSGCNT 4572
LANgateway_RAWMSG 0500005710800253D859560FB8010100004C
LANgateway_RSSI -87
LANgateway_TIME 2020-01-31 09:00:00
LASTInputDev LANgateway
MSGCNT 4572
NAME VCCU
NOTIFYDEV global
NR 21
STATE LANgateway:ok
TYPE CUL_HM
assignedIOs LANgateway
chanNo 01
protSnd 4 last_at:2020-01-30 20:47:56
protState CMDs_done
READINGS:
2020-01-30 18:36:04 IOopen 1
2020-01-30 18:36:04 state LANgateway:ok
2020-01-31 08:04:06 unknown_52E818 received
2020-01-31 09:00:00 unknown_53D859 received
2020-01-31 08:42:19 unknown_593F7F received
2020-01-31 08:30:00 unknown_5B91A5 received
helper:
HM_CMDNR 54
mId FFF0
peerFriend
peerOpt v:virtual
regLst
rxType 1
ack:
expert:
def 1
det 0
raw 0
tpl 0
io:
prefIO
vccu VCCU
ioList:
LANgateway
mRssi:
mNo
io:
LANgateway:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
Attributes:
IODev LANgateway
IOList LANgateway
IOgrp VCCU
icon it_wifi
model CCU-FHEM
room 00_SYSTEM
subType virtual
webCmd virtual:update
hminfo meldet das, was schon bekannt ist.
Interessant ist aber die folgende Meldung, die ich nicht einordnen kann:
templist mismatch
HM_687208_Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
list hminfo
Internals:
ERR__protocol HM_6F4BCE
FUUID 5e19c8f4-f33f-4dd6-5e79-e6ad3fde562cda3f
I_HM_IOdevices ok: LANgateway;
I_autoReadPend HM_687208
NAME hminfo
NR 23
NTFY_ORDER 50-hminfo
STATE updated:2020-01-30 18:36:04
TYPE HMinfo
Version 01
W__protoNames HM_687208,HM_6F4BCE
READINGS:
2020-01-30 18:36:04 CRI__protocol -
2020-01-30 18:36:04 C_sumDefined entities:11,device:3,channel:8,virtual:2
2020-01-30 18:36:04 ERR__protocol CmdDel:1,ResndFail:1
2020-01-11 17:01:30 ERR__unreachable 0
2020-01-30 18:36:04 I_actTotal alive:1,dead:0,unkn:0,off:0
2020-01-11 17:01:30 I_autoReadPend 1
2020-01-30 18:36:04 I_rssiMinLevel 59<:1 60>:1 80>:0 99>:0
2020-01-11 17:01:30 W__protocol CmdPend:1,Resnd:1
helper:
cfgChkResult configCheck done:
missing register list
HM_687208: RegL_00.
HM_687208_Climate: RegL_01.,RegL_07.,RegL_08.,RegL_09.
HM_687208_SwitchTr: RegL_01.
HM_687208_Weather: RegL_01.
HM_687208_WindowRec: RegL_01.
HM_687208_remote: RegL_01.
peer list incomplete. Use getConfig to read it.
incomplete: HM_687208_Climate:
incomplete: HM_687208_SwitchTr:
incomplete: HM_687208_Weather:
incomplete: HM_687208_WindowRec:
incomplete: HM_687208_remote:
PairedTo missing/unknown
HM_687208
templist mismatch
HM_687208_Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
nb:
cnt 3
Attributes:
room 00_SYSTEM
sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
sumStatus battery,sabotageError,powerError,motor
webCmd update:protoEvents short:rssi:peerXref:configCheck:models
Guten Morgen, :D
templist missing ist aus meiner Sicht eher ein Kosmetik Problem: Du kannst mit hmInfo die Listen der Thermostate sichern, solange man das nicht gemacht hat kommt die Meldung, einmal gesichert ist sie weg.
set hm tempList saveJetzt fällt mir noch auf:
Zitatfür einen Bekannten möchte ich eine FHEM-Installation auf einem neuen RPi3 vorbereiten.
Du hast jetzt zwei HM Umgebungen die sich sehen können? das hier sind Deine?
Zitat2020-01-31 08:04:06 unknown_52E818 received
2020-01-31 09:00:00 unknown_53D859 received
2020-01-31 08:42:19 unknown_593F7F received
2020-01-31 08:30:00 unknown_5B91A5 received
Dann solltest Du zum pairen nur eine Zentrale aktiv haben (IO: set close) ansonsten reden die alle durcheinander.
Zitat von: Otto123 am 31 Januar 2020, 10:34:29
das hier sind Deine?
Entweder meine oder die der Nachbarn links und rechts, welche beide auch HM-Komponenten verwenden.
Zitat von: Otto123 am 31 Januar 2020, 10:34:29
Dann solltest Du zum pairen nur eine Zentrale aktiv haben
Das habe ich sowieso gemacht.
Zwischenzeitlich habe ich mal versucht, die zuvor zurückgesetzten Thermostaten in
meine etablierte HM Umgebung einzubinden. Das funktioniert zwar, aber genauso schlecht wie in der neuen. Alles wie gehabt. >:(
Mittlerweile befürchte ich, dass beide Thermostaten von Anfang an ein techn. Problem hatten. Das wäre zwar ein ziemlich großer Zufall, aber grundsätzlich nicht auszuschließen.
Das autocreate definiert beide nahezu gleich: HM_6872
08 und HM_6872
A3, und auch die Seriennummern sind ähnlich: PEQ1258998 und PEQ1259152. dazwischen liegen also nur 154 Geräte, die durchaus aus demselben Produktionbatch stammen könnten.
Ich versuche als letzten Schritt jetzt noch, einen Thermostaten aus meiner Umgebung abzumelden und ihn dann im neuen System zu verwenden. Mal sehen, ob das geht.
Da würde ich der Empfangsreichweite der Nachbarn aber mal nachgehen. Die reden doch auch bloß dazwischen wenn Du versuchst zu pairen. Oder macht es wirklich bloß die Zentrale die paarunsgbereit ist? Ich bin da unsicher ...
Die Wandthermostate ...
Bei denen gab es noch das Problem, dass konstruktiv bedingt die Federn von den Batterien Kontakt mit der Leiterplatte bekommen können. Schau da mal nach, nicht das die schlecht montiert sind. Ich hatte mal den Fall, da war ein paar Tage nach dem Wechsel die Batterie wieder alle und der Thermostat hat sich komisch verhalten.
Gruß Otto
Zitat von: Otto123 am 31 Januar 2020, 14:51:17
Die reden doch auch bloß dazwischen wenn Du versuchst zu pairen. Oder macht es wirklich bloß die Zentrale die paarunsgbereit ist? Ich bin da unsicher ...
Nun ja... Die quatschen natürlich ständig dazwischen. Aber dennoch gab es in
meiner HM-Umgebung niemals ein Problem beim Pairing (am HM-CFG-LAN). Ich kann ja schlecht von meinen Nachbarn verlangen, den Funkverkehr ihrer Installation zu stoppen. ;)
Umgekehrt klappt es ja offenbar auch. Die arbeiten allerdings nicht mit FHEM, sondern mit HM-CCUs. Ich glaube also nicht, dass das ein Problem darstellt.
Zitat
konstruktiv bedingt die Federn von den Batterien Kontakt mit der Leiterplatte bekommen können. Schau da mal nach, nicht das die schlecht montiert sind.
Muss ich mal nachsehen, danke. Allerdings kann man die Gehäuse schlecht öffnen. Ich möchte sie nicht beschädigen, weil ich sie umtauschen möchte...
Hallo zusammen,
ich bin neu im Bereich der Hausautomatisierung. Ich habe ebenfalls ein Problem mit dem LAN-Gateway. Habe, soweit ich das beurteilen kann, das Gateway erfolgreich nach Anleitung https://wiki.fhem.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway eingebunden.
Leider geht es beim Punkt Firmware update nicht weiter.
pi@raspberrypi:~ $ sudo apt-get install libc6-i386 lib32stdc++6
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Paket libc6-i386 ist nicht verfügbar, wird aber von einem anderen Paket
referenziert. Das kann heißen, dass das Paket fehlt, dass es abgelöst
wurde oder nur aus einer anderen Quelle verfügbar ist.
E: Für Paket »libc6-i386« existiert kein Installationskandidat.
E: Paket lib32stdc++6 kann nicht gefunden werden.
E: Mittels regulärem Ausdruck »lib32stdc++6« konnte kein Paket gefunden werden.
Habe auch ein KeyMatic am laufen, das wurde anscheinen automatisch eingebunden, kann das sein? Glaube das ist geschehen, als ich die Fernbedienung an KeyMatic angelernt habe. Dieses kann ich jedoch nicht aus fhem ansteuern.
Über Hilfe würde ich mich sehr freuen, danke.
Meines Wissens ist ein FW Update nicht unbedingt nötig. Nur dann, wenn das Release älter ist.
Ich habe es nicht durchgeführt.
Die Details dazu stehen im Wiki (Wiki.fhem.de) zum Thema LAN Gateway.
Bei deinen Update Problemen kann ich dazu leider nichts sagen.
Keymatic habe ich nicht im Einsatz und kann aus Erfahrung also nichts sagen.
Normalerweise richtet FHEM neue Geräte selbst ein, sobald das Pairing erfolgreich war.
Zitat von: DocCyber am 31 Januar 2020, 19:43:25
Normalerweise richtet FHEM neue Geräte selbst ein, sobald das Pairing erfolgreich war.
Nicht ganz. FHEM richtet per autocreate die Geräte von HM ein wenn deren Anlernmessage kommt. Die wird erzeugt, wenn "der Anlernknopf am Gerät gedrückt" wird. Mit pairen hat dies allein nicht zu tun!
Aber die Geräte zeigen danach in der Regel vieles, man kann in FHEM darauf reagieren, steuern kann man damit aber nicht. Dafür muss gepairt werden.
Das mit dem Update ist aus meiner Sicht das falsche Vorgehen, Ich würde nur Punkt 3.3 im Wiki versuchen. Die beiden Punkte davor sind sicher historisch so da drin. Das wurde irgendwann durch die Entwicklung des Moduls HMUARTLGW überholt.
@xMaXiiMuSx: In diesem Thread geht es um Pairing Probleme mit dem Lan-Gateway. Firmware Update war nicht das Thema. ::)
Gruß Otto
Zitat von: Otto123 am 31 Januar 2020, 20:46:55
In diesem Thread geht es um Pairing Probleme mit dem Lan-Gateway.
Um darauf noch mal zurückzukommen:
Welchen Grund kann es dafür geben, dass Pairing am HM-CFG-LAN innerhalb von wenigen Sekunden erfolgreich durchgeführt werden kann, aber am LAN-Gateway mehrere Minuten verstreichen, teils bis zu einer halben Stunde?
Guten Morgen,
Funktioniert denn jetzt das pairing der Thermostate?
Hallo Otto,
ich habe erst soeben damit beginnen können.
Folgendes habe ich gemacht:
Ich habe einen der Thermostate aus meiner bestehenden, funktionierenden HM-Umgebung rausgenommen, auf Werkseinstellung zurückgesetzt und den HM-CFG-LAN gestoppt (set HM-CFG-LAN close). Diesen Thermostaten habe ich dann mit der VCCU meiner der zweiten Umgebung (mit LAN-Gateway) angelernt.
Folgendes kann ich feststellen:
hmPairSerial funktioniert beim Thermostaten scheinbar tatsächlich nicht. Scheinbar deshalb, weil ich der LGW-Umgebung noch nicht so richtig traue.
mhPairForSec "funktioniert" zügig, aber ich warte noch immer noch auf ein erfolgreiches Pairing.
Wie gesagt: es dauert und dauert... Mittlerweile warte ich schon mehr als 30 Minuten. CMDs_pending. :o
Warum ist das so?
An meinen Örtlichkeiten kann es nicht liegen. Beide Zentralen, also CFG-LAN wie auch LAN-GW, sind 2-3 Meter entfernt. Das anzulernende Gerät (Thermostat) ist identisch.
Da es mit dem CFG-LAN bis vorhin lief, kann es nur noch am LAN-GW oder am Softwaremodul liegen.
Habe ich etwas übersehen?
Wie erkenne ich denn ob das pairing eines Gerätes erfolgreich war?
Zitat von: xMaXiiMuSx am 01 Februar 2020, 14:58:17
Wie erkenne ich denn ob das pairing eines Gerätes erfolgreich war?
Daran das hmInfo nicht meckert oder das Gerät hat die readings ordentlich mit der hmId gefüllt. In der Art:
PairedTo 0x200DB8
R-pairCentral 0x200DB8
@DocCyber
hast Du nochmal mal ein getConfig am Thermostaten abgesetzt? Der sendet glaube ich etwas verzögert. Bereich 2,5 min - aber nicht 30 min!
CMDs_pending bedeutet, er will Daten senden und/oder wartet auf welche bekommt es aber nicht hin. Nochmal den Configtaster drücken? Ist beim Thermostaten boost - oder?
Zitat von: Otto123 am 01 Februar 2020, 15:46:03
hast Du nochmal mal ein getConfig am Thermostaten abgesetzt?
Ja, das habe ich alles schon mehrfach wiederholt.
Zitat
CMDs_pending bedeutet, er will Daten senden und/oder wartet auf welche bekommt es aber nicht hin.
Das ist mir durchaus klar.
Wie gesagt: Ich habe ungefähr 40 HM-Geräte in meiner
etablierten Umgebung, und ich hatte bis dato keinerlei Pairing-Probleme. Alles immer mit hmPairForSec gemacht, und immer war alles innerhalb von wenigen Sekunden korrekt gepairt. Auch dieser Thermostat, der am LGW nun partout nicht will.
Immer noch CMDs_pending. Nach Stunden mittlerweile ...
was sagt der load und loadLvl im HMLGW?
Aus meiner Sicht alles okay:
Internals:
AssignedPeerCnt 3
CNT 165
Clients :CUL_HM:
DEF 192.168.178.24
DEVCNT 215
DevState 99
DevType LGW
DeviceName 192.168.178.24:2000
FD 15
FUUID 5e19b827-f33f-4dd6-9509-4a2257861abfdb55
LastOpen 1580571934.89153
NAME LANgateway
NOTIFYDEV global
NR 19
NTFY_ORDER 50-LANgateway
PARTIAL
RAWMSG 0500003A6B8002ABBA0040A1950101C800
RSSI -58
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model eQ3-HM-LGW
msgLoadCurrent 1
msgLoadHistory 0/0/-15/-7/0/-5/0/0/0/0/1/0
msgLoadHistoryAbs 1/1/1/16/23/23/28/28/28/28/28/27/27
owner CAFE00
owner_CCU VCCU
Helper:
CreditTimer 344
FW 66561
Initialized 1
SendCnt 24
AckPending:
LastSendLen:
3
3
Log:
IDs:
PendingCMD:
RoundTrip:
Delay 0.0041351318359375
loadLvl:
lastHistory 1580577039.91427
MatchList:
1:CUL_HM ^A......................
Peers:
4E6F4E +4E6F4E,00,00,00
6F49DB +6F49DB,00,00,00
6F4BCE +6F4BCE,00,00,00
READINGS:
2020-02-01 16:45:39 D-HMIdAssigned CAFE00
2020-02-01 16:45:39 D-HMIdOriginal FFFFFF
2020-02-01 16:45:34 D-LANfirmware 1.1.5
2020-02-01 16:45:39 D-firmware 1.4.1
2020-02-01 16:45:34 D-serialNr PEQ2247964
2020-02-01 16:45:34 D-type eQ3-HM-LGW
2020-02-01 16:45:39 cond ok
2020-02-01 18:00:43 load 1
2020-02-01 16:45:39 loadLvl low
2020-02-01 16:45:34 state opened
helper:
keepAlive:
CNT 25
DEVCNT 24
DevState 99
DevType LGW-KeepAlive
DeviceName 192.168.178.24:2001
FD 16
LastOpen 1580571934.89734
NAME LANgateway:keepAlive
NR 51
PARTIAL
STATE opened
TEMPORARY 1
TYPE HMUARTLGW
XmitOpen 0
Helper:
NextKeepAlive 1580577108.61653
Log:
Resolve 1
IDs:
READINGS:
2020-02-01 16:45:34 state opened
Attributes:
hmId CAFE00
lgwPw VAKGCBW6L!
room 00_SYSTEM
Für heute ist erstmal Schluss mit fhem; es hat mich genug geärgert.
Fußball ist jetzt (noch!) wichtiger:
Leipzig - Gladbach. :)
Melde mich morgen...
Moin,
mir fiel da noch ein: Wie hast Du es mit der LAN Verschlüsselung gemacht? Ist die AN oder AUS?
Ich rede ja mit dem HM-LGW-O-TW-W-EU-2 nur theoretisch, ich habe selbst keins.
Gruß Otto
Guten Morgen Otto
mmm... Interessanter Aspekt
Ich habe keine diesbezüglichen Einstellungen gemacht, lediglich das vorgegebene Kennwort des LGW gesetzt. Gemäß commandref müsste die Verschlüsselung also eingeschaltet sein:
lgwPw
AES password for the eQ-3 HomeMatic Wireless LAN Gateway. The default password is printed on the back of the device (but can be changed by the user). If AES communication is enabled on the LAN Gateway (default), this attribute has to be set to the correct value or communication will not be possible. In addition, the perl-module Crypt::Rijndael (which provides the AES cipher) must be installed.
Das Perlmodul Crypt::Rijndael habe ich aber nicht installiert, zumindest nicht wissentlich. Wie finde ich heraus, ob es schon serienmäßig beim Raspi-Setup installiert wurde - und wie installiere ich es, wenn es nicht drauf ist?
Andererseits: Die beiden Switches funktionieren ja, auch wenn das Paring hier auch eine Weile benötigte. Also müsste die Kommunikation grundsätzlich doch funktionieren?
Generell hatte ich heute früh den Gedanken, ob nicht die Raspi-Einstellungen nochmals gescheckt werden sollten. Wie berichtet, hatte ich ja zunächst mit der kleinen Funkplatine (HM-MOD-RPI-PCB) experimentiert und dazu etliche Änderungen (u.a. lt. deines Blogs) durchgeführt. Evtl ist mir dabei ein Fehler unterlaufen. Könnte es ein, dass diese Änderungen nun Probleme beim Betrieb des LGW verursachen, weil ich den HM-MOD-RPI-PCB ja nun doch nicht nicht im Einsatz habe? Nicht zuletzt auch wegen meiner Lötfähigkeiten. ???
Wäre es ggf sogar sinnvoll, ein komplett neues Raspi-Setup zu starten, also das Image neu aufzuspielen? Es gibt schließlich seit Kurzem FHEM 6.0...
Wenn man nicht mehr genau weiß ob man etwas installiert hat - da habe ich mal was vorbereitet: ;)
https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html
Im Wiki steht etwas dazu wie man die AES Kommunikation über LAN ein oder ausschalten kann.
Ich denk eigentlich nicht, das Deine Versuche mit dem HMUART Modul etwas mit dem LAN Gateway zu tun haben ...
Oder gibt es ein generelles Problem mit der Netzwerk Kommunikation mit dem Langateway ? IP Adress Konflikt oder so?
Zitat von: Otto123 am 01 Februar 2020, 15:46:03
Daran das hmInfo nicht meckert oder das Gerät hat die readings ordentlich mit der hmId gefüllt. In der Art:
PairedTo 0x200DB8
R-pairCentral 0x200DB8
pairing scheint nicht funktioniert zu haben.
CommandAccepted no 2020-01-31 18:33:24
D-firmware 2.5 2020-01-29 18:59:22
D-serialNr OEQ1391192 2020-01-29 18:59:22
PairedTo 0x000000 2020-01-29 18:51:36das LGW hat HMid 000001 somit müsste ich diese id in der Info des KeyMatic sehen richtig?
pairing habe ich beim LGW mit
set "meinLGW" hmPairSerialdurchgeführt.
Zitat von: xMaXiiMuSx am 02 Februar 2020, 14:18:35
pairing habe ich beim LGW mit
set "meinLGW" hmPairSerial
durchgeführt.
Da weiß ich nicht ob das mit der Keymatic wirklich funktioniert :-[
Aber er hat angefangen es gibt schon PairedTo allerdings mit dem "Zwischenwert" 6 mal 0.
Nimm normalerweise hmPairForSec ...
Hier gibt es was zum lesen: https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen
Die hmId 000001 geht sicher, ich hätte die nicht genommen. Normalerweise haben die ersten und letzten Ziffern in solchen Systemen eine Sonderbedeutung. zB. der ActionDetector 000000
Ja Du müsstest die 000001 im PairedTo sehen
Zitat von: Otto123 am 02 Februar 2020, 11:51:36
Wenn man nicht mehr genau weiß ob man etwas installiert hat - da habe ich mal was vorbereitet: ;)
https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html
Im Wiki steht etwas dazu wie man die AES Kommunikation über LAN ein oder ausschalten kann.
Das sehe ich mir an. Danke.
Zitat
Ich denk eigentlich nicht, das Deine Versuche mit dem HMUART Modul etwas mit dem LAN Gateway zu tun haben ...
Beruhigend. :)
Zitat
Oder gibt es ein generelles Problem mit der Netzwerk Kommunikation mit dem Langateway ? IP Adress Konflikt oder so?
Ich denke nicht. Habe jetzt alle IP-Adressen von aktuellen und früheren Netzwerkverbindungen (Fritzbox 9470) geprüft: sie werden alle nur einmal verwendet, und zwar für jedes Gerät jeweils dieselbe Adresse.
Ob ich mal eine Umfrage starten soll, wer hier im Forum ein LGW verwendet? Vielleicht haben andere ähnliche Probleme...
Zitat von: Otto123 am 02 Februar 2020, 14:34:59
Nimm normalerweise hmPairForSec ...
Hier gibt es was zum lesen: https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen
Die hmId 000001 geht sicher, ich hätte die nicht genommen. Normalerweise haben die ersten und letzten Ziffern in solchen Systemen eine Sonderbedeutung. zB. der ActionDetector 000000
Ja Du müsstest die 000001 im PairedTo sehen
mit hmPairForSec habe ich es auch schon probiert.
Werde das Gerät mal auf Werkseinstellungen zurücksetzten. Vielleicht hätte ich auch die Fernbedienung noch nicht anlernen dürfen.
Zitat von: xMaXiiMuSx am 02 Februar 2020, 17:22:12
Vielleicht hätte ich auch die Fernbedienung noch nicht anlernen dürfen.
Die Annahme ist falsch. Ich habe auch die erste Fernbedienung als Master angelernt. Ich habe das als wesentliches Sicherheitsfeature verstanden.
Ach so Keymatic - daran hast Du gedacht?
ZitatGerät in FHEM anlernen
Türschlossantrieb
Mit set <vccu> hmPairForSec 60 die Zentrale in den Anlernmodus versetzen
Am Antrieb die obere Taste (Schloss auf) 2 sec drücken, die Anzeige wechselt nach X
Mit der Master FB durch drücken einer der beiden Tasten (Schloss auf oder zu) den Vorgang quittieren (Sicherheitsabfrage)
Ein erneuter Anlernversuch wird durch Anzeige von "c" im Display verweigert.
Siehe auch (https://heinz-otto.blogspot.com/2017/09/homematic-turschlieer.html)
Zitat von: DocCyber am 02 Februar 2020, 10:55:03
Das Perlmodul Crypt::Rijndael habe ich aber nicht installiert, zumindest nicht wissentlich.
Crypt::Rijndael war installiert - gefunden dank deines Skripts, Otto!
Ergänzung 18:30
Offenbar ist die Verschlüsselung ab Werk aktiviert: Nach
deleteattr lgwPwd funktionierte der Switch nicht mehr.
Zitat von: Otto123 am 02 Februar 2020, 17:33:18
Die Annahme ist falsch. Ich habe auch die erste Fernbedienung als Master angelernt. Ich habe das als wesentliches Sicherheitsfeature verstanden.
Ach so Keymatic - daran hast Du gedacht?
Siehe auch (https://heinz-otto.blogspot.com/2017/09/homematic-turschlieer.html)
Habe es hinbekommen, danke.
Musste, nachdem ich das Gerät in den Anlernmodus gebracht habe, eine Taste an der Master-Fernbedienung drücken.
Dachte diese müsste ich nur verwenden, wenn ich eine weitere Fernbedienung anlernen möchte.
So langsam wird es was...
Ihr könnt froh sein, dass Otto123 so eine EselsGeduld hat ;D
Das stimmt genau.
Noch ein neuer Raspi.
Komplett neues Image - Buster lite.
Ganz neues FHEM- jetzt v 6.0
Thermostat lässt sich nicht am LGW anlernen.
Das selbe Gerät zurückgesetzt.
Pairing am HM-CFG-LAN gestartet.
Nach drei Sekunden erfolgreich.
Entweder ist das LGW (ist brandneu!) defekt, oder es gibt ein Problem mit der Software.
Anders kann ich mir das nicht mehr erklären - selbst Otto123 hat keine Idee mehr.
Ich bin gern bereit, die Hardware zu Testzwecken zur Verfügung zu stellen und mich davon überzeugen zu lassen, dass es einen anderen Grund gibt.
Wenn ich ein Vergleichsgerät hätte würde ich das ja machen. Aber wenn die Vermutung Richtung defekt geht (ich meine wir hatten das wirklich schon mal hier im Forum) wäre es ja besser das Ding zurück zu schicken und einen Neuen zu ordern?
Ich meine, wenn Du ihn mir schickst gibt es auch drei mögliche Varianten:
1. es verhält sich wie bei Dir und wir wissen nicht warum
2. es funktioniert bei mir
3. es ist wirklich kaputt. Das könnte eben nur einer sagen, der ein LGW im Einsatz hat.
Gruß Otto
Danke, Otto, dass du dran bleibst!
(Ich würde dich gern zu einem Bier einladen, nur leider ist es etwas weit nach Leipzig. :) )
Du hast völlig recht mit deinem Kommentar, und ich hatte mir ähnliche Gedanken gemacht.
Als Konsequenz gbt es nun eine neue Situation:
Ich bin mit den problematischen Geräten (2xSwitch, 2xThermostat) zu meinem Nachbarn gegangen und habe ihn gebeten, das Pairing an seiner CCU2 zu versuchen.
Alle Geräte wurden sofort erkannt. Die Schalter funktionieren auf allen Kanälen, und ein eingebauter Funktionstest hat auch die Thermostate als okay eingestuft.
Damit bleiben als möglichen Ursachen tatsächlich nur noch ein defektes HM-LGW oder ein Softwarefehler.
Zunächst besorge ich nun einen neuen HM-LGW. Ich denke, das dauert 3 Tage, und dann melde ich mich wieder.
EDIT 17.02.2020: Ich habe den Titel dieses Threads angepasst
Zwischenzeitlich habe ich das LAN Gateway von HM mit der Diagnose zurück erhalten, dass das Gerät technisch in Ordnung sei. ???
Ich habe also alles nochmals versucht.
Einzige Änderung im Vergleich zu meinen vergangenen Versuchen: etwas größerer Abstand zwischen den zu pairenden Devices und dem LAN-Gateway; jetzt etwa 4 Meter Luftlinie.
Schaltaktoren okay
Pairing zweier Schaltaktoren vom Typ HM-LC-SW2-FM funktioniert quasi einwandfrei, wenn auch nicht ganz so zügig wie gewohnt.
Wandthermostat geht nicht
Allerdings geht nach wie vor nichts bei den Wandthermostaten vom Typ HM-TC-IT-WM-W-EU. Ich kann festhalten, dass die Thermostaten ebenfalls technisch okay sind, denn sie werden beim Pairing an der CCU2 meines Nachbarn problemlos gefunden.
Ich hatte an anderer Stelle (nicht hier im Forum!) eine kurze Bemerkung gelesen, wonach die Thermostaten Probleme beim Pairing haben sollen. An meiner "eigenen" Installation funktionieren die Dinger tadellos; ich habe 8 Stück im Einsatz. Allerdings sind diese mittels HM_CFG_LAN gepairt.
Es sieht so aus, als ob die Thermostaten ein grundsätzliches Problem am LAN Gateway haben.
Frage:
Hat jemand von euch dieselbe Kombination wie ich, also Wandthermostate an eQ3-HM-LGW?
Klappt das problemlos?
Zitat von: DocCyber am 17 Februar 2020, 14:55:23
EDIT 17.02.2020: Ich habe den Titel dieses Threads angepasst
Zwischenzeitlich habe ich das LAN Gateway von HM mit der Diagnose zurück erhalten, dass das Gerät technisch in Ordnung sei. ???
...
Nach dem Durchlesen des ganzen Threads (den ich schon von Anfang an oberflächlich verfolgt habe) stelle ich folgende Abhängigkeit fest:
Besagte Wandthermostaten tun am HM-LGW-... nicht pairen. Ein Schaltaktor tut, wenn auch widerwillig.
Beide Geräte arbeiten mit anderen IO-Interfaces einwandfrei.
Auch wenn ELV der Meinung ist, dass das Gerät technisch einwandfrei arbeitet ...
Ist es denkbar, dass das betreffende LGW Probleme mit der Funkfrequenz hat, also so weit "daneben" arbeitet, dass das Pairing mit dem Steckdosenaktor gerade noch mit ein paar Fehlversuchen klappt, mit dem ungleich anspruchsvolleren Thermostat aber nicht mehr? Vielleicht einmal interessehalber den Abstand eines Thermostaten unter die magische 1-m-Grenze bringen und erneut versuchen?
Ein unfertiges Pairing liefert ja leider keine rssi-Werte von beiden Seiten. Das wäre auch ein interessanter Anhaltspunkt. Vielleicht doch von dem gepairten Schaltaktor? Wie gut reagiert der auf Schaltbefehle?
Zitat von: Pfriemler am 17 Februar 2020, 17:20:12
... (den ich schon von Anfang an oberflächlich verfolgt habe) ...
Finde ich klasse! ;)
Ich schlage mich nun seit rund 4 Wochen mit dem Problem rum, und ich bin sicher, dass ich auch schon Pairingversuche über die kürzere Distanz versucht hatte.
Die Schaltaktoren reagieren einwandfrei auf Schaltbefehle. Man sieht an der LED, dass ein Kanal geschaltet wurde, und man hört das Relais klicken.
(Es liegt nur leider keine Spannung an, sobald durchgeschaltet wurde. Evtl sind die Relais durch das so häufige Reset während der Testphase defekt.)
Was die Wandthermostaten angeht, vermute ich mittlerweile ein grundsätzliches Problem* beim Pairen dieses Gerätetypus mit dem LAN-Gateway. Ich habe daher einen entsprechenden Thread im Homematic-Teil dieses Forums gestartet:
https://forum.fhem.de/index.php/topic,108504.msg1024794.html#msg1024794 (https://forum.fhem.de/index.php/topic,108504.msg1024794.html#msg1024794)
Edit 17.02. 18:45
*"Leider" nicht - diese "Hoffnung" hat sich wohl zerschlagen - vgl. den neuen Thread
Aber da es - warum auch immer - bei mir dieses Problem gibt, möchte ich eine weitere Frage stellen:
Ich könnte doch die kritischen Geräte am HMLAN in HM-Umgebung-1 anlernen und diese Geräte danach das LAN-Gateway in HM-Umgebung-2 zu Kommunkation verwenden, sofern die hm-IDs in Umgebung 1 und 2 gleich sind, oder?
Natürlich nicht gleichzeitig... Ich würde also den HMLAN quasi nur als Pairing-Hilfe einsetzen. Geht so etwas? ::)
Den anderen Thread hatte ich gelesen, aber nur hier geantwortet. Ich habe kein LGW, kann daher dazu nichts sagen.
Zitat von: DocCyber am 17 Februar 2020, 17:35:11
... in HM-Umgebung-1 anlernen ... in HM-Umgebung-2 ... verwenden, sofern die hm-IDs in Umgebung 1 und 2 gleich sind, oder?
Das sollte funktionieren. Die Frage ist nur, ob die Kommunikation zwischen LGW und den Thermostaten stabil ist, wenn das Pairing schon nicht funktioniert hat...?
Warum sollten die Relais durch die vielen Versuche Schaden genommen haben? Da liegt ein anderes Problem vor.
Ich probiere es morgen mal aus und melde mich dann wieder.
Zwischenzeitliches Update:
Umgebung1: das ist meine etablierte HM-Umgebung mit x HM-Geräten an HMLAN und VCCU
Folgender Versuch:
# problematisches LAN-Gateway zurückgesetzt und
# als zweites IO in meine Umgebung1 eingebunden.
# hmID identisch zu der in Umgebung1.
# Reset an zwei Schaltaktoren und an zwei Wandthermostaten gemacht, danach
# Pairingversuch via VCCU an HMLAN erfolgreich durchgeführt.
# HMLAN als IO abgeschaltet (set <HMLAN> close), somit nur noch LAN-Gateway aktiv.
=> Gesamte Konfiguration / Kommunikation läuft ohne Probleme über LAN-Gateway, d.h. sowohl die "etablierten" als auch die neuen Geräte senden, empfangen, lassen sich schalten, etc.
# erneuter Reset eines Wandthermostaten
# Mehrere Pairingversuche via VCCU an LAN-Gateway (in derselben Umgebung1) scheitern.
Zusammengefasst: Betrieb an LAN-Gateway okay, aber das Pairing von Wandthermostaten daran funktioniert nicht.
Ich weiß nicht, was ich noch tun könnte. >:(
sniffe jeweils das pairen des selben thermostats einmal mit hmlan und dann mit hmlgw wie im wiki beschrieben.
hört sich nach timing problemen des hmlgw an.
unterschiedliche netzanbindung?
Hallo Frank,
danke für den Hinweis.
Morgen gebe ich mich ans Sniffen und mede mich dann wieder.
Zitat von: frank am 18 Februar 2020, 18:11:37
hört sich nach timing problemen des hmlgw an.
unterschiedliche netzanbindung?
HMLAN hängt über einen Netzwerkswitch an der Fritzbox, LGW ist über 2 Switches mit der FB verbunden.
Ich könnte beide IOs mal an denselben Switch hängen und prüfen, ob sich was ändert.
Zitat von: frank am 18 Februar 2020, 18:11:37
unterschiedliche netzanbindung?
Es sieht so aus, als ob dies der entscheidende Hinweis gewesen ist!
Ich hatte jetzt
beide IOs an den selben Netzwerk-Switch gehängt und dann meinen Versuch von hier
https://forum.fhem.de/index.php/topic,107931.msg1025169.html#msg1025169 (https://forum.fhem.de/index.php/topic,107931.msg1025169.html#msg1025169)
wiederholt.
Das Pairing eines Thermostaten am LANgateway hat nun zum ersten Mal funktioniert! Ich bin überrascht, begeistert ... und auf jeden Fall erleichtert. 8)
Hatte schon die Befürchtung, ich bekomme das Problem überhaupt nicht gelöst.
Aber ein paar Fragen bleiben noch:
Weshalb macht es einen solchen Unterschied, ob die Netzanbindung über einen oder zwei Netzwerk-Switches geschieht?
Was passiert da?
Und warum sind Thermostaten so kritisch, wenn es um's Pairing geht?
@frank:
Soll ich die Sniffing-Resultate noch hochladen?Auf jeden Fall warte ich noch etwas, bevor ich den Thread als gelöst markiere.
setze mal beim hmlgw "attr logIDs sys".
im fhem.log erscheint dann alle 15sek eine zeile mit roundtripdelay.
du könntest diese delays zb 5 min sammeln und je eine liste für beide netzanbindungen posten.
das werde ich tun, aber das Hobby fhem muss jetzt erst mal ein bis zwei Tage warten.
Es wird also etwas dauern.
Hab ja noch andere Hobbys; z.B. einen Beruf. ;)
Vielen Dank für deine Hilfe, Frank!
Zitat von: frank am 19 Februar 2020, 18:11:04
setze mal beim hmlgw "attr logIDs sys".
im fhem.log erscheint dann alle 15sek eine zeile mit roundtripdelay.
du könntest diese delays zb 5 min sammeln und je eine liste für beide netzanbindungen posten.
Ich habe festgestellt, dass ein Netzwerkhub defekt ist.
Nach Austausch läuft nun wieder alles. :)
Allerdings, das sei noch gesagt, ist das Pairing von Thermostaten noch immer schwieriger als mit anderen Devices, d.h. man muss den Pairingprozess öfter wiederholen.
Letzten Endes geht's es
jetzt aber immmer.
Allen, die mir hier geholfen haben, gilt mein herzlicher Dank.