Conrad RS-200 Schaltsteckdosen

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

Vorheriges Thema - Nächstes Thema

Jaydee

Hallo zusammen!

So langsam nimmt die FHEM-Vernetzung meiner Wohnung Formen an.
Neben einiger HomeMatic-Komponenten über HM-LAN und einiger Conrad Schaltsteckdosen (IT-kompatibel) per Busware-COC würde ich nun gerne noch einige schon länger vorhandene Schaltsteckdosen nutzen, weiß aber leider nicht so recht wie.

1. Ich habe hier einen Satz Conrad RS-200 Funksteckdosen. Laut Aufdruck 433 MHz. Nach einiger Sucherei habe ich für diese folgende Codes gefunden: LINK

Die Frage ist nur, wie ich diese via COC, bzw. CUL senden kann? Kann man die irgendwie umrechnen oder gibt es eine art RAW-Modus in dem man diese Codes direkt in den/die/das COC füttern kann?

2. Weiterhin habe ich hier noch Tevion GT-FSI-05 Funksteckdosen. Weiß jemand irgendwas darüber?

Vielen Dank,
Jan

zgadgeter

Ich habe auch noch beide Steckdosen, und habe sie noch nicht ans Funktionieren bekommen. Wenn Du erfolgreich warst, kannst Du mir helfen?
danke.
NUC FHEM mit vielen Intertechno/FS20/Flamingo schalter
und Busware CUL und nanoCUL

cerberus

#2
Hi, ich habe auch noch 4 davon und würde diese gern als Alternative zu FS20-st nutzen. Intertechno sollen ja auch mit CUL bzw. COC 868 Mhz funktionieren.

Hier mal den Code den ich zu den RS-200 gefunden habe, leider weiß ich nicht wie ich den in FHEM anwenden kann.

https://docs.google.com/file/d/0B3Q6EJfD8nnKUWMteVJBMUJVY28/edit?usp=sharing

Gruß
cerberus
Banana PI mit Bananian + Fhem 5.5, 2x SCC SlowRF/Homematic + RS485 LAN Gateway HMW-LGW-O-DR-GS-EU + RPI2 I2C to 1-Wire Host Adapter for Raspberry Pi

rainboxx

Hallo zusammen, habt ihr eure RS-200 inzwischen zum Laufen bekommen? Wenn ja, wie?

Grüße,
  Matthias

zgadgeter

Nein, nicht von meiner Seite. Ich habe meine in den Schrank gelegt, und habe neue Funksteckdosen die mit FHEM funktionieren.
NUC FHEM mit vielen Intertechno/FS20/Flamingo schalter
und Busware CUL und nanoCUL

feger

Hallo!

Gibt es vielleicht irgendetwas neues zum Thema Conrad RS200 und fhem?
Ich würde gerne meine auch noch nutzen.
CUL433MHz für Intertechno & Somfy
CUL868MHz für Homematic
RFXTRX433E für Oregon & KeeLoq

feger

Hallo!

Ich habe jetzt mal RFXCOM angeschrieben, ob es möglich ist diese Funksteckdosen mit dem RFXTRX433E zu bedienen.
Mal sehen was die dazu sagen.

mfg Feger
CUL433MHz für Intertechno & Somfy
CUL868MHz für Homematic
RFXTRX433E für Oregon & KeeLoq

Domjo75

Hallo,
gibt es hier irgendwelche neuen Erkenntnisse? Ich hab den Kram massenhaft im Keller liegen :)

RxTx

Hallo ihr lieben,


von den RS-200 Steckdosen habe ich auch noch welche im Schrank liegen und mich heute gefragt, ob ich sie mit einem eigenen Sender ansprechen kann. Ich möchte dies unabhängig von FHEM machen.

Dazu habe ich einen einfachem Empfänger für 433MHz an mein Scope angeschlossen und mal geschaut, was da raus kommt.
Ob das so der richtige Weg ist, weiß ich nicht, aber mal sehn.

Was ich glaube sagen zu können ist, dass es sich wohl um ein 26 Bit langes Signal handelt mit folgenden Eckdaten:
High: 1,3ms Puls
Low: 0,52ms Puls
Pause 3,3ms.

