[Gelöst] Waveshare RS485 to ETH Gateway anstatt HM-Wired RS485 LAN Gateway geht

[bmwfan]

Hallo,
da ich im OG auch Rolladenaktoren HMW-LC-Bl1-DR an meine Jalousien installieren will aber keine ModBus-Verbindung vom EG ins OG habe, benötige ich ein weiteres HMLAN-Gateway. Da vom Homematic RS485-GW abgeraten wird

Allerdings gab es mit dem HMW-LAN-GW in der Vergangenheit viele Probleme, so dass der Einsatz nicht empfohlen wird.

habe ich einen Waveshare RS485 to ETH (B) Gateway besorgt (Anleitung im Anhang). Leider bekomme ich das nicht zum Laufen.

Meine Konfiguration:
Raspberry 3B als Testhardware mit laufendem aktuellem FHEM.
HM_LAN nach Wiki https://wiki.fhem.de/wiki/Serial/Netzwerk-RS485-Adapter installiert.

Code Auswählen Erweitern

Internals:
   DEF        localhost:2000
   DeviceName localhost:2000
   FD         4
   FUUID      6399f5dc-f33f-6794-2eaa-bd09830029689131
   HM485d_CommandLine ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device 192.168.178.30:5000 --localPort 2000
   HM485d_PID  6144
   HM485d_STATE started
   InterfaceType HMW-SOFT-GW
   Last_Sent_RAW_CMD FFFFFFFF 98 00000001 5A
   NAME       Waveshare485
   NR         45
   PARTIAL   
   ProtokolVersion 01
   STATE      opened
   SerialNumber SGW0123456
   TYPE       HM485_LAN
   Version    0.2.2
   currentQueueId 0
   discoveryRunning 0
   eventCount 6
   hmwId      00000001
   msgCounter 47
   queueId    5
   queueRunning 0
   READINGS:
     2022-12-19 10:01:54   state           opened
   ctrl:
     FFFFFFFF   98
   keepalive:
     ok         1
     retry      0
   sendQueue:
Attributes:
   HM485d_bind 1
   HM485d_device 192.168.178.30:5000
   HM485d_serialNumber SGW0123456
   hmwId      00000001
   icon       lan_rs485
   room       RS485,9.6.0_System
   verbose    5

Das Gateway wurde mit der Konfigurationssoftware VirCom eingestellt (siehe Dateianhang VirCom_20221219_1121.jpg).
192.168.178.30 ist die IP des Gateways. Der Port kann scheinbar willkürlich gewählt werden und ich habe den 5000 genommen, da er in einem funktionierenden Beispiel im Forum genannt wurde.
Die Felder Dest.IP/Domain und Dest.Port. sind mir nicht klar. In einem Thread habe ich gelesen, dass die Angabe keine Auswirkung auf die Funktion hatte. Ich habe zur Sicherheit die IP des Raspberry mit dem HM485 Dämon angegeben.

Im Log fällt mir als allererstes auf, dass nach der Initialisierung keine HM485 Module geladen werden, wie es bei meinem laufenden Homematic-Gateway im Haupt-FHEM oder auch in Beispielen im Forum der Fall ist.

Das log nach einem Neustart:

Code Auswählen Erweitern

