Hauscode von RSL-Schaltern auslesen

[litronics]

Hallo Zusammen,

ich habe mittlerweile FHEM auf einem RPI mit einem CUL am laufen und funktioniert soweit sehr gut.

Ich habe aber noch ein paar RSL Schalter die ich von meiner EZ-Control steuern kann.
Bevor ich jetzt lange rumrechne und überlege, wie die Hauscodes in FHEM einzutragen sind, wäre es einfacher das Funksignal abzufangen und den Hauscode einfach auszulesen.

Hat jemand eine Idee, wie ich den CUL kurzzeitig so auf 433MHz umstelle, damit ich den Code auslesen kann?

Herzlichen Dank für die Hilfe!
Stefan

[Fixel2012]

Fhem kann normale IT Devices per Autocreate selbst anlegen.

Welche MHz Zahl steht denn bei den RSL Schaltern drauf? Versuch den CUL auf diese Frequenz zu stellen. Mit ein wenig Glück werden diese automatisch angelegt.


http://commandref.fhem.de/#CUL

Dort ist nach zu lesen, wie der CUL auf eine bestimmte frequenz gestellt wird.

Das Log wird dir sicher auch infos geben.

[KölnSolar]

klingt nach 868er  Mit aktuellster culfw u. freq auf 433.92 könntest Du mit autocreate Glück haben.

[litronics]

Ich hab jetzt versucht mit "set freq 433.92" den CUL umzustellen und laut "get cccconf" hat er auch umgestellt.
Autocreate findet die Schalter aber leider nicht

Jetzt hatte ich die Idee ob man nicht den Funkverkehr auf 433MHz nicht einfach belauschen kann. Würde ja reichen, wenn ich das in einem telnet Fenster sehen kann.
Aber mit "inform timer" bekomme ich nur die Änderungen der Aktoren innerhalb FHEM angezeigt und nicht das, was auf der Funkseite los ist.

Ich hab auch schon mal versucht mit "set CUL raw X61" mir mehr Details in der Kommunikation anzeigen zu lassen - das ändert aber an der Menge die ich in telnet sehe nix

Entweder mach ich hier grundlegend was falsch, hab irgendwas nicht verstanden oder es ist was kaputt.

Zu guter letzt hab ich jetzt auch noch festgestellt, dass autocreate nach dem zurückstellen auf 868MHz auch keine FS-20 Devices mehr anlegt
Oh mann - irgendwas hab ich da jetzt echt kaputt "gespielt".

Nachdem ich mit FHEM gerade eben erst anfange - wäre ich echt dankbar, wenn mir jemand beim Troubleshooten helfen könnte.

Herzlichen Dank

[litronics]

So - ein Schritt weiter.

Autocreate geht nach einem Reboot des RPI wieder. Würde mich ja interessieren was falsch gelaufen ist aber egal.

Ich hab jetzt auf die Schnelle meinen Arduino mit einer 433MHz Angenne genommen und einen Sniffer mit RC-Switch raufgespielt.

Ergebnis für einen Schalter wäre folgendes:
Received 3061380518 / 32bit Protocol: 2
Received 3195598246 / 32bit Protocol: 2

Wenn ich beide 32Bit langen Werte vergleiche ist der Unterschied an der 5. Stelle:
10110110011110001111010110100110
10111110011110001111010110100110

Jetzt stellt sich mir die Frage wie ich das in die Definition übernehme?

Hat jemand eine Idee?

[Beta-User]

Flashe den Arduino doch mal mit der Signalduino-Firmware (unterstellt, die PIN-Belegung paßt). Damit könnte dann das autocreate klappen, den Code sollte dann auch der CUL "verstehen", wenn du das IO-Device danach änderst.

[litronics]

Danke für den Tip - werde ich nachher mal testen.

Was mich aktuell etwas mehr irritiert ist, wenn ich ein IT Gerät mit Bit-Code definiere, z.B. so
define RSL_Schalter1 IT 01010010101011101000000110 1 0011

Dann bekomme ich in meinem Sniffer nix angezeigt - ergo wird FHEM auch nicht auf 433MHz senden.
Ich hätte ja gehofft darüber herauszufinden, wie ich den Bit-Code drehen muss.

Kann es sein, dass mein CUL die verschiedenen Protokolle nicht kann?

[Beta-User]

Kann es sein, dass mein CUL die verschiedenen Protokolle nicht kann?

Evtl. solltest du mal die a-culfw testen.

[litronics]

Sodalle - a-culf 433 auf dem CUL geflashed und Autocreate legt auch devices an

Allerdings sind es keine Schalter:

Code Auswählen Erweitern

