Usertreffen 2019 – Platine HB-RF-USB – Absetzen der Funkmodule über USB CAT Extender bis zu 15 Meter
Wir haben euch ja bereits in dem Artikel neue Platine HB-RF-USB zum Anschluss der Homematic Funkmodule via USB diese sehr interessante Platine beschrieben. Auf dem Heute zuende gegangenen Usertreffen 2019 in Kassel hat der Entwickler Alexander Reinert noch einmal im Detail die Vorteile dieser Platine dargestellt und das Interesse was anschließend sehr groß. Da wir von Technikkram eng mit Alex zusammen arbeiten, zeigen wir in diesem neuen Artikel auch den Anwendern, die nicht am Usertreffen teilnehmen konnten, den Inhalt der Präsentation von Alex zu der Platine. Schon mit einem kurzen USB Kabel (15 – 20 Zentimeter) sind deutlich bessere Werte im Funkverkehr zwischen Zentrale und Aktoren festzustellen. Der Grudn dafür ist die tatsache, dass die Funkmodule von der Raspberry oder dem Tinker Board abgesetzt und daher nicht mehr den Störfaktoren der Single Board Rechner ausgesetzt sind. Ein ähnliches Prinzip verfolgt eQ-3 ja auch mit der CCU3 und dem neuen Funkmodul, welches nicht mehr direkt über der Raspi Pi 3, sondern seitlich versetzt seine Dienst versieht. Über sogenannte USB-CAT-Extender ist es möglich, die Funkmodule bis zu 15 Meter von der Zentrale abzusetzen, ohen Verluste, da dies über USB-Kabel und nicht Antennekabel erfolgt. Es ist laut Beschreibung der von mir verwendeten USB-CAT-Extender eine Verlägerung der USB-Verbindung über CAT6 Kabel bis zu 60 Meter möglich. Für meinen Test hatte ich aber nur ein 10 Meter langes CAT6 Kabel und kann bestätigen, dass dies funktioniert hat. Im Artikel erfahrt ihr mehr darüber.
Wichtig: Stromversorgung RPI-RF-MOD ausschließlich per USB!
HB-RF-USB – Einsatzmöglichkeiten
Funkmodul an x64 Hardware
Absetzen des Funkmoduls
Bessere Entstörung
Zentrale im Schaltschrank ohne Einschränkung möglich
Zentrale im Keller möglich
Per USB over CAT Extender 15 Meter problemlos möglich
HB-RF-USB – Unterstüzung
Die nachfoolgend aufgeführten Systeme unterstützen die Platine:
piVCCU3
debmatic
Raspberrymatic
Test – Absetzen über USB CAT Extender
Ich hatte mir bereits vor einiger Zeit für die Verlängerung eines USB Gerätes über CAT6 Kabel den folgenden USB-CAT-Extender zugelegt. Nachdem Alex das Heute auf dem Usertreffen vorgestellt hat, habe ich das eben mal flott getestet. Es hat einwandfrei funktioniert. Somit ist es möglich die Platine mit dem jeweiligen Funkmodul im Haus an geeigneter Stelle zu plazieren. Wichtig ist dabei noch zu erwähnen, das die USB-Verlängerung auf jeden Fall über ein „losgelöstes“ CAT6 Kabel umgesetzt werden muss. Damit meine ich, das es eine direkte Verbindung zwischen den beiden Extendern hergestellt werden muss, ohne Einbindung in das bestehende LAN-Netztwerk vorzunehmen.
Die Beschreibung des eingesetzen USB-CAT-Extenders gibt an, das USB Signal bis zu 60 Meter verlängern zu können. Da mir aktuell nur ein 10 Meter langes CAT6 Kabel zur Verfügung steht, konnte ich die von Alex genannten 15 Meter nicht testen. Natürlich benötigt ihr zusätzlich noch einen Adapter USB-A-Stecker auf Micro-USB-B-Stecker.
Wo könnt ihr die Platine HB-RF-USB beziehen?
Wir haben im Tahmen unserer Zusammenarbeit mit Alexander Reinert den Vertrieb der Platine übernommen. Wir haben die Platine komplett bestückt mit allen SMD-Bauteilen bei uns im Shop. Der Platine liegt zudem ein 2×20 Pin-Header bei, sodass Ihr wahlweise das alte oder neue Funkmodul mit der Platine verbinden könnt. Eine Beschreibung des Bausatzes, sowie eine kleine Einführung hat Sebastian bereits in diesem Artikel Homematic Funkmodul per USB anbinden HB-RF-USB-TK jetzt verfügbar! vorgestellt.
Homematic Wired RS485 Bus Fehler an CCU3… 1. April 2026 KI-generiert: Dieser Artikel und seine Abbildungen wurden von einem KI-System erstellt. Mehr dazu Homematic CCU3 mit angeschlossenen Wired-Geräten und RS485-Bus-Diagnose-Tools…
Homematic Wired Bus Terminierung mit Fluke 115… 3. April 2026 KI-generiert: Dieser Artikel und seine Abbildungen wurden von einem KI-System erstellt. Mehr dazu Präzise Multimeter-Messung zeigt korrekte 120 Ohm Terminierung…
Smart Home Neubau planen: Verkabelung und Kosten… 14. Mai 2026 Professionelle Smart Home Verkabelung während der Rohbauphase - die Basis für ein zuverlässiges intelligentes Zuhause Smart Home Neubau planen bedeutet…
Garagentor per Smartphone öffnen - Homematic… 1. Juli 2026 Moderne Garagentor-Steuerung: Mit Homematic wird jedes elektrische Garagentor smart und per App bedienbar Das Garagentor per Smartphone öffnen ist mit…
https://technikkram.net/wp-content/uploads/2019/04/HB-RF-USB-top.jpg445734Wernerhttps://technikkram.net/wp-content/uploads/2019/05/technikkram_transparent.pngWerner2019-04-07 22:02:442019-04-07 22:02:49Usertreffen 2019 – Platine HB-RF-USB – Absetzen der Funkmodule über USB CAT Extender bis zu 15 Meter
Hallo, wurde diese Verlängerung auch einmal über ein Patchfeld probiert? Habe bei mir im Keller ein Patchfeld, von da aus gehen Leitungen in fast jeden Raum. Ist hiermit eine Verlängerung der Funkreichweite denkbar?
Hallo,
habe mir jetzt die Platine HB-RF-USB zugelegt und testweise mit dem Modul HM-MOD-RPI-PCB über piVCCU am Laufen. RPI-RF-MOD ist bestellt und soll dann den Dienst aufnehmen.
Eine Frage: Besteht die Möglichkeit die Platine über /dev/ttyUSBx anzubinden (usb zu seriell) ?
Grund: Habe derzeit noch HM über fhem am Laufen und würde es gerne noch eine Zeitlang, bis zur Umstellung auf piVCCU, so belassen.
Hi,
das ist so nicht vorgesehen. Eine Idee wäre es, dass du nur die Kernel Module von piVCCU installierst. Dann wird die Platine unter /dev/raw-uart oder /dev/raw-uart2 eingehängt und könnte da von FHEM angesprochen werden. Dabei muss man aber beachten, dass FHEM nur mit dem HM-MOD-RPI-PCB mit der alten BidCoS-only Firmware arbeiten kann.
Viele Grüße
Alex
Ist eigentlich schon bekannt,
wann es das dazugehörige Gehäuse gibt?
Werner hat versprochen, uns bei der Vorstellung der Platine mitzuteilen, daß das Gehäuse „in einigen Tagen“ erhältlich ist.
Nun sind einige Wochen ins Land gezogen und vom Gehäuse immer noch keine Spur…….
wir haben auf dem Usertreffen ein Gehäuse mitgehabt und vorgestellt. Da die Reaktion auf dieses Gehäuse sehr positiv ausgefallen ist, werden wir spätestens nächste Woche das Gehäuse im Shop anbieten. Ein entsprechender Artikel mit Beschreibung und Fotos ist in Arbeit.
Wir haben uns entschieden ein gelasertes Gehäuse zu erstellen und kein Gehäuse aus dem 3D Drucker. Daher hat die Erstellung auch ein wenig mehr Zeit in Anspruch genommen wie ursprünglich gedacht.
vielleicht noch eine kurze Erläuterung, woher die 15m kommen: Ich habe schlicht keine längere Leitung um das zu testen. An die theoretischen 60m der Geräte glaube ich aber nicht. Selbt bei den laut USB Standard offiziell erlaubten 5m sieht man schon einen gut messbaren Spannungsabfall, welcher aber noch im grünen Bereich ist. Bei 15m geht das auch noch, ich denke aber, dass das (je nach Kabel) bei spätestens 20m kritisch werden wird. Ggf. könnte man da dann noch etwas mit einem aktiven Hub am Ende der Leitung reißen, das habe ich aber bisher nie getestet.
Eine USB Verlängerung auf diesen abstand ist durchaus möglich mit dem RX/TX Signal, es gibt aber Grenzen wie dur bereits meintest abhängig welche kabel benutzt werden.
2 alternatieven :
– Powered USB-HUB
– USB kabel zum gerät, +/- Spannung abzweigen und dort erst wieder einspeisen.
Damit nimmt man RX-TX direct, und die Spannung local an der stelle wo benötigt.
interessant währe noch eine Erweiterung dieses Moduls per Netwerk Schnittstellen damit wahre eine LAN-Gateway Erweiterung möglich was EQ3 nicht bietet für HM-IP.
Technisch kan ich sowas umsetzen durch den RX/TX per TCP-IP weiter zu leiten, problematisch könnte aber die Integration in die CCU werden da unbekannt welche Kommunikation darin verwendet wird
im HM-Forum habe ich schonmal ausfürlich dargelegt, warum eine Anbindung des gesamten Funkmoduls per Netzwerk nicht die beste Idee ist. Kurzgefasst geht es dabei darum, dass man ziemlich extreme Latenzanforderungen hat, wenn der multimacd mit der DualCoPro Firmware kommuniziert, welche mit Netzwerk nicht mehr eingehalten werden können. Das ist auch der Grund, warum für die Anbindung des Funkmoduls selbst bei Raspberry Pi spezielle Kernel Module verwendet werden, die Standard tty Kernel Module könnten die Latenzen nicht mehr garantieren.
Danke Alex dem war ich mir nicht bewusst aber definitief logisch obwohl im internen netzwerk eine latenz/verzoegerung van über 500ms doch schon selten ist.
Aber Protokoll bedingt verstehe ich was du meinst.
dennoch macht das LAN-Gatewau doch etwas vergleichbares was meine basis war fuer diesen loesungsansatz
Beim Lan GW kommuniziert man auf einer etwas höheren Schicht. Ein Teil der ursprünglich im Funkmodul gelegenen Funktionalität ist in den multimacd gewandert. Und daher ist die Latenzanforderung deutlich extremer, als bei der Kommnunikation mit dem LAN GW, daher ist das eine ganz andere Nummer. Wir reden da von 5ms. Klingt erstmal unkritisch, aber bei der Latenz ist die Zeit gemeint, zwischen dem Senden des ersten Bytes und dem Empfangen des letzen Bytes der Antwort gemeint. (Im Gegensatz zum normalen Ping, bei welchen die Zeit zwischen letzen Byte der Anfrage und erstem Byte der Antwort gemessen wird) Rein durch die Verzögerungen im Kernel und im Funkmodul bist du bei ca. 3ms. Auf der Transportschicht im Netzwerk bist du für die Gesamtnachricht bei 1ms. Passt auch noch. Sobald da aber jetzt eine ARP Auflösung reinkommt oder noch irgendwas im FIFO der Netzwerkkarte drin hängt, dann knallt es, realistisch muss man hier selbst bei einem nicht ausgelasteten Netzwerk mit ca. 6-7ms durchschnittlicher Latenz rechnen und in Peaks auch gerne mal in Richung 20ms. Bei einem ausgelasteten Netz reden wir dann locker vom 10-20 fachen.
Und was man hier dann auch nicht ignorieren darf: Man muss nicht nur auf die maximale Latenz achten, sondern auch auf eine gleichmäßige. Und die ist im Netzwerk absolut nicht gegeben.
Viele Grüße
Alex
Hinterlasse einen Kommentar
An der Diskussion beteiligen? Hinterlasse uns deinen Kommentar!
Sie sehen gerade einen Platzhalterinhalt von Turnstile. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Super Bericht, danke! Es würde sicher auch mit einem 60 Meter CAT Kabel funktionieren:)
Hallo, wurde diese Verlängerung auch einmal über ein Patchfeld probiert? Habe bei mir im Keller ein Patchfeld, von da aus gehen Leitungen in fast jeden Raum. Ist hiermit eine Verlängerung der Funkreichweite denkbar?
Ja geht, aber nicht mit dem von Werner vorgestellten USB-Extender.
Dieser hier funktioniert Plug and Play:
https://www.amazon.de/DIGITUS-70141-Verl%C3%A4ngerung-Kabel-Schwarz/dp/B01FDHG0EE/ref=sr_1_4?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=1RIIX0UF5K439&dchild=1&keywords=usb+extender&qid=1592484811&sprefix=usb+exten%2Caps%2C165&sr=8-4
Hallo,
habe mir jetzt die Platine HB-RF-USB zugelegt und testweise mit dem Modul HM-MOD-RPI-PCB über piVCCU am Laufen. RPI-RF-MOD ist bestellt und soll dann den Dienst aufnehmen.
Eine Frage: Besteht die Möglichkeit die Platine über /dev/ttyUSBx anzubinden (usb zu seriell) ?
Grund: Habe derzeit noch HM über fhem am Laufen und würde es gerne noch eine Zeitlang, bis zur Umstellung auf piVCCU, so belassen.
Gruß,
wbini
Hi,
das ist so nicht vorgesehen. Eine Idee wäre es, dass du nur die Kernel Module von piVCCU installierst. Dann wird die Platine unter /dev/raw-uart oder /dev/raw-uart2 eingehängt und könnte da von FHEM angesprochen werden. Dabei muss man aber beachten, dass FHEM nur mit dem HM-MOD-RPI-PCB mit der alten BidCoS-only Firmware arbeiten kann.
Viele Grüße
Alex
Verstehe ich es richtig, dass mit dem Einsatz HB-RF-USB Platine auch ein x64 System z.B. ein Intel Nuc als CCU3 eingesetzt werden kann ?
Ja, mit der Platine HB-RF-USB und debmatic kannst du eine CCU auf einem Intel Nuc betreiben.
Ist eigentlich schon bekannt,
wann es das dazugehörige Gehäuse gibt?
Werner hat versprochen, uns bei der Vorstellung der Platine mitzuteilen, daß das Gehäuse „in einigen Tagen“ erhältlich ist.
Nun sind einige Wochen ins Land gezogen und vom Gehäuse immer noch keine Spur…….
Hallo Mathias,
wir haben auf dem Usertreffen ein Gehäuse mitgehabt und vorgestellt. Da die Reaktion auf dieses Gehäuse sehr positiv ausgefallen ist, werden wir spätestens nächste Woche das Gehäuse im Shop anbieten. Ein entsprechender Artikel mit Beschreibung und Fotos ist in Arbeit.
Wir haben uns entschieden ein gelasertes Gehäuse zu erstellen und kein Gehäuse aus dem 3D Drucker. Daher hat die Erstellung auch ein wenig mehr Zeit in Anspruch genommen wie ursprünglich gedacht.
Gruss
Werner
Hi,
vielleicht noch eine kurze Erläuterung, woher die 15m kommen: Ich habe schlicht keine längere Leitung um das zu testen. An die theoretischen 60m der Geräte glaube ich aber nicht. Selbt bei den laut USB Standard offiziell erlaubten 5m sieht man schon einen gut messbaren Spannungsabfall, welcher aber noch im grünen Bereich ist. Bei 15m geht das auch noch, ich denke aber, dass das (je nach Kabel) bei spätestens 20m kritisch werden wird. Ggf. könnte man da dann noch etwas mit einem aktiven Hub am Ende der Leitung reißen, das habe ich aber bisher nie getestet.
Viele Grüße
Alex
Eine USB Verlängerung auf diesen abstand ist durchaus möglich mit dem RX/TX Signal, es gibt aber Grenzen wie dur bereits meintest abhängig welche kabel benutzt werden.
2 alternatieven :
– Powered USB-HUB
– USB kabel zum gerät, +/- Spannung abzweigen und dort erst wieder einspeisen.
Damit nimmt man RX-TX direct, und die Spannung local an der stelle wo benötigt.
interessant währe noch eine Erweiterung dieses Moduls per Netwerk Schnittstellen damit wahre eine LAN-Gateway Erweiterung möglich was EQ3 nicht bietet für HM-IP.
Technisch kan ich sowas umsetzen durch den RX/TX per TCP-IP weiter zu leiten, problematisch könnte aber die Integration in die CCU werden da unbekannt welche Kommunikation darin verwendet wird
Hi,
im HM-Forum habe ich schonmal ausfürlich dargelegt, warum eine Anbindung des gesamten Funkmoduls per Netzwerk nicht die beste Idee ist. Kurzgefasst geht es dabei darum, dass man ziemlich extreme Latenzanforderungen hat, wenn der multimacd mit der DualCoPro Firmware kommuniziert, welche mit Netzwerk nicht mehr eingehalten werden können. Das ist auch der Grund, warum für die Anbindung des Funkmoduls selbst bei Raspberry Pi spezielle Kernel Module verwendet werden, die Standard tty Kernel Module könnten die Latenzen nicht mehr garantieren.
Viele Grüße
Alex
Danke Alex dem war ich mir nicht bewusst aber definitief logisch obwohl im internen netzwerk eine latenz/verzoegerung van über 500ms doch schon selten ist.
Aber Protokoll bedingt verstehe ich was du meinst.
dennoch macht das LAN-Gatewau doch etwas vergleichbares was meine basis war fuer diesen loesungsansatz
Beim Lan GW kommuniziert man auf einer etwas höheren Schicht. Ein Teil der ursprünglich im Funkmodul gelegenen Funktionalität ist in den multimacd gewandert. Und daher ist die Latenzanforderung deutlich extremer, als bei der Kommnunikation mit dem LAN GW, daher ist das eine ganz andere Nummer. Wir reden da von 5ms. Klingt erstmal unkritisch, aber bei der Latenz ist die Zeit gemeint, zwischen dem Senden des ersten Bytes und dem Empfangen des letzen Bytes der Antwort gemeint. (Im Gegensatz zum normalen Ping, bei welchen die Zeit zwischen letzen Byte der Anfrage und erstem Byte der Antwort gemessen wird) Rein durch die Verzögerungen im Kernel und im Funkmodul bist du bei ca. 3ms. Auf der Transportschicht im Netzwerk bist du für die Gesamtnachricht bei 1ms. Passt auch noch. Sobald da aber jetzt eine ARP Auflösung reinkommt oder noch irgendwas im FIFO der Netzwerkkarte drin hängt, dann knallt es, realistisch muss man hier selbst bei einem nicht ausgelasteten Netzwerk mit ca. 6-7ms durchschnittlicher Latenz rechnen und in Peaks auch gerne mal in Richung 20ms. Bei einem ausgelasteten Netz reden wir dann locker vom 10-20 fachen.
Und was man hier dann auch nicht ignorieren darf: Man muss nicht nur auf die maximale Latenz achten, sondern auch auf eine gleichmäßige. Und die ist im Netzwerk absolut nicht gegeben.
Viele Grüße
Alex