Unbekannte Funkprotokolle

Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber wenn es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

Basics

Hardware

Neben den bekannten Hardware-Dongles gibt es Selbstbaulösungen in Form eines SIGNALduino, CUL oder JeeLink.

Diese unterscheiden sich in verschiedener Hinsicht:

• Sendemodul (SIGNALduino/CUL -> CC1101; JeeLink -> RF12B) [1]
• Modulationsverfahren (OOK, ASK/FSK)
• Frequenzband (433 MHz, 868 MHz)

Frequenzbereich

Für die funkbasierte Heimautomation werden im Wesentlichen zwei Frequenzbänder in Frage: 433 und 868 MHz.

Alle Geräte sollten auf der Rückseite ein Typenschild haben auf dem das Frequenzband ausgewiesen ist. Das klärt zunächst einmal die Frage ob 433 oder 868 MHz.

Dann gibt es noch 2,4 GHz(WLAN, Bluetooth...), das Frequenzband wird in diesem Artikel aber nicht betrachtet.

Modulationsverfahren

So wie vom Rundfunk her bekannt (AM/FM) kennt auch die Heimautomation verschiedene Modulationsverfahren.

• OOK/ASK/Amplitudenabtastung

Das Signal des Senders wir auf der angegebenen Frequenz ein-/ausgeschaltet um die Dateninformationen zu übermitteln.

• FSK/Frequenzumtastung

Der Sender überträgt den Datenstrom indem, ausgehend von der Trägerfrequenz, zwischen Frequenzen (z.B. Frequenz-Frequenzhub, Frequenz+Frequenzhub) hin- und hergeschaltet wird. Dieses Verfahren kennt verschiedene Ausprägungen: 2-FSK, 4-FSK, GFSK (Details siehe hier).

Encoding oder auch Leitungscode

Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

• Leitungscode (Einstieg)
• NRZ
• Manchester

Je nach verwendetem Encoding wird ggf. mehr als 1 Übertragungs-Bit für ein Datenbit benötigt. Der Empfänger erwartet z.B. einen Bitwechsel zu einem bestimmten Zeitpunkt. Eine Abfolge

• 100 (short high, long low) wird als 0
• 110 (long high, short low) wird als 1

interpretiert.

Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.

Signalstruktur

Ein typischer Aufbau eines sieht z.B. so aus

| Pause | Sync | Pause | Daten |

• eine größere Pause zur Trennung der Sequenzen
• ein Sync-Block mit dem sich der Empfänger auf den Sender einstellt
• eine Pasue um Sync und Daten zu trennen
• die eigentlichen, zu übertragenden Daten.

Es müssen nicht immer alle Bestandteile in der übertragenen Signalstruktur vorkommen (Details siehe auch Datenpräambel oder auch Syncword).

Die Sequenz wird ggf. mehrfach wiederholt

| Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | Pause | Sync | Pause | Daten | ...

Protokoll

Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Defintion der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragebn, es gibt aber auch rollierende Codes bei denen sich die Daten bei jeder Übertragung ändern.

Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passenden Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

Wie fange ich an?

Recherche

Sucht im Internet nach Informationen zu dem fraglichen Device. Zu bekannten Devices sollten sich Informationen finden lassen die einem weiter helfen. Solltet Ihr fündig werden, verfolgt die Hinweise wie diese Devices in FHEM eingebunden werden können.

Wenn sich nichts Verwertbares finden lässt geht's mit dem nächsten Abschnitt weiter.

Ansatz 1 - Versuchen

Egal, ich probier's halt mal (So hat mein Weg zum Erfolg begonnen. Wäre ich ihn nicht gegangen hätte ich heute (wenn überhaupt) eine ganz andere Lösung.). Bau Dir einen SIGNALduino für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die nominelle ein (cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

Ist ein Gerät in Reichweite das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn autocreate aktiv ist werden auf Basis der erkannten, bekannten Funktporokolle automatisch neue Devices angelegt (nicht wundern wenn diverse Funkthermometer der Nachbarschaft auftauchen).

Ist es ein Gerät das sich über eine Fernbedienung steuern lässt: Betätigt eine Taste und hofft, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechende Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier Intertechno_Code_Berechnung) nach.

Solltet Ihr mit diesem Ansatz Erfolg haben ist das schon mal gut - Euer Gerät sendet ein bekanntes Protokoll und wird unterstützt.

Solltet Ihr etwas empfangen (MC, MS, MU), aber keine neuen Devices sehen, wird Euer Gerät möglicherweise noch nicht unterstützt. Jetzt gibt es zwei Varianten

• es handelt sich um ein neues, noch nicht bekanntes Protokoll -> postet einen Log-Ausschnitt auf github wie im SIGNALduino-Wiki vorgeschlagen)
• es handelt sich um etwas proprietäres, altes oder ähnlich kompliziertes (nicht aufgeben, weiterlesen)

Ansatz 2 - Aufschrauben

Fernbedienung aufschrauben, schauen welcher Chip dort verbaut ist. Endgerät/Device aufschrauben, schauen welcher Chip dort verbaut ist.

Das Teil ist zu klein? Abfotografieren und das Foto vergößern bis Ihr den Aufdruck lesen könnt.

Danach folgt dann Google und das Studim der zugehörigen Data Sheets der Chips.

Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen die die Chips unterstützen.

Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen

• OOK-Modulation -> SIGNALduino
• ASK/FSK -> Selbstbau_CUL oder JeeLink

Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.

Ansatz 3 - Messen

Ihr nutzt einen Spektrumanalysator. Es gibt verschiedene preisgünstige Ansätze.