Nun habe ich meine Fernbedienung auf den Code 1 2 3 4 gestellt und nach einander die Tasten aufgenommen. Ich habe folgendes aufgezeichnet und schon mal versucht die Daten zu interpretieren.
:

Sync                  Code                        ?      Kanal         S   ?   ?      Parität?               Kanal /    Aktion
                  1      2      3      4                                             
                                                                                 
1   0   0   1   1   0   0   0   0   1   1   0   1   1   0   1   1   1   1   1   1   1   1   1   0   0   -> 1   on
1   0   0   1   1   0   0   0   0   1   1   0   1   1   1   1   1   1   1   0   1   1   0   0   0   0   -> 1   off
1   0   0   1   1   0   0   0   0   1   1   0   1   1   1   1   1   0   1   1   1   1   0   0   1   1   -> 2   on
1   0   0   1   1   0   0   0   0   1   1   0   1   1   0   1   1   0   1   0   1   1   0   1   1   1   -> 2   off
1   0   0   1   1   0   0   0   0   1   1   0   1   1   1   1   0   1   1   1   1   1   0   0   1   0   -> 3   on
1   0   0   1   1   0   0   0   0   1   1   0   1   1   0   1   0   1   1   0   1   1   0   1   1   0   -> 3   off
1   0   0   1   1   0   0   0   0   1   1   0   1   1   0   1   0   0   1   1   1   1   1   0   0   1   -> 4   on
1   0   0   1   1   0   0   0   0   1   1   0   1   1   1   1   0   0   1   0   1   1   1   1   0   1   -> 4   off


Jeder Frame fängt scheinbar mit 100110 an
Danach kann man den Code sehen (0 basierend) Die nächste spalte verstehe ich nicht. Ich glaube, wenn ich die gleiche Taste drücke, kommt auch immer das gleiche Bit. Ich hatte vermutet, dass es ein Toggle Bit ist, scheint aber so nicht zu sein. Dann kommen immer nur '1' Vielleicht gehört das aber auch schon zur Kanalnummer, da das RS 200 System scheinbar mehr als 4 Kanäle hat.

Die Kanäle habe ich so dekodiert:

1 : 1 1
2 : 1 0
3 : 0 1
4 : 0 0

Das konnte ich auch mit anderen Codes reproduzieren

Das nächste Bit (bei Spalte S) scheint die Schaltaktion zu sein. 1 für on, 0 für off

Die nächsten beiden Spalten waren immer 1.

So die letzten 4 Spalten müssen wohl eine Prüfsumme sein. Sie ändern sich, wenn sich die vorherigen Bits ändern. Sonst nicht. Ich habe schon versucht mit Xor und verschiedenen Gruppen dahinter zukommen, leider ohne Erfolg.

Hier nochmal ein Listing mit dem Sender Code 2233

Sync                  Code                              Kanal         S                     Kanal   Aktion
                  1      2      3      4                                             

1   0   0   1   1   0   0   1   0   1   1   0   1   0   0   1   1   1   1   1   1   1   1   1   1   1   -> 1   on
1   0   0   1   1   0   0   1   0   1   1   0   1   0   1   1   1   1   1   0   1   1   0   0   1   1   -> 1   off

Man kann deutlich sehen, dass der Sender Code nun anders ist. Kanal stimmt, Schaltaktion stimmt, die Spalten mit den einsen sind da, aber die letzten 4 Stellen sind anders.

Was meint ihr. Kriegen wir das noch raus? Oder bin ich völlig auf dem Holzweg?

Als Anhang noch die Tabellen von oben.

Grüße

RxTx

rhuber

#9
Hi RxTx,
ich hab auch noch diverse alte rs200 rumliegen...

Deine Analyse entspricht den Codes im oben verlinkten Dokument nur die notation unterscheidet sich.

0015 = 0
0032 = 1
0078 = Füllmaterial ?
0000 0074 0000 001a = irgend ein header?

Damit wird aus


