Conrad RS-200 Schaltsteckdosen

Begonnen von Jaydee, 12 April 2013, 19:17:24

Vorheriges Thema - Nächstes Thema

DDTech

Ich möchte diesen Thread gerne noch einmal aus der Versenkung heben, auch wenn es diese Fernbedienungen schon lange nicht mehr gibt und hier auch wahrscheinlich nicht mehr viel passiert. Aber ich habe den Thread ja auch erst jetzt gefunden und er scheint mir zu diesen RS-200 Dosen von Conrad (auch mit "Europe Supplies Ltd." gelabelt) die besten Informationen zu liefern - sofern man sie denn anderweitig steuern möchte.   

Ich will versuchen, dazu noch etwas beizutragen.

Die Dosen sind relativ robust. Wenn sie nicht mehr funktionieren, ist vermutlich nur der 22,2 KOhm-Widerstand kaputt. Der arbeitet Zeit seines Lebens als Heizung und kann schon mal den Dienst quittieren.

Wird ein 433MHz-Empfänger benötigt, läßt sich eine Dose leicht "hacken" und direkt anzapfen. Wie, würde ich bei Bedarf in einem getrennten Post beschreiben. Mit einem ESP8266 ließe sich sicher auch leicht eine WLAN-Dose daraus machen.

Die Sender lassen sich ebenfalls leicht reparieren. Die "Knackfrosch"-Tastkappen sind nur aufgeklemmt und lassen sich leicht entfernen. Nach der Reinigung der Kontakte funktionieren sie in der Regel wieder einwandfrei.

Schade, dass der Beitrag von BeRo so gar keine Reaktion und Würdigung erfahren hat, denn er ergänzt die Informationen von RxTx um einiges.
Vielleicht liegt es daran, dass sein Timing (auch bei mir) nicht funktioniert hat. 700/1400, also 1:2, ist scheinbar zu dicht beieinander. Meine Messungen liegen eher bei denen von RxTx. Mit 500µs für "1" und 1300 für "0" erziele ich bessere Ergebnisse. 3300µs zwischen den Pulsen passt aber auch bei mir.

Die Telegramme haben, wie von beiden erwähnt, 26 Bits und sind durch eine längere Pause (LOW) voneinander getrennt. Diese Pause wird im Anschluss an ein Telegramm gesendet. Die Dauer variiert. Nach den ersten beiden Telegrammen beträgt sie ca. 26.300 µs (26ms), nach den folgenden ist sie 10ms länger, also ca. 36.300µs. Darüber wird vermutlich das Dimmen gesteuert, das erst nach einer gewissen Verzögerung einsetzt - Es gab zu diesem System auch dimmbare Dosen und Deckeneinsätze.
Da jedes Bit mit mit einem 3300µs LOW endet, fließt das in die Pause mit ein. D.h. der eigene Code muss 23.000 bzw. 33.000µs senden. Alle Zeiten scheinen aber auch nicht besonders kritisch zu sein.

Mit dem Loslassen der Taste wird das entsprechende Telegramm mit "UpClick" oder "Toggle" gesendet (Schaltwert 0b11). Dieses Telegramm wird drei Mal gesendet, die ersten beiden Male wieder mit einem Abstand von 26.300
Also ON oder OFF im Abstand von zunächst 26 dann 36ms so lange die Taste gedrückt wird, dann mit dem Loslassen TOGGLE drei Mal im Abstand von 26ms.

Lange habe ich mit der Checksumme gekämpft. Sie hat bei mir zunächst nur für Taster 1 funktioniert. Man kann sich die Prozedur hundert Mal ansehen, aber wenn man sie nicht so "schmutzig" ausführt, wie sie gemeint ist, stimmt das Ergebnis trotzdem nicht.
Jetzt funktioniert BeRos Aufbau tatsächlich mit allen von mir getesteten Kombinationen, darum will ich den Aufbau nochmal etwas erläutern. Wenn sich seinen Post schon damals gesehen hätte, hätte mich brennend interessiert, wie er darauf gekommen ist. Ich habe es, weil die Berechnung zunächst nicht richtig funktionierte, tagelang mit anderen Varianten probiert und doch immer wieder auch ungültige Ergebnisse erhalten.

