HomeMatic:      Aufbau   ·   Kleine Schritte   ·   «Protokolle»   ·   Bootloader   ·   Firmware

Das ewige Hin und Her: Protokolle


BidCoS, das HomeMatic Protokoll

Alle HomeMatic Komponenten sind mit dem TI CC1100 Transceiver ausgestattet. So lnage alle Transceiver gleich programmiert sind, kann jedes Gerät mit jedem anderen kommunizieren. Alle Geräte können immer alle Nachrichten hören (es sei denn, man hat zu wenig Reichweite und setzt Repeater ein).

Also brauchen wir ein Protokoll, um Ordnung in die Sache zu bringen. eQ-3 hat sich dafür BdCoS ausgedacht, verrät uns Bastlern aber nicht die Details. Das ist nicht sonderlich schlimm, denn die können wir uns erabeiten. Ausserdem existieren schon einige Resourcen im Netz, die viele Details schon enträtselt haben. Ich denke bei so etwas immer an ein riesig grosses Sudoku Rätsel. In diesem Fall sind schon viele Felder ausgefüllt.


Generelles Funktionprinzip

HM Geräte kommunizieren entweder mit einer Zentrale, oder direkt mit anderen HM Geräten, (oder sogar beides?). Die Zentrale hat ier eine echte Sonderstellung. Es kann auch immer nur mit einer Zentrale zusammen gearbeitet werden.

Pairing: (Päarchen) beim Pairing wird dem HM Gerät erklärt, wer seine Zentrale ist. Die Zentrale schaltet in den Anlernmodus. Dann drückt mann den Lernknopf am Gerät, dass sich dann an der Zentrale anmeldet. Danach hört das Gerät nur noch auf diese Zentrale.

Peering: (Kumples) beim Peering werden zwei HM Geräte aneinander gekoppelt. Das eine Gerät muss dabai immer ein Sensor/Taster sein, und das andere muss immer ein Aktor sein. Ein Sensor kann mehrere Aktoren steuern, ein Aktor kann auf mehrere Sensoren hören. Als Befehle gibt's im Lichtbereich An, Aus, Toggle, Heller, und Dunkler.

Wenn also ein Sensor einen Event feststellt (Bewohner drückt eine Taste), dann sendet der Sensor eine Meldung an die Zentrale (Pairs) und an alle angelernten Geräte (Peers). Die Zentrale wertet den Event aus und sendet u.U. weitere Events and Aktoren. Alle Aktoren quittieren die Befehle. So weiss z.B. die Zentrale, dass ein Taster eine Steckdose eingeschaltet hat, und dass die Steckdose dies auch getan hat.

Unser Sorgenkind, der UP Schaltaktor, macht das leider nicht so. Die An-Aus-Wippe zählt nicht als Sensor, sondern als "interner" Schalter. Immerhin sendet der Aktor trotzdem noch eine Statusmeldung, so dass die Zentrale verspätet weiss, dass irgendwann mal etwas passiert ist. So kann man aber z.B. keine Wechselschaltung aufbauen.

Aber um das in Ordnung zu bringen, dafür sind wir ja hier.


Beschränken auf das Wichtigste

Wir wollen also etwas ganz bestimmtes: mit unserer neuen Firmware soll sich der HM UP Schaltaktor wie zwei Geräte verhalten. Einmal wie ein einfacher Relais-Aktor, und ausserdem wie ein Batterietaster. So soll sich das Gerät dann auch bei der Zentrale anmelden. Somit hätte man dann die Möglichkeit, zwei UP Schalter gegenseitig zu Peeren und einen Wechselschalter ohne nennenswerte Verzögerung zu bauen.

Was wir also brauchen sind die Protokolle vom:

  • HM-LC-Sw1PBU-FM - Funk-Schaltaktor 1-fach, UP
    • Ziel ist die Wiederherstellung des Aktor-Verhaltens trotz Austausch der Firmware.
  • HM-PB-2-WM55 - Funk-Wandtaster 2-fach, AP
    • Ziel ist die Übertragen des Sensorverhaltens auf den UP Schaltaktor
  • HM-LC-Sw1-Pl - Funk-Zwischenstecker-Schaltaktor 1fach
    • dieses Gerät soll direkt gesteuert werden

Alle weiteren Protokolle zur Heizungssteuerung, Fensterkontrolle und zum Dimmen von Licht soll zunächst aussen vor bleiben. Vielleicht ergänzen wir all das später. Es gäbe noch einige andere wichtige Dinge zu dem Protokoll, wie z.B. echte Verschlüsselung, zentralenlose Vernetzung usw., aber das würde hier und jetzt den Rahmen sprengen.


