Integration von Homematic IP

Der Unterschied zwischen BidCos und HomematicIP

Zur Erläuterung der Unterschiede beginnen wir mal mit den Gemeinsamkeiten. Beide Technologien basieren auf der Funkfrequenz 868 MHz und deshalb können beide auch auf den gleichen Funkchips verwendet bzw. in einem gemeinsamen Netzwerk eingesetzt werden. Die Unterschiede liegen also nicht unbedingt in der Hardware, sondern mehr im Protokoll.

• Während BidCos ein rein proprietäres Binärprotokoll ist, setzt Homematic IP auf IPv6 als Trägerschicht. Das Protokoll wird dadurch leichter verschlüsselbar und kann leichter in gewöhnliche Internet Protokoll-Pakete transformiert werden um sie anschließend z.B. in eine Cloud zu leiten.
• Beide Protokolle unterstützen die Verbindung von Geräten durch Direct Links. Das bedeutet, dass einzelne Geräte direkt miteinander kommunizieren können ohne Cloud oder ein Gateway. Das ist interessant für fest eingestellte Anwendungsfälle wie die direkte Verkopplung eines Lichtschalters mit einem Lampenaktor, oder eines Fensterkontaktes mit einem Heizkörperthermostat ohne Zwischenstation. Ich mach von dieser Option keinen Gebrauch, weil diese Kommunikation an einem zentralen Gateway vorbeigeht und dadurch nicht mit der Logik im Gateway interagiert. Einerseits erhöht das zwar die Zuverlässigkeit (keine Abhängig vom Gateway) aber auf der anderen Seite verliert das zentrale Gateway die Kontrolle über die Automatismen.
• Beide Protokolle erlauben es, dass die Geräte mit einer CCU2 aus der BidCos Welt verbunden werden und somit über dort angelegte Programme in gemeinsame Regeln eingesetzt werden.
• Bei Homematic IP Geräten ist es darüber hinaus möglich, dass die Geräte mit dem sog. Access Point gekoppelt werden. Dieses neue Gerät aus der Homematic IP Welt übersetzt das Protokoll in Internet-fähige Pakete und überträgt sie in die Cloud. Dort betreibt der Hersteller eQ3 einen Server, der es erlaubt, Programme und Regeln auszuführen, so wie es sonst die CCU tut. Es entsteht die Möglichkeit eine Gateway-freie Lösung aufzubauen und voll auf die Cloud zu setzen.

Verwendung von Homematic IP Geräten mit der CCU2

Da ich keine Direct Links verwende und die Geräte mit meinem item Manager zentral / lokal im Haus ansprechen möchte, nutze ich auch keinen Access Point mit Cloud-Schnittstelle, sondern nur meine bestehende CCU2. Die Unterstützung von Homematic IP Geräten für die CCU2 wurde per Firmware Update nachgerüstet (seit Version 2.7.14). Direct Links zwischen BidCos und Homematic IP Geräten sind auch danach nicht möglich. Aber die Geräte können in den Regeln der CCU2 (sog. Programme) beliebig miteinander kombiniert werden, so dass es aus Nutzersicht transparent ist.
Desweiteren ist noch zu beachten, dass Homematic IP Geräte lediglich direkt mit der CCU2 verbunden sein müssen. Die Nutzung eines Homematic LAN Extenders oder des LAN Gateways als Reichweitenverlängerung ist leider nicht bzw. noch nicht möglich. In einem späteren Beitrag plane ich mich mit diesem Thema zu beschäftigen.

Integration von Homematic IP Geräten in den item Manager

Die Integration in hundhome erfolgt wie bereits bei den Homematic BidCos Geräten über die CCU2 als Zwischen-Gateway. Das folgende Bild erläutert noch einmal, wie die Software der CCU2 strukturiert ist. Während das Ausführen von Regeln (sog. Programme) in der CCU2 zentral in einer Art Ausführungsumgebung als Software vorliegt (Execution Environment), werden die einzeln unterstützten Geräte-Protokolle als separate Adaptoren angebunden, die im Linux Betriebssystem der CCU2 als eigene Prozesse ausgeführt werden:

