Hallo,
ich bin mir nicht sicher, ob der Thread in dieses Unterforum gehört oder zum Forum NAS. Bitte an die Moderatoren: Bitte entsprechend verschieben, wenn hier falsch.
Nachdem ich das Waveshare-GW mit den Rolladenaktoren HMW-LC-Bl1-DR auf dem Raspi zum laufen bekommen habe (siehe hier: https://forum.fhem.de/index.php/topic,131037.0.html (https://forum.fhem.de/index.php/topic,131037.0.html)), erfolgte der Umzug auf das NAS in den Docker-Container. Wie zu erwarten war, kamen neue Probleme auf.
Das war die Definition beim Raspi:
define Waveshare485 HM485_LAN localhost:2000
attr Waveshare485 HM485d_bind 1
attr Waveshare485 HM485d_device 192.168.178.30:5000
attr Waveshare485 HM485d_logVerbose 5
attr Waveshare485 HM485d_logfile HM485LogJG.log
attr Waveshare485 HM485d_serialNumber XXXXXYYY
attr Waveshare485 autoReadConfig always
attr Waveshare485 hmwId 00000002
attr Waveshare485 icon lan_rs485
attr Waveshare485 room RS485,9.6.0_System
attr Waveshare485 verbose 1
Da der Port 2000 in Docker schon belegt war, wurde auf 2003 gewechselt.
Da der Port 5000 in Docker nicht als Portweiterleitung angelegt werden konnte (???), wurde der Port 4196 verwendet. Dieser konnte weitergeleitet werden.
Aus der Definition localhost:2003 beim Anlegen des Device wurde dann --localPort 2003. Warum ist mir nicht klar
Da ich Anfangs keine Verbindung zum Device bekommen habe und beim Googlen zum Thema localhost und Container einen Hinweis gefunden habe https://forums.docker.com/t/localhost-and-docker-compose-networking-issue/23100/5 (https://forums.docker.com/t/localhost-and-docker-compose-networking-issue/23100/5), dass statt localhost der host.docker.internal verwendet werden soll, habe ich das geändert und tatsächlich eine Verbindung zum Gateway erhalten.
Das Gateway wird scheinbar erkannt (LED leuchtet auch Blau) und der Port 2003 genutzt.
2022.12.22 16:38:57.338 3: HM485d: server waiting for client connection on port 2003
2022.12.22 16:38:57.339 3: Opening SERIAL device 192.168.178.30:4196
2022.12.22 16:38:57.342 3: SERIAL device opened
2022.12.22 16:38:57.342 2: HM485d: SERIAL connected to device 192.168.178.30:4196
2022.12.22 16:38:57.342 1: HM485d: Server started ...
2022.12.22 16:39:02.327 4: Connection accepted from HM485d_172.17.0.1_47952
2022.12.22 16:39:02.327 4: HM485d: Tx: H00,01,HMW-SOFT-GW,0.2.2,2863EBA7E7CE
2022.12.22 16:39:02.329 4: HM485d: Rx: FD3E30312C303030300D0A
Das list des Device in Docker sieht jetzt so aus:
Internals:
DEF host.docker.internal:2003
DeviceName host.docker.internal:2003
FD 38
HM485d_CommandLine ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000002 --serialNumber XXXXXYYY --device 192.168.178.30:4196 --localPort 2003 --logfile WaveshareRS485.log --verbose 5
HM485d_PID 6724
HM485d_STATE started
InterfaceType HMW-SOFT-GW
LASTInputDev Waveshare485
Last_Sent_RAW_CMD FFFFFFFF 98 00000002 5A
Last_Sent_RAW_CMD_State NACK
MSGCNT 24
NAME Waveshare485
NR 378
PARTIAL
ProtokolVersion 01
STATE opened
SerialNumber XXXXXYYY
TYPE HM485_LAN
Version 0.2.2
Waveshare485_MSGCNT 24
Waveshare485_TIME 2022-12-22 16:01:58
currentQueueId 0
discoveryRunning 0
eventCount 3
hmwId 00000002
msgCounter 86
queueId 14
queueRunning 0
READINGS:
2022-12-22 15:49:00 state opened
ctrl:
00013381 1E
FFFFFFFF 98
hmccu:
keepalive:
ok 1
retry 0
sendQueue:
Attributes:
HM485d_bind 1
HM485d_device 192.168.178.30:4196
HM485d_logVerbose 5
HM485d_logfile WaveshareRS485.log
HM485d_serialNumber XXXXXYYY
autoReadConfig always
comment localhost:2000
hmwId 00000002
icon lan_rs485
room 9.6.0_System,Test
verbose 5
Leider werden die Device auf dem Bus nicht erkannt. Erkannt wird, dass Device vorhanden sind, aber weder der Typ des Device noch die Seriennummer.
Nach dem Neustart stand dies im LOG:
2022.12.22 15:53:00.859 5: DevIo_SimpleWrite Waveshare485: fd0d1153c8ffffffff98000000025a
2022.12.22 15:53:00.860 4: Waveshare485: Waveshare485: TX: (17) I[0](0,Y,F,B)(98) 00000002 -> FFFFFFFF [3] 5A(Z)
2022.12.22 15:53:00.961 5: Waveshare485: HM485_LAN_CheckResendQueueItems: QID: 00000005
2022.12.22 15:53:08.991 5: Waveshare485: HM485_LAN_parseIncommingCommand: MsgId: 0 Cmd: 101
2022.12.22 15:53:08.991 4: Waveshare485: Event:HASH(0x55a3f556dc20)
2022.12.22 15:53:08.991 5: Waveshare485: Dispatch: FD0F006500000001F80001338169025E20
2022.12.22 15:53:08.991 5: Waveshare485: dispatch �\017\000e\000\000\000\001�\000\0013�i\002^
2022.12.22 15:53:09.020 3: HM485: HM485: Converting device files
2022.12.22 15:53:09.020 3: HM485: ==============================
2022.12.22 15:53:09.020 3: HM485: hmw_central.xml up to date
2022.12.22 15:53:09.020 3: HM485: hmw_generic.xml up to date
2022.12.22 15:53:09.020 3: HM485: hmw_io12_sw14_dr.xml up to date
2022.12.22 15:53:09.020 3: HM485: hmw_io12_sw7_dr.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_io12_sw7_dr_V3_02.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_io_12_fm.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_io_4_fm.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_io_4_fm_V3_02.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_io_sr_fm.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_lc_bl1_dr.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_lc_bl1_dr_V3_02.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_lc_dim1l_dr.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_lc_sw2_dr.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_lc_sw2_dr_V3_02.xml up to date
2022.12.22 15:53:09.021 3: HM485: hmw_sen_sc_12_dr.xml up to date
2022.12.22 15:53:09.021 3: HM485: Loading available device files
2022.12.22 15:53:09.021 3: HM485: ==============================
2022.12.22 15:53:09.021 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_central.pm
2022.12.22 15:53:09.022 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_generic.pm
2022.12.22 15:53:09.022 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw14_dr.pm
2022.12.22 15:53:09.023 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr.pm
2022.12.22 15:53:09.026 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_V3_02.pm
2022.12.22 15:53:09.028 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_12_fm.pm
2022.12.22 15:53:09.031 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm.pm
2022.12.22 15:53:09.034 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm_V3_02.pm
2022.12.22 15:53:09.037 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_sr_fm.pm
2022.12.22 15:53:09.039 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr.pm
2022.12.22 15:53:09.043 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr_V3_02.pm
2022.12.22 15:53:09.046 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_dim1l_dr.pm
2022.12.22 15:53:09.050 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr.pm
2022.12.22 15:53:09.053 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr_V3_02.pm
2022.12.22 15:53:09.055 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_sen_sc_12_dr.pm
2022.12.22 15:53:09.056 5: Waveshare485: HM485_Parse: MsgId: 0
2022.12.22 15:53:09.056 5: Waveshare485: HM485_Parse: ProcessEvent
2022.12.22 15:53:09.056 5: Waveshare485: HM485_ProcessEvent: hmwId = 00013381 msgData = 69025E20
2022.12.22 15:53:09.056 4: Waveshare485: Device 00013381 not defined yet. We need the type for autocreate
2022.12.22 15:53:09.056 5: Waveshare485: HM485_QueueCommand68
2022.12.22 15:53:09.056 5: Waveshare485: HM485_QueueStart: Num: 0
2022.12.22 15:53:09.056 5: Waveshare485: HM485_QueueProcessStep: HASH(0x55a3f6392548)
2022.12.22 15:53:09.059 5: Waveshare485: HM485_LAN_Write TX: 18
2022.12.22 15:53:09.059 5: Waveshare485: HM485_LAN_SendQueueNextItem: QID: 00000006
2022.12.22 15:53:09.059 5: DevIo_SimpleWrite Waveshare485: fd0d1253c800013381980000000268
2022.12.22 15:53:09.060 4: Waveshare485: Waveshare485: TX: (18) I[0](0,Y,F,B)(98) 00000002 -> 00013381 [3] 68(h)
2022.12.22 15:53:09.060 5: Waveshare485: HM485_QueueSetRequestId start
2022.12.22 15:53:09.060 5: Waveshare485: HM485_QueueSetRequestId: Id: 18
2022.12.22 15:53:09.061 5: Waveshare485: HM485_LAN_parseIncommingCommand: MsgId: 0 Cmd: 101
2022.12.22 15:53:09.061 4: Waveshare485: Event:HASH(0x55a3f5b2b5c8)
2022.12.22 15:53:09.061 5: Waveshare485: Dispatch: FD0F006500000001F80001338169025E20
2022.12.22 15:53:09.061 5: Waveshare485: dispatch �\017\000e\000\000\000\001�\000\0013�i\002^
2022.12.22 15:53:09.064 5: Waveshare485: HM485_Parse: MsgId: 0
2022.12.22 15:53:09.064 5: Waveshare485: HM485_Parse: ProcessEvent
2022.12.22 15:53:09.064 5: Waveshare485: HM485_ProcessEvent: hmwId = 00013381 msgData = 69025E20
2022.12.22 15:53:09.065 4: Waveshare485: Device 00013381 not defined yet. We need the type for autocreate
2022.12.22 15:53:09.065 5: Waveshare485: HM485_QueueCommand68
2022.12.22 15:53:09.065 5: Waveshare485: HM485_QueueStart: Num: 1
2022.12.22 15:53:09.126 5: Waveshare485: HM485_LAN_parseIncommingCommand: MsgId: 0 Cmd: 101
2022.12.22 15:53:09.126 4: Waveshare485: Event:HASH(0x55a3f5c2a988)
2022.12.22 15:53:09.126 5: Waveshare485: Dispatch: FD0F006500000001F80001338169025E20
2022.12.22 15:53:09.126 5: Waveshare485: dispatch �\017\000e\000\000\000\001�\000\0013�i\002^
2022.12.22 15:53:09.126 5: Waveshare485: HM485_Parse: MsgId: 0
2022.12.22 15:53:09.126 5: Waveshare485: HM485_Parse: ProcessEvent
2022.12.22 15:53:09.126 5: Waveshare485: HM485_ProcessEvent: hmwId = 00013381 msgData = 69025E20
2022.12.22 15:53:09.126 4: Waveshare485: Device 00013381 not defined yet. We need the type for autocreate
2022.12.22 15:53:09.126 5: Waveshare485: HM485_QueueCommand68
2022.12.22 15:53:09.126 5: Waveshare485: HM485_QueueStart: Num: 2
2022.12.22 15:53:09.291 5: Waveshare485: HM485_LAN_parseIncommingCommand: MsgId: 18 Cmd: 114
2022.12.22 15:53:09.291 5: Waveshare485: HM485_LAN_parseIncommingCommand: Response: (18) 1500
2022.12.22 15:53:09.291 5: Waveshare485: Dispatch: FD0512729E1500
2022.12.22 15:53:09.291 5: Waveshare485: dispatch �\005\022r�\025\000
2022.12.22 15:53:09.291 5: Waveshare485: HM485_Parse: MsgId: 18
2022.12.22 15:53:09.291 5: Waveshare485: HM485_Parse: ProcessResponse
2022.12.22 15:53:09.291 5: Waveshare485: HM485_ProcessResponse: msgData = 1500
2022.12.22 15:53:09.291 4: Waveshare485: Device 00013381 not defined yet. We need the serial number for autocreate
2022.12.22 15:53:09.292 5: Waveshare485: HM485_QueueCommand6E
2022.12.22 15:53:09.292 5: Waveshare485: HM485_QueueStart: Num: 3
2022.12.22 15:53:09.292 5: Waveshare485: HM485_QueueStepSuccess called
2022.12.22 15:53:09.292 5: Waveshare485: HM485_QueueStepSuccess: Entries: 0 Index: 0
2022.12.22 15:53:09.292 5: Waveshare485: HM485_QueueProcessStep: HASH(0x55a3f5a94e48)
2022.12.22 15:53:09.292 5: Waveshare485: HM485_LAN_parseIncommingCommand: Removing Queue 00000006
2022.12.22 15:53:09.292 5: Waveshare485: HM485_LAN_Write TX: 19
2022.12.22 15:53:09.292 5: Waveshare485: HM485_LAN_SendQueueNextItem: QID: 00000007
2022.12.22 15:53:09.292 5: DevIo_SimpleWrite Waveshare485: fd0d1353c8000133811a0000000268
2022.12.22 15:53:09.294 4: Waveshare485: Waveshare485: TX: (19) I[1](0,F,B)(1A) 00000002 -> 00013381 [3] 68(h)
2022.12.22 15:53:09.294 5: Waveshare485: HM485_QueueSetRequestId start
2022.12.22 15:53:09.294 5: Waveshare485: HM485_QueueSetRequestId: Id: 19
Und dies im Log des HM485d:
2022.12.22 15:53:00.756 4: HM485d: Rx: FD0D1053C8FFFFFFFF98000000025A
2022.12.22 15:53:00.756 5: SW: fdffffffff9800000002035a7b5c
2022.12.22 15:53:00.758 3: HM485d: Tx: (16:1) I[0](0,Y,F,B)(98) 00000002 -> FFFFFFFF [3] 5A(Z) {7B5C}
2022.12.22 15:53:00.859 4: HM485d: Rx: FD0D1153C8FFFFFFFF98000000025A
2022.12.22 15:53:00.860 5: SW: fdffffffff9800000002035a7b5c
2022.12.22 15:53:00.861 3: HM485d: Tx: (17:1) I[0](0,Y,F,B)(98) 00000002 -> FFFFFFFF [3] 5A(Z) {7B5C}
2022.12.22 15:53:08.989 3: HM485d: Rx: I[0](3,Y,F,B)(F8) 00013381 -> 00000001 [6] 69(i) 025E20 {3F5E}
2022.12.22 15:53:08.989 4: HM485d: Tx: FD0F006500000001F80001338169025E20
2022.12.22 15:53:09.049 3: HM485d: Rx: I[0](3,Y,F,B)(F8) 00013381 -> 00000001 [6] 69(i) 025E20 {3F5E}
2022.12.22 15:53:09.050 4: HM485d: Tx: FD0F006500000001F80001338169025E20
2022.12.22 15:53:09.059 4: HM485d: Rx: FD0D1253C800013381980000000268
2022.12.22 15:53:09.059 5: SW: fd0001338198000000020368edae
2022.12.22 15:53:09.061 3: HM485d: Tx: (18:1) I[0](0,Y,F,B)(98) 00000002 -> 00013381 [3] 68(h) {EDAE}
2022.12.22 15:53:09.124 3: HM485d: Rx: I[0](3,Y,F,B)(F8) 00013381 -> 00000001 [6] 69(i) 025E20 {3F5E}
2022.12.22 15:53:09.124 4: HM485d: Tx: FD0F006500000001F80001338169025E20
2022.12.22 15:53:09.261 5: SW: fd0001338198000000020368edae
2022.12.22 15:53:09.262 3: HM485d: Tx: (18:2) I[0](0,Y,F,B)(98) 00000002 -> 00013381 [3] 68(h) {EDAE}
2022.12.22 15:53:09.288 3: HM485d: Rx: Response: (18) I[3](0,Y,F,B)(9E) 00013381 -> 00000002 [4] 15() 00 {447E}
2022.12.22 15:53:09.289 5: SW: fd00013381790000000202226e
2022.12.22 15:53:09.290 3: HM485d: Tx: ACK(3,B)(79) 00000002 -> 00013381 [2] {226E}
2022.12.22 15:53:09.290 4: HM485d: Tx: FD0512729E1500
2022.12.22 15:53:09.293 4: HM485d: Rx: FD0D1353C8000133811A0000000268
2022.12.22 15:53:09.293 5: SW: fd000133811a000000020368ce80
2022.12.22 15:53:09.294 3: HM485d: Tx: (19:1) I[1](0,F,B)(1A) 00000002 -> 00013381 [3] 68(h) {CE80}
2022.12.22 15:53:09.360 3: HM485d: Rx: I[3](0,Y,F,B)(9E) 00013381 -> 00000002 [4] 15() 00 {447E}
2022.12.22 15:53:09.361 5: SW: fd00013381790000000202226e
2022.12.22 15:53:09.362 3: HM485d: Tx: ACK(3,B)(79) 00000002 -> 00013381 [2] {226E}
2022.12.22 15:53:09.362 4: HM485d: Tx: FD0D0065000000029E000133811500
2022.12.22 15:53:09.433 3: HM485d: Rx: Response: (19) I[1](1,F,B)(3A) 00013381 -> 00000002 [4] 15() 00 {992A}
2022.12.22 15:53:09.434 5: SW: fd00013381390000000202fbe0
2022.12.22 15:53:09.435 3: HM485d: Tx: ACK(1,B)(39) 00000002 -> 00013381 [2] {FBE0}
2022.12.22 15:53:09.435 4: HM485d: Tx: FD0513723A1500
2022.12.22 15:53:09.438 4: HM485d: Rx: FD0D1453C8000133811C0000000268
2022.12.22 15:53:09.438 5: SW: fd000133811c0000000203682a06
2022.12.22 15:53:09.439 3: HM485d: Tx: (20:1) I[2](0,F,B)(1C) 00000002 -> 00013381 [3] 68(h) {2A06}
2022.12.22 15:53:09.506 3: HM485d: Rx: dup frame: I[1](1,F,B)(3A) 00013381 -> 00000002 [4] 15() 00 {992A}
2022.12.22 15:53:09.577 3: HM485d: Rx: dup frame: I[1](1,F,B)(3A) 00013381 -> 00000002 [4] 15() 00 {992A}
2022.12.22 15:53:09.640 5: SW: fd000133811c0000000203682a06
2022.12.22 15:53:09.641 3: HM485d: Tx: (20:2) I[2](0,F,B)(1C) 00000002 -> 00013381 [3] 68(h) {2A06}
2022.12.22 15:53:09.651 3: HM485d: Rx: Response: (20) I[0](2,F,B)(58) 00013381 -> 00000002 [4] 15() 00 {D922}
2022.12.22 15:53:09.651 5: SW: fd000133811900000002021f26
Da die Device mit dem Raspi erkannt werden gehe ich davon aus, dass der Bus physikalisch in Ordnung ist und es ein Problem der Konfiguration ist, aber welches?
Ich komme hier nicht weiter. Hat jemand eine Idee oder solch ein Problem schon gelöst?
Grüße Jürgen
Hi,
das einzige seltsame, was mir da auffällt: Das Device 00013381 (vermutlich ein HMW-LC-Bl1-DR) sendet ein paar 69025E20. Das heißt soviel wie "Kanal 2 (bzw. 3, je nach Zählung) steht auf 5E20. Der Rolloaktor sendet da also seinen momentanen Stand. Normalerweise macht der das nicht von selbst (außer wenn man gerade auf einen Knopf drückt).
Das verwirrt wohl dann die FHEM-Seite ein bisschen. Allerdings sieht die Frage nach Gerätetyp erstmal vernünftig aus und das Gerät antwortet auch.
Wenn man sich mal die Nachrichten, die das Gerät sendet, genauer anschaut:
FD0F006500000001F80001338169025E20
...dann fällt auf, dass das Ding versucht, an die Zentrale 00000001 zu senden. Kann es sein, dass Du beide Zentralen im selben HM485-Netz hängen hast und die eine versucht, mit dem Gerät zu reden?
Gruß,
Thorsten
Was meinst Du mit "selben RS485-Netz"?
Meine Topologie sieht so aus:
EG: HM-Wired RS485 LAN Gateway (HMW-LGW-O-DR-GS-EU) und 8 Rolladenaktoren (HMW-LC-Bl1-DR) mit einem Busabschluß. Früher lief FHEM auf einem Raspi und da hatte die Zentrale die HmID 00000001. Später habe ich eine piVCCU3 auf einem eigenen Raspi ohne FHEM installiert und greife auf die Aktoren über das Modul HMCCU als Device vom Typ HMCCUDEV und die piVCCU (Version 3.65.8.-74) zu. Dort ist das LAN-Gateway definiert, allerdings nur über Seriennummer, Sicherheitsschlüssel und IP-Adresse. Eine HmID wird nicht angezeigt.
OG: Waveshare- Gateway mit 3 Rolladenaktoren (HMW-LC-Bl1-DR) und einem Busabschluß. Dieser Bus ist nicht mit dem Bus im EG verbunden. Da es schon die hmID 00000001 gegeben hat und wie ich vermute immer noch gibt habe ich die HmID 00000002 eingestellt.
Hängen jetzt beide Zentralen im selben Netz? Sie benutzen dasselbe LAN-Netzwerk, aber die Busse sind physikalisch getrennt.
Grüße Jürgen
Hi,
mit demselben RS485-Netz meinte ich, dass die beiden Gateways an der RS485-Seite miteinander verbunden sind. Das sind sie aber anscheinend nicht, wie Du gesagt hast. Soweit ich verstanden habe, werden die beiden Gateways sogar von unterschiedlichen Zentralen (einmal VCCU und einmal FHEM) angesprochen. Es ist also ziemlich unwahrscheinlich, dass die Nachricht an 00000001 von der anderen Zentrale getriggert wurde.
Es bleibt rätselhaft, warum das Device mit der ID 00013381 trotzdem diese Nachrichten an die Zentrale 00000001 verschickt. Dabei ist es einigermaßen klar, dass es die Zentrale 00000001 verwendet, aber es ist nicht so klar, warum es die Nachrichten überhaupt schickt.
Vielleicht kommen wir dahinter, wenn wir die ganzen Nachrichten etwas genauer betrachten:
15:53:00.860: Hier schickt die Zentrale (die 00000002) ein "Ende des Discovery-Modes" und erlaubt damit allen Devices wieder, normal zu senden. Ich gehe mal davon aus, dass das noch von einem vorherigen Versuch stammt bevor dann FHEM durchgestartet wurde.
15:53:08.991: Da sendet das Device 00013381 die erwähnte 69er-Nachricht. D.h. den momentanen Zustand. Das dürfte es nur machen, wenn die Zentrale vorher danach gefragt hat oder wenn man einen Knopf gedrückt hat, der mit dem Rollladen-Kanal gepeert ist. Je nach Logging-Time passiert das dann ein paar Sekunden nach der Aktion. Das HM485-Modul ist an der Stelle noch nicht initialisiert, es reagiert also auch noch nicht wirklich auf diese Nachricht.
15:53:09.020: Hier initialisiert sich das HM485-Modul. D.h. die Dateien für die einzelnen Device-Arten werden geprüft und eingelesen. Das ist ganz normal.
15:53:09.056: Jetzt verarbeitet das HM485-Modul die 69er Nachricht von 15:53:08.991. Dabei stellt das Modul fest, dass es das Device noch nicht kennt und schickt ab 15:53:09.059 die 68er "Gib mir mal Deinen Type"-Message raus.
15:53:09.061: Da kommt die nächste 69er-Nachricht vom Device rein. Entweder stand die noch im Empfangspuffer oder jemand hält eine Taste fest. ...oder irgend was anderes stimmt da nicht.
15:53:09.065: Da noch keine Antwort auf die 68er-Message kam kennen wir den Device-Type noch nicht. Also fragt FHEM nochmal nach. (Das ist etwas unschön, da man an der Stelle erstmal nur warten sollte. Das sollte aber kein prinzipielles Problem sein.)
15:53:09.126: Das Device 00013381 sendet nochmal die 69er-Message. Das kommt alles ein bisschen zu schnell hintereinander. Ich vermute daher, dass da einiges in irgendeinem Puffer steckt. Natürlich kennen wir den Gerätetyp immer noch nicht und es wird nochmal die 68er Message rausgehauen.
15:53:09.291: Das ist die Antwort zur 68er-Nachricht. Das Gerät sagt uns, dass es Typ 0x15 hat, also ein HMW-LC-Bl1-DR. Das hat jetzt über 200ms gedauert, aber das ist bei HMW noch im Rahmen, zumal noch ein paar andere Nachrichten dazwischenkamen.
15:53:09.291 Device 00013381 not defined yet...: Jetzt kommt der nächste Schritt: Die Zentrale will die Seriennummer haben und schickt daher eine 6E-Message raus. (Bzw. die Nachricht wird in die Queue geschrieben.) Das ist ok und ganz normal.
15:53:09.294: Die zweite (oder dritte) 68er-Nachricht wird rausgeschickt. Im Prinzip würden wir eine 6E erwarten, aber zuerst einmal werden die anderen Nachrichten, die noch in der Queue stehen abgearbeitet. Das ist normal.
Danach endet leider das Log. Bis an diese Stelle ist alles einigermaßen normal und sieht so aus, als ob es im Endeffekt erfolgreich werden sollte.
Im Log vom HM485d sieht man noch ein bisschen mehr:
15:53:09.360: Das Device antwortet auf die nächste 68er-Meldung.
15:53:09.433: ...und nochmal dasselbe.
15:53:09.439: Hier kommt noch eine 68er von der Zentrale
15:53:09.506: Hier kommen zwei "dup frames". Möglicherweise hat das Device die ACKs von der Zentrale nicht mitbekommen (15:53:09.435). Das dürfte aber auch nicht wirklich schlimm sein.
15:53:09.641: Nochmal eine 68 von der Zentrale und danach die Antwort darauf.
Also so wirklich sehe ich da keinen Fehler. Das läuft alles ganz normal. Es ist halt ein bisschen langsam, weil die 69er-Meldungen dazwischenkommen. Das müsste sich aber eigentlich mit der Zeit beruhigen.
Ich glaube auch nicht, dass da im Docker- oder sonstigem Setup was falsch ist. Die Kommunikation funktioniert ja im Prinzip.
Ich würde vorschlagen: FHEM nochmal durchstarten und warten, bis sich im Log (also im normalen FHEM-Log) nichts mehr tut. Dann mal eine Taste kurz auf einem Rolloaktor drücken. Dann etwas Geduld haben und weiterhin das FHEM-Log beobachten. Dabei keine Tasten mehr drücken.
Vergiss auch erst einmal den Discovery-Modus. Damit hatte ich bisher auch nur mäßigen Erfolg.
Das Attribut autoReadConfig sollte außerdem auf atstartup stehen oder einfach gar nicht gesetzt sein. Ansonsten kann es passieren, dass sich das System bei Verbindungsproblemen mit sich selbst beschäftigt.
...und noch eine ganz blöde Frage: Autocreate ist aktiv?
Gruß,
Thorsten
Hallo Thorsten,
besten Dank für die sehr gute Erklärung wie die Kommunikation funktioniert. Warum es so lange daueert, bis die Device gefunden werden ist mir nicht ganz klar. Anhand Deiner Erklärung mit dem Puffer habe ich das Gateway in Verdacht, da dort tatsächlich für eine ModBus RTU-Kommunikation ein Puffer eingestellt werden kann. Ob der auch im Durchleitungskodus aktiv ist, wird nicht beschrieben und ich habe ihn vorsorglich deaktiviert.
Ich habe dann das Gateway auf dem Raspi installiert, auf dem auch die piVCCU läuft (wollte alle HM-Wired Komponenten wenigstens auf dem selben Raspi haben) mit dem Erfolg, dass der RPC-Server in Docker nicht mehr richtig lief. Diese Meldung kommt im Haupt-FHEM in Docker:
2022.12.23 16:04:31.939 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] CCU interface BidCos-Wired doesn't support RPC multicalls
2022.12.23 16:04:31.939 1: HMCCURPCPROC [d_rpc178109BidCos_Wired] Initialized version 5.0 222930908 for interface BidCos-Wired with I/O device myHMCCU3
2022.12.23 16:04:31.949 2: HMCCURPCPROC [d_rpc178109BidCos_RF] CCU interface BidCos-RF supports RPC multicalls
2022.12.23 16:04:31.949 1: HMCCURPCPROC [d_rpc178109BidCos_RF] Initialized version 5.0 222930908 for interface BidCos-RF with I/O device myHMCCU3
2022.12.23 16:04:31.967 2: HMCCURPCPROC [d_rpc178109HmIP_RF] CCU interface HmIP-RF doesn't support RPC multicalls
2022.12.23 16:04:31.967 1: HMCCURPCPROC [d_rpc178109HmIP_RF] Initialized version 5.0 222930908 for interface HmIP-RF with I/O device myHMCCU3
2022.12.23 16:04:31.982 2: HMCCURPCPROC [d_rpc178109VirtualDevices] CCU interface VirtualDevices doesn't support RPC multicalls
2022.12.23 16:04:31.982 1: HMCCURPCPROC [d_rpc178109VirtualDevices] Initialized version 5.0 222930908 for interface VirtualDevices with I/O device myHMCCU3
2022.12.23 16:04:31.983 1: Including ./log/fhem.save
2022.12.23 16:04:32.956 0: HMCCU [myHMCCU3] Scheduling post FHEM initialization tasks in 12 seconds
2022.12.23 16:04:44.957 1: HMCCU [myHMCCU3] Reading device config from CCU. This may take a couple of seconds ...
2022.12.23 16:04:51.907 2: HMCCURPCPROC [d_rpc178109VirtualDevices] RPC server process started for interface VirtualDevices with PID=8833
2022.12.23 16:04:51.910 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Initializing RPC server CB9292000002178109 for interface VirtualDevices
2022.12.23 16:04:51.911 1: HMCCURPCPROC [d_rpc178109VirtualDevices] RPC server starting
2022.12.23 16:04:51.919 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server process started for interface BidCos-Wired with PID=8834
2022.12.23 16:04:51.922 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Initializing RPC server CB2000000002178109 for interface BidCos-Wired
2022.12.23 16:04:51.923 1: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server starting
2022.12.23 16:04:51.931 2: HMCCURPCPROC [d_rpc178109BidCos_RF] RPC server process started for interface BidCos-RF with PID=8835
2022.12.23 16:04:51.935 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Initializing RPC server CB2001000002178109 for interface BidCos-RF
2022.12.23 16:04:51.935 1: HMCCURPCPROC [d_rpc178109BidCos_RF] RPC server starting
2022.12.23 16:04:51.936 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Callback server CB9292000002178109 created. Listening on port 14702
2022.12.23 16:04:51.937 2: HMCCURPCPROC [d_rpc178109VirtualDevices] CB9292000002178109 accepting connections. PID=8833
2022.12.23 16:04:51.943 2: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server process started for interface HmIP-RF with PID=8836
2022.12.23 16:04:51.947 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Initializing RPC server CB2010000002178109 for interface HmIP-RF
2022.12.23 16:04:51.948 1: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server starting
2022.12.23 16:04:51.949 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Callback server CB2000000002178109 created. Listening on port 7410
2022.12.23 16:04:51.950 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] CB2000000002178109 accepting connections. PID=8834
2022.12.23 16:04:51.959 2: HMCCURPCPROC [d_rpc178109VirtualDevices] RPC server CB9292000002178109 enters server loop
2022.12.23 16:04:51.960 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Registering callback http://172.17.0.2:14702/fh9292 of type A with ID CB9292000002178109 at http://192.168.178.109:9292/groups
2022.12.23 16:04:51.960 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Callback server CB2001000002178109 created. Listening on port 7411
2022.12.23 16:04:51.961 2: HMCCURPCPROC [d_rpc178109BidCos_RF] CB2001000002178109 accepting connections. PID=8835
2022.12.23 16:04:51.970 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Callback server CB2010000002178109 created. Listening on port 7420
2022.12.23 16:04:51.971 2: HMCCURPCPROC [d_rpc178109HmIP_RF] CB2010000002178109 accepting connections. PID=8836
2022.12.23 16:05:01.979 1: HMCCURPCPROC [d_rpc178109VirtualDevices] RPC server CB9292000002178109 running
2022.12.23 16:05:02.103 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server CB2000000002178109 enters server loop
2022.12.23 16:05:02.104 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://172.17.0.2:7410/fh2000 of type A with ID CB2000000002178109 at http://192.168.178.109:2000
2022.12.23 16:05:02.117 1: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server CB2000000002178109 running
2022.12.23 16:05:02.131 2: HMCCURPCPROC [d_rpc178109BidCos_RF] RPC server CB2001000002178109 enters server loop
2022.12.23 16:05:02.131 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Registering callback http://172.17.0.2:7411/fh2001 of type A with ID CB2001000002178109 at http://192.168.178.109:2001
2022.12.23 16:05:02.141 1: HMCCURPCPROC [d_rpc178109BidCos_RF] RPC server CB2001000002178109 running
2022.12.23 16:05:02.142 1: HMCCURPCPROC [d_rpc178109BidCos_RF] Scheduled CCU ping every 300 seconds
2022.12.23 16:05:02.151 2: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server CB2010000002178109 enters server loop
2022.12.23 16:05:02.152 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Registering callback http://172.17.0.2:7420/fh2010 of type A with ID CB2010000002178109 at http://192.168.178.109:2010
2022.12.23 16:05:02.168 1: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server CB2010000002178109 running
2022.12.23 16:05:02.169 1: HMCCU [myHMCCU3] All RPC servers running
2022.12.23 16:05:02.325 2: AttrTemplates: got 282 entries
2022.12.23 16:14:52.857 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Received no events from interface CB2001000002178109 for 600.895588159561 seconds
2022.12.23 16:14:52.859 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Registering callback http://172.17.0.2:7411/fh2001 of type A with ID CB2001000002178109 at http://192.168.178.109:2001
2022.12.23 16:14:52.868 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Registering callback http://172.17.0.2:7420/fh2010 of type A with ID CB2010000002178109 at http://192.168.178.109:2010
2022.12.23 16:14:52.886 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Registering callback http://172.17.0.2:14702/fh9292 of type A with ID CB9292000002178109 at http://192.168.178.109:9292/groups
2022.12.23 16:15:02.904 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://172.17.0.2:7410/fh2000 of type A with ID CB2000000002178109 at http://192.168.178.109:2000
Die CCU3 in piVCCU läuft und ich kann von dort auf die Device (Aktoren...) zugreifen.
So ein Mist. Das überschaubare Problem mit dem Gateway hat jetzt mein halbes System lahmgelegt. Jetzt muss ich versuchen, das System wieder zum Laufen zu bringen.
Hast Du eine Idee, wo anfangen? HMCCU in FHEM neu installieren oder die piVCCU neu aufsetzen?
Gruß Jürgen
Habe folgenden Unterwschied in den Log-Dateien zu früher gefunden:
Wenn der RPC-Server ordnungsgemäß startet steht im Log:
2021.12.06 09:42:23.323 2: HMCCURPCPROC [d_rpc178109VirtualDevices] RPC server CB9292178092178109 enters server loop
2021.12.06 09:42:23.326 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Registering callback http://192.168.178.92:14702/fh9292 of type A with ID CB9292178092178109 at http://192.168.178.109:9292/groups
2021.12.06 09:42:23.477 2: HMCCURPCPROC [d_rpc178109VirtualDevices] CB9292178092178109 NewDevice received 8 device and channel specifications
2021.12.06 09:42:33.536 1: HMCCURPCPROC [d_rpc178109VirtualDevices] RPC server CB9292178092178109 running
2021.12.06 09:42:35.380 3: CUL_HM set Ga_UmweltSen getConfig noArg
2021.12.06 09:42:38.109 2: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server CB2010178092178109 enters server loop
2021.12.06 09:42:38.112 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Registering callback http://192.168.178.92:7420/fh2010 of type A with ID CB2010178092178109 at http://192.168.178.109:2010
2021.12.06 09:42:38.331 1: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server CB2010178092178109 running
2021.12.06 09:42:38.904 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server CB2000178092178109 enters server loop
2021.12.06 09:42:38.907 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://192.168.178.92:7410/fh2000 of type A with ID CB2000178092178109 at http://192.168.178.109:2000
2021.12.06 09:42:39.154 1: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server CB2000178092178109 running
2021.12.06 09:42:39.463 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] CB2000178092178109 NewDevice received 106 device and channel specifications
2021.12.06 09:42:39.583 2: HMCCURPCPROC [d_rpc178109HmIP_RF] CB2010178092178109 NewDevice received 148 device and channel specifications
2021.12.06 09:42:39.818 2: HMCCURPCPROC [d_rpc178109BidCos_RF] RPC server CB2001178092178109 enters server loop
2021.12.06 09:42:39.821 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Registering callback http://192.168.178.92:7411/fh2001 of type A with ID CB2001178092178109 at http://192.168.178.109:2001
2021.12.06 09:42:40.057 1: HMCCURPCPROC [d_rpc178109BidCos_RF] RPC server CB2001178092178109 running
2021.12.06 09:42:40.120 2: HMCCURPCPROC [d_rpc178109BidCos_RF] CB2001178092178109 NewDevice received 52 device and channel specifications
2021.12.06 09:42:40.236 1: HMCCU [myHMCCU3] All RPC servers running
Jetzt steht im Log:
2022.12.23 16:05:02.103 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server CB2000000002178109 enters server loop
2022.12.23 16:05:02.104 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://172.17.0.2:7410/fh2000 of type A with ID CB2000000002178109 at http://192.168.178.109:2000
2022.12.23 16:05:02.117 1: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server CB2000000002178109 running
2022.12.23 16:05:02.131 2: HMCCURPCPROC [d_rpc178109BidCos_RF] RPC server CB2001000002178109 enters server loop
2022.12.23 16:05:02.131 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Registering callback http://172.17.0.2:7411/fh2001 of type A with ID CB2001000002178109 at http://192.168.178.109:2001
2022.12.23 16:05:02.141 1: HMCCURPCPROC [d_rpc178109BidCos_RF] RPC server CB2001000002178109 running
2022.12.23 16:05:02.142 1: HMCCURPCPROC [d_rpc178109BidCos_RF] Scheduled CCU ping every 300 seconds
2022.12.23 16:05:02.151 2: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server CB2010000002178109 enters server loop
2022.12.23 16:05:02.152 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Registering callback http://172.17.0.2:7420/fh2010 of type A with ID CB2010000002178109 at http://192.168.178.109:2010
2022.12.23 16:05:02.168 1: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server CB2010000002178109 running
2022.12.23 16:05:02.169 1: HMCCU [myHMCCU3] All RPC servers running
Die IP des callback ist anderst, aber wo wird die eingestellt?
Hi,
ich glaube, die CCU kann nicht mehr als ein Gateway. Möglicherweise findet die CCU den HM485-Daemon, da der für eine CCU praktisch genauso aussieht wie das originale eq3-Gateway. Allerdings kenne ich mich mit der CCU nicht aus, kann also nicht wirklich helfen.
Gruß,
Thorsten
Laut Doku kann die CCU nur ein Wired-Gateway, höchstens zusätzlich noch IP-gateways.
Habe jetzt alles zum Waveshare-Gateway gelöscht, die piVCCU auf dem Raspi neu aufgesetzt und in FHEM den callback-port, der früher eingestellt war, als attr rpcServerAddr eingegeben und anschließend den Docker-Container neu gestartet. Jetzt läuft die Initialisierung fehlerfrei durch und es werden auch die Werte von der CCU gezogen, aber nur beim Start. Danach kommen keine Werte mehr an.
2022.12.23 17:41:55.442 1: HMCCURPCPROC [d_rpc178109VirtualDevices] RPC server CB9292000002178109 running
2022.12.23 17:41:55.561 2: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server CB2010000002178109 enters server loop
2022.12.23 17:41:55.562 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Registering callback http://192.168.178.92:7420/fh2010 of type A with ID CB2010000002178109 at http://192.168.178.109:2010
2022.12.23 17:41:55.582 1: HMCCURPCPROC [d_rpc178109HmIP_RF] RPC server CB2010000002178109 running
2022.12.23 17:41:55.586 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server CB2000000002178109 enters server loop
2022.12.23 17:41:55.587 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://192.168.178.92:7410/fh2000 of type A with ID CB2000000002178109 at http://192.168.178.109:2000
2022.12.23 17:42:00.871 1: HMCCURPCPROC [d_rpc178109BidCos_Wired] RPC server CB2000000002178109 running
2022.12.23 17:42:00.872 1: HMCCU [myHMCCU3] All RPC servers running
2022.12.23 17:45:22.225 2: AttrTemplates: got 282 entries
2022.12.23 17:51:39.907 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Received no events from interface CB2001000002178109 for 600.889363050461 seconds
2022.12.23 17:51:39.909 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Registering callback http://192.168.178.92:7420/fh2010 of type A with ID CB2010000002178109 at http://192.168.178.109:2010
2022.12.23 17:51:39.928 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Registering callback http://192.168.178.92:14702/fh9292 of type A with ID CB9292000002178109 at http://192.168.178.109:9292/groups
2022.12.23 17:51:49.948 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Registering callback http://192.168.178.92:7411/fh2001 of type A with ID CB2001000002178109 at http://192.168.178.109:2001
2022.12.23 17:51:55.591 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://192.168.178.92:7410/fh2000 of type A with ID CB2000000002178109 at http://192.168.178.109:2000
2022.12.23 18:01:40.782 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Received no events from interface CB2001000002178109 for 600.874435186386 seconds
2022.12.23 18:01:40.784 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Registering callback http://192.168.178.92:14702/fh9292 of type A with ID CB9292000002178109 at http://192.168.178.109:9292/groups
2022.12.23 18:01:50.805 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Registering callback http://192.168.178.92:7420/fh2010 of type A with ID CB2010000002178109 at http://192.168.178.109:2010
2022.12.23 18:01:50.829 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Registering callback http://192.168.178.92:7411/fh2001 of type A with ID CB2001000002178109 at http://192.168.178.109:2001
2022.12.23 18:01:56.391 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://192.168.178.92:7410/fh2000 of type A with ID CB2000000002178109 at http://192.168.178.109:2000
2022.12.23 18:11:41.646 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Received no events from interface CB2001000002178109 for 600.864061832428 seconds
2022.12.23 18:11:41.648 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Registering callback http://192.168.178.92:7411/fh2001 of type A with ID CB2001000002178109 at http://192.168.178.109:2001
2022.12.23 18:11:47.911 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://192.168.178.92:7410/fh2000 of type A with ID CB2000000002178109 at http://192.168.178.109:2000
2022.12.23 18:11:54.151 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Registering callback http://192.168.178.92:7420/fh2010 of type A with ID CB2010000002178109 at http://192.168.178.109:2010
2022.12.23 18:11:54.170 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Registering callback http://192.168.178.92:14702/fh9292 of type A with ID CB9292000002178109 at http://192.168.178.109:9292/groups
Liegt das Problem nun auf dem Raspi mit der CCU (piVCCU) oder in FHEM am rpc-Server?
Noch eine grundsätzliche Frage zum Verständniss:
Wenn ich eine CCU (hier auf piVCCU) nutze, benötige ich dann in FHEM noch den HM485-Dämon? Muss ein Device HM485_LAN, das auf die CCU zeigt, vorhanden sein oder reicht der rpc-Server, der auf
die CCU zeigt aus?
Wie komme ich wieder zu einem funktionierenden System?
Grüße Jürgen
Zitat von: bmwfan am 23 Dezember 2022, 18:24:25
Noch eine grundsätzliche Frage zum Verständniss:
Wenn ich eine CCU (hier auf piVCCU) nutze, benötige ich dann in FHEM noch den HM485-Dämon?
Nur wenn Du ein "dummes" Gateway nutzen willst. Mit dem eq3-Teil nicht.
Zitat
Muss ein Device HM485_LAN, das auf die CCU zeigt, vorhanden sein oder reicht der rpc-Server, der auf
die CCU zeigt aus?
HM485_LAN braucht man nur, wenn man auch das FHEM-Modul HM485 verwenden will. Wenn man eine CCU hat, dann ist das wahrscheinlich nicht so gut, da sich da das HM485_LAN mit dem Gateway verbinden will.
Was Du mit "das auf die CCU zeigt" meinst verstehe ich nicht.
Zitat
Wie komme ich wieder zu einem funktionierenden System?
Tja, wie gesagt kann ich zu den CCU-Problemen nicht viel sagen. Wenn Du jetzt am Anfang stehen würdest, dann würde ich sagen: Kauf Dir das serielle Digitus-Teil und häng es an den RasPi (oder was auch immer) und mach alles über FHEM. Dann könnte ich Dir vielleicht weiterhelfen, wenn das nicht klappt.
Für das OG: Wenn es geht, dann die RS485-Leitungen über das Netzwerkkabel laufen lassen. Bei mir geht das, da ich genügend CAT7 verbaut habe und alles über Patchpanel läuft. Wenn das nicht geht, dann einen kleinen RasPi mit Digitus-Stick nehmen und den Daemon darauf laufen lassen. Den kann man dann mit einem zweiten HM485_LAN in FHEM ansprechen. FHEM kann nämlich mehrere Gateways...
Gruß,
Thorsten
Ich werde das Vorhaben mit dem Waveshare-GW für das HM-Wired begraben. Ich habe zwar Daten bekommen, aber habe mir auch einiges zerschossen und weis nicht warum. Da ich noch eine ganze Reihe Messgeräte (z.B. Calep Wärmemengenzähler etc.) habe, die über ModBus kommunizieren und deren Daten ich auch in FHEM haben will, werde ich versuchen es da einzusetzen.
Für HM-Wired im OG prüfe ich zuerst, ob ich eine Datenleitung vom UV im EG zum UV im OG habe (sollte laut Vorgabe an den Elektriker eines für eine EIB-Verdrahtung liegen). Wenn ja, versuche ich die zu nutzen und alles auf den RS485-Bus des bestehenden Homematic LAN-Gateways im EG zu legen.
Wenn das nicht gehen sollte werde ich einen Digitus USB-RS485 Adapter im OG installieren. Gibt es da zum Raspi günstigere Alternativen? Ein Raspi ist doch sehr überdimensioniert für diese Aufgabe.
Zu Deinen Fragen:
ZitatWas Du mit "das auf die CCU zeigt" meinst verstehe ich nicht.
Der Homematic HM-LAN ist mit der CCU auf der piVCCU verbunden. In FHEM im Docker-Container läuft das Modul HMCCU und der/die RPC-Server, die mit unterschiedlichen Protokollen (BidCos-RF, Wired...) die CCU ansprechen (so mein Verständnis). In diesem FHEM ist kein HM_LAN-Modul definiert, daher vermute ich dass auch kein HM485d-Dämon läuft. Meine Frage war, ob ich zur Verbindung mit der CCU im FHEM zu den RPC-Servern auch einen HM485-Dämon benötige.
Grüße
Jürgen
Zitat von: bmwfan am 24 Dezember 2022, 10:01:42
Für HM-Wired im OG prüfe ich zuerst, ob ich eine Datenleitung vom UV im EG zum UV im OG habe (sollte laut Vorgabe an den Elektriker eines für eine EIB-Verdrahtung liegen). Wenn ja, versuche ich die zu nutzen und alles auf den RS485-Bus des bestehenden Homematic LAN-Gateways im EG zu legen.
Wie gesagt, bei mir läuft das über die CAT7-Verkabelung. Ich hatte von Anfang an ein paar mehr Netzwerkkabel reingelegt. Darüber sind die RS485-Netze der einzelnen Stockwerke verbunden. Nur die Stromversorgung hat jedes Stockwerk nochmal selbst. (Natürlich ist V+ nicht verbunden.)
Zitat
Wenn das nicht gehen sollte werde ich einen Digitus USB-RS485 Adapter im OG installieren. Gibt es da zum Raspi günstigere Alternativen? Ein Raspi ist doch sehr überdimensioniert für diese Aufgabe.
Naja, man braucht halt was, auf dem Perl läuft und was einen USB-Port hat. Ein Pi Zero oder ein alter Pi 1 müsste es da schon tun. Theoretisch müsste man das ganze auch auf einen Mikroprozessor portieren können, also Arduino oder so. Das wäre aber nochmal einiges an Entwicklungsarbeit.
Zitat
Zu Deinen Fragen:Der Homematic HM-LAN ist mit der CCU auf der piVCCU verbunden. In FHEM im Docker-Container läuft das Modul HMCCU und der/die RPC-Server, die mit unterschiedlichen Protokollen (BidCos-RF, Wired...) die CCU ansprechen (so mein Verständnis). In diesem FHEM ist kein HM_LAN-Modul definiert, daher vermute ich dass auch kein HM485d-Dämon läuft. Meine Frage war, ob ich zur Verbindung mit der CCU im FHEM zu den RPC-Servern auch einen HM485-Dämon benötige.
Nein, das braucht man nicht. Der HM485-Dämon "simuliert" ja sozusagen den HMW-LGW-O-DR-GS-EU. Wenn Du den aber sowieso schon hast, dann erübrigt sich das natürlich.
(Es müsste möglich sein, der CCU ein HMW-LGW-O-DR-GS-EU vorzugaukeln, obwohl das RS485-Netzwerk über den Digitus-Adapter angeschlossen ist. Das willst Du aber offenbar nicht.)
Gruß,
Thorsten
Was mir beim durchlesen so aufgefallen ist:
2022.12.23 16:05:02.104 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://172.17.0.2:7410/fh2000 of type A with ID CB2000000002178109 at http://192.168.178.109:2000
172.17.0.2 ist normalerweise eine IP eines Docker-Containers. Dein Netzwerk hat bestimmt die IP-Range 192.168.178,X (und Du hast bestimmt eine FritzBox)
Da Du bestimmt den RPC-Port für den Docker-Container definiert hast, must Du dem HMCCU auch die IP des Docker-Host (hier Deine NAS?) mitgeben.
Stichwort: rpcserveraddr
Habe jetzt nicht gesehen, das es eingetragen wurde ... kann abr auch sein, das ich es übersehen habe. Dein Beitrag: Nach dem booten kommt nichts mehr, hört sich dńach dem Problem an.
@Wernieman:
Fritzbox ist korrekt, ebenso der Adressraum.
Hatte im Log den callback auf die Adresse 172.17.0.2, die ich nicht kannte, gesehen.
2022.12.23 16:04:51.960 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Registering callback http://172.17.0.2:14702/fh9292 of type A with ID CB9292000002178109 at http://192.168.178.109:9292/groups
Nachdem ich in alten Log-Dateien, bevor das Problem entstanden ist, gesehen habe, dass dort der callback auf
2022.12.23 17:51:39.928 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Registering callback http://192.168.178.92:14702/fh9292 of type A with ID CB9292000002178109 at http://192.168.178.109:9292/groups
lief, habe ich bei den 4 Devices HMCCURPCPROC als rpcserveraddr die Adresse von vor dem Problem, also die 192.168.178.92, eingegeben. Hat das Problem aber nicht gelöst und kann es auch nicht, wie ich gerade sehe, da diese IP in der Fritzbox gar nicht mehr vergeben ist. Keine Ahnung mehr, was das für ein Device war. Üblicherweise stelle ich die IP-Adresse auf statisch, nachdem über DHCP ein neues Device gefunden wurde. Hier aber scheinbar nicht. :-(
Dann lege ich die rpcserveraddr auf das NAS und damit ist das Problem scheinbar gelöst. Nach über 10 Minuten keine Meldung über ausbleibende Events. :)
Besten Dank für die Hilfe.
Grüße Jürgen
Du musst es "nur" im globalem HMDevice setzen und nicht in den einzelnen "RPC-Servern" ......
Verstehe irgendwie Dein Beitrag nicht .. ist Dir klar, warum es jetzt funktioniert?
Habe vermutlich etwas zusammenhanglos gepostet.
Als ich nach der missglückten Aktion mit dem Waveshare-Gateway plötzlich die regelmäßigen Meldungen (alle 10 Minuten) des callback im Log hatte
2022.12.23 16:14:52.857 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Received no events from interface CB2001000002178109 for 600.895588159561 seconds
2022.12.23 16:14:52.859 2: HMCCURPCPROC [d_rpc178109BidCos_RF] Registering callback http://172.17.0.2:7411/fh2001 of type A with ID CB2001000002178109 at http://192.168.178.109:2001
2022.12.23 16:14:52.868 2: HMCCURPCPROC [d_rpc178109HmIP_RF] Registering callback http://172.17.0.2:7420/fh2010 of type A with ID CB2010000002178109 at http://192.168.178.109:2010
2022.12.23 16:14:52.886 2: HMCCURPCPROC [d_rpc178109VirtualDevices] Registering callback http://172.17.0.2:14702/fh9292 of type A with ID CB9292000002178109 at http://192.168.178.109:9292/groups
2022.12.23 16:15:02.904 2: HMCCURPCPROC [d_rpc178109BidCos_Wired] Registering callback http://172.17.0.2:7410/fh2000 of type A with ID CB2000000002178109 at http://192.168.178.109:2000, habe ich versucht herauszufinden, was sich in der Verbindung zur CCU (auf der piVCCU mit Adresse 192.168.178.109) verändert hat. Habe dazu das akteulle Log mit einem älteren Log verglichen, bei dem diese Meldung nicht kam.
Der Unterschied lag in der Callback-Adresse, die dort eine Adresse, die 192.168.178.92, aus meinem Adressraum war. Dann habe ich im Forum recherchiert und gefunden, dass ich diese Adresse als rpcserveraddr festlegen kann und habe das dann bei den HMCCURPCPROC-Device getan. Hat das Problem aber nicht gelöst und erst durch Deinen Post habe ich erfahren, dass dort die Adresse des NAS eingetragen werden muss. Werde es jetzt noch im HMDevice (hier: myHMCCU3, siehe List) setzen.
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPCPROC:
DEF 192.168.178.109 ccudelay=180
FUUID 6196849f-f33f-d125-5cc6-946542907ac2c676
NAME myHMCCU3
NOTIFYDEV global
NR 46
NTFY_ORDER 50-myHMCCU3
RPCState running
STATE running/OK
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 300
ccudevices 23
ccuif BidCos-RF
ccuinterfaces BidCos-RF,BidCos-Wired,HmIP-RF,VirtualDevices
ccuip 192.168.178.109
ccuname HM-RCV-50 BidCoS-RF
ccustate active
ccutype CCU2/3
config 5.0
eventCount 16
firmware 3.65.8
host 192.168.178.109
prot http
version 5.0 222930908
READINGS:
2022-12-24 11:54:33 PLATFORM rpi3
2022-12-24 11:54:33 PRODUCT ccu3
2022-12-24 11:54:33 VERSION 3.65.8
2022-12-24 11:54:33 count_channels 300
2022-12-24 11:54:33 count_devices 23
2022-12-24 11:54:33 count_groups 0
2022-12-24 11:54:33 count_interfaces 4
2022-12-24 11:54:33 count_programs 0
2022-12-25 10:41:51 rpcstate running
2022-12-25 10:41:51 state OK
hmccu:
ccuDevList "HM-RCV-50#BidCoS-RF","HMW-RCV-50#BidCoS-Wir","HMW-Sen-SC-12-DR#LEQ0439520","HmIP-RCV-50#HmIP-RCV-1",Alarm-KueOst-HmIP,Alarm-KueSued-HmIP,Alarm-WZ-Hm,Heiz-AZ-HmIP,Heiz-Andreas-HmIP,Heiz-BadOG-Handtuch-HmIP,Heiz-BadOG-HmIP,Heiz-Bib-HmIP,Heiz-Kue-HmIP,Heiz-WZ-HmIP,Jal-Kue-Fenster,Jal-Kue-Sued,Jal-Kue-Tuer-Ost,Jal-WZ-Fest-Ost,Jal-WZ-Fest-Sued,Jal-WZ-Fest-Suedwest,Jal-WZ-Fest-West,Jal-WZ-Schiebetuer,Licht-BadOG-Spiegel-HmIP
ccuSuppDevList "HMW-RCV-50#BidCoS-Wir","HMW-Sen-SC-12-DR#LEQ0439520",Alarm-KueOst-HmIP,Alarm-KueSued-HmIP,Alarm-WZ-Hm,Heiz-AZ-HmIP,Heiz-Andreas-HmIP,Heiz-BadOG-Handtuch-HmIP,Heiz-BadOG-HmIP,Heiz-Bib-HmIP,Heiz-Kue-HmIP,Heiz-WZ-HmIP,Jal-Kue-Fenster,Jal-Kue-Sued,Jal-Kue-Tuer-Ost,Jal-WZ-Fest-Ost,Jal-WZ-Fest-Sued,Jal-WZ-Fest-Suedwest,Jal-WZ-Fest-West,Jal-WZ-Schiebetuer,Licht-BadOG-Spiegel-HmIP
defaults 0
evtime 0
evtimeout 0
postInit 0
rpccount 0
rpcports 2010,9292,2001,2000
updatetime 0
adr:
Alarm-KueOst-HmIP:
address 00109BE989D89B
addtype dev
valid 1
.
.
.
Attributes:
ccuReqTimeout 6
ccudef-attributes 9.6.0_System
ccudef-substitute AES_KEY!(0|false):off,(1|true):on;;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;;UNREACH!(0|false):alive,(1|true):dead;;MOTION!(0|false):noMotion,(1|true):motion;;DIRECTION!0:stop,1:up,2:down,3:undefined;;WORKING!0:false,1:true;;INHIBIT!(0|false):unlocked,(1|true):locked
ccuflags procrpc,nonBlocking,reconnect
cmdIcon on:general_an off:general_aus
room 9.6.0_System
rpcinterfaces BidCos-Wired,VirtualDevices,HmIP-RF,BidCos-RF
rpcserver on
rpcserveraddr 192.168.178.5
stateFormat rpcstate/state
verbose 1.
Zitat... Dir klar, warum es jetzt funktioniert?
Ich habe verstanden, dass die Adresse für den Callback falsch war. Was das System verbogen hat, da es vorher ja auch ohne Angabe der rpcserveraddr funktioniert hat, weis ich nicht, will ich aber auch nicht nachstellen
Ebenso ist mir nicht klar, da ich die Kommunikation von FHEM mit der piVCCU nicht kenne, warum dieser callback benötigt wird.
Grüße Jürgen
Vereinfacht gesagt hat jeder Docker-Container eine IP. Du hast zwar den Port per Docker freigegegebn, fhem "sieht" aber nur diese Docker-IP und versucht sich damit bei der CCU zu registrieren, Kann natürlich nicht funktionieren. Durch die Festlegung mit rpcserveraddr teilst Du "manuell" HMCCU aber die richtige IP mit und voila ......
Läuft bisher wieder problemlos.
Danke an Alle.
Grüße Jürgen