Hagen Fritsch

3 Wege zum Funksteckdosen hacken

Steckdosen mit Funkfernbedienung sind super praktisch, wären aber noch praktischer wenn man nicht auf die Fernbedienung angewiesen wäre.
Vor einiger Zeit habe ich mir günstige ALDI Funksteckdosen (Tevion GT-9000) besorgt und gehofft, diese recht einfach mit einem Gerät wie der CUL ansteuern zu können. Leider Fehlanzeige, unbekanntes Protokoll, hat noch keiner vorher gemacht etc. Für die ebenfalls günstig zu erstehenden Intertechno (ELRO) Steckdosen gibt es genug Material im Internet, aber diese hier sind doch etwas hartnäckiger.

Die CUL erlaubt später Kommandos zu senden, kann bequem an den Router angeschlossen werden und über FHEM kann man dann über das Smartphone und Apps die Geräte steuern.

Funksteckdosen sind zumeist sehr einfach gestrickt. Sie senden recht kurze Datenpakete mittels einfachem ASK/OOK.

Methode 1: Timings und Daten via CUL auslesen

Die CUL hat einen Monitor Mode, der einem die Zeit seit der letzten rising/falling flank ausgibt. Die bisherige Version hatte ein paar Fehler was die Timings insbesondere am Anfang und Ende von Paketen betraf (siehe auch), aber in github:rumpeltux/culfw/tree/tevion gibt es eine verbesserte Version. Zunächst also die CUL anstecken und aktualisieren:

git clone https://github.com/rumpeltux/culfw.git
cd culfw
git checkout tevion
cd culfw/Devices/CUL
make TARGET=CUL_V3 MCU=atmega32u4 build size
echo 'B01' > /dev/ttyACM0 # Reboot the device for flashing
make usbprogram_v3

Meines Erachtens sehr hilfreich ist auch LONG_PULSE anzuschalten, damit werden auch Pakete > 4ms korrekt geloggt.
Dazu einfach: #define LONG_PULSE in die Datei board.h eintragen und mit obigen Schritten neu kompilieren und flashen.

Mit folgendem Befehl startet man den Monitor Mode:

echo X98 > /dev/ttyACM0

Allerdings ist die binäre Ausgabe davon zunächst vollkommen unbrauchbar. Zur Analyse kann das raw_analysis.py tool verwendet werden, das versucht aus einem raw dump die gesendeten Paketdaten und -parameter herauszufinden.

Als erstes werden einige Daten aufgezeichnet, die im Anschluss analysiert werden.

python tools/raw_analysis.py --pause 4000 --plot /dev/ttyACM0

Nun die gewünschte Taste auf der Fernbedienung drücken, ggf. gedrückt lassen damit mehr Pakete gesendet werden und dann Ctrl+C zum Abbrechen der Aufzeichnung drücken. Mit --plot bekommen wir einen Plot der Daten um zu sehen was aufgezeichnet wurde:

python tools/raw_analysis.py --pause 4000 --plot /dev/ttyACM0

Plot of Hightimes & Lowtimes of the received signal

Die Höhe der Ausschläge ist die Signalqualität, die Zeitachse ist in ms, wobei die Pause zwischen Paketen nicht angezeigt wird, aber ein Paketende durch eine Schräge angezeigt wird (z.B. ganz am Anfang im Bild). Auch das Kodierungsschema für Bits ist klar erkennbar: kurz-lang für eine 0, lang-kurz für eine 1.
Wenn wir den Plot schließen sehen wir auch eine Liste der erkannten Pakete. Manche sind 1 bit zu kurz, aber oft wurden sie richtig erkannt.
Hier stehen auch die erkannten Timings (in Einheiten zu je 16μs):

Global Timings: [28, 62, 56, 33] (hi0, lo0, hi1, lo1)

  • ‘0’ Hightime: 28 (=0.45ms)
  • ‘0’ Lowtime: 62 (=0.99ms)
  • ‘1’ Hightime: 56 (=0.90ms)
  • ‘1’ Lowtime: 33 (=0.53mμs)
