HomeMatic IP ohne CCU

[Hinata]

Im Wiki ist eine Beschreibung wie man HomeMatic IP Komponenten in FHEM einbinden kann (https://wiki.fhem.de/wiki/HomeMatic_IP).

Was ich nicht verstehe ist der technische Hintergrund warum das nich wie bei FS20 oder HomeMatic ohne CCU geht?
Was ist so speziell an dem Protokoll? Oder ist das Protokoll irgendwie rechtlich geschützt?

[marvin78]

Es ist verschlüsselt und es gibt aktuell keinen guten Grund, aus dem man sich hinsetzen sollte um das Protokoll zu entschlüsseln. Es gibt einfachere Wege (CCU, Raspberrymatic, Debmatic.....).

[MadMax-FHEM]

Das Homematic-IP Protokoll ist verschlüsselt (BidCos ist unverschlüsselt, kann aber signiert werden: AES) und es ist (daher) noch nicht "reverse-engineered"...

Wenn du es "reverse-engineeren" willst/kannst oder eine Quelle kennst wo das passiert ist, dann ist es sicher/wahrscheinlich/u.U. möglich es wie FS20 oder Homematic BidCos in fhem zu integrieren...

Gruß, Joachim

[Hinata]

Die Verschlüsselung findet ja anscheinend im RPI-RF-MOD statt?
https://homematic-forum.de/forum/viewtopic.php?f=65&t=68575

Das RPI-RF-MOD ist mehr als ein Funkmodul. Es hat einen Coprozessor an Board der sich unter anderem um die Verschlüsselung der HmIP Pakete kümmert.

• Wozu braucht es dann noch z.B. die RaspberryMatic? (https://raspberrymatic.de/de/home/).
• RaspberryMatic scheint selbst wiederum das HM-OCCU-SDK zu verwenden (https://github.com/eq-3/occu/ )?
  https://github.com/eq-3/occu/blob/master/KernelDrivers/Dual_Protocol_Linux_Drivers.pdf
• Wo ist der Schlüssel für das AES hinterlegt? Software/Hardware?
• Symcon kann irgendwie auch über einen BidCos-Service kommunizieren https://www.symcon.de/service/dokumentation/modulreferenz/homematic/geraeteliste/

[zap]

Selbst wenn man es schaffen sollte, das Protokoll zu entschlüsseln: dann geht die Arbeit erst richtig los. All die netten Dinge wie z.B. virtuelle Gerätegruppen, die die CCU schon mitbringt, müsste man wieder in FHEM nachbauen. Wozu?

Alle bekannten Smarthome Lösungen (ioBroker, OpenHab, ...) nutzen die git dokumentierten Schnittstellen der CCU. Nicht nur für HmIP, sondern auch für wired und bidcos. Software Projekte profitieren von APIs. Wer versucht, das Rad neu zu erfinden, wird früher oder später bestraft, spätestens, wenn sich an der Technik etwas ändert (so wie jetzt beim Wechsel von BidCos zu IP).

[Hinata]

... git dokumentierten Schnittstellen der CCU

Welche meinst du, kannst du einen Link schicken?

[zap]

RPC

https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HM_XmlRpc_API.pdf

Homematic Script: Die Teile 2 und 3 findest Du per Google:

https://www.eq-3.com/Downloads/eq3/download%20bereich/hm_web_ui_doku/HM-Skript_Teil_1_Sprachbeschreibung_V2.2.pdf

Dazu kommen ca 12.000 PDF Seiten mit der Doku aller Geräte und ihrer Datenpunkte und Parameter.

HMCCU basiert auf dieser Doku.

[jhohmann]

Ich verstehe das Problem nicht wirklich.
Selbst wenn man eine CCU braucht, kann man die virtualisiert auf demselben PI laufen lassen wie FHEM. Bei mir ist es piVCCU.
Das wäre bei deconz für Zigbee auch nicht anders. Hier wird ja auch nicht erwartet, dass FHEM von sich aus Zigbee "sprechen" kann.