Wichtigste Erkenntnis war, dass Taster 2 und 3 in die Checksummenberechnung tatsächlich mit 10 und 11 (zehn und elf) einfließen und nicht mit 0b10 und 0b11 (zwei und drei) - darum "schmutzig". 1, 4 und 6 (Master) fließen mit ihren Positionswerten ein.
Damit funktionierte die Checksummenberechnung dann für ON und OFF, aber nicht für den Toggle-Wert (0b11). Oben trennt er tatsächlich auch Schalt- und Toggle-Wert, was eigentlich nicht ganz korrekt ist, denn es werden beim UpClick beide Bits auf 1 gesetzt und nicht nur das Toggle-Bit. Etwas weiter unten beschreibt er die Zustände auch mit ON= 0b00,  OFF=0b01 und TOGGLE (Loslassen) = 0b11. Mit 11 stimmt aber die Checksumme nicht, die immer identisch mit der des OFF-Zustandes ist.

Ich denke, in die "Original"-Checksummenberechnung fließt das Paritäts-Bit mit ein, das bei OFF immer liegt und bei TOGGLE steht. Man kann sich aber behelfen, indem wirklich nur das letzte Bit in die Berechnung eingeht. Dann passt das Ergebnis.

Die Berechnung der Checksumme liefert so für mich gültige Ergebnisse:

Taster: 1 = 0b0001 (1) ; 2 =  0b1010 (10); 3 = 0b1011 (11); 4 = 0b0100 (4); 6 = 0b0110 (6)   -   6 ist "Master" am Handsender
SenderCode: von links nach rechts, null-basiert, also bspw. 1-2-3-4 --> 0-1-2-3 oder 1-1-1-1 -> 0-0-0-0
Aktion: ON = 0; OFF und TOGGLE = 1
Maske: 0x0F

CheckSum = ( Taster + SC-1 + (SC-2 * 4) + SC-3 + (SC-4 * 4) + (Aktion * 0x0C) ) & Maske

Beispiel:
Taster: 3
SenderCode: 3424
Aktion: OFF

CheckSum = (11 + 2 +(3*4) + 1 + (3*4) + (1 * 0x0C) )  & 0x0F  =  0b000010 = 2

Der generelle Aufbau des Telegramms wurde von BeRo bereits beschrieben. Ich glaube, ich habe noch etwas an den SenderCodes drehen müssen, damit es bei mir mit allen Codes funktioniert:

- Konstanter Header 011001
- gefolgt vom null-basierten SenderCode in umgekehrter Reihenfolge (anders, als bei der Eingabe und Checksummenberechnung)
   00 steht dabei bei mir für die 1 und 11 für die 4, also für 3-4-2-4  wäre das 3-1-3-2 bzw. 11 01 11 10
- Paritätsbit für ungerade Parität der folgenden fünf Bits
- drei Bits für die Taste - null-basiert als Bit-Wert: 1 = 0b000, 2 = 0b001, 3 = 0b010, 4 = 0b011, 6 = Master = 0b101
- zwei Bits für die Aktion: ON: 0b00, OFF = 0b01, TOGGLE = 0b11

oder am Beispiel von oben:
Header  4  2  4  3 P  3 OFF  Check
011001 11 01 11 10 1 010 01 000010

Dieses Signal auch einmal in der Anlage als Sende- und Empfangsprotokoll.

Ich hoffe, diese Informationen können auch anderen helfen.

Happy coding!


dora71

Hallo zusammen,

es gibt ja anscheinend immer noch Bedarf zur Integration der Steckdosen in FHEM, auch ich bin noch daran interessiert.

Es gab ja weiter oben die Frage, wie ich die RAW-Pakete über den CUL schicken kann, hierzu habe ich hier https://itooktheredpill.irgendwo.org/2013/funksteckdosen-hacken/ noch einen interessanten Beitrag gefunden. Weiter unten ist auf eine html-Seite verwiesen, die die herausgefundenen Signale in "CUL"-Sprache übersetzen kann.

Ausprobieren konnte ich das bisher noch nicht, warte z. Zt. noch auf die "Einzelteile" meines Selbstbau-CULs für 433 MHz.