Auch die eigentlichen Paketdaten werden gemessen. Hier haben wir es also mit Paketen bestehend aus je 24bit + 1 einem Sync-Bit zu tun. Pausezeiten wurden ebenfalls gemessen und das Tool spuckt einem einen CUL Befehl aus, der ein ähnliches Paket zu senden versucht.

Mit etwas Glück reicht es, diesen Befehl an die CUL zu schicken und die Steckdose schaltet. Leider sind die gemessenen Timings nicht immer 100% akkurat (bei mir habe ich z.B. einen leichten Bias bzgl. einer zu kurz gemessenen hightime festgestellt), es lohnt sich also die Werte ein bisschen zu variieren. Zum Bau der CUL Kommandos zum Senden der Pakete ist das tool in docs/rawcmd.html ebenfalls sehr hilfreich.

Hat man weiterhin keinen Erfolg, kann man mit folgenden Mitteln nochmal genauere Daten bekommen, die dann hoffentlich ausreichen, um die entsprechenden Kommandos zu konstruieren.

Methode 2: Timings mit der Soundkarte analysieren

Diese absolute low-cost Variante reicht zumindest zum Sniffen der Daten vollkommen aus. Zum Senden benötigt man dann wieder Hardware wie z.B. die CUL oder günstig erhältliche 433 Mhz Sender, die man dann z.B. mit einem Arduino oder Raspberry Pi steuern kann. Zur Analyse nehme ich Baudline, aber eigentlich tut auch jeder andere Audioeditor in dem man die Waveform des Signals sehen kann.

Ich habe ein Cinch-Kabel genommen in den Mikrofoneingang gesteckt und das andere Ende des Kabels auf verschiedene Pins der Fernbedienung gehalten in der Hoffnung, dass auf einem der Pins ein Signal wahrnehmbar sein wird, das etwas mit dem gesendeten Funksignal zu tun hat. In der Tat, ist das fast auf jeder Pin der Fall und das Signal sieht dann z.B. wie folgt aus:
Baudline: Headphone Jack

Man sieht zwar nur die Übergänge, aber das reicht um das Signal rekonstruieren zu können schon aus.
Die Timings können wir diesmal ganz exakt ablesen:
Kurz ist 0.5ms und lang 1ms. Ein Bit also immer 1.5ms. Nach jedem Paket folgt ein syncbit mit einer hightime von 2.8ms und einer lowtime (Pause) von 6.7ms.

Die Daten könnte man demnach hier auch manuell dekodieren, aber das hat das raw_analysis Tool in Methode 1 bereits für uns getan. Auch hier hilft letztendlich wieder  docs/rawcmd.html beim Erstellen eines Pakets mit den gemessenen Daten/Timings.

Methode 3: RTLSDR

Statt der Soundkarte, kann man auch ein Software Radio zur Aufzeichnung benutzen und muss nun die Fernbedienung nicht einmal mehr aufmachen bzw. könnte z.B. auch nach Signalen der Nachbarn suchen. Dank eines DVB-T Sticks der sich als Software Defined Radio missbrauchen lässt (siehe RTLSDR), gibt es kompatible Hardware zur Aufzeichnung bereits unter 15€.

Nun einfach auf die gewünschte Frequenz tunen und die Aufzeichnung starten:

rtl_sdr logfile.raw -s 2e6 -f 433.92e6

Anschließen kann man sich die Daten z.B. wieder mit Baudline ansehen:
baudline -reset -basefrequency 433920000 -samplerate 2000000 -channels 2 -format u8 -quadrature -stdin < logfile.raw
Baudline Graph showing the recorded waveform

Auch hier kann man die Timings wieder exakt ablesen. Man sieht auch, dass das lange Sync Bit und die anschließende Pause, die am Ende von jedem Paket kommt, eigentlich den Beginn eines Pakets signalisiert, aber da man beim Senden die Pakete eh ein paar Mal wiederholt, ist das zu vernachlässigen.

Zu guter Letzt: Benutzung der Befehle in FHEM