• Zum einen könnte Ihr den nrfmon-Ansatz verfolgen (siehe hier). Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
• Der andere Ansatz nutzt mit einem DVB-T-Stick (siehe z.B. hier. Es gibt aber viele Google-Treffer unter dem Stichwort SDR.
• Mein persönlicher Favorit ist der Universal Radio Hacker. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.

Die Spektrumanalyse gibt Aufschluss über

• das Modulationsverfahren (OOK vs. FSK) sowie
• die relevante(n) Frequenz(en)

SIGNALduino - OOK

Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Log-Meldungen

Der SIGNALduino empfängt die Rohdaten, ermittelt identische Zeitscheiben und ordnet diese den Zahlen 0-7 zu (P0...P7). Ein negativer Zahlenwert bedeutet "kein Empfang" und ein positiver "Signal empfangen". Damit lässt sich der Datenstrom analysieren und für das Sender auch wieder generieren. Die Zahlen stehen für Mikrosekunden

P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;

Was bedeutet D=012323...?

0 -> P0=-13020 => 13.020 Mikrosekunden Pause

1 -> P1=15916 => 15.916 Mikrosekunden Signal

2 -> P2=-398 => 398 Mikrosekunden Pause

3 -> P2=415 => 415 Mikrosekunden Signal

2 -> P2=-398 => 398 Mikrosekunden Pause

3 -> P2=415 => 415 Mikrosekunden Signal

...

Frequenz ermitteln

Das folgenden Beispiel geht wir davon aus, dass Ihr im 868 MHZ-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststell, ob Ihr Euch der Sendefrequenz nähert oder entfernt.

Wenn Ihr nun Frequenzen gefunden habt bei denen Ihr etwas empfangt, dann könnt Ihr die bWidth jeweils halbieren und den Bereich, in dem etwas empfangen wurde, mit halbierter Frequenz-Schritteweite weiter durchforsten. Das macht Ihr so lange, bis bWidth bei 58 kHz angekommen ist. Damit sollte sich die gesuchte Trägerfrequenz herauskristallisieren.

Selektiver Empfang

Am sichersten geht man selektiv vor - einen Message-Typ nach dem anderen testen. Im SIGNALduino kann man über das set-Command disableMessagetype die Interpretation als MC, MS und MU selektiv ausschalten. Man kann mit MC beginnen und danach beobachten, ob bei aktivem MS + MU Dekoder jeweils nur eine Art von Nachrichten gibt.

Sobald man sieht, dass die Meldungen im FHEM-Log wechseln, die Message-Typen MS, MU bzw. MC mit nur einem aktiven Dekoder aufzeichnen.

Das sollte Anhaltspunkte geben worauf der S'duino am Besten reagiert.

Variationen

Solltet Ihr verschiedene Fernbedienungen für die Produktfamilie besitzen oder so wie ich eine die 8 Rolllädenmotoren bedienen kann, könnt Ihr bei nicht dokumentierten Protokollen trotzdem die Funktion der einzelnen Bytes herausarbeiten.

Spielt jede Tastenkombinastion durch, extrahiert die Meldungen aus dem FHEM-Log und legt sie in separaten Dateien ab die ihr z.B. mit Motor, Richtung, Fernbedienung kennzeichnet.

Signal analysieren

Habt Ihr nun den Punkt erreicht an dem Ihr reproduzierbar Code-Sequenzen im FHEM-Log seht, geht es ans entschlüsseln. Auch hier wieder der einfache Fall: SIGNALduino kennt den Hersteller bzw. Device-Typ schon und legt automatisch ein FHEM-Device an.

Wenn ein Signal demoduliert wurde ist man den Bits und Bytes schon einen Schritt näher gekommen.

Gehen wir wieder von unserem Beispiel aus:

P0=-13020;P1=15916;P2=-398;P3=415;P4=4008;P5=-794;P6=812;D=01232323232323232323232324532653265353532653262653265326 26262626265353532653265326532653535326265353535353265353532653262653265353265353535353535353265326;

Wie ist diese Seuqnz zu interpretieren?

• Es startet mit einer Pause D=0123232323232
• gefolgt von einem Signal D=0123232323232 in der Länge von ca. 16 ms.
• danach folt ein Sync-Block D=0123232323232... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
• Sync- und Datenteil sind durch einen Puls von 4 ms getrennt D=0123232323232323232323232453265
• gefolgt vom Datenteil D=0123232323232323232323232453265....

Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

Beispiel: Den Vorspann P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324 lassen wir mal außen vor und konzentrieren uns auf die Daten

53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL

1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100

AD99 79A2 9FBC B7FC

Die Analyse basiert auf folgenden Annahmen

• Ist der Wert kleiner 0 (z.B. -800) ist ein l (long low), > 0 L (long high), sS sind die 400-ter (short low/high).
• Weiter angenommen es werden immer 2 Frequenzen/Zustände verglichen (lS => 1 und sL => 0).

Sollte man mit dem SIGNALduino ein FSK-Signal empfangen/interpretieren, hängt die Bewertung davon ab, ob man die Sendefrequenz+Frequenzhub oder Sendefrequenz-Frequenzhub empfängt. Die Bedeutung von 0/1 wird dann negiert.

Steuern

Die empfangenen, im Log ausgewiesenen Sequenzen könnt Ihr als Basis für das Senden verwenden. Relevant sind dabei P0...P7 sowie D (Data). Die RSSI-Empfangsstärke wird beim Empfang als R= ausgewiesen. Beim Senden steht R für die Anzahl der Wiederholgen. Entnehmt die Details und Möglichkeiten bitte der Dokumentation Commands.

CUL - FSK und Co.

Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Es befindet sich aber noch im Aufbau....

Links

• Signalanalyse für Dummies
• Universal Radio Hacker
• Intro SDR and RF Analysis
• Signal Identification Guide
• Unknown Signal Reverse Engineering and Decoding AFSK Signals Tutorial