Conrad Power Switches 1234_1_power_on
0000 0074 0000 001a 0032 0078 0015 0078 0015 0078 0032 0078 0032 0078 0015 0078 0015 0078 0015 0078 0015 0078 0032 0078 0032 0078 0015 0078 0032 0078 0032 0078 0015 0078 0032 0078 0032 0078 0032 0078 0032 0078 0032 0078 0032 0078 0032 0078 0032 0078 0032 0078 0015 0078 0015 0500

0000 0074 0000 001a 1  0  0  1  1  0  0  0  0  1  1  0  1  1  0  1  1  1  1  1  1  1  1  1  0  0 0500


Damit hätten wir schon ein par Codes mehr zum analysieren oder die Alternative sie fix zu codieren.
Hast Du schon mal versucht einen der codes zu senden?

Gruss Raimund

P.S. spannend ist noch, dass sich die Checksumme von power on zu toggle nicht ändert.

BeRo

#10
Hallo zusammen,
ich habe mal eure Untersuchungen zum Anlass genommen, den Code mit Hilfe eines Oszilloskops und einer Mikrocontroller Schaltung weiter zu analysieren.
Auch ich habe noch zwei Handsender einen Wandsender und mehrere Schaltsteckdosen im Einsatz. Mir gefällt das Design und will sie deshalb weiter
benutzen. Ich bin der Überzeugung den Code komplett entschlüsselt zu haben. Ich kann jedenfalls mit der Mikrocontroller Schaltung meine Deckenlampe
jetzt Ein und Ausschalten und dimmen.

Ich habe folgendes für mich festgelegt und festgestellt:
Der Code besteht aus 26 Bit. Der Impuls 700µs/3300µs ist log. 1 und der Impuls 1400µs/3300µs ist log. 0. Zwischen den 26 Impulspaketen ist eine 30ms Pause.

Hier ein Beispiel für den Handsender Hauscode 1234:

Header -> 011001 ist bei allen Sendern so
Hauscode -> 11 10 01 00 von rechts nach links 1234
Schaltaktion -> 100000 von links nach rechts 1 Bit Parity, 3Bit Taste, 1 Bit toggle, 1 Bit Schaltaktion
Checksumme -> 000011

Wie berechnet sich das Paritybit?
Die Anzahl der 1 Bits in der Schaltaktion muss ungerade sein!

Wie berechnet sich die Checksumme?
CS = ROW + (HC1) + (HC2 * 4) + (HC3) + (HC4 * 4) + (Schaltaktion * 0x0c)
ROW ist die Taste die betätigt wurde.
ROW1 = 1
ROW2 = 10
ROW3 = 11
ROW4 = 4
ROW6 = 6 ROW6 gibt es nur beim Handsender ROW5 gibt es nicht.

Ergebnis für das obigen Beispiels:
CS = 1 + (0) + (1 * 4) + (2) + (3 * 4) + (0 * 0x0c) = 19 das stimmt noch nicht ganz. Wir müssen noch eine Maske darüber legen da das Ergebnis nur 4 Bit lang ist.
CS = dez.19 = 0x13 und dann die Maske 0x13 & 0x0f = 0x03 stimmt! Die zwei letzten Bits sind immer 0.
Das funktioniert bei allen Tasten und Hauscodes.

Die Sender schicken immer 2 Strings. Taste gedrückt, Taste losgelassen.

Beispiel:
Taste gedrückt
011001 11 10 01 00 100000 000011 Handsender Hauscode 1234 Taste oben links ON
Taste losgelassen
011001 11 10 01 00 100011 001111 Handsender Hauscode 1234 Taste oben links ON

Taste gedrückt
011001 11 10 01 00 000001 001111 Handsender Hauscode 1234 Taste oben rechts OFF
Taste losgelassen
011001 11 10 01 00 100011 001111 Handsender Hauscode 1234 Taste oben rechts OFF
Also: ON = 00
      Off = 01
      losgelassen = 11

Der Wandsender hat nur jeweils 1 Taste, das sieht dann so aus:
Taste gedrückt = 10 die 1 ist das toggle Bit.
Taste losgelassen = 11

Ich hoffe das hilft euch; Viel Spaß beim Basteln.

BeRo

Jostar

Zitat von: feger am 23 September 2015, 09:37:04
Hallo!