Die raw Pakete, die man mit der CUL sendet, kann man auch zur Steuerung in FHEM einsetzen. Mit andFHEM lassen sie sich dann auch per App steuern. Hier eine Beispielkonfiguration:

define Stehlampe dummy
attr Stehlampe onOffDevice false
attr Stehlampe room Wohnzimmer
attr Stehlampe setList on off
define taste_1_1_An notify Stehlampe:on set CUL raw G0030751f3e3e1fb6012345
define taste_1_1_Aus notify Stehlampe:off set CUL raw G0030751f3e3e1fb6abcdef

Ich hoffe mit den Tools und Methoden lassen sich weitere Geräte und Protokolle noch schneller untersuchen und dann auch leicht in die Heimautomatisierung einbinden.

22 Kommentare zu “3 Wege zum Funksteckdosen hacken”

  1. Stefanam 05.03.2014 um 8:14 pm

    Hi,

    vielen Dank für das super Tutorial. Ich bin jetzt soweit das ich die Hex-Daten am PC aufzeichnen kann, leider hast du kein link zu deinem Python Script (raw_analysis.py) angegeben. Wo finde ich das denn?

    Vielen Dank,

    Stefan

  2. Hagen Fritscham 06.03.2014 um 6:25 pm

    Das Tool findest du hier: https://github.com/rumpeltux/culfw/blob/tevion/culfw/tools/raw_analysis.py
    Zu beachten ist, dass es nur mit der CUL firmware aus dem selben Branch funktioniert, da die originale CUL firmware ein paar Fehler drin hat.

  3. Stefanam 07.03.2014 um 8:19 pm

    Hi,

    hab jetzt alles soweit am laufen aber leider scheint irgendetwas mit der Formatierung nicht zupassen. Was für eine formatierung muss den die input datei haben? selbst wenn ich das script direct auf dev/ttyAMC0 als input laufen habe funktioniert es nicht…:
    Error: UnexpectedData 20 ( ): Expected Status Indicator
    Error: UnexpectedData 20 ( ): Expected Status Indicator
    Error: UnexpectedData 20 ( ): Expected Status Indicator
    Error: UnexpectedData 20 ( ): Expected Status Indicator
    Error: UnexpectedData 74 (t): Expected Quality Indicator (a..z / A..Z)
    Error: UnexpectedData 20 ( ): Expected Quality Indicator (a..z / A..Z)
    Error: UnexpectedData 75 (u): Expected Quality Indicator (a..z / A..Z)
    Error: UnexpectedData 20 ( ): Expected Quality Indicator (a..z / A..Z)
    Error: UnexpectedData 78 (x): Expected Quality Indicator (a..z / A..Z)
    Error: UnexpectedData 0a (

    und so weiter und so weiter…

    Vielen Dank für deine Hilfe,

    Stefan

  4. Jürgenam 18.03.2014 um 7:23 pm

    Hallo,
    ich bin FHEM Anfänger, daher folgende Frage: Der CUL Befehl G0030 heißt ja 1 Sync bit, 3Byte+0bit Daten, also 24 bit. Das steht ja auch oben so. Aber nach dem Timing 1f3e3e1f kommen dann b6012345 bzw. b6abcdef, sind das nicht 4 Byte ? Warum steht sowohl bei “on” b6, als auch bei “off” bzw. gehört das b6 zur Adresse, und was ist dann der “on” und der “off” Code ?
    Vielen Dank für die Antwort !
    Gruß
    Jürgen

  5. Hagen Fritscham 19.03.2014 um 8:48 am

    Das hast du richtig bemerkt. Die angegebenen Befehle beziehen sich auf den tevion branch der CUL firmware (wie in Methode 1 beschrieben) in der das G…-Kommando einen zusätzlichen Parameter enthält: „High-Time for the final 1-bit, Unit is 16us“ (siehe https://github.com/rumpeltux/culfw/blob/c4fe172f23294d2b61a5967c9eae3bd8ed318809/culfw/docs/commandref.html#L456)
    Ohne diese Modifikation gelang es mir nicht die Funksteckdosen zu schalten. Bei anderen mag das anders sein und ev. reicht es aus, für die reguläre CUL firmware diesen letzten Parameter (b6 in dem Beispiel) zu entfernen und trotzdem das gewünschte Ergebnis zu erzielen.

  6. Hagen Fritscham 19.03.2014 um 8:50 am

    Hallo Stefan, bist du ganz sicher, dass du die CUL firmware aus dem Tevion-Branch benutzt hast? Ansonsten verschluckt manchmal auch das seriell-nach-USB interface Pakete wodurch das data-reporting die Synchronisation verlieren kann und solche Meldungen erscheinen könnten.

  7. Jürgenam 19.03.2014 um 7:36 pm

    Hallo Hagen,
    vielen Dank für die Info. Ich beschäftige mich schon länger mit diesen Dosen, und habe die Platine analysiert. Es ist ein BL35p02 uController verbaut, der die Tasten nach folgender Matrix pollt:

    Ausgang Eingang
    PB7-PB4 PA7-PA0
    Aon 1101 xxx110xx hex dfb oder fbd
    Aoff 1101 xxx101xx hex df7 oder f7d
    Bon 1011 xxx110xx hex bfb oder fbb
    Boff 1110 xxx110xx hex efb oder fbe
    Con 1011 xxx101xx hex bf7 oder f7b
    Coff 1110 xxx101xx hex ef7 oder f7e
    Don 1011 xxx011xx hex bef oder efb
    Doff 1110 xxx011xx hex eef oder efe
    Mon 0111 xxx110xx hex 7fb oder fb7
    Moff 0111 xxx101xx hex 7f7 oder f77

    Die Dosen könne auch angelernt werden, und schalten dann auch mit einem Standard CUL EIN und Dimmen mit diversen Codes zB.

    G0030751f3e3e1f000dfb ( Aon)
    G0030751f3e3e1f555dfb ( Aon)
    G0030751f3e3e1f888dfb ( Aon)
    G0030751f3e3e1f999dfb ( Aon)
    G0030751f3e3e1f000bfb ( Bon)
    G0030751f3e3e1f000bf7 ( Con)
    G0030751f3e3e1f000bef ( Don)
    G0030751f3e3e1f0007f7 ( Mon)

    aber AUS-schalten geht nicht.

    könntest Du mir als Beispiel zwei, drei Ein und Aus Codes geben, die Du gefunden hast. Ich werde dann versuchen die anderen Codes zu finden.
    Gruß
    Jürgen

  8. Daniel Sam 14.04.2014 um 6:04 pm

    Hallo Stefan, Hallo Hagen,

    ich habe das gleiche Problem wie Stefan und habe definitiv den Tevion-Branch benutzt.

    Woran könnte der Fehler noch liegen?

    Grüße

    Daniel

  9. steffenam 10.02.2015 um 11:36 am

    Hallo,

    ich versuche gerade in Signal in FHEM per CUL zu senden aber ich komme nicht rauf, wie ich das Signal für FHEM und CUL umwandel kann. Hier erst mal die Aufzeichnung.

    Start Bit L: 10060 H: 10076
    Data Bits: 24
    L: 1524 1524 520 520 1528 1528 1528 524 1528 524 524 524 524 1528 524 1524 524 524 520 524 520 524 520 1528
    H: 496 496 496 496 492 492 492 492 492 492 492 492 492 492 492 492 492 492 492 492 492 492 492 492
    AVG : 899 110011101000010100000001

    Wie muss ich das umwandeln, damit das FHEM und CUL verstehen und senden können.

    Danke
    Steffen

  10. Thomasam 03.04.2015 um 12:04 pm

    Hallo

    Ich habe folgende Konfiguration:

    FHEM, upgedatet

    nanoCUL v1.63, jeweils auf Arduino Nano 3.0, einmal mit CC1101 433MHz und einmal mit CC1101 868MHz

    Ich kann mit den Befehlen

    set nanoCUL868 raw is000000FFFFFF
    set nanoCUL868 raw is000000FFFFF0
    set nanoCUL433 raw is000000FFFFFF
    set nanoCUL433 raw is000000FFFFF0

    eine andere Steckdose schalten. Die beiden senden also.

    Nun habe ich mir bei Aldi Quigg Steckdosen gekauft:

    Fernbedienung Globaltronics GT-9000 433,92 MHZ
    Schalter GT-FSI-09

    Weiterhin habe ich mit dem Mikrofon Eingang am PC die Bitfolge für den Schalter 1 ausgelesen:

    1 AN
    00100001 01010000 01011100
    1 AUS
    00101000 11110101 10001100

    Das und folgende Werte habe ich dem culfw Raw Command Generator gefüttert und den RAW Code

    G003075203f3f1f1f21505c

    erhalten, geht aber nicht. Mit keinem der beiden CUL’s.

    Ich sehe in AUdacity deutlich die 4 Pausen mit den darauf folgenden Bitfolgen, also 5 REPEAT.

    Bei 96kHz Sampling Rate habe ich folgende Timings gemessen:

    0 HIGH 50 samples 521us
    0 LOW 98 samples 1021us
    1 HIGH 98 samples 1021us
    1 LOW 49 samples 510us

    PAUSE 685 samples 7135us -> 7ms
    Snyc Bit 292 samples 3042us

    Final HIGH habe ich auch auf 510us gesetzt, aber ich bin mir nicht sicher, was damit genau gemeint ist. Sync Bits habe ich mit 0 und 1 probiert, weil ich mir auch hier nicht sicher war wie es gemeint ist.

    Weiterhin habe ich natürlich auch ein wenig mit den Timings rumgespielt, aber hat nichts gebracht.

    Ehe ich weiter versuche Stelle ich hier folgende Fragen:

    Habe ich die Werte für

    REPEAT
    Final HIGH
    Sync Bits

    richtig eingestellt?

    Für was stehen die Bits vor den 5 Code Wiederholungen?

    Bilder habe ich hier:

    https://www.dropbox.com/sh/opu2up4a2xrbtml/AABN0BqMHYWDczwS7M8cXLh2a?dl=0

    in die Dropbox gelegt und kann weitere gerne hinzufügen.

    Danke, Thomas

  11. Hagen Fritscham 27.09.2015 um 10:54 am

    Hallo Steffen,
    du kannst das Tool docs/ramcmd.html benutzen um das Kommando für deine Timings / Daten zusammenzustellen. 1 High: 1524, 0 High: 520, 0/1 low: 492. Dann kommt G0030751e201e5f1ece8501 raus, du benötigst aber die Firmware des tevion branches auf deiner CUL. Viel Erfolg.

  12. Hagen Fritscham 27.09.2015 um 11:02 am

    Hallo Thomas, man muss leider ggf. einiges experimentieren bis es funktioniert. Wenn dein Sync bit 3ms ist gefolgt von der 7ms, würde ich diesen Wert für final high verwenden. Kommt dein sync bit allerdings erst nach der Pause, wird diese Konfiguration von dem raw Befehl nicht unterstüzt und du müsstest die Firmware anpassen um das zu erreichen.
    Im Zweifel ist es auch hilfreich mit der Mikrofonmethode aufzuzeichnen, was die CUL sendet und das mit dem erwarteten Kommando zu vergleichen.

  13. Hagen Fritscham 27.09.2015 um 11:06 am

    Mir ist das mit den UnexpectedData Fehlermeldungen heute auch passiert und im Logfile standen eine Reihe von Nachrichten bzgl Unknown Commands, irgendwie bekam die CUL also eingaben, vllt hat da der Network-Manager versucht das als Modem zu benutzen. Irgendwann hat’s dann jedenfalls wieder geklappt. Zwischenzeitlich hatte ich die CUL an und wieder abgestöpselt bzw mit screen /dev/ttyACM0 geöffnet. Woran’s genau lag weiß ich aber auch nicht…

  14. Jörg Wegmannam 07.11.2015 um 6:01 pm

    ich stoße auch überall auf diesen Fehler:
    Error: UnexpectedData 78 (x): Expected Quality Indicator (a..z / A..Z)

    Egal was ich versuche, es kommt immer diese Meldung. Und ja, es ist der Tevion branch.

    Die Aufzeichnungen mache ich inzwischen mit cutecom. Ist wirklich sehr komfortabel. Dabei frage ich mich allerdings, wie genau die Parameter sein sollen?
    Mit Parity, oder ohne?
    7 oder 8 Bit?
    Mit Stoppbit, oder ohne?
    Welches Handshake?

    Welche Parameter versprechen denn da Erfolg?

    gruß und danke
    jörg

  15. DonKrachoam 14.04.2016 um 2:28 am

    Für einen Arduino Uno habe ich einen Sketch entwickelt, der die Dosen zuverlässig schaltet. Die GT-9000 Fernbedienung sendet nacheinander zwei unterschiedliche Codierungen, wobei für die Steckdosen nur die erste Codefolge (die 4 mal wiederholt wird) relevant ist. Wegen zwei komplett unterschiedlicher Codesequenzen bekommt ein automatischer Code Analysator natürlich Probleme.

    Siehe: https://www.mikrocontroller.net/topic/312742#new

    Wie sich der Code berechnet und die Relation zwischen An, Aus und Master hat sich mir allerdings nicht erschlossen. Ich bin auf der Suche danach auf dieser Seite gelandet;)

  16. Hagen Fritscham 14.12.2016 um 9:25 pm

    Das log wohl an einem Bug der durch einen Merge-Konflikt in den Branch gekommen war und den ich eben erst gefunden habe.
    Dieser sollte in https://github.com/rumpeltux/culfw/commit/e043570ec64628bed7e9e79193ddbac8dce3a93b gefixt sein.

  17. svenam 15.12.2016 um 12:52 pm

    Hi,

    ich habe gerade versucht nach deinem Tutorial meine Tevion Steckdosen GT-8000 zu anlysieren.

    Dieses Gebiet ist absolutes Neuland für mich.
    Nachdem ich mir die Sourcen von Github geholt habe bin ich natürlich in das Verzeichnis /Devices/nanoCul gegangen und habe hier mit make programm meinen selbstbau Cul mit der FW beschrieben.

    Er blinkt auch schön, aber in Fhem bekomme ich im Monitor nichts mehr angezeigt wie zuvor mit der FW a-cul.

    Der Befehl echo X98 > /dev/ttyUSB0 (bei mir das Device) ist anscheinend nicht funktional.
    ich bekomme mit cat /dev/ttyACM0 > logfile den logfile nicht geschrieben.

    Nach absenden des Kommands springt mir das System gleich wieder auf die Shell raus.

    Ich nutze hier ein Ubuntu System als Testumgebung mit einem Selbstbau CUL aus einen Andruino nano und dem CC1101 mit 433 MHZ.

    Hast du hier eine Idee was ich machen muss um die Sache hier zum laufen zu bringen ?

    Viele Grüße

    Sven

  18. Hagen Fritscham 15.12.2016 um 3:17 pm

    Ich kenne mich mit der nanoCUL nicht aus. Probiere mal screen /dev/ttyUSB0 (mit Strg+A \ kommst du wieder raus), gib X98 (+ENTER) ein und drück ein paar Tasten auf der Fernbedienung. Wenn du da was siehst sollte es gehen, wenn nicht, weiß ich leider auch nicht.
    Ich habe auch den Blogpost nochmal aktualisiert, das Tool raw_analysis.py wurde gestern geändert und das Procedere sieht jetzt ein bisschen anders aus.

  19. svenam 16.12.2016 um 11:15 am

    Hallo Hagen,

    ich bekomme nun die entsprechenden Ausgaben und benötige das python tool.

    Wo finde ich dies ?

    Im Netz und bei dir in der culfw habe ich es nicht gefunden.

    Viele Grüße

    Sven

  20. Hagen Fritscham 16.12.2016 um 1:53 pm

    Den tevion branch müsstest du schon haben und die Firmware geflasht haben. In dem branch dann tools/raw_analysis.py

  21. Svenam 17.12.2016 um 4:14 pm

    Hallo Hagen,

    CUL mit Tevion Branch geflashed.
    Echo X98 auf /dev/ttyUSB0

    Dann das Python tool gestartet.

    Soweit hat alles funktioniert.

    Dann bekomme ich jedoch immer Fehlermeldungen.
    Ich habe auch schon probiert hier die Fernbedienung zur drücken bevor ich das Tool gestartet habe. Dies hat auch nicht geholfen.
    Folgende Meldungen bekomme ich hier.

    python raw_analysis.py –pause 4000 –plot /dev/ttyUSB0
    Error: UnexpectedData 08 ): Expected Quality Indicator (a..z / A..Z)
    Error: UnexpectedData 6a (j): Expected Status Indicator
    Not enough packets were received or another error ocurred.
    (Timings incomplete: ([], [], [], []))
    Traceback (most recent call last):
    File “raw_analysis.py”, line 305, in
    p.plot()
    File “raw_analysis.py”, line 251, in plot
    data[0] = [i * 16 for i in data[0]] # Adjust the time-scale first.
    IndexError: list index out of range

    Ist es denn nicht möglich aus den Meldungen von Fhem rauszulesen wie man die Steckdosen schalten kann ?

    Viele Grüße
    Sven

  22. Thuffiram 08.01.2017 um 12:14 am

    Hallo Hagen,

    ich habe den oben genannten Funksteckdosen erfolgreich in FHEM integriert. (Mittels günstige 433 Funkmodul direkt an RasPI GPIO angebunden. Die Ansteuerung dazu hier: https://github.com/Thuffir/rftx/blob/master/gt9000.c)

    Das Protokoll konnte ich leider nicht vollständig entziffern aber anscheinend nutzen die Fernbedienungen unterschiedliche Codegruppen um einander nicht zu beeinflussen.

    Meine Codes sind:

    1 ON
    1100 1100001101010111 0000
    1100 0101011111011011 0000
    1100 1110010111000011 0000
    1100 1000111100100100 0000

    1 OFF
    1100 1011101010111010 0000
    1100 0001100001000010 0000
    1100 0110110100000001 0000
    1100 0100001011111001 0000

    2 ON
    1100 1000111100100100 0100
    1100 1110010111000011 0100
    1100 0101011111011011 0100
    1100 1100001101010111 0100

    2 OFF
    1100 0100001011111001 0100
    1100 0110110100000001 0100
    1100 0001100001000010 0100
    1100 1011101010111010 0100

    3 ON
    1100 1000111100100100 1100
    1100 1110010111000011 1100
    1100 0101011111011011 1100
    1100 1100001101010111 1100

    3 OFF
    1100 0001100001000010 1100
    1100 1011101010111010 1100
    1100 0100001011111001 1100
    1100 0110110100000001 1100

    4 ON
    1100 0110110100000001 0010
    1100 0100001011111001 0010
    1100 1011101010111010 0010
    1100 0001100001000010 0010

    4 OFF
    1100 1110010111000011 0010
    1100 1000111100100100 0010
    1100 1100001101010111 0010
    1100 0101011111011011 0010

    ALL ON
    1100 0001100001000010 1010
    1100 0110110100000001 1010
    1100 0100001011111001 1010
    1100 1011101010111010 1010

    ALL OFF
    1100 1100001101010111 1010
    1100 0101011111011011 1010
    1100 1110010111000011 1010
    1100 1000111100100100 1010

    Wie man sehen kann sind das 8 Codes in 2 Gruppen (gleiche Tastendrücke nacheinander erzeugen 4 unterschiedliche Codes):

    Gruppe A: 0x8F24, 0xC357, 0x57DB, 0xE5C3
    Gruppe B: 0xBABA, 0x1842, 0x6D01, 0x42F9

    Mich würde interessieren welche Codes andere Fernbedienungen schicken um irgend ein System zu erkennen. Könntest du bitte deine Codes schicken?

Trackback URI | Kommentare als RSS

Einen Kommentar schreiben