Help needed to decode/replay UK dimmer light switch RF 433Mhz signal

Hi there

As like many before me, I’m trying to “smart up” my house and I’ve decided to start with a smart light switch. I purchased the below light switch which comes with this RF 433Mhz remote

Eager to try and replace the remote with an arduino and RF433Mhz transmitter/receiver I started trying to sniff the signals using the rc-switch library, as I had done successfully for my energenie UK plug sockets (one like this ) a few weeks earlier.

The rc-switch GitHub - sui77/rc-switch: Arduino lib to operate 433/315Mhz devices like power outlet sockets. library was not capturing any details and I soon realised I was not alone. After trawling through dozens of forums and trying other libraries like the Martin Laclaustra (GitHub - Martin-Laclaustra/rc-switch: Arduino lib to operate 433/315Mhz devices like power outlet sockets.), Radiohead, Livolo as per lots of useful tips in this post (as this light switch looks identical to mine!), Remote Sensor, Remote Switch, RFReceiver - none of them worked.

I then stumbled on the forum which suggested this read to record the signals in an audio program like Audacity. It’s a great read and this is where I’ve had some success but now I’m stuck decoding the RF signals. I did the same exercise for the energenie plug sockets, for which I already knew the binary codes, and the decoded signals in Audacity were a match, but I’m struggling with this light switch remote. I can definitely see a pattern repeated over 40 times however I think there must be another signal before it that I’m missing, perhaps the “pairing” signal so the light switch knows it’s the paired remote?

The code I’ve managed to get so far from this is 110111010111100111110100, but sending that in rc-switch mySwitch.send(“110111010111100111110100”) does nothing and I’ve tried random setPulseLength() and setProtocol() values.

I believe my wiring of my RF receiver is OK because as I say I can successfully use rc-switch to control my Energenie plug socket via RF 433Mhz. I’d be grateful if anyone could help either by recommending another way I could sniff unknown RF signals, or perhaps help me decode the RF signal in Audacity into a binary code that I can then send using rc-switch.

Attached are a few images of how I came to the above binary code from reviewing the signal in audacity, as well as the WAV file itself.

Any advice would be appreciated.

Thank you
Phil (169 KB)

Its unlikley that RC switch will work on a switch like yours as it has a dimming function, and RC switch isnt used for devices that have incremental type controls.
The only hope is to pull the 4 button remote apart and see if you can identify any ICs that will indicate what type of encoding that it uses.
Otherwise its reverse engineering of an unknown protocol and thats hard.

Its unlikley that RC switch will work on a switch like yours as it has a dimming function, and RC switch isnt used for devices that have incremental type controls.
The only hope is to pull the 4 button remote apart and see if you can identify any ICs that will indicate what type of encoding that it uses.
Otherwise its reverse engineering of an unknown protocol and thats hard.

Thanks for your feedback mauried - apologies for the late reply!

I’ve tried before and I couldn’t identify any ICs in the remote but I can try again and perhaps post a picture of the internal boards of the remote.

Failing that, as you say then it’s hard work decoding unknown protocols - does that mean even with sampling the signals in audio software like Audacity wouldn’t work?


It will show you some kind of signal, but what it means is the problem, and you have to figure out how the signal conveys the data.
ie does it use some kind of Manchester coding which is quite common , or some other sort.

I have had a similar issue with their on/off light switches … frustrating that the broadlink would not read the remote.( not that the broadlink is liked by many as deeper research would appear to show)

The protocol had me brain stumped for a while, but I have sussed it for on/off at least. I don’t have dimmer types so I don’t know quite how they function. If they just send the same code then it may well be that it will work.

I used a cheap logic analyser connected to pin 1 of the Tx chip in the 4 button remote.

After much pondering I sussed the following.

the data frame consists of 12 4bit nibbles.
The last three of which change according to which of the 4 buttons is pressed.
Do not know yet if other remotes change the first 9 nibbles.

The remote sends about 45 frames per hit.
Each frame starts with a 400uS high then a 400uS low. (can be 375 to 450uS )
Each bit of the nibble is detected by a high/lo or lo/hi transition.
It is the width of each transition gap, whether hi or lo determines a 0 or 1 bit.
ie. a hi ‘short’ = 0. hi ‘long’ = 1, lo ‘short’= 0. lo ‘long’= 1
Short duration set at 175uS.(120 -210) long duration is set at 300uS ( 275 -325)

After getting this worked out, I put the data into a spreadsheet which then resovled the code.

In my case the codes worked out as …


Interesting to see only the last three nibbles changed here. I will look at other remotes for these switches to see what else changes between different remotes.

I initially just used an esp32 loaded with ‘fauxmoESP’ and had pull downs connected to the remote pcb.
(The remote seems to be quite happy to work at 5V, although I expect the range is reduced). The fauxmoESP is great in that it replicates a phillips hue lamp, so no ‘cloud’ logon required and the Alexa find it with no problem.

I have just tested a transmitter program to check that it would work, and it does. Next step will be to combine it with fauxmo.

I have attached my quick test ino, which might show a little more.
While I am at it, the spreadsheet as well. Just import csv data from a analyser into the first two columns.

rfremote_test.ino (7.54 KB) (271 KB)

Thought I’d post a scope view of the start of a data packet, and how I connected to use the remote as a TX for the data.
I cut the track from the internal encoder and connected the esp32 drive to the base/gate resistor as shown.

hope this gives a little help


no space for the scope jpg … so it’s here.

This works out as

start hi/ start lo/ 1010 0110 1010 0101 1001 ie start 565A9 etc

Just decoded a second keyfob, which has also paired to the light switches.

These codes are

Don't know why the fourth code is not the same 9 first digits, maybe there is no manf code in there.

When I get a bit more set up, I will play with code numbers and see what pairs up.

One final addition for a while

Download fauxmoESP from github

This prog will fire the remote data out of port 5 on an ESP32, in a response to a call from Alexa.
Run it up. Discover devices.
Devices are REM1 to REM5. Changes names as required…

Put Router Name and Password into credentials_blank.h file and rename as credentials.h

rfremote_fauxmo.ino (9.89 KB)

credentials_blank.h (63 Bytes)

For the sake of completeness, I should mention there is an error in the code which causes resets.
This is where fauxmo has sensed a call and is matching an ID against a defined one.

Fauxmo does not like to deal with long processes within itself, and will cause a reset.
In my haste, I left a call to a routine instead of marking variables, which cause processes to run once outside of the fauxmo routine.

This is at line 140 and should be ' whatcode=2;doSend=1; ' instead of the call to a routine.

If you look at the Alexa call response on the serial monitor, you will see the other lines responding, but asking for REM2 will result in a reset. Altering this line fixes that issue.

Also, I was using the phone app 'buttons' rather than using the word REM1 etc. Alexa seems to find an issue with differentiating 'REM' with ROOM, so best to use alternate names. (change name in devices menu).

I also have just used ID names as all I wanted was on/off control. Note in the Serial Monitor, a value is also sent as the dimming value. This can be assigned to a variable and used as desired.

I think that's about all ......

Nope … there is something else …. don't bother with H3V4F type TX's . They can't handle the higher data rate required. Best to use the Hartington Heath spare remotes as a driver … cheap enough.

Also see

and protocol doc iLumos/iLumos Light Switch protocol.pdf at master · roberttidey/iLumos · GitHub