Architektur rfd, hs485d, crRFD usw

Fragen, Support etc.

Moderator: Co-Administratoren

theshmike
Beiträge: 31
Registriert: 12.01.2018, 11:54
Danksagung erhalten: 1 Mal

Architektur rfd, hs485d, crRFD usw

Beitrag von theshmike » 26.11.2020, 13:30

Hallo Community,

ich habe ein paar Fragen zum besseren Verständnis der verschiedenen Systemkomponenten der *CCU.
Am Ende interessiert mich eigentlich nur das, was ich minimal brauche um HMIP-Komponenten mit eigener Software anzusteuern.
Was ich meine bisher herausgefunden zu haben ist:
  • rfd ist ein daemon der nach "vorne" eine XMLRPC-Schnittstelle exportiert und nach "hinten" alles in BidCoS via 868MHz an Homematic-Geräte "schickt" und umgekehrt für Statusmeldungen (an einen am daemon registrierten XMLRPC-Receiver
  • hs485d macht das selbe, aber für die wired-Komponenten
  • hmipserver.jar (Frage: =crRFD?) ist ein daemon der nach "vorne" ebenfalls die XMLRPC-Schnittstelle exportiert und nach "hinten" über IPv6 über das entsprechende Medium die HMIP und auch die HMIP-Wired-Geräte, bzw. APs anspricht?
Letztendlich interessiert mich dann hier nur der hmipserver.jar, da ich ja nur mit HMIP-Geräten sprechen will. Ich meine verstanden zu haben, dass der hmipserver-daemon als Hardware zur Übermittlung, also quasi als Netzwerkkarte, dann entwer das Funkmodul für den RPI oder eben z.B. den USB-Stick verwenden kann. Wenn mit einem Wired-AP gesprochen werden soll, erfolgt das dann ja folgerichtig über die "normale" Ethernet-Schnitsttelle, richtig?

D.h. letztendlich, in der THEORIE, könnte ich den offensichtlich in Java geschriebenen daemon auch auf einer Windows-Kiste zum laufen kriegen und dort den USB-Stick verwenden, richtig?

Unabhängig vom OS wollte ich dann noch wissen, ob die zum Start des daeoms erforderlichen Configfiles usw. irgendwo dokumentiert sind? Ich hatte dazu im OCCU-Repo auf GitHub wenig bis nichts gefunden. Also irgendwo muss man ja z.B. einstellen können ob der daemon des USB-Stick oder z.B. das Funkmodul verwenden soll.

Als letztes habe ich im OCCU-Repo neben der hmipserver.jar auch noch eine hmserver.jar gefunden. kann dazu auch noch jemand was sagen? Ohne irgendwelche Infos dazu zu haben hätte ich das jetzt mal so interpretiert, dass das eine nachträgliche Java-Variante von rfd+hs485d ist?

Vielen Dank fürs Lesen und ggf. euer Feedback,
Mike

hobbyquaker
Beiträge: 3978
Registriert: 12.07.2009, 20:01
Hat sich bedankt: 17 Mal
Danksagung erhalten: 176 Mal
Kontaktdaten:

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von hobbyquaker » 26.11.2020, 15:31

theshmike hat geschrieben:
26.11.2020, 13:30
hmipserver.jar (Frage: =crRFD?)
Der crRFD steckt im hmipserver drin, ist also quasi eine Teilmenge. Außer dem crRFD gibt es im hmipserver auch noch die Gruppen- ("VirtualDevices" Interface) und Diagramm-Funktionen und ein paar Teile des CCU WebUI werde darüber bereitgestellt, außerdem stecken afaik noch Updatemechanismen für den HAP/DRAP im hmipserver drin.
theshmike hat geschrieben:
26.11.2020, 13:30
ist ein daemon der nach "vorne" ebenfalls die XMLRPC-Schnittstelle exportiert
Ja.
theshmike hat geschrieben:
26.11.2020, 13:30
und nach "hinten" über IPv6 über das entsprechende Medium die HMIP und auch die HMIP-Wired-Geräte, bzw. APs anspricht?
Der crRFD spricht erstmal mit dem Funkmodul bzw. Coprozessor, dieser wiederum kommuniziert dann über das proprietäre HmIP Protokoll (hat mit IPv6 nicht viel zu tun) über Funk oder verpackt die HmIP Pakete und kommuniziert dann via Ethernet/IPv4/IPv6 mit dem HmIP-HAP/DRAP.
theshmike hat geschrieben:
26.11.2020, 13:30
Wenn mit einem Wired-AP gesprochen werden soll, erfolgt das dann ja folgerichtig über die "normale" Ethernet-Schnitsttelle, richtig?
Ja, der crRFD bindet HAP/DRAP über Ethernet/IP an. "Nach vorne" ist das transparent, ist egal ob die Pakete über Router oder direkt, über Wired oder Funk oder IP-Netzwerke geroutet werden, auf der RPC Schnittstelle sieht man das nicht worüber das Routing der Pakete für bestimmte Geräte läuft.
theshmike hat geschrieben:
26.11.2020, 13:30
D.h. letztendlich, in der THEORIE, könnte ich den offensichtlich in Java geschriebenen daemon auch auf einer Windows-Kiste zum laufen kriegen und dort den USB-Stick verwenden, richtig?
Ja.
theshmike hat geschrieben:
26.11.2020, 13:30
Als letztes habe ich im OCCU-Repo neben der hmipserver.jar auch noch eine hmserver.jar gefunden. kann dazu auch noch jemand was sagen? Ohne irgendwelche Infos dazu zu haben hätte ich das jetzt mal so interpretiert, dass das eine nachträgliche Java-Variante von rfd+hs485d ist?
Das ist ein "Überbleibsel" aus prä-HmIP CCU2 Zeiten vermute ich. Der hmserver ist afaik der hmipserver ohne crRFD, kann also glaube ich nicht verwendet werden um HmIP Geräte anzusteuern. Der hat iirc nur die Diagramm- und Gruppen-Funktionalität auf die CCU2 gebracht bevor es HmIP gab.

theshmike
Beiträge: 31
Registriert: 12.01.2018, 11:54
Danksagung erhalten: 1 Mal

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von theshmike » 26.11.2020, 15:55

Mega, vielen Dank erstmal für die Infos!
hobbyquaker hat geschrieben: Der crRFD steckt im hmipserver drin
...bedeutet aber nicht gleichzeitig, dass der hmipserver auch "alte" BidCoS-Geräte ansprechen kann, oder? Er ist quasi nur der RFD-Daemon für HMIP?
hobbyquaker hat geschrieben: Der crRFD spricht erstmal mit dem Funkmodul bzw. Coprozessor, dieser wiederum kommuniziert dann über das proprietäre HmIP Protokoll (hat mit IPv6 nicht viel zu tun) über Funk oder verpackt die HmIP Pakete und kommuniziert dann via Ethernet/IPv4 mit dem HmIP-HAP/DRAP.
Verstehe ich das richtig, dass der hmipserver dann z.B. über den HMIP-RFUSB direkt mit HMIP-Geräten spricht und alternativ quasi den HAP als "Funkmodul" verwenden kann indem er den HAP via Ethernet anspricht und dieser dann über 868MHz mit den Geräten spricht (und analog dazu den DRAP, der dann über den Bus mit den wired-Geräten spricht)?

Das würde ja dann bedeuten:
  • das man irgendwo in der Config des hmipservers mehrere "Bridges" angeben kann, also z.B. die IP-Adressen von HAP/DRAP
  • das ich dem hmipserver jeweils mitteilen muss, welches Gerät er über welche "Bridge" erreichen soll (ggf. findet er das ja auch selbst über eine device discovery-Funktion raus, konnte mir die entsprechende Doku zur XMLRPC-Schnittstelle noch nicht genau ansehen)
Was mir noch fehlt sind Infos zur Parametern etc. für den hmipserver. Irgendwo im OCCU-Repo ist ja z.B. ein Startscript für den hmipserver. Da werden iirc auch ein paar Parameter verwendet die sich mir jetzt nicht wirklich selbst erschließen.
Ist die Architektur mit zugehörigen Configfiles usw. iregndwo dokumentiert oder gibts dazu irgend eine Art von Infos?

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von jmaus » 26.11.2020, 16:30

theshmike hat geschrieben:
26.11.2020, 15:55
Verstehe ich das richtig, dass der hmipserver dann z.B. über den HMIP-RFUSB direkt mit HMIP-Geräten spricht und alternativ quasi den HAP als "Funkmodul" verwenden kann indem er den HAP via Ethernet anspricht und dieser dann über 868MHz mit den Geräten spricht (und analog dazu den DRAP, der dann über den Bus mit den wired-Geräten spricht)?
Nein, für die Kommunikation mit einem HmIP-HAP oder HmIPW-DRAP benötigt HMIPServer bzw. du definitiv das RPI-RF-MOD Funkmodul. Mit einem HmIP-RFUSB Stick wirst du keine Kommunikation mit einem HmIP-HAP oder DRAP und folglich dann auch nicht mit HmIP-Wired hinbekommen.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

hobbyquaker
Beiträge: 3978
Registriert: 12.07.2009, 20:01
Hat sich bedankt: 17 Mal
Danksagung erhalten: 176 Mal
Kontaktdaten:

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von hobbyquaker » 26.11.2020, 16:39

theshmike hat geschrieben:
26.11.2020, 15:55
Er ist quasi nur der RFD-Daemon für HMIP?
Ja, die alten BidCos Protokolle laufen über rfd/hs485d, damit hat der crRFD nichts zu tun. Damit dann sowohl der alte rfd als auch der neue crRFD auf das Funkmodul zugreifen können kommt auf einer CCU dann noch der multimacd ins spiel, der spielt aber bei Deinem Vorhaben keine Rolle.
theshmike hat geschrieben:
26.11.2020, 15:55
Verstehe ich das richtig, dass der hmipserver dann z.B. über den HMIP-RFUSB direkt mit HMIP-Geräten spricht
Bis hierhin: ja.
theshmike hat geschrieben:
26.11.2020, 15:55
und alternativ quasi den HAP als "Funkmodul" verwenden kann indem er den HAP via Ethernet anspricht
Nein, nicht alternativ, nur als zusätzlichen Router. Ein direkt via (usb-)seriell am crRFD angebundenes Funkmodul ist immer Pflicht, nur mit einem HAP aber ohne Funkmodul geht es nicht. Dabei reicht allerdings der HmIP-RF-USB nicht aus, um den HAP/DRAP (=Routing von HmIP über IP-Netzwerke) zu verwenden ist das Funkmodul "RPI-RF-MOD" zwingend notwendig.
theshmike hat geschrieben:
26.11.2020, 15:55
das man irgendwo in der Config des hmipservers mehrere "Bridges" angeben kann, also z.B. die IP-Adressen von HAP/DRAP
Nein, die werden nicht fest konfiguriert, der HAP wird wie ein "normales Gerät" per setInstallMode RPC Call angelernt. Beim DRAP weiss ichs grade nicht sicher.
theshmike hat geschrieben:
26.11.2020, 15:55
das ich dem hmipserver jeweils mitteilen muss, welches Gerät er über welche "Bridge" erreichen soll
Nein, darauf kannst Du keinen Einfluss nehmen. Im HmIP-Netzwerk werden die Routen automatisch und dynamisch festgelegt.
theshmike hat geschrieben:
26.11.2020, 15:55
Was mir noch fehlt sind Infos zur Parametern etc. für den hmipserver.
Die Doku des crRFD und der crRFD.conf ist glaube/befürchte ich nicht öffentlich verfügbar. Da musst einfach ich try&error spielen und schauen wie die Config auf einer CCU3/RaspberryMatic so aussieht...

Die Doku zur XML RPC Schnittstelle (im eQ-3 Sprech "Legacy API") und das Addendum dazu für HmIP gibts auf der eQ-3 Seite zum Download. Neben XML RPC gäbe es auch die Möglichkeit Dich in Java direkt an den Vert.x Eventbus des crRFD ranzuhängen (daher nennt eQ-3 die XML RPC Schnittstelle auch "Legacy API"), das ist aber glaube ich auch nicht öffentlich dokumentiert.

theshmike
Beiträge: 31
Registriert: 12.01.2018, 11:54
Danksagung erhalten: 1 Mal

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von theshmike » 26.11.2020, 17:27

Thanks again! Sorry für meine Penetranz, aber ich habe leider immer den Drang die Dinge ganz genau zu verstehen bevor ich anfange an irgendwas zu arbeiten :mrgreen:
hobbyquaker hat geschrieben: Nein, nicht alternativ, nur als zusätzlichen Router.
Verstehe ich, der HAP wird als normales Gerät angelernt und dient dann einfach nur als HMIP-interner Router/Repeater
hobbyquaker hat geschrieben: Ein direkt via (usb-)seriell am crRFD angebundenes Funkmodul ist immer Pflicht, nur mit einem HAP aber ohne Funkmodul geht es nicht. Dabei reicht allerdings der HmIP-RF-USB nicht aus, um den HAP/DRAP (=Routing von HmIP über IP-Netzwerke) zu verwenden ist das Funkmodul "RPI-RF-MOD" zwingend notwendig.
Verstehe ich hingegen nicht, weil
  • ich bisher dachte, dass der crRFD mit dem HAP über Ethernet spricht. Dafür hat der ja (neben der Kommunikation mit der HMIP-Cloud) extra eine
    Ethernet-Schnittstelle, oder?
  • der DRAP ja kein Funkmodul eingebaut hat (afaik), d.h. der crRFD MUSS ja quasi mit dem DRAP über Ethernet sprechen. Verstehe nicht, wozu der crRFD dann dazu ein Funkmodul braucht...
Mein Zielszenario wäre eine kleine HMIP-Wired-Testinstallation (DRAP + z.B. irgendein Schaltaktor) mit z.B. einem oder zwei zusätzlichen HMIP-Funkdevices direkt über XMLRPC und hmipserver anzusteuern. Mein bisheriger Plan war:
  • RPI mit HMIP-RFUSB
  • laufendem hmipserver auf dem RPI
  • eigenes Programm welches via XMLRPC mt dem hmipserver spricht
  • hmipserver spricht via USB-Stick mit den Funkdevices und via Ethernet mit dem DRAP der wiederum über den Bus den Aktor ansteuert
HAP würde in diesem Szenario also eh keine Rolle spielen.
Das wäre dann aber ja so ohne das "echte" Funkmodul trotzdem nicht umsetzbar, wobei ich das wiegesagt nicht wirklich nachvollziehen kann... :(

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von jp112sdl » 26.11.2020, 17:34

theshmike hat geschrieben:
26.11.2020, 17:27
ohne das "echte" Funkmodul trotzdem nicht umsetzbar, wobei ich das wiegesagt nicht wirklich nachvollziehen kann...
In dem Funkmodul arbeitet ein TI CC1310 (RF Modul mit MCU und AES Kryptokomponente).
Diese AES Funktion wird zentral für die Verschlüsselung der Kommunikation genutzt.
Egal,ob die Befehle verschlüsselt über einen Bus gehen (DRAP) oder zu einem abgesetzten HAP per Ethernet.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von jmaus » 26.11.2020, 17:49

theshmike hat geschrieben:
26.11.2020, 17:27
Mein Zielszenario wäre eine kleine HMIP-Wired-Testinstallation (DRAP + z.B. irgendein Schaltaktor) mit z.B. einem oder zwei zusätzlichen HMIP-Funkdevices direkt über XMLRPC und hmipserver anzusteuern. Mein bisheriger Plan war:
  • RPI mit HMIP-RFUSB
  • laufendem hmipserver auf dem RPI
  • eigenes Programm welches via XMLRPC mt dem hmipserver spricht
  • hmipserver spricht via USB-Stick mit den Funkdevices und via Ethernet mit dem DRAP der wiederum über den Bus den Aktor ansteuert
HAP würde in diesem Szenario also eh keine Rolle spielen.
Das wäre dann aber ja so ohne das "echte" Funkmodul trotzdem nicht umsetzbar, wobei ich das wiegesagt nicht wirklich nachvollziehen kann... :(
Genau so ist es. Wie schon mehrfach gesagt, man braucht zwingend ein RPI-RF-MOD wenn man mit einem HmIPW-DRAP oder HMIP-HAP kommunizieren mag. Und ja, es klingt erst einmal missverständlich wenn man weiss das eine CCU mit einem HmIPW-DRAP oder HMIP-HAP ja eigentlich nur über Ethernet spricht, aber wie von @jp112sdl schon ausgeführt, das RPI-RF-MOD wird eben als "Coprozessor" für gewisse Verschlüsselungs- und Routing jobs quasi genutzt/missbraucht und deshalb gibt es nunmal diese Abhängigkeit. Mag komisch klingen, ist aber so und lässt sich auch ohne zutun von eQ3 nicht ändern und soweit ich das überblicke haben sie auch nicht vor zu ändern.

Das einzige was du also anders einplanen solltest ist, statt des HmIP-RFUSB (der übrigens ansich schon eine Krücke ist) ein RPI-RF-MOD zu nutzen. Und wenn du nicht den GPIO des RaspberryPi dafür besetzen/belegen willst, dann nutz eben eine HB-RF-USB-2 Adapterplatine, dann kannst du das RPI-RF-MOD auch via USB anschließen, benötigst dann allerdings auch ein extra Kernelmodul dafür.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

theshmike
Beiträge: 31
Registriert: 12.01.2018, 11:54
Danksagung erhalten: 1 Mal

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von theshmike » 26.11.2020, 18:01

Ah alles klar, die Info mit dem Coprozessor hat mir gefehlt, bzw. ich hatte sie oben missverstanden.

Das relativiert dann aber auch wieder die Theorie mit dem hmipserver auf Windows, da ich ja erstmal das Funkmodul irgendwie an einer Windows-Kiste anschliessen/zum Laufen bringen müsste...

Für mich relativiert sich dann auch irgendwie der Sinn des USB-Sticks. Oder kann ich mit dem alleine ohne Modul direkt mit Geräten sprechen die kein HAP sind?
Falls nicht, ist der einzige Sinn des Sticks dann, ihn als abgesetzte Antenne zu verwenden?

Habe irgendwo auch gesehen, dass die Telekom den Stick zum Anschluss an einen Magenta-Smarthome-fähigen Router vertreibt? Kann man dann davon ausgehen, dass diese Router ebenfalls bereits einen Coprozessor eingebaut haben? Wobei das ja wahrscheinlich eh eine von eq3 speziell auf die Telekom angepasste Variante sein wird...

1000 Dank für euren Support!

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 950 Mal
Kontaktdaten:

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von deimos » 26.11.2020, 18:13

Hi,

der HmIP-RFUSB kann mit HmIP Funk Geräten kommunizieren, aber nur mit diesen. Direkt an Windows betreiben wirst du ihn nicht können, weil er zwar einen CP2102N drauf hat, aber mit eigener USB ID. Das an sich ist noch lösbar.
Das RPI-RF-MOD wirst du unter Windows nicht zum Laufen bekommen. Mit meiner HB-RF-USB-2 bekommst du es zwar angeschlossen, aber da es nicht nur HmIP spricht, sondern auch BidCos muss man zwingend den multimacd und spezielle Kernel Module zwischenschalten und beides gibt es nur für Linux.
und zu guter letzt: Auch wenn der hmipserver in Java programmiert ist, gehe ich sehr stark davon aus, dass er nicht unter Windows lauffähig ist, ich weiß leider mittlerweile, wie in Leer programmiert wird und da muss man davon ausgehen, dass sie nicht drauf achten, dass das System außerhalb der CCU lauffähig ist und Pfade etc. fest eincodiert werden.

Viele Grüße
Alex

Antworten

Zurück zu „Allgemeines zur OCCU“