Neues Homematic Protokoll "Homematic IP" auf Basis von IPv6/AES128-CCM

Deutsche Foren Allgemein
#61

Hallo,

ich habe mir auf jeden Fall mal einen der Sticks bestellt :wink: - mal sehen. Bisher ließe sich auch theoretisch bereits der HM-MOD-RPI-PCB in Verbindung mit dem im Rahmen des OCCU-Projektes veröffentlichen Dienstes (war das der multimacd?) verwenden. Diesen könnte Homegear dann über XML-RPC ansprechen. Das Hauptproblem ist nur (neben dem Punkt, dass der Quelltext für den multimacd nicht vorliegt), dass für den komischen Split-UART-Treiber UART auf der entsprechenden Plattform komplett deaktiviert werden muss. Komisch deswegen, weil das auch einfacher implementiert werden könnte (siehe zum Beispiel SCC). So ist die Nutzung nur mit Kernelpatch möglich und daher mit aus meiner Sicht zu großem Aufwand verbunden. Falls sich jemand die Mühe machen möchte, ist die direkte Nutzung des multimacd mit dem neuen CCU-Modul problemlos möglich. Das einfachste ist an dieser Stelle aber vermutlich die Nutzung der RaspberryMatic (die auch mit dem CCU-Modul zusammenläuft).

Viele Grüße

Sathya

1 Like
Funkmodul RPI-RF-MOD
#62

Hallo zusammen,

ich habe mir die Geschichte mit dem Stick mal näher angeschaut.
So wie es aussieht, wird der multimacd für den Stick nicht benötigt.

Der Kombination aus eigenem Low-Latency Kernel UART Driver und multimacd wird nur für das HM-MOD-RPI-PCB benötigt, da hierüber beide Protokolle gefahren werden können/müssen.

Der multimacd stellt zusammen mit dem zweiten Kernel Treiber, dem Character-Loopback Treiber einfach mehrere virtuelle serielle Ports zur Verfügung.
Mit diesen virtuellen Ports verbindet sich dann RFD bzw. der crRFD (HMIPserver).
In der Doku steht, dass die Kommunikation über diese virtuellen Ports für RFD und crRFD genauso aussieht, als seien sie mit einem “echten” Coprozessor verbunden. Der Coprozessor im Homematic-Slang ist ein kleiner Controller, die zeitkritische Ansteuerung des CC1101 abwickelt. Er ist also für die Kommunikation zuständig.

So wie ich das nun sehe, stellt der USB Stick selbst einfach nur direkt einen seriellen Port bereit, über den sich dann direkt der crRFD (HMIPserver) verbinden kann.

Es sind also keine Kerneltreiber und auch kein multimacd mehr notwendig.

Evtl. wäre es ja interessant, nur den crRFD(HMIPserver), der in JAVA(!) geschrieben ist, in einen Docker-Container zu packen und das USB-Device durchzureichen.

Siehe dazu auch: https://github.com/litti/dccu2

2 Likes
#63

Evtl. wäre es ja interessant, nur den crRFD(HMIPserver), der in JAVA(!) geschrieben ist, in einen Docker-Container zu packen und das USB-Device durchzureichen.

Das sollte funktionieren.

#64

Nachdem ich mir (versehentlich) eine HMIP-Wetterstation bestellt habe, versuche ich sie momentan in meine HA-Infrastruktur zu integrieren :-/
Bisher habe ich einen Selbstbau-CUL mit Homegear in Betrieb, um die HMBidcos-Geräte zu steuern. Läuft seit Monaten völlig problemlos, daher erstmal vielen Dank an alle Homegear-Macher :slight_smile:
Was ich bisher verstanden habe:

  • mit meinem CUL (Hardware) und Homegear (Software) komme ich hier nicht weiter
  • als Hardware brauche ich z.B. den RF USB Stick (ist bereits bestellt)
  • als Software brauche ich ein Zwischenstück zwischen dem Stick und Homegear (crRFD aus dem OCCU-Repo)

Meine erste Frage: Habe ich da alles richtig verstanden/wird der Plan funktionieren?

Meine zweite Frage (da bin ich auch gern zu einem Beitrag bereit): Könnte das Zwischenstück nicht durch ein passendes Modul in Homegear ersetzt werden? Ich hatte mich gerade gefreut, Java auf meinem Pi loszusein, indem ich openHAB durch Home Assistant ersetzt habe :wink:

#65

Hallo @ingo,

Korrekt. Das liegt daran, dass das Protokoll noch von niemandem weit genug analysiert wurde.

Ja.

Ebenfalls korrekt. So sollte es funktionieren.

Prinzipiell natürlich schon, aber dafür müsste das Protokoll von irgendjemandem analysiert werden. Wir schaffen das gerade zeitlich nicht.

Viele Grüße

Sathya