2022.12.19 10:20:37.589 1: Including ./log/fhem.save
2022.12.19 10:20:37.594 3: ModBus1: Notify / Init: device is disabled
2022.12.19 10:20:37.594 3: WP: Notify / Init: device is disabled
2022.12.19 10:20:37.594 3: Waveshare: Notify / Init: device is disabled
2022.12.19 10:20:37.594 3: Waveshare_Modbus: Notify / Init: device is disabled
2022.12.19 10:20:37.594 3: Waveshare_RTU: Notify / Init: device is disabled
2022.12.19 10:20:37.596 0: Featurelevel: 6.1
2022.12.19 10:20:37.596 0: Server started with 11 defined entities (fhem.pl:26868/2022-12-18 perl:5.028001 os:linux user:fhem pid:6221)
2022.12.19 10:20:37.634 3: Waveshare485: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device 192.168.178.30:5000 --localPort 2000
2022.12.19 10:20:37.667 3: Waveshare485: HM485d was started with PID:  6227
2022.12.19 10:20:37.667 3: Waveshare485: Connect to HM485d delayed for 5 seconds
2022.12.19 10:20:42.769 3: Opening Waveshare485 device localhost:2000
2022.12.19 10:20:42.782 3: Waveshare485: connected to device localhost:2000
2022.12.19 10:20:42.783 3: Waveshare485 device opened
2022.12.19 10:20:42.785 3: Waveshare485: Lan Device Information
2022.12.19 10:20:42.785 3: Waveshare485: Protocol-Version: 01
2022.12.19 10:20:42.786 3: Waveshare485: Interface-Type: HMW-SOFT-GW
2022.12.19 10:20:42.786 3: Waveshare485: Firmware-Version: 0.2.2
2022.12.19 10:20:42.786 3: Waveshare485: Serial-Number: SGW0123456
2022.12.19 10:20:42.787 5: Waveshare485: HM485_LAN_Write TX: 1
2022.12.19 10:20:42.787 3: Waveshare485: Initialize the interface
2022.12.19 10:20:42.787 5: DevIo_SimpleWrite Waveshare485: fd3e30312c303030300d0a
2022.12.19 10:21:02.792 5: Waveshare485: HM485_LAN_Write TX: 2
2022.12.19 10:21:02.793 5: DevIo_SimpleWrite Waveshare485: fd02024b
2022.12.19 10:21:02.795 5: Waveshare485: HM485_LAN_parseIncommingCommand: MsgId: 2 Cmd: 97
2022.12.19 10:21:02.796 5: Waveshare485: HM485_LAN_parseIncommingCommand: Alive: (2) 00 AliveStatus: 00
2022.12.19 10:21:06.808 5: Waveshare485: HM485_LAN_Write TX: 3
2022.12.19 10:21:06.809 5: Waveshare485: HM485_LAN_SendQueueNextItem: QID: 00000001
2022.12.19 10:21:06.810 5: DevIo_SimpleWrite Waveshare485: fd0d0353c8ffffffff98000000017a
2022.12.19 10:21:06.811 4: Waveshare485: Waveshare485: TX: (3) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2022.12.19 10:21:06.812 5: Waveshare485: HM485_LAN_Write TX: 4
2022.12.19 10:21:06.814 5: Waveshare485: HM485_LAN_Write TX: 5
2022.12.19 10:21:06.912 5: Waveshare485: HM485_LAN_CheckResendQueueItems: QID: 00000001
2022.12.19 10:21:06.913 5: Waveshare485: HM485_LAN_SendQueueNextItem: QID: 00000002
2022.12.19 10:21:06.913 5: DevIo_SimpleWrite Waveshare485: fd0d0453c8ffffffff98000000017a
2022.12.19 10:21:06.915 4: Waveshare485: Waveshare485: TX: (4) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2022.12.19 10:21:07.016 5: Waveshare485: HM485_LAN_CheckResendQueueItems: QID: 00000002
2022.12.19 10:21:07.016 5: Waveshare485: HM485_LAN_SendQueueNextItem: QID: 00000003
2022.12.19 10:21:07.016 5: DevIo_SimpleWrite Waveshare485: fd04054400ff
2022.12.19 10:21:07.681 5: Waveshare485: HM485_LAN_parseIncommingCommand: MsgId: 5 Cmd: 99
2022.12.19 10:21:07.682 4: Waveshare485: Do action after discovery Found Devices: 0
2022.12.19 10:21:07.682 5: Waveshare485: HM485_LAN_parseIncommingCommand: Removing Queue 00000003
2022.12.19 10:21:07.683 5: Waveshare485: HM485_LAN_Write TX: 6
2022.12.19 10:21:07.683 5: Waveshare485: HM485_LAN_SendQueueNextItem: QID: 00000004
2022.12.19 10:21:07.684 5: DevIo_SimpleWrite Waveshare485: fd0d0653c8ffffffff98000000015a
2022.12.19 10:21:07.685 4: Waveshare485: Waveshare485: TX: (6) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)

Die Device WP, Waveshare und Waveshare_RTU stammen von Versuchen, per Modul ModBus auf die Daten zuzugreifen. Hat auch nicht funktioniert und ich habe sie Disabled, um mit HM485d weiter zu machen.
Um 2022.12.19 10:21:06.808 habe ich einen set Waveshare485 discovery abgesetzt, aber keines der 3  angeschlossenen Device (Rolladenaktoren HMW-LC-Bl1-DR) wurde erkannt.

Ich habe schon alle möglichen Ports (502, 4196) durchprobiert, aber keinen Erfolg mit der Anbindung erzielen können.

Kann mir jemand der erfahrenen Nutzer einen Hinweis geben, woran es liegen könnte.

Grüße Jürgen

