Problems controlling specific 433 MHz rc sockets


I wanted to do some home automation, (what else to choose for that if not blynk :wink: ) And so I saw some RF sockets for good price, so I ensured it runs on 433MHz (wich they are) bought some. But, it looks like they are using rolling code, and additionally some non-standard protocol :disappointed: . BUT, there is hope, as I found some forum, where apparently, somebody did it working, (another) but… It is in german language :confounded: and google translator… well, is still just google translator. So, I would like to ask for help especially the english-german speaking members of this forum.

Other useful informations:
Brand: SilverCrest
Model: RCR DP3 3711-A IP20 FR 3726
Operating freq: 433.93 MHz
Using RC-switch library on ESP8266 (WeMos mini d1)

I can add more informations as needed. Thank you!

maybe ?

What kinda 433MHz transmitter/receiver do you have on the WeMos?

Looking at the RCSwitch link, it seems that they use 4 different codes in sequence, rather than a true rolling code, and the switches will respond to repeated use of just one of these codes if you want to go that way.

For me, the only benefit of using 433MHz sockets over something like the Sonoff S20 is the handheld remote that you get. However, as decoding the signals from your particular switch is going to be a bit of a pain, and of course keeping Blynk synchronised with the handheld remote is also a challenge (but very do-able), I think I’d use different hardware for the home automation project if I were you.

If you do want to get into decoding weird and wonderful 433MHz devices then sooner or later you’ll end-up using the audio input of your PC and software like Audacity (it’s free!) to analyse the transmission timings.
I was extremely skeptical about this approach when I was trying to decode the signals for my 433MHz window blinds, but having tried all the digital solutions I could find with no success I finally turned to the analogue audio input and had the signal protocol identified and reproduced very quickly.

Also, it helps to have a variety of 433MHz transmitter and receiver modules to try, as some receivers generate so much noise that they’re virtually unuseable, as I’m sure @distans will confirm.


I am using these:

Pretty cheap, but it is doing its job. I have other few 433MHz sockets working with this transmitter just fine, wich codes I sniffed with the receiever, and its working so far so good.

I have a RTL-SDR on hand and I have some recordings, that i was looking at via Audacity, but… I was not looking “hard enough”(?), because I did not figured out anything. If you think, you can do better, I can send you the recordings.

They look as good as most. The ones to avoid are the ones with tuned inductors rather than crystals.

I’m travelling at the moment and although I have a laptop with me it’s probably not the best tool for the job; and the sun on the beach tends to make it difficult to read the screen :sunglasses:

There are a few good tutorials on the Internet, I’ll see if I can find them later and send you a link.


For me, this was probably the single, most useful resource I found for helping me overcome my 433MHz problem:

It has some very useful links, and a method of sending pulses at the correct timing without the need for any library.
You’ll see that I added a write-up on my findings near the end.


Rolling code in a cheap 433 MHz power plugg sounded a bit exotic so I had to do some Google-Fu :man_dancing: and check it out. But I’m not sure to what conclusion I have derived… :face_with_raised_eyebrow:

As per my findings:

The protocol is called QUIGG and have 3 different flavors; GT-1000 GT-7000 and GT-9000. They all seem quite straight forward, just timing and data length that differs slightly, except for maybe the GT-9000. According to a post on the Athom (Homey) forum, the GT-9000 protocol sends a group of (different) data patterns instead of just one (fixed) as @PeteKnight mentioned above. This is not rolling code per definition as the pattern is the same all the time (but probably sender unique).

Here is how implement the different protocols:


If you search for something like “Arduino Quigg” or “Arduino GT-7000” etc you should find some code examples. But it all depends on which protocol your remote is using.

Who? Me? Why? :rofl: :kissing_heart:

Looks like Pilight stole my idea of using an ATTiny for noise reduction. :face_with_raised_eyebrow: But I would call my implementation a preprocessor, not a band-pass filter. :smiley:

I’m back home now if you want to send me a recording or two.



Sorry for late reply, I was busy doing… stuff… :wink:
But I tried some things too in midtime, so let´s take a look:
It really does not look like a rolling code, so, I got RPI, I got 433Mhz Utils for RPI, and captured. :slight_smile: I found some similarities, but the thing is, when I replay the codes, well, nothing happens. Like at all :frowning:. So, if you want, you can take a look, if you will find something:


Edit: Yes, and if you would want some more dumps, or something raw, just say how and I will do my best!

Hmmm, I think we were talking at cross-purposes.
I thought you were going to send me some analogue captures of the waveforms as Audacity files. The data you linked to doesn’t mean anything to me I’m afraid.



Some time passed, and trough some googling, resting and figuring out I got It to work. I am a bit too tired now to explain how I did it but you can take a look at this, especially, if you came here from the google and are looking for the way to get your sockets work with something else than original remote :wink:

The only thing I would like to know, If it is possible to clone my success to work with ESP8266, or at least how to call the RPi over the LAN to execute needed commands.

Thank you all for your support so far, because we all know, that another problems will definitive come in the future.

1 Like

Glad you’ve made some progress.
Can you share the output of one of your captures?


Hello Pete

Sorry for not replying so long but I had a lot of work over top of my head :upside_down_face:
I… actually does not have any captures :confused: I actually firstly discovered/confirmed, that the remote is actually sending multiple codes with different pulselengths. Then I found out that codes actually were changing, but they are just looping between about 5 variations. And then I found out that it is not working properly, because reported pulselength values were waaaay off, but transmitting code had right pulselenth. So, after figuring out the correct pulselength, and the correct code to use, I have sucesfully managed to control my sockets on… pressing button… :smiley: ?

The only “captures” I have ever had, was these I captured with the help of my RTL-SDR, but there was just too much noise to make something out of it, so I never really used them, and before you asked, I think, I even deleted them already… so… sorry for that, I guess…?

If you want so much though, I could make some more captures, but only with RTL-SDR. So say if you are interested…

Thank you anyways for the support. I would have beed given up, if you were (actually all in this thread, not only you, Pete, but you was biggest help.) not there for me and others.


1 Like

No, it’s no problem.
I was just curious and wanting to increase my knowledge of 433 protocols.

I found that capturing the data packets using a sound card and analysing the results in Audacity was really quite simple. Much easier than looking at a screen full of numbers - probably something to do with the way my brain works.

Anyway, glad all is working well.


sudo ./codesend CODE 4 355
Solved this for me. CODE is one of the repeating codes.