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.

HB-RF-USB

  • Anschluss per USB
  • Unterstützung:
  • Unterstützung für BidCoS und HmIP
  • LEDs vom RPI-RF-MOD werden unterstützt

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.

So sieht der Bausatz aus.
11 Kommentare
  1. Avatar
    wbini sagte:

    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

    Antworten
    • Avatar
      Alex sagte:

      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

      Antworten
  2. Avatar
    Roman sagte:

    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 ?

    Antworten
  3. Avatar
    Mathias sagte:

    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…….

    Antworten
    • Werner
      Werner sagte:

      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

      Antworten
  4. Avatar
    Alex sagte:

    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

    Antworten
    • Avatar
      Rafal Drozda alias Dutchman sagte:

      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

      Antworten
      • Avatar
        Alex sagte:

        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

        Antworten
        • Avatar
          Rafal Drozda alias Dutchman sagte:

          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

          Antworten
          • Avatar
            Alex sagte:

            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

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ich akzeptiere die Speicherung der Daten.