433mhz RSL Funkschalter nimmt Code nicht an

  • Hey zusammen,

    ich habe diesen Schalter https://www.conrad.de/de/rsl-funk-sc…0-m-640553.html zusammen mit dem Sender https://www.conrad.de/de/rsl-funk-wa…0-m-646602.html angelernt und diese funktionieren im zusammenspiel auch super.

    Nun habe ich mit dem RFSniffer die Codes abgefangen, die der "Lichtschalter" sendet um die Deckenleuchte ein/aus zu Schalten. Es gibt 2 verschiedene Codes. Einen für ein und einen für aus.

    Soweit so gut.. Dachte ich.

    .. Habe wie sonst auch codesend benutzt um die Codes zu senden (433mhz Steckdosen lassen sich so schalten). Jedoch die Deckenlampe nicht.


    An was kann das liegen? Entfernung sollte machbar sein (Eine Funksteckdose ist weiter entfernt und funktioniert)

    Lg

    Einmal editiert, zuletzt von script1996 (20. Oktober 2016 um 19:13)


  • Nun habe ich mit dem RFSniffer die Codes abgefangen, die der "Lichtschalter" sendet um die Deckenleuchte ein/aus zu Schalten. Es gibt 2 verschiedene Codes. Einen für ein und einen für aus.


    .. Habe wie sonst auch codesend benutzt um die Codes zu senden (433mhz Steckdosen lassen sich so schalten). Jedoch die Deckenlampe nicht.


    An was kann das liegen?


    An vielem.

    Zum Beispiel können Empfänger und Sender zur Erhöhung der Abhörsicherheit einen Rolling-Code verwenden. D.h. Der Code funktioniert nur einmal und danach nicht mehr. Prinzipiell macht man das, damit eben nicht per Capture and Replay ein Schaltsignal ausgelöst werden kann. Zu erkennen sind solche Datagramme daran, daß sie sich bei der gleichen Operation irgendwo unterscheiden. D.h. drückst Du mehrfach die An-Taste, erhältst Du mehrere unterschiedliche Datagramme. Nun kann das System durchaus auch nur halbintelligent sein und nach mehreren solcher Zyklen auch wieder "alte" Datagramme akzeptieren. Das wäre zu testen.

    Benötigt der Empfänger vielleicht mehrere korrekte Datagramme hintereinander (Erhöhung der Schaltsicherheit)? Falls ja, spielt die Dir Dein RF-Sniffer ab?

    Sind die empfangenen Codes reproduzierbar? D.h. Eignet sich deine Snifferempfangs- Sendemimik, um dem Empfänger ein korrektes Datagramm vorzugaukeln?

    Richtige Modulationsart?

    ...

  • Hey,

    danke für die schnelle Antwort. Ein Rollingcode kann man denke ich ausschließen, da der Taster jedesmal "961992192" als Code für "AN" sendet. Der Code für "AUS" ändert sich auch nicht, ist jedoch "894883328".

    Der RFSniffer gibt mir jeweils nur "Received 961992192" oder "Received 894883328" aus.
    So sende ich natürlich auch immer einen der beiden Codes, wie ich es von Funksteckdosen gewöhnt bin. Also im Prinzip "codesend 961992192" mehr nicht, da es ja bei Steckdosen komischerweise funktioniert..

    Lg

  • Hallo script1996,


    Ein Rollingcode kann man denke ich ausschließen, da der Taster jedesmal "961992192" als Code für "AN" sendet.


    Das sehe ich nach Deinen weiteren Ausführungen auch so.

    Was wir aber nicht wissen ist, ob die gewählte Abtastrate zur Protokollerkennung auch zum Protokoll Deiner Sender- Empfängermimik paßt. Ich selbst habe mit RFSniffer noch nicht gearbeitet. Nach kurzem Googeln unterstelle ich aber mal folgenden Code:
    a.) https://github.com/ninjablocks/43…s/RFSniffer.cpp
    b.) https://github.com/ninjablocks/43…ls/codesend.cpp
    und als RCSwitch:
    c.) https://github.com/sui77/rc-switch/blob/master/RCSwitch.cpp

    Nun unterstellt schon a.) eine semantische Abhängigkeit des Signals zu gewissen Pulsbreiten. c.) definiert noch weitere Semantik zum zu erkennenden Protokoll. Wenn Dein Codec nun ganz andere Timings hat, dann wird der Sniffer ein z.B. schnelleres Signal nicht abarbeiten können. Das Problem ist, daß RFSniffer Annahmen macht, die für Deinen Sender/Empfänger möglicherweise nicht gelten. Wenn Deine Schalter obendrein ein anderes Modulationsprinzip als das der Amplitudenumtastung (OOK) verwenden, dann hast Du sowieso verloren.

    Ich hatte mir zur Dekodierung meines Autoschlüssels und eines Temperatursenders mal ein Progrämmchen geschrieben, welches einfach die Zeit zwischen Zwei Signalwechseln loggt und in eine Datei schreibt. Das Programm kann die aufgenommenen Werte auch ebenso wieder abspielen. Damit benötigt es keine a priori Information über das Timing eines zu suchenden Codes. Das Programm heißt Tranceiver und liegt den Demoprogrammen meiner Hubo-Distribution bei. Am einfachsten lädst Du Dir das fertige Image runter und probierst (unter ~/HuboDemo/Tranceiver/):

    Code
    sudo ./Transceiver.out r myfile.txt


    zur Aufnahme und

    Code
    sudo ./Transceiver.out w myfile.txt


    zum Test ob Deine Schalter dann schalten.

    Dabei gelten die folgenden Pins:
    receive_pin = 17; // GPIO0
    transmit_pin = 22; // GPIO3


    Anbei der Code, falls Du zunächst mal reinschauen willst, was es macht. Ist alles pretty straight forward und basiert auf einfachem Bitbanging der Broadcomregister.


    Viel Erfolg!

    schnasseldag

  • Hey schnasseldag,

    vielen Dank schonmal für die ausführliche Antwort. Ausprobieren würd ich das ganze schonmal ganz gerne. Nur kommt leider ein komplettes Image bei mir nicht in Frage, da mein derzeitiges perfekt für meine Anliegen angepasst wurde.

    Gibts dazu evtl. eine Gitrepository?

    E: Oh nevermind! Habe den link auf der HP gefunden und werde es mal testen :)

    Vielen Dank und Grüße

    Einmal editiert, zuletzt von script1996 (21. Oktober 2016 um 18:41)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!