• HS485D: Prozess für die Anbindung der "Homematic wired" Geräten
• BidCos RFD: Prozess für die Anbindung von "Homematic BidCos" Geräten
• Cloud Ready RFD: Prozess für die Anbindung von "Homematic IP" Geräten

Diese drei Prozesse machen funktional das Gleiche und sie haben prinzipiell die gleiche Schnittstellenbeschreibung (XML-RPC) für Zugriffe von außen. Aber es sind autonome Software-Implementierungen, die im System getrennt laufen, auf unterschiedlichen Kommunikations-Ports ansprechbar sind und die sich im Detail auch unterschiedlich verhalten können.

Dokumentationen:

• Link: Homepage der XML-RPC Standardisierung
• Link: Schnittstellenbeschreibung XML-RPC
• Link: Schnittstellenbeschreibung XML-RPC Erweiterungen für Homematic IP

Da die Zusatz-Software XML-API unabhängig von den Prozessen läuft, sind über diese alternative Schnittstelle die Homematic IP Geräte automatisch auch unterstützt.
In meiner Implementierung des item Managers habe ich beide Homamtic Varianten in einem gemeinsamen Module realisiert. Dazu musste ich meine XML-RPC Schnittstelle (Calls und Events) für die Kommunikation mit der CCU2 erweitern bzw. anpassen. Das folgende Bild zeigt die Sequenzdiagramme für den Initialisierungsvorgang beim Starten meines item Managers sowie für das Empfangen eines Events von einem Homematic Gerät.

Start-Sequenz

Beim Starten meines item Managers in meinem hundmedia PC benutze ich zunächst nicht die Low Level XML-RPC Schnittstelle, sondern die XML-API als high Level Interface, weil dort die Geräte des BidCos Protokolls als auch die Geräte von Homematic IP zusammen angesprochen werden können. Die XML-RPC Schnittstelle nutze ich ausschließlich für das Empfangen von Events, weil dazu keine Funktion von der ansonsten einfacheren XML-API bereitgestellt wird.
Die Schritte im Einzelnen:

1. Mit dem ersten XML-API Aufruf "devicelist" frage ich eine vollständige Liste der angebundenen Geräte ab, um deren Adressen und Datenpunkte in den item Manager zu importieren.
2. Der zweite Aufruf der XML-API "roomlist" gibt die Liste aller konfigurierten Räume der CCU2 zurück mit der Zuordnung der Geräte. Damit kann ich die Meta-Daten zu meinen Geräten vervollständigen.
3. Der dritte Aufruf der XML-API "functionlist" liefert die Informationen zu den sogenannten Gewerken der Geräte zurück. Also die Information, ob ein Gerät zur Heizungssteuerung, zur Sicherheit, zur Lichtsteuerung oder z.B. zu der Rollladensteuerung gehört. Auch diese Metadaten speichere ich für jedes Gerät im item Manager.
4. Der vierte Aufruf der XML-API "statelist" liefert letztendlich die Liste der aktuellen Werte der Aktoren und Sensoren. Damit kenne ich dann jeden Zustand der Geräte.

Die folgenden Aufrufe erfolgen nun als XML-RPC Request und sie initialisieren die XML-RPC Clients, so dass diese danach Events an meinen item Manager Module als Server senden:
5. Initialisierung des XML-RPC Clients für den BidCos RFD
6. Initialisierung des XML-RPC Clients für den Homematic IP crRFD

Nach dieser Initialisierung senden die beiden Protokoll-RFDs Requests an den eigenen Server. Beide Implementierungen beginnen damit, dass sie sofort einen XML-RPC Request senden mit einer Anfrage an den bereits bekannten Geräten:
7. XML-RPC Request "listDevices" des BidCos RFD
8. XML-RPC Request "listDevices" des Homematic IP crRFD