[bmwfan]

Durch viele Versuche endlich selber die Lösung gefunden. Scheinbar nutzen wenige ein Waveshare-GW auf RS485 für HM-Wired. Damit anderen Nutzern die langen Versuche erspart bleiben anbei meine Lösung.

Die Lösung waren die Einstellungen Work Mode= TCP-Server und Transfer Protocol= None in der VirCom-Software sowie die Eingabe der DevID aus der VirCom-Konfigurationssoftware in FHEM als HM485d_serialNumber (siehe List). Danach wurden Schritt für Schritt, allerdings erst nachdem der Bus einige Zeit lief, die Device gefunden. Beim 3.ten Rolladenaktor hat es ca. 2 Stunden gedauert, bis er plötzlich gefunden wurde. Betätigen der Tasten AUF / AB am Aktor beschleunigt das Ganze nicht. Der Bus ist ordnungsgemäß mit einem Widerstandsnetzwerk (Werte für Homematic, nicht für ModBus) abgeschlossen.

Code Auswählen Erweitern

Internals:
   DEF        localhost:2000
   DeviceName localhost:2000
   FD         15
   FUUID      6399f5dc-f33f-6794-2eaa-bd09830029689131
   HM485d_CommandLine ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000002 --serialNumber XXXXXXYYYYY --device 192.168.178.30:5000 --localPort 2000 --logfile HM485LogJG.log --verbose 5
   HM485d_PID   734
   HM485d_STATE started
   InterfaceType HMW-SOFT-GW
   LASTInputDev Waveshare485
   Last_Sent_RAW_CMD 00013381 18 00000002 52019010
   Last_Sent_RAW_CMD_State ACK
   MSGCNT     70
   NAME       Waveshare485
   NR         44
   PARTIAL   
   ProtokolVersion 01
   STATE      opened
   SerialNumber XXXXXXYYYYY
   TYPE       HM485_LAN
   Version    0.2.2
   Waveshare485_MSGCNT 70
   Waveshare485_TIME 2022-12-22 13:20:59
   currentQueueId 00000023
   eventCount 1
   hmwId      00000002
   msgCounter 37
   queueId    35
   queueRunning 1
   READINGS:
     2022-12-21 09:37:51   state           opened
   ctrl:
     00013381   18
     0001663D   1C
     00016A3B   1C
   keepalive:
     ok         1
     retry      0
   sendQueue:
     00000023:
       data       �$S�
3�R
�
       dataLog    Waveshare485: TX: (36) I[0](0,F,B)(18) 00000002 -> 00013381 [6] 52(R) 019010
       hmwId      00013381
       msgId      36
Attributes:
   HM485d_bind 1
   HM485d_device 192.168.178.30:5000
   HM485d_logVerbose 5
   HM485d_logfile HM485LogJG.log
   HM485d_serialNumber XXXXXXYYYYY
   autoReadConfig always
   comment    SGW0123456
   hmwId      00000002
   icon       lan_rs485
   room       RS485,9.6.0_System
   verbose    1

Da das System in einem Docker-Container laufen soll und die Installation auf dem Raspi nur zur Inbetriebnahme des Gateways gedacht war, musste das Gateway im Docker-Container in FHEM noch einmal konfiguriert werden. Dabei sind, wie nicht anders zu erwarten, weitere Probleme aufgetaucht, bei denen ich Hilfe benötige. Die werde ich aber in einem neuen Thread stellen.

Grüße Jürgen

[Thorsten Pferdekaemper]

Hi,
gut, dass es inzwischen klappt. Ich habe dazu trotzdem noch ein paar Bemerkungen.

Scheinbar nutzen wenige ein Waveshare-GW auf RS485 für HM-Wired.

Ich könnte mir vorstellen, dass Du der einzige bist. Inzwischen dürften die meisten einen primitiven RS485/USB-Adapter nehmen, der entweder direkt am FHEM-Rechner hängt oder an einem kleinen Raspi, auf dem der HM485-Daemon läuft. Das scheinen die stabilsten Lösungen zu sein.

Die Lösung waren die Einstellungen Work Mode= TCP-Server und Transfer Protocol= None in der VirCom-Software sowie die Eingabe der DevID aus der VirCom-Konfigurationssoftware in FHEM als HM485d_serialNumber (siehe List).

Das mit dem Server ist eigentlich klar und das mit dem Protokoll zumindest plausibel. Das mit der DevID verstehe ich nicht. Der HM485-Daemon verwendet das nur in Richtung FHEM. Das dürfte mit nichts anderem abgeglichen werden. Probleme kann es nur geben, wenn man ein zweites HM485-Gateway hat mit derselben serialNumber.