define ABS700_135 CUL_TCM97001 CUL_TCM97001_135
attr ABS700_135 event-min-interval .*:300
attr ABS700_135 event-on-change-reading .*
attr ABS700_135 room CUL_TCM97001
define FileLog_ABS700_135 FileLog ./log/ABS700_135-%Y.log ABS700_135
attr FileLog_ABS700_135 logtype temp4hum4:Temp/Hum,text
attr FileLog_ABS700_135 room CUL_TCM97001
define SVG_ABS700_135 SVG FileLog_ABS700_135:SVG_ABS700_135:CURRENT
attr SVG_ABS700_135 label "ABS700_135 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_ABS700_135 room Plots

Es sieht wohl so aus als wären die Conrad RSL-Schalt-Aktoren nicht wirklich mit Intertechno kompatibel

Hat vielleicht jemand eine Idee wie ich die noch an's laufen bekomme?

[KölnSolar]

Ich meine in Erinnerung zu haben, dass die RSL gingen. Musst Du mal im Forum suchen.

Jetzt hatte ich die Idee ob man nicht den Funkverkehr auf 433MHz nicht einfach belauschen kann. Würde ja reichen, wenn ich das in einem telnet Fenster sehen kann.

Wie und was auch immer Du mit telnet sehen wolltest. In FHEM haben wir dafür den event monitor oder halt das Log. Probier noch mal mit raw X67 und verbose 5 eine Taste an der FB zu drücken. Und ansonsten bliebe nur die harte Tour... Aber da flashen für Dich problemlos zu sein scheint, könntest Du ihn auch als S'duino flashen. Da sieht man etwas deutlicher den Aufbau von empfangenen Signalen.
Grüße Markus

[litronics]

ich werd jetzt noch wahnsinnig mit den RSL-Schaltern...

Nachdem auslesen des Hauscodes und automatisches Anlegen (mit a-culf433 auf dem CUL) nicht funktioniert hab ich noch folgendes Versucht:

Anlegen  in FHEM und neues Anlernen der Schalter --> geht nicht
Anlernen in der ezControl um dann den Schalter neu anzulernen --> geht nicht

Als nächstes werde ich wohl die Kommunikation von FHEM mit meinem Arduino Sniffer mitschneiden und dann einen kleinen Code schreiben der das Signal ständig sendet - vielleicht klappt das Anlernen dann.

Falls noch jemand andere Ideen hat - wäre ich echt dankbar!

[litronics]

so nach weiteren Tests glaube ich, dass das Conrad RSL NICHT mit IT kompatibel ist!

In der EZcontrol kann ich sowol IT, IT V3 sowie RSL einstellen. Die beiden IT Varianten werden von FHEM mit Signalduino einwandfrei erkannt und eingetragen.
Die RSL Konfiguration dagegen überhaupt nicht.

Ich habe auch versucht die Schalter auf IT oder IT V3 einzulernen mit der EZcontrol als Sender. Das klappt auch nicht - dagegen mit RSL funktionieren die Schalter perfekt.

Scheint wohl so, als müsste man das Protokoll noch implementieren

[Wzut]

Das war auch mein Stand vor 2,5 Jahren -> https://forum.fhem.de/index.php/topic,33413.0.html
RSL ist IT ähnlich aber eben nicht gleich

[litronics]

So ist es wohl

mittlerweile habe ich auch die Protokoll-Spec so einigermaßen zusammen.

Gibt es denn irgendwo ein Tutorial wie man so ein Modul programmieren muss?
Für mich persönlich muss das nicht viel können ausßer eben genau diese Schalter zu schalten. Kein Auslesen, kein Autocreate oder sonst irgendwas aufwändiges - einfach nur Schalter an und Schalter aus

Mein jugendlicher Leitsinn sagt, dass das nicht so schwer sein kann...

[CoolTux]

Wiki, Developer Guide.

[Wzut]

Mein jugendlicher Leitsinn sagt, dass das nicht so schwer sein kann...

Das war auch für einen alten Mann kein großes Hexenwerk, die bestehende IT .c genommen , Startsequenz und Puls/Pause etwas angepasst , einen neuen Kennbuchstaben festgelegt und unter neuem Namen abgespeichert.
(kann heute Abend mal schauen ob die noch irgendwo auf der Platte liegt)
Dann die a-culfw mit der neu eingebunden rsl.c kompilieren und flashen, damit ging dann das schalten meiner RSL Rollo Aktoren. Das Thema RSL Empfang habe damals nach einigen unbefriedigenden Versuchen eingestellt. 

[Ralf9]

In der EZcontrol kann ich sowol IT, IT V3 sowie RSL einstellen. Die beiden IT Varianten werden von FHEM mit Signalduino einwandfrei erkannt und eingetragen.
Die RSL Konfiguration dagegen überhaupt nicht.

Mit dem Signalduino und dem Modul 14_SD_RSL.pm müsste das senden und empfangen von Conrad RSL eigentlich funktionieren
https://forum.fhem.de/index.php/topic,72499.msg

Falls es nicht funktioniert wäre ein log Auszug mit verbose 4 vom Signalduino hilfreich.

Im log müsste es ungefähr so aussehen:

Code Auswählen Erweitern

2017.10.27 17:09:39.056 4 : sduinoD/msg READ: MS;P0=524;P1=-1272;P3=-6830;P4=1094;P5=-672;D=034501450145010145450145450101014545014501450101010101010101010101;CP=0;SP=3;R=79;
2017.10.27 17:09:39.056 4 : sduinoD: Matched MS Protocol id 1 -> ConradRSL
2017.10.27 17:09:39.056 4 : sduinoD: Decoded MS Protocol id 1 dmsg P1#A9B1A800 length 32 RSSI = -34.5
2017.10.27 17:09:39.078 4 : sduinoD RSL_Parse Message: A9B1A800
2017.10.27 17:09:39.078 4 : SD_RSL Message parsed Devicecode: B1A800 Buttoncode: 41

Gruß Ralf

[rudikx]

Hallo zusammen,

jetzt habe ich fast alles seit 2015 zum Thema RSL von Conrad hier im Forum durchgelesen und nun bin ich bei dem letzten Thema hier im Thread angekommen, sogar ganz aktuell

Nun suche ich auch eine Möglichkeit die RSL Rolloschalter zu bedienen.

@Wzut: Besteht die Möglichkeit die FW mit der wichtigen rsl.c von dir zu bekommen?
aber wie macht du das dann mit den 3 Sekunden?

Aktuell habe ich einen nanoCUL (selbstbau) mit der aCulFW drauf, ich sehe die Signal der RSL Fernbedienung aber so richtig kann ich damit nix anfangen.

Code Auswählen Erweitern


ON
2017.12.14 18:48:16 5 : CUL/RAW: /o
2017.12.14 18:48:16 5 : CUL/RAW: o/mB35AA
2017.12.14 18:48:16 5 : CUL/RAW: omB35AA/8AA17
2017.12.14 18:48:16 5 : CUL/RAW: omB35AA8AA17/
2017.12.14 18:48:16 4 : CUL_Parse: nanoCUL4 omB35AA8AA17
2017.12.14 18:48:16 5 : nanoCUL4 dispatch omB35AA8AA17
2017.12.14 18:48:16 5 : CUL_REDIRECT (mB35AA8AA17) length: 11 RSSI: -62.5
2017.12.14 18:48:16 5 : CUL_REDIRECT (mB35AA8AA17) match Manchester COODE length: 11
2017.12.14 18:48:16 5 : CUL_REDIRECT decode Oregon 2 (B35AA8AA17)
2017.12.14 18:48:16 5 : bitdata: 1011001101011010101010001010101000010111
2017.12.14 18:48:16 5 : CUL_REDIRECT decode Oregon 3 (B35AA8AA17)
2017.12.14 18:48:16 5 : bitdata: 1011001101011010101010001010101000010111
2017.12.14 18:48:16 5 : CUL_REDIRECT decode Hideki (B35AA8AA17)
2017.12.14 18:48:16 5 : nanoCUL4: search in 1011001101011010101010001010101000010111
2017.12.14 18:48:16 5 : protocol does not match, ignore received package (B35AA8AA17) Reason: Not a hideki protocol

OFF
2017.12.14 18:49:33 5 : CUL/RAW: /om
2017.12.14 18:49:33 5 : CUL/RAW: om/A8AA00
2017.12.14 18:49:33 5 : CUL/RAW: omA8AA00/
2017.12.14 18:49:33 4 : CUL_Parse: nanoCUL4 omA8AA00
2017.12.14 18:49:33 5 : nanoCUL4 dispatch omA8AA00
2017.12.14 18:49:33 5 : CUL_REDIRECT (mA8AA00) length: 7
2017.12.14 18:49:33 5 : CUL_REDIRECT (mA8AA00) match Manchester COODE length: 7
2017.12.14 18:49:33 5 : CUL_REDIRECT decode Oregon 2 (A8AA00)
2017.12.14 18:49:33 5 : bitdata: 101010001010101000000000
2017.12.14 18:49:33 5 : CUL_REDIRECT decode Oregon 3 (A8AA00)
2017.12.14 18:49:33 5 : bitdata: 101010001010101000000000
2017.12.14 18:49:33 5 : CUL_REDIRECT decode Hideki (A8AA00)
2017.12.14 18:49:33 5 : nanoCUL4: search in 101010001010101000000000
2017.12.14 18:49:33 5 : protocol does not match, ignore received package (A8AA00) Reason: Not a hideki protocol

Danke und Gruß, Rudi

[Wzut]

@Wzut: Besteht die Möglichkeit die FW mit der wichtigen rsl.c von dir zu bekommen?
aber wie macht du das dann mit den 3 Sekunden?

Komplette FW nein , aber ich habe in einem Backup Archiv von 2015 meinen letzten Stand vom Feb 2015 gefunden.
Vllt findest ja jemand der in dir einbaut. Was ist mit 3 Sekunden ?