Ich habe jetzt mal RFXCOM angeschrieben, ob es möglich ist diese Funksteckdosen mit dem RFXTRX433E zu bedienen.
Mal sehen was die dazu sagen.

mfg Feger
Gab es darauf eine Antwort? Ich habe auch noch einige der Steckdosen und würde die gerne zum laufen bringen. Als Zur-Not-Alternative könnte man die Tasten einer zusätzlichen Handfernbedienung über Ausgänge (z.B. Piface) direkt ansteuern...
Gruß Jork
Raspberry Pi(s) mit FHEM auf Rasbian Jessie/Strech, DbLog/DbRep mit mySQL, piface, 1Wire-USB-Master von SMS-GUARD, RFXtrx433E

Uwe B.

Auch von mir eine Nachfrage nach Neuigkeiten zur direkten Integration der RS-200 Sender und Empfänger ins FHEM (CUL433 oder anders?)

Oder mangelt es an Interesse kompetenter Aktivisten?
Grüße - Uwe

Lache nie über die Dummheit der anderen. Sie ist deine Chance.

FHEM 5.9 auf Ubuntu Srv 19.04 u. RasPi Zero W Raspbian Stretch; CUNX mit Modulen HM u. slowRF433; RFXtrx433E; FB 7590; FRITZ!DECT 200; Wetter HM WDS100-C6-O OC3; Xiaomi Flower Sense; Broadlink RM Mini u. Pro; EZcontrol XS1

Goggo16

Hi,

vielleicht schaff ich als neuer Alter mal den alten Thread etwas zu erneuern und dabei die gute Arbeit etwas fort zu führen.

Nach etwas Experimentieren ist mir gelungen, die Kodierung der RS-200 Funkschalter so auf zu loesen, dass man sie von einem Raspberry PI mit Pilight steuern kann. Geholfen haben mir dabei die Messergebnisse von RxTx (weiter oben) sowie die von Cerberus verlinkte Liste mit allen Codes.

Geschafft habe ich das allerdings nur für die RAW-Codes. Hab nun allerdings (noch) keine Ahnung, wie man das nun als Protokoll in Pilight oder sogar FHEM rein bekommt.

Dazu hatte ich in der Code-Liste die ersten vier "Worte" (wohl ein Header fuer die Pronto) erst mal geloescht. Dann habe ich die Werte für "1", "0" und "Pause" (0032, 0015, 0078) durch die von RxTx gemessenen Zeiten in Micro-Sekunden ersetzt. Die Laenge des "Footer Pulse" am Ende hat bei mir keinen Unterschied gemacht. Hab die 0500 durch 6500 ersetzt, aber eben rein intuitiv.

Getestet habe ich das auszugsweise mit Pilight auf einem Raspberry, und zwar mit folgendem Kommando (in die Anführungszeichen ist der ganze Raw-Code ein zu setzen.
pilight-send -p raw -c "1300 ... 6500"

Erfolgreich getestet habe ich auch das Anlernen eines Funkschalters vom Raspberry aus. Ging ohne Probleme.

Dabei habe ich noch ein paar interessante Sachen festgestellt. Lt. der Code Liste gibt es nicht nur "An" und "Aus", sondern auch "Umschalten". Funktioniert problemlos. Dann gibt es auch noch sechs IDs fuer Taster (... obwohl meine Fernbedienung nur 4 Taster hat, plus dem Alles-AN/AUS-Taster).

Anbei ist eine Textdatei mit allen IDs, Units und Aktionen sowie der dazu gehoerenden Raw-Codes. Vielleicht hilft es dem ein oder anderen weiter.

Was bislang noch nicht gut geht, ist den Funkdimmer (RS-221) aus der gleichen Produktreihe richtig zu bedienen. "Aus" geht z.B. nicht. Beschäftige mich daher gerade mit dem "conrad_rsl_switch" Protokoll und Pilight. Da gehen aber keine vierstelligen IDs.

LG, Goggo
MapleCUN x4 | RPI mit FHEM, HA-Bridge und FS1000A via GPIO | FHEM Anfaenger ;-)

Crush85

Wie kann ich die RAW Codes nutzen?

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