Danach wurden Schritt für Schritt, allerdings erst nachdem der Bus einige Zeit lief, die Device gefunden. Beim 3.ten Rolladenaktor hat es ca. 2 Stunden gedauert, bis er plötzlich gefunden wurde.

Da ist dann aber noch irgendwas anderes faul. Entweder da ist noch was anderes auf dem Bus los oder das Gateway taugt eben doch nichts. Ich könnte mir vorstellen, dass die "Keep Alive Time" was damit zu tun hat. Kann es sein, dass das Gateway regelmäßig "alive" Meldungen abschickt und darauf eine entsprechende Antwort erwartet oder sogar irgendeine regelmäßige Meldung erwartet? Kann man das deaktivieren (Keep Alive auf 0 oder so)?

Gruß,
    Thorsten

[bmwfan]

Hallo Thorsten,

Inzwischen dürften die meisten einen primitiven RS485/USB-Adapter nehmen, der entweder direkt am FHEM-Rechner hängt oder an einem kleinen Raspi, auf dem der HM485-Daemon läuft.

Das Gateway und die Aktoren sollen in den Unterverteiler im OG. Da ist zwar LAN-Anschluß vorhanden, aber noch kein Raspi. Ich dachte deswegen, dass es am einfachsten ist mit einem LAN / RS485 Gateway. So wie es sich herausgestellt hat doch nicht. 

Probleme kann es nur geben, wenn man ein zweites HM485-Gateway hat mit derselben serialNumber.

Ein HM-LAN von eq3 ist im EG schon installiert. Der hatte, bevor ich ihn über HMCCU und eine piVCCU3 angesprochen habe, am Raspi die hmwid 001 gehabt. Deswegen habe ich hier die hmwid 0002 genommen. Ich hatte, als ich die Standardbezeichnung (glaube SGW1234567) verwendet habe, nie eine Verbindung zum Gateway bekommen, erst als ich die Dev-ID des Gateways selber als Seriennummer eingegeben habe. Vielleicht haben sich aber auch Änderungen überschnitten und es liegt gar nicht an der Dev-ID.

oder das Gateway taugt eben doch nichts

Hatte in Amazon in einer Rezension gefunden, dass jemand mit FHEM einen Stromzähler ausgelesen hat. Deswegen war ich der Meinung, dass es damit auch für HM-Wired gehen sollte.

Ich könnte mir vorstellen, dass die "Keep Alive Time" was damit zu tun hat.

Da ist die Anleitung etwas unklar. Kann man, zumindest im TCP-Client Mode den ich ja aber nicht verwende. Für den TCP-Server Mode wird nichts ausgesagt. Im TCP-Client Mode kann man sie ausschalten wenn man sie auf 0 oder 255 (wird widersprüchlich genannt) setzt.

Kann man in den Messages erkennen, was solche Keep Alive-Messages sind? Ich schreibe ja das LOG des HM485d mit.

Gruß Jürgen

[Thorsten Pferdekaemper]

Ein HM-LAN von eq3 ist im EG schon installiert. Der hatte, bevor ich ihn über HMCCU und eine piVCCU3 angesprochen habe, am Raspi die hmwid 001 gehabt. Deswegen habe ich hier die hmwid 0002 genommen. Ich hatte, als ich die Standardbezeichnung (glaube SGW1234567) verwendet habe, nie eine Verbindung zum Gateway bekommen, erst als ich die Dev-ID des Gateways selber als Seriennummer eingegeben habe. Vielleicht haben sich aber auch Änderungen überschnitten und es liegt gar nicht an der Dev-ID.

Die hmwid hat mit der serialNumber erst einmal nichts zu tun. Wenn es zwei Gateways gibt, dann müssen die natürlich sowohl eine unterschiedliche hmwid als auch eine unterschiedliche serialNumber haben. Aber das ist auch schon alles. Ich habe gerade nochmal im Coding nachgsehen. Die serialNumber wird an den Client (also FHEM) geschickt, wenn dieser sich verbindet. Das ist alles.

Kann man in den Messages erkennen, was solche Keep Alive-Messages sind? Ich schreibe ja das LOG des HM485d mit.

Im Prinzip könnte man das wahrscheinlich. Man sieht halt nicht, wenn das Teil auf eine Meldung wartet.

Gruß,
   Thorsten

[Ralf9]