Bei den Responses ist darauf zu achten, dass diese ordentlich kodiert sind und idealerweise eine leere Liste zurück liefern! Eigentlich kennt ja nun der item Manager bereits die Geräte aber insbesondere der Homematic IP crRFD mag es garnicht, wenn man eine valide Antwort mit den Geräten zurücksendet und stellt dann alle weiteren Requests wieder ein.
Am besten man sendet als Antwort die folgende XML-Struktur:

<?xml version="1.0"?>
<methodResponse>
   <params>
      <param>
         <value>
            <array>
               <data>
               </data>
            </array>
         </value>
      </param>
   </params>
</methodResponse>

Nach meiner Erfahrung war es tatsächlich wichtig, diese inhaltsleere Struktur genauso zu senden, damit die RFD Clients weiter arbeiten. Weicht man davon ab, indem man z.B. das element weglässt weil es ja leer ist, dann meldet sich der RFD Client nicht mehr ohne sich abzumelden oder eine Fehlermeldung zu senden.

Sequenz beim Empfangen von Events

Wenn ein Homematic Aktor oder Sensor neue Events generiert, so werden diese vom RFD Client an den item Manager Server als XML-RPC Request gesendet. Dies erfolgt in der Regel als sog. system-multicall. Das bedeutet, Events kommen immer als eine Form von Gruppen-Event an auch wenn sich nur ein Element der Gruppe geändert hat. Beim BidCos RFD kann diese Gruppe aus Events verschiedener Geräte bestehen, die sich zufällig gleichzeitig geändert haben. Beim Homematic IP crRFD sind in den Gruppen meistens alle Datenpunkte eines Geräts, auch wenn sich nur ein Wert verändert hat. Man muss also im eigenen Server die multicalls genau durchgehen und auswerten.
9. XML-RPC Request vom BidCos RFD
10. XML-RPC Request vom Homematic IP crRFD

Die Kodierung der Response erfolgt analog zu oben wieder mit einer vollständigen und leeren XML-RPC Antwort. Wieder ist es so, dass der Client seine Arbeit einstellt, wenn die Antwort nicht genau so kodiert ist, wie er es will. Fehlertolerant oder Standard-Konform ist das nicht unbedingt.

Weiterhin zu beachten: Es kann immer mal passieren, dass der crRFD seinen Client Prozess beendet ohne Ankündigung. Dann hört er einfach auf Events zu senden und man denkt, es gäbe einfach keinen Event. Deshalb habe ich einen zusätzlichen Timer eingerichtet, der den Server-Prozess neu initialisiert, wenn über einen längeren Zeitraum keine Events mehr empfangen wurden.
Darüber hinaus habe ich mehrfach beobachtet, dass sich der Client-Prozess so aufhängt, dass er keine Events mehr generiert und sich auch nicht neu initialisieren lässt. In den Fällen half nur ein manueller Neustart der gesamten CCU2.

Fazit

Es hat lange gedauert, bis ich das item Manager Module für Homematic soweit hatte, dass es auch zu dem crRFD für Homematic IP passt. Aber inzwischen bin ich bis auf die sich aufhängenden crRFD-Prozesse sehr zufrieden. Insbesondere die Homematic IP Geräte sind im Vergleich zu den frühen Homematic BidCos Geräten stabiler, stromsparender und teilweise auch schöner. Wer sich überlegt, ein neues System auf Basis von Homematic anzuschaffen, der sollte Homematic IP Geräten den Vorzug geben gegenüber den BidCos Geräten. Ich habe inzwischen mehr als 30 Geräte ausgetauscht und habe es bisher nicht bereut. Dazu gehören insbesondere die Wandtaster (2fach und 6fach), Tür/Fensterkontakte, Bewegungsmelder für innen und außen sowie die viel schöneren Zwischenstecker mit Strommessfunktion.

Bildquelle: cyberport.de

Update: Im Laufe der Monate habe ich im hundhome fast sämtliche Homematic Aktoren und Sensoren gegen HomematicIP Geräte ausgetauscht, weil diese signifikant stabiler laufen. Teilweise wurde ältere Beiträge aktualisiert, damit erkennbar ist, welche Geräte aktuell zum Einsatz kommen.