Jeder hat sein Paket zu tragen

Die Pakete zwischen den Geräten werden in alle Richtungen auf einer öffentlichen Frequenz versandt. Es ist also ein Leichtes, die Pakete mitzuschneiden, und dann auch zu verstehen. eQ-3 hat die Paketinhalte zwar verschleiert, aber nicht verschlüsselt, oder besser noch, rolling codes benutzt.

Hat man also einmal den XOR Algrhitmus verstanden, dann lassen sich per CUL (Busware)und Terminal Programm alle Pakete munter mitschneiden und verstehen.

Jedes Paket enthält einen Header, der u.a. die Paketlänge bestimmt. Alles was nicht zum Header gehört ist dann Payload, also Daten, die das Paket mitnimmt, ohne sie weiter zu beschreiben. Der Empfänger erkennt dann entweder die Payload am Message Type, oder ignoriert den ganzen Block.

Die Beschreibung der Payload findet man dann ohne grosse Umstände im CCU Firmware Image als XML Datei, inklusive aller "versteckten" Protokolle zur Abfrage der Batterie, etc. . Also auch wenn BidCoS nicht öffentlich ist, so hat eQ-3 das Format auch nicht wirklich geschützt.

  • HM-LC-Sw1PBU-FM ist in rf_s_1conf_644.xml beschrieben
  • HM-PB-2-WM55 ist in rf_rc_wakeup.xml beschrieben
  • HM-LC-Sw1-Pl ist in rf_s.xml, rf_s_le_v1_5.xml und rf_s_mega168.xml beschrieben

Die CCU Firmware beinhaltet sogar eine ganze Reihe von Firmware-Dateien, mit denen wohl einzelne Geräte per Funk auf den neuesten Stand gebracht werden können. Da frage ich mich, ob alle Geräte einen versteckten Bootloader bereits besitzen. Ausserdem könnte man natürlich auch eine solche Firmware disassemblieren. Aber das Resultat zu interpretieren ist sehr sehr mühsam.


Der Plan schlüpft

Achja, die Anglizismen: now lets hatch a plan:

Wir kennen die Parameter aller relevanten Pakete. Wir kennen die grundsätzliche Funktion. Wir können alle Pakete mitlesen und übersetzen. Mit CUL und FHEM können wir die meissten Pakete auch erzeugen. Das sind ganz hervorragende Voraussetzungen.

Als nächstes müssen wir also:

  • die Programmierung der Geräte vereinfachen (OTA Bootloader)
  • die Paketfolge erforschen
  • die Paketfolge in einer neuen Firmware nachprogrammieren

Das wird spannend.


Grundsätzliches Paketformat

Alle Pakete, die von der CCU oder jedem beliebigen Gerät verschickt werden können mit einem Gerät names "CUL" mitgelesen werden. Die Pakete aheb einen Header und eine grundsätzliche Ordnung, sind aber für jedes Gerät mal weniger, mal mehr modifiziert.

Hier aber erst einmal das Header Format:

Der Header ist immer 10 bytes lang, wobei die ersten zwei Bytes automatisch generiert werden und bei den Referenzen in den XML Dateien nicht gezählt werden. Das Byte mit dem iIndex 9 ist also das ersten Byte in der Payload. Die Payload ist Teil des Paketes und folgt unmittelbar nach dem Header.

  • Byte 0 ist die Länge des Pakets in Bytes. Der Header wird hier mit 8 Bytes mitgezählt.
  • Byte 1 (idx 0) ist die Nummer des Vorgangs. Im allgemeinen wird diese Zahl einfach nur hochgezählt. Beim ACK wird die gesendete Vorgangsnummer wieder zurück gesendet. Bei komplexeren Vorgängen wird diese Zahl auch mal nicht weitergezählt.
  • Byte 2 (idx 1) enthält verschieden Flags, deren Bedeutung ich leider noch nicht kenne
  • Byte 3 (idx 2) ist der type des frames, also der Befehlsindex. Dieser kann für jedes Gerät anders sein und andere Parameter haben. Ein paar Typen sind jedoch für alle Geräte gleich:
    • 0x00: info?
    • 0x01: learn?
    • 0x02: ack/nack
  • Byte 4-6 (idx 3, 4, 5) ist die HardwareID des Senders
  • Byte 7-9 (idx 6, 7, 8) ist die HardwareID des Empfängers, oder 000000 für Broadcasts
  • das optionale Byte 10 (idx 9)und folgende enthalten Daten abhängig vom type und vom Gerät. In XML hat dieses Byte den index 9!