Deswegen habe ich hier die hmwid 0002 genommen

Ist in den angeschlossenen Rolladenaktoren auch als Zentrale die hmwid 0002 eingetragen?

Kann man in den Messages erkennen, was solche Keep Alive-Messages sind? Ich schreibe ja das LOG des HM485d mit.

Ja mit verbose 5 beim HM485_LAN.
z.B.

Code Auswählen Erweitern

2022.12.23 11:05:24.133 5 : HM485_LAN4: HM485_LAN_Write TX: 97
2022.12.23 11:05:24.133 5 : HM485_LAN4: TX:     614b   keepalive
2022.12.23 11:05:24.134 5 : DevIo_SimpleWrite HM485_LAN4: fd02614b
2022.12.23 11:05:24.136 5 : HM485_LAN4: RX: fd02616100
2022.12.23 11:05:24.136 5 : HM485_LAN4: HM485_LAN_parseIncommingCommand: MsgId: 97 Cmd: 97
2022.12.23 11:05:24.136 5 : HM485_LAN4: HM485_LAN_parseIncommingCommand: Alive: (97) 00 AliveStatus: 00
2022.12.23 11:05:44.140 5 : HM485_LAN4: HM485_LAN_Write TX: 98
2022.12.23 11:05:44.140 5 : HM485_LAN4: TX:     624b   keepalive
2022.12.23 11:05:44.140 5 : DevIo_SimpleWrite HM485_LAN4: fd02624b
2022.12.23 11:05:44.142 5 : HM485_LAN4: RX: fd02626100
2022.12.23 11:05:44.142 5 : HM485_LAN4: HM485_LAN_parseIncommingCommand: MsgId: 98 Cmd: 97
2022.12.23 11:05:44.142 5 : HM485_LAN4: HM485_LAN_parseIncommingCommand: Alive: (98) 00 AliveStatus: 00
2022.12.23 11:06:04.145 5 : HM485_LAN4: HM485_LAN_Write TX: 99
2022.12.23 11:06:04.145 5 : HM485_LAN4: TX:     634b   keepalive
2022.12.23 11:06:04.145 5 : DevIo_SimpleWrite HM485_LAN4: fd02634b
2022.12.23 11:06:04.147 5 : HM485_LAN4: RX: fd02636100
2022.12.23 11:06:04.147 5 : HM485_LAN4: HM485_LAN_parseIncommingCommand: MsgId: 99 Cmd: 97
2022.12.23 11:06:04.147 5 : HM485_LAN4: HM485_LAN_parseIncommingCommand: Alive: (99) 00 AliveStatus: 00

Gruß Ralf

[Mellowback]

Hallo zusammen,

ich habe mir auch ein Waveshare zugelegt und nach dieser Anleitung gearbeitet (Port: Waveshare auf 2000 statt 5000).

Code Auswählen Erweitern


Internals:
   DEF        localhost:2000
   FUUID      67a8e91c-f33f-2b59-129e-d274b2acc43078c5
   HM485d_CommandLine ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000002 --serialNumber 28760E2Dxxxx --device 192.168.2.197:2000 --localPort 2000
   Last_Sent_RAW_CMD FFFFFFFF 98 00000002 5A
   Last_Sent_RAW_CMD_State NACK
   NAME       hm485
   NR         945
   STATE     
   TYPE       HM485_LAN
   currentQueueId 0
   discoveryRunning 0
   eventCount 1
   hmwId      00000002
   msgCounter 5
   queueId    5
   queueRunning 0
   READINGS:
     2025-02-09 18:44:53   state           disconnected
   ctrl:
     FFFFFFFF   98
   sendQueue:
Attributes:
   HM485d_bind 1
   HM485d_device 192.168.2.197:2000
   HM485d_serialNumber 28760E2D5861
   hmwId      00000002
   room       Technikraum

[bmwfan]

Ich habe inzwischen für meine Rolläden eine einfachere Lösung mit den Shelly Dual Cover gefunden. Dabei muss ich weder die Schalter zu Tastern umbauen, noch eine LAN-Verbindung legen. Funktioniert sehr gut.

Daher verkaufe ich meine 3 Stück Homematic Wired RS485-Rollladenaktor, 1fach HMW-LC-Bl1-DR, wieder unbenutzt. Falls jemand Interesse hat: einfach PN an mich (hoffe die Info verstößt nicht gegen Forenregeln. Falls doch bitte Info, damit ich den Hinweis wieder lösche).

Grüße Jürgen