Funk Steckdose via uC

[Benjamin M. (kilobyte_ch)]

Hallo

Ich versuche mich derzeit mit dem steuern von Funk Steckdosen mittels 
uC. Ich möchte dafür einen ESP8266 verwenden.

Derzeit hänge ich jedoch mit dem "verstehen" des Protokolls fest. Im 
Internet habe ich bereits viele Beiträge gefunden mit selbigen/ähnlichen 
Projekten. Die da gezeigten Protokolle unterscheiden sich jedoch stark 
von dem, was ich hier vorfinde. Ich habe Brennenstuhl Funksteckdosen vom 
Typ "FE433". Die Fernbedienung ist vom Typ "HS433". Zusätzlich habe ich 
noch ältere Kertesz Funksteckdosen vom Typ "RC402". Diese lassen sich 
mit der Brennenstuhl Fernbedienung steuern.

Das "Pairen" zwischen Fernbedienung und Funksteckdose funktioniert 
automatisch. In der Fenbedienung ist auch ein Knopf mit welchem man die 
ID der Fernbedienung setzen kann. Vermutlich rechnet der sich eine Zahl 
je nach dem wie lange man den Knopf drückt. Die Daten Telegramme schauen 
auch anders aus nachdem man den Knopf gedrückt hat. Auf den 
Funksteckdosen ist dann auch entsprechend ein Knopf mit dem man die 
Funksteckdose neu der Fernbedienung anlernen kann.

Nun zum eigentlichen Problem:
Ich habe bereits versucht das Protokoll (siehe Anhang) mit meinem ESP zu 
generieren. Dafür habe ich das entsprechende Digital Signal in den 
Sender der Fernbedienung eingespiesen. Ich habe dann entsprechend via RF 
das Signal moduliert erhalten. Die Funksteckdosen reagieren jedoch 
(natürlich) nicht.

Ich vermute das Problem darin, dass die Zeiten zwischen den Signalen im 
originalen Protokoll wild verschieden zu sein scheinen. Das ist auch der 
Punkt welcher ich nicht verstehe. Weiss da allenfalls jemand mehr?

Was ich bislang angenommen habe:
Ein kurzer "Burst" ist eine 1, ein langer "Burst" eine 0. Ich komme 
dabei im Protokoll im Anhang auf folgenden Datenwert:
0b101111101111000000000

Im Programm habe ich eine 1 so realisiert, das ich 600us sende und 600us 
warte.
Bei einer 0 sende ich 1300us und warte 1300us.
Genau da vermute ich das noch viel mehr dahinter hockt..

Benjamin

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Benjamin M. schrieb:
> Im Programm habe ich eine 1 so realisiert, das ich 600us sende und 600us
> warte.
> Bei einer 0 sende ich 1300us und warte 1300us.
> Genau da vermute ich das noch viel mehr dahinter hockt..

Das ganze ist eher so:
* Langer Pause, kurzer Burst = 0
* kurze Pause, langer Burst = 1
wobei die Definition, was eine Null und was eine Eins ist, auch 
umgekehrt sein kann.
Wie man auch auf dem Oszillogram sieht, ist die Gesamtdauer immer etwa 
gleich, also etwa 1/3 zu 2/3 bzw. umgekehrt. Das kommt also etwa hin mit 
600µs zu 1300µs und 1300µs zu 600µs.
Oft ist übrigens die Präambel, also das was vor den Daten kommt, recht 
wichtig, um die Empfänger scharf zu schalten.

[Benjamin M. (kilobyte_ch)]

hmm, deine Ansichtsweise scheint auf den ersten Blick zu passen. Ich 
versuch das ganze mal zu realisieren und berichte mit dem Ergebnis!

[Sascha W. (sascha-w)]

Hallo Benjamin,

zeichne doch mal auf was vor dem oben gesehenen noch passiert. Wie 
Matthias schon schrieb haben eigentlich alle derartigen Protokolle vor 
den eigentlichen Daten noch eine Präambel mit Bitzeiten die in den 
Datenbits nicht vorkommen.

Wo hast du das obige Signal abgegriffen? Zeichne doch von dort auf wo du 
auch einspeisen willst, dann hast du ein unmoduliertes Signal das nicht 
durch den Funkweg verändert ist.

Sascha

[Benjamin M. (kilobyte_ch)]

Das ganze funktioniert nun. Das Problem war definitiv mein falsches 
Verständnis, ich habe das ganze immer so betrachtet das ein Burst und 
dann eine Pause kommt. Daher gings auch nicht auf. Die richtige 
Betrachtungsweise ist zuerst Pause, dann Burst.

Die einzige "präambel" scheint zu sein, dass das erste Bit immer das mit 
dem kurzen Burst ist. Sonst kommt da definitiv nichts. Ich hab im Anhang 
noch ein Screenshot wo man die 4 Pakete sieht (Er sendet immer 4 Pakete 
die gleich sind).