Architektur rfd, hs485d, crRFD usw

Fragen, Support etc.

Moderator: Co-Administratoren

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, 18:16

theshmike hat geschrieben:
26.11.2020, 18:01
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...
Windows sollte man IMHO ohnehin nicht für solch etwas kritisches wie eine Hausautomation einsetzen. Ist also IMHO verschmerzbar.
theshmike hat geschrieben:
26.11.2020, 18:01
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?
Genau deshalb sage ich ja das der eine "Krücke" ist. Leider der falsche Funkchip drauf und der Stick kann auch nur HmIP und kein BidCos-RF. Sonst wäre der Kundenkreis bzw. Nutzbarkeit des Sticks wesentlich höher.
theshmike hat geschrieben:
26.11.2020, 18:01
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?
Nöh, du kannst dann davon ausgehen das die "Magenta-Smarthome-fähigen" Router nicht mit einem HmIP-HAP oder mit HmIP-Wired erweitert werden können. Sie können zwar HmIP-RF sprechen/funken und nutzen dafür ihren Funkchip zur Verschlüsselung. Aber die "Advanced Routing" Features beherrscht dieser HmIP-RFUSB genauso wenig wie das alt HM-MOD-RPI-PCB Funkmodul. Daher propagiere ich ja schon seit geraumer Zeit das man ab sofort nur noch auf das RPI-RF-MOD setzen sollte und die Finger von den anderen/alten Funkmodullösungen lassen sollte.
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, 18:19

theshmike hat geschrieben:
26.11.2020, 18:01
ü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?
Mit dem HmIP-RF-USB kannst Du alle HmIP Funk Geräte nutzen außer eben den DRAP und HAP. Routing über IP-Netzwerke (zu einem HAP oder DRAP) ist das was zwingend den Coprozessor des RPI-RF-MOD benötigt. Routing rein über Funk (via HmIP-PSM z.B.) geht hingegen auch mit dem HmIP-RF-USB. Ein weiterer Nachteil des RF-USB ist das Limit von 100 Geräten, das gibt es mit dem RPI-RF-MOD nicht. Spricht aus meiner Sicht aber nichts dagegen mit dem RF-USB anzufangen, auf das RPI-RF-MOD kannst auch bei Bedarf dann noch umsteigen (wie Deimos schon erklärt hat aber nicht unter Windows, für das RPI-RF-MOD musst dann doch in irgend einer Form auf Linux setzen)
deimos hat geschrieben:
26.11.2020, 18:13
Direkt an Windows betreiben wirst du ihn nicht können, weil er zwar einen CP2102N drauf hat, aber mit eigener USB ID.
Die passenden Treiber für Windows bietet ELV zum Download an: https://de.elv.com/elv-homematic-ip-arr ... ion-152306
Habe den HmIP-RF-USB selbst schon unter Windows betrieben, geht einwandfrei.
deimos hat geschrieben:
26.11.2020, 18:13
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.
Der crRFD läuft einwandfrei unter Windows, der einzige Pfad von dem ich jetzt nicht wüsste wie man ihn beim hmipserver conft ist der zur groups.gson, die gibts beim crRFD nicht, aber dann kackt beim hmipserver denke ich wenn dann nur der VirtualDevices Teil ab ;-)

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, 20:43

Alles klar, damit komme ich erstmal weiter. Vielen Dank an alle die geantwortet haben.
Letzte Frage: Wo könnte ich mir noch Informationen dazu holen, wie ich das Funkmodul unter z.B. raspbian mit hmipserver zum laufen bekomme? Habe hier noch eins rumliegen und werde das dann mal zeitnah probieren :)

Der hmipserver braucht ja sicher wieder irgendwelche Berechtigungen auf irgendwelche GPIOs. Sorry, wenn die Frage evtl. dumm gestellt ist. Ich bin nicht der 100%ige Linux-Native, kriege das aber sicher mit entsprechenden Informationsquellen ganz gut hin. Hatte dazu mal das Installationsscript von hmcon (thx hobbyquaker 8) ) durchgeschaut, das iirc den rfd und hs485d installiert und auch irgendwelche Berechtigungen auf GPIOs setzt...das beträfe ja dann aber das alte BidCoS-Modul

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, 20:46

Hi,

schau dir debmatic an, da dürftest du alles notwendige finden.

Viele Grüße
Alex

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

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von theshmike » 27.11.2020, 07:44

hobbyquaker hat geschrieben:
26.11.2020, 16:39
kommt auf einer CCU dann noch der multimacd ins spiel, der spielt aber bei Deinem Vorhaben keine Rolle.
Wollte das jetzt nochmal verifizieren. Habe mich jetzt ein wenig durch die verfügbaren Infos gewühlt. Ist nicht der mutlimacd der, der die eq3loop-subdevices, also /dev/mmd_hmip anlegt?

Der hmipserver kommuniziert ja über /dev/mmd_hmip?

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 » 27.11.2020, 08:16

Hi,

Der multimacd ist das Gegenstück zur Dual CoPro Firmware auf den Funkmodulen RPI-RF-MOD und HM-MOD-RPI-PCB, welcher vereinfacht die Aufteilung in BidCos und HmIP macht. Dabei legt er die beiden Dev-Nodes an, über welche der rfd und der hmipserver (indirekt) mit der Hardware kommunizieren.
Beim HmIP-RFUSB brauchst du diesen nicht, da der nur HmIP spricht, also das Protokoll identisch ist zu dem, was der multimacd auf /dev/mmd_hmip bereitstellt.

Viele Grüße
Alex

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

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von theshmike » 27.11.2020, 08:56

...und da ich ja jetzt gelernt habe, dass ich zur Kommunikation mit einem HMW-DRAP den RPI-RF-MOD brauche, brauche ich dann folglich trotzdem auch den multimacd am laufen, der mir das virtuelle HMIP-Device bereitstellt. Richtig?

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 » 27.11.2020, 09:13

Hi,

genau. Und für den multimacd brauchst du dann wiederrum die speziellen Kernel Module, also eq3_char_loop und ein zur Hardware Schnittstelle passendes raw-uart Kernel Module, welches wiederum ggf. ein passendes Device Tree Overlay braucht.

Viele Grüße
Alex

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

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von theshmike » 27.11.2020, 11:13

Puuuuh, naja ich werde mal versuchen mich durchzuarbeiten :)
Ggf. mache ich dazu ja nochmal den einen oder anderen Thread auf.

Ziel ist für mich ein laufender hmipserver. BidCoS, ReGa, WebUI & Co. brauche ich alles nicht :)

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 » 27.11.2020, 11:24

theshmike hat geschrieben:
27.11.2020, 11:13
Ziel ist für mich ein laufender hmipserver. BidCoS, ReGa, WebUI & Co. brauche ich alles nicht :)
Dann nimm doch eine bestehende Appliance (CCU3 FW, Raspberrymatic, debmatic, ...) und schmeiß die von dir nicht benötigten Dienste (sofern sie denn stören, wenn sie einfach nur mitlaufen) aus dem init.d raus.
So hast du auch immer einen konsistenten Stand mit der vom HMIPServer benötigten Java-Version.

VG,
Jérôme ☕️

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

Antworten

Zurück zu „Allgemeines zur OCCU“