Zur Zeit behelfe ich mir anderweitig (umständlich, aber es funktioniert!):
Ich habe mir an einem Arduino nano ein 433MHz-Sendemodul gebastelt, die Codings, die ich mir vor längerer Zeit schon einmal rausgesucht hatte, im Arduino "nachgebaut", dieser steckt z. Zt. an einem dedizierten Rechner und nimmt über die serielle Schnittstelle Befehle entgegen. Auf dem Rechner werkelt ein kleines Python-Script hauptsächlich als UDP-Server, der UDP-Pakete aus FHEM entgegennimmt und darüber das 4er-Set Steckdosen schalten kann. Wie gesagt, nicht schön, aber läuft.

Ideal wäre es jetzt natürlich, mit dem Selbstbau-CUL die RAW-Pakete direkt verschicken zu können.

Gruß und frohe Pfingsten noch

Rainer

PS: Werde bei Gelegenheit mal schauen, ob ich noch die alten Unterlagen zu dem o. g. "Behelf" finde.

DDTech

Ich habe in der Zwischenzeit noch etwas mit den Dosen gearbeitet. Unter anderem habe ich eine Liste mit allen 3840 Codekombinationen erstellt und ein einfaches Demo, um Dosen mit der RC-Switch-Klasse ansteuern zu können.

Aus der Liste lassen sich benötigte Code-Knopf-Kombinationen leicht auslesen. Keine Garantie, dass alle Codes tatsächlich funktionieren, aber von denen, die ich probiert habe, waren alle gut.

https://github.com/sui77/rc-switch/issues/231

Die Liste findet Ihr ungefähr bei Post Nr. 9. Es gibt auch eine Aufstellung mit invertierter Logik, also der Überlegung, dass nicht ein kurzer Puls einer logischen 1 entspricht, sondern ein langer.

In dem Thread ist auch erwähnte der "Hack" beschrieben, um das Empfangssignal direkt an der Dose abzugreifen.


VG

Frank

dora71

Hallo Forum,

ich habe mich nochmal dran gesetzt und tatsächlich eine Lösung gefunden, die Conrad Funksteckdosen in FHEM zu integrieren.

Hierfür benutze ich einen Signalduino (s. Link https://wiki.fhem.de/wiki/SIGNALduino#Unterst.C3.BCtzte_Ger.C3.A4te).

Dieser hat die Möglichkeit, auch raw-Nachrichten zu schicken. Folgendes Paket wäre nötig, um die 1. Steckdose mit dem Code 1111 einzuschalten:

set sduino raw SR;;R=5;;P1=500;;P2=-3300;;P3=1300;;D=3212123232123232323232323232123232323232323232323212;;

Dabei wurde der Signalduino vorher als sduino definiert.

Kurze Erklärung: Als Basis diente mir die Liste von Frank aus der vorherigen Antwort (vielen Dank dafür).
Ob es nötig ist, die Signalfolge 5x zu wiederholen (R=5) weiß ich nicht, es schadet aber auf jeden Fall nicht.
P1 bis P3 sind die Pulslängen in Mikrosekunden, dabei ist es wichtig, dass das Low-Signal mit "-" angegeben wird (s. Parameter P2)
Das Signal wird dann wie folgt "angepasst": Eine "1" ist die Folge 12, eine "0" ist die Folge 32, die komplette Folge findet Ihr unter D=...

Bei mir klappt das prima, ob es schon jemand mal in ein Perl-Modul umgesetzt hat, glaube ich nicht, aber so kann ich damit leben.

Viel Spaß beim Nachbauen. Erfolgsmeldungen und/oder Verbesserung sind hier natürlich willkommen.

Gruß und schönen Sonntag. Rainer

DDTech

Hallo Rainer,

Zitat von: dora71 am 17 Juni 2018, 12:52:29
Kurze Erklärung: Als Basis diente mir die Liste von Frank aus der vorherigen Antwort (vielen Dank dafür).

gerne. Freut mich, wenn es hilft.

Zitat von: dora71 am 17 Juni 2018, 12:52:29
Ob es nötig ist, die Signalfolge 5x zu wiederholen (R=5) weiß ich nicht, es schadet aber auf jeden Fall nicht.

Die Folge muss schon einige Male wiederholt werden, da die "Meldung" aus einer Menge noise heraus beginnt. Manche Systeme brauchen die mehrfache Wiederholung auch zur Verifizierung des Signals. Es gibt ja hier keine Kommunikation, die erst einmal aufgebaut und stabilisiert wird, sondern der Sender schickt seine Nachricht in den Orbit, unabhängig davon, ob jemand zuhört oder nicht.

Gruß

Frank