Reverse Eng Pt 2: Watts Clever Easy-Off w/SMART Box (ES-AUS1103)

Continuing on from my last post about the Watts Clever Easy-Off Sockets with Smart Box, there were a few things still bugging me in the back of my head. After all, they do advertise that their other system has >1 million codes, so how does that work given the few codes I’ve observed? Are some of the fixed bits not fixed at all? How intelligent is the learning in the switches? How do they cope with distorted signals, and how many repetitions are actually necessary?

Part of the reason I started to indulge myself into these questions was because of a post by Mark from NZ a while back on the element14 communities where he analyzed a Watts Clever RF-only version of the switch which uses a 24-bit code rather than the 25-bit code used in my units. The format of the code was different, so that got me thinking, what is the function of the codes and is the conventional wisdom of fixed segments being a sort of preamble to help the receiver lock on/identify the data stream correct?

Pesky Screws

Another reason for my interest is the fact that I couldn’t help but order another stack of these switches just because they were so cheap. Taking them apart is still a drama for me, although this time, I did manage to drill one apart and take the screw out. It definitely is a peculiar screw that I haven’t seen a driver for.

2016041318513182 2016041318513183

Generic Transmitter

To start this investigation, I decided to grab my last 433.92Mhz ASK/OOK transmitter and a spare Arduino board to do some coding. Ultimately, I wanted a generic transmitter, which takes in a serial code string and blurts it out over the air with virtually all the parameters being configurable.

What started off being a somewhat simple Watts Clever “anypacket” sender evolved significantly, because of a realization that other 433Mhz protocols are not always the same. Where the Watts Clever system uses a “fixed” bit-time with a long/short pulse coding, others use a myriad of other techniques including Manchester encoding, pulse distance coding, or pulse position encoding where the pulse moves relative to the beginning of the slot, a type of “phase” encoding if you will.


As a result, I decided the code will end up emulating only binary signalling systems with each zero and one symbol represented by three times – pre-low, high and low. By setting these to appropriate values (including zero), most of the 433Mhz transmission mode symbols can be emulated.

Another parameter required is the delay between repetitions, and number of repetitions. Finally, of course, you need the string of data itself.

The code is as follows (ZIP File Download):

// Generic 433Mhz ASK Serial Bridge by Gough Lui
// For experimental emission of 433Mhz Data Packets
// April 2016

#define DATA_PIN A4
#define KEYBUFFER 256

int sendkey[KEYBUFFER];
int inbuffer[KEYBUFFER];
int sendreps;
int sendkeycount;
int delaytime;
int inputcount;
int zeroprelow;
int zerohigh;
int zerolow;
int oneprelow;
int onehigh;
int onelow;

void setup() {
   // A3 GND, A5 VCC
   while(!Serial) {
   Serial.println("Generic 433Mhz ASK Serial Bridge by");
   Serial.print("Format: Zero-PreLow(us), Zero-High(us), Zero-Low(u");
   Serial.print("s), One-PreLow(us), One-High(us), One-Low(us), Del");
   Serial.println("ay(us), Repetitions, Data");

void loop() {
  Serial.print("Enter Command: ");
  while(!Serial.available()) {  
  while(Serial.peek()!='\r'&&Serial.peek()!='\n') {
    if(Serial.available()) {
      if(inputcount<KEYBUFFER-1) {
  while(Serial.available()) {;
  while(inbuffer[inputcount]!='\0') {
  if(sendkeycount) {
    Serial.print("\r\nSending [");
    while(inputcount<sendkeycount) {
    Serial.print("] ");
    Serial.print(" times with a pause of ");
  } else {
    Serial.println("Generic 433Mhz ASK Serial Bridge by");
    Serial.print("Format: Zero-PreLow(us), Zero-High(us), Zero-Low(u");
    Serial.print("s), One-PreLow(us), One-High(us), One-Low(us), Del");
    Serial.println("ay(us), Repetitions, Data");  }

void senddata() {
  int sendcount=0;
  int loopcount=0;
  while(loopcount<sendreps) {
    while(sendcount<sendkeycount) {
     if(sendkey[sendcount]) {
     } else {

int getcsval() {
  int value=0;
  while(inbuffer[inputcount]!=','&&inbuffer[inputcount]!='\0') {

Ultimately, it takes in a carriage-return terminated line of information that is comma separated, by reading the line into a buffer and then parsing it (somewhat hackishly) to set the necessary parameters and then call a modified version of the Watts Clever sending function to blurt it out.


The code can be used interactively by typing in or pasting into the serial monitor or a terminal window, or you can also automate things by using a batch script file and the echo command on the command line. Note that this seems to only work if the port was already opened once before at the right speed since the unit was plugged in.


Command strings up to 255 characters are accommodated – I didn’t think there was a need for more, although by changing constants, it is possible to increase the buffer size. One issue will be the lack of RAM, which isn’t helped because I parse the incoming buffer and copy the data to be sent into another array (of the necessary characters, transforming ASCII into actual values), whereas a more efficient way may be to rewrite the sending function to expect ASCII character data and pass a pointer to the beginning of the data itself, thus avoiding the copying and halving memory usage. That said, it didn’t seem too important.


I also decided to build myself a nice version of this to make it convenient to use for other 433Mhz projects, since I suspect this timing-based system is going to be useful for later testing as well. As a result, I pulled out a spare Freetronics Leostick and soldered the 433Mhz transmitter module to the back, pulled out some solid core wire and made it a USB plug-in 433Mhz sender.


Part of the motivation to code this was to also make something where I could translate some of the rtl_433 analyzed code into a transmission over the air as well. I wanted to emulate my Quhwa doorbell sender, so I timed the pulses and used the data as returned by rtl_433 to result in a working sender:


I don’t know how the other values from rtl_433 as for the signal timings work, but I’m happy enough since it can be derived using SDRSharp, RTL-SDR in USB mode with an audio editor quite easily. I realized that this code didn’t provide a mechanism for sending preamble and postamble zeros or something like that possibly to help the AGC in the receiving devices lock-on, but I suppose in the end, it doesn’t really matter where the number of repetitions is high (e.g. for the doorbell), although it might be a feature enhancement I might look into later.

Burning Questions Get Answers

From the previous part, we had determined that the general format of transmissions (in the notation as used by the generic transmitter) was:

0,938,249,0,406,782,12000,6,0001101001011111111100001 [ORIG FMT]
0,938,249,0,406,782,12000,6,0001101001011111111111111 [CH7 OFF]
0,938,249,0,406,782,12000,6,0001101001011111111101111 [CH7 ON]

Where F’s are all fixed bits, S indicates the switch action, VVV is the variable channel number.

Bit Toggling

If I want to look for the possibility of more channels, in a non-interfering way, I should toggle the fixed bits and observe the result. As Channel 7 is connected to a light, I can easily visually confirm its status. As a result, I commanded Channel 7 to on, and then sent messages which have one bit toggled from the rightmost fixed bit through to the leftmost.

0,938,249,0,406,782,12000,6,0001101001011111111111110 [CH7 V1] OK
0,938,249,0,406,782,12000,6,0001101001011111111011111 [CH7 V2] NG
0,938,249,0,406,782,12000,6,0001101001011111110111111 [CH7 V3] NG
0,938,249,0,406,782,12000,6,0001101001011111101111111 [CH7 V4] NG
0,938,249,0,406,782,12000,6,0001101001011111011111111 [CH7 V5] NG
0,938,249,0,406,782,12000,6,0001101001011110111111111 [CH7 V6] NG
0,938,249,0,406,782,12000,6,0001101001011101111111111 [CH7 V7] NG
0,938,249,0,406,782,12000,6,0001101001011011111111111 [CH7 V8] NG
0,938,249,0,406,782,12000,6,0001101001010111111111111 [CH7 V9] NG
0,938,249,0,406,782,12000,6,0001101001001111111111111 [CH7 V10] NG
0,938,249,0,406,782,12000,6,0001101001111111111111111 [CH7 V11] NG
0,938,249,0,406,782,12000,6,0001101000011111111111111 [CH7 V12] NG
0,938,249,0,406,782,12000,6,0001101011011111111111111 [CH7 V13] NG
0,938,249,0,406,782,12000,6,0001101101011111111111111 [CH7 V14] NG
0,938,249,0,406,782,12000,6,0001100001011111111111111 [CH7 V15] NG
0,938,249,0,406,782,12000,6,0001111001011111111111111 [CH7 V16] NG
0,938,249,0,406,782,12000,6,0001001001011111111111111 [CH7 V17] NG
0,938,249,0,406,782,12000,6,0000101001011111111111111 [CH7 V18] NG
0,938,249,0,406,782,12000,6,0011101001011111111111111 [CH7 V19] NG
0,938,249,0,406,782,12000,6,0101101001011111111111111 [CH7 V20] NG
0,938,249,0,406,782,12000,6,1001101001011111111111111 [CH7 V21] NG

It was found that bit 25, namely the last fixed bit, appears to be a do-not-care bit. No matter whether it is 0 or 1, regardless of what it was when learnt, the command will be executed.

Therefore, new channels cannot lie by changing bit 25. Instead, all other bits when toggled did not command the existing pre-programmed switch, meaning that the first 20 bits may be useful for new channels, if and only if they are learnable (tested later).

Additional Bits Test

What happens to the switches if we add extra ones to the end or zeroes to the beginning?

0,938,249,0,406,782,12000,6,00011010010111111111111111 [CH7 +1] NG
0,938,249,0,406,782,12000,6,000110100101111111111111111 [CH7 +2] NG
0,938,249,0,406,782,12000,6,0001101001011111111111111111 [CH7 +3] NG
0,938,249,0,406,782,12000,6,00011010010111111111111111111 [CH7 +4] NG
0,938,249,0,406,782,12000,6,00001101001011111111111111 [CH7 -1] NG
0,938,249,0,406,782,12000,6,000001101001011111111111111 [CH7 -2] NG
0,938,249,0,406,782,12000,6,0000001101001011111111111111 [CH7 -3] NG
0,938,249,0,406,782,12000,6,00000001101001011111111111111 [CH7 -4] NG

As it turns out, the switches ignore the packets entirely. It seems the packets must be 25 bits long for them to be used. Trying to learn these new combinations did not succeed.

Short Packets Test

What happens if we remove some bits from the front? How about if we remote the do not care bit at the end?

0,938,249,0,406,782,12000,6,001101001011111111111111 [CH7 1S] NG
0,938,249,0,406,782,12000,6,01101001011111111111111 [CH7 2S] NG
0,938,249,0,406,782,12000,6,1101001011111111111111 [CH7 3S] NG
0,938,249,0,406,782,12000,6,000110100101111111111111 [CH7 1T] NG

Similarly, as before, no reaction was found for any non-25-bit packet.

Number of Repetitions Test

How many repetitions are needed for the switch to actuate under perfect signal conditions? This would indicate how many copies needed to be received, as often, the number of repetitions of the sender is above that strictly necessary for operation to cover against noise and interference.

0,938,249,0,406,782,12000,6,0001101001011111111111111 [CH7 6R] OK
0,938,249,0,406,782,12000,5,0001101001011111111111111 [CH7 5R] OK
0,938,249,0,406,782,12000,4,0001101001011111111111111 [CH7 4R] OK
0,938,249,0,406,782,12000,3,0001101001011111111111111 [CH7 3R] OK
0,938,249,0,406,782,12000,2,0001101001011111111111111 [CH7 2R] OK
0,938,249,0,406,782,12000,1,0001101001011111111111111 [CH7 1R] NG

It was found that as few as two repetitions is sufficient to cause the unit to switch, although reliability was somewhat poorer. Three repetitions produced much more consistent results, likely because the first repetition may have been lost in the AGC of the front-end of the receiver.

Repetition Delay Test

The default sender uses a repetition delay of about 12ms between sends. How short can this delay be before the receiver cannot handle the signal?

0,938,249,0,406,782,11000,6,0001101001011111111111111 [CH7 11M] OK
0,938,249,0,406,782,10000,6,0001101001011111111111111 [CH7 10M] OK
0,938,249,0,406,782,9000,6,0001101001011111111111111 [CH7 9M] OK
0,938,249,0,406,782,8000,6,0001101001011111111111111 [CH7 8M] OK
0,938,249,0,406,782,7000,6,0001101001011111111111111 [CH7 7M] OK
0,938,249,0,406,782,6000,6,0001101001011111111111111 [CH7 6M] OK
0,938,249,0,406,782,5000,6,0001101001011111111111111 [CH7 5M] OK
0,938,249,0,406,782,4000,6,0001101001011111111111111 [CH7 4M] OK
0,938,249,0,406,782,3000,6,0001101001011111111111111 [CH7 3M] OK
0,938,249,0,406,782,2000,6,0001101001011111111111111 [CH7 2M] OK
0,938,249,0,406,782,1000,6,0001101001011111111111111 [CH7 1M] NG

It appears that even 2ms is sufficient, but 1ms is not as the bit-time is about 1ms, and thus the receiver cannot distinguish the pause from the data stream. A shorter between-repetition pause allows for faster air-throughput, but less protection against noise. It suggests that the receiver resets its reception when it fails to see a signal for >1ms.

Pulse Length Variation

How short can we make our pulses, and coincidentally, how fast can we send the signal with the switch still able to recognize it?

0,700,200,0,290,600,12000,6,0001101001011111111111111 [CH7 1124] OK
0,600,160,0,250,500,12000,6,0001101001011111111111111 [CH7 1333] OK
0,500,135,0,210,425,12000,6,0001101001011111111111111 [CH7 1575] OK
0,485,129,0,210,404,12000,6,0001101001011111111111111 [CH7 1628] NG
0,475,128,0,205,398,12000,6,0001101001011111111111111 [CH7 1658] NG
0,450,120,0,190,380,12000,6,0001101001011111111111111 [CH7 1754] NG
0,420,112,0,180,352,12000,6,0001101001011111111111111 [CH7 1880] NG
0,400,110,0,170,340,12000,6,0001101001011111111111111 [CH7 1960] NG

From the results, it seems like an 80% speed-up in the signal bitrate is achievable without problems. This is not unsurprising as many 433Mhz devices are known to be quite timing tolerant since many of them are produced at very low cost using very imprecise timing references. Of course, this can vary from switch to switch, so working at the high end of the bitrate is probably not a good idea, and could reduce the range.

Switch Code Learning Test

Of the first 20 fixed bits, how many can we change and still have the switches learn the code?

0,938,249,0,406,782,12000,6,0001101001011111111001111 [CH7 V2] USABLE
0,938,249,0,406,782,12000,6,0001101001011111111011111 [CH7 V2]

0,938,249,0,406,782,12000,6,0001101001011111110101111 [CH7 V3] USABLE
0,938,249,0,406,782,12000,6,0001101001011111110111111 [CH7 V3]

0,938,249,0,406,782,12000,6,0001101001011111101101111 [CH7 V4] USABLE
0,938,249,0,406,782,12000,6,0001101001011111101111111 [CH7 V4]

0,938,249,0,406,782,12000,6,0001101001011111011101111 [CH7 V5] USABLE
0,938,249,0,406,782,12000,6,0001101001011111011111111 [CH7 V5]

0,938,249,0,406,782,12000,6,0001101001011110111101111 [CH7 V6] USABLE
0,938,249,0,406,782,12000,6,0001101001011110111111111 [CH7 V6] 

0,938,249,0,406,782,12000,6,0001101001011101111101111 [CH7 V7] USABLE
0,938,249,0,406,782,12000,6,0001101001011101111111111 [CH7 V7] 

0,938,249,0,406,782,12000,6,0001101001011011111101111 [CH7 V8] USABLE
0,938,249,0,406,782,12000,6,0001101001011011111111111 [CH7 V8]

0,938,249,0,406,782,12000,6,0001101001010111111101111 [CH7 V9] USABLE
0,938,249,0,406,782,12000,6,0001101001010111111111111 [CH7 V9] 

0,938,249,0,406,782,12000,6,0001101001001111111101111 [CH7 V10] USABLE
0,938,249,0,406,782,12000,6,0001101001001111111111111 [CH7 V10] 

0,938,249,0,406,782,12000,6,0001101001111111111101111 [CH7 V11] USABLE
0,938,249,0,406,782,12000,6,0001101001111111111111111 [CH7 V11]

0,938,249,0,406,782,12000,6,0001101000011111111101111 [CH7 V12] USABLE
0,938,249,0,406,782,12000,6,0001101000011111111111111 [CH7 V12]

0,938,249,0,406,782,12000,6,0001101011011111111101111 [CH7 V13] USABLE
0,938,249,0,406,782,12000,6,0001101011011111111111111 [CH7 V13]

0,938,249,0,406,782,12000,6,0001101101011111111101111 [CH7 V14] USABLE
0,938,249,0,406,782,12000,6,0001101101011111111111111 [CH7 V14]

0,938,249,0,406,782,12000,6,0001100001011111111101111 [CH7 V15] USABLE
0,938,249,0,406,782,12000,6,0001100001011111111111111 [CH7 V15]

0,938,249,0,406,782,12000,6,0001111001011111111101111 [CH7 V16] USABLE
0,938,249,0,406,782,12000,6,0001111001011111111111111 [CH7 V16]

0,938,249,0,406,782,12000,6,0001001001011111111101111 [CH7 V17] USABLE
0,938,249,0,406,782,12000,6,0001001001011111111111111 [CH7 V17]

0,938,249,0,406,782,12000,6,0000101001011111111101111 [CH7 V18] USABLE
0,938,249,0,406,782,12000,6,0000101001011111111111111 [CH7 V18]

0,938,249,0,406,782,12000,6,0011101001011111111101111 [CH7 V19] USABLE
0,938,249,0,406,782,12000,6,0011101001011111111111111 [CH7 V19]

0,938,249,0,406,782,12000,6,0101101001011111111101111 [CH7 V20] USABLE
0,938,249,0,406,782,12000,6,0101101001011111111111111 [CH7 V20]

0,938,249,0,406,782,12000,6,1001101001011111111101111 [CH7 V21] USABLE
0,938,249,0,406,782,12000,6,1001101001011111111111111 [CH7 V21]

As it turns out, the answer is ALL of them! None of those bits are fixed bits at all, and instead represent a house code. This can be considered like a bank switch, for each unique combination of 20-bits, they get the 5 default (7 extended) + 1 all switches channel.

0,938,249,0,406,782,12000,6,1111111111111111111101111 [CH7 A1S] USABLE
0,938,249,0,406,782,12000,6,1111111111111111111111111 [CH7 A1S]

0,938,249,0,406,782,12000,6,0000000000000000000001111 [CH7 A0S] USABLE
0,938,249,0,406,782,12000,6,0000000000000000000011111 [CH7 A0S]

I even checked with edge-case codes, which worked, and were unique rather than bit-mapped – e.g. code 00000000000000000000 is different from 00000000000000000001, etc.

This changes quite a bit, as now, it’s possible to understand where the vendor’s claim of >1 million codes comes from. With the final format as:

0,938,249,0,406,782,12000,6,0001101001011111111100001 [FINAL FMT]
20 "house bits" = 2^20 combinations = 1,048,576 banks
3 "address bits" -> 5 default addresses = 5,242,880 combinations
                 -> 7 extended addresses = 7,340,032 combinations

Therefore, with the 5-default addresses allocated, there are over 5 million individual switch combinations of codes which can be used. The reason this wasn’t understood? Because I only had one sender! (and they’re entirely out of stock of them).

However, this assumes that senders have a unique and even distribution of codes for house codes. Whether this is actually true in practice is doubtable. Also, regardless of this fact, any one sender still only has a set of 5 channels it can use. The house code is fixed in the sender, thus, if the code is captured from the air, the security is compromised and there is no ability to change it.

Is this likely to be a problem in real life? Probably not, unless you have pesky neighbours, or they’re using a system with the same house code. But it’s still worth considering.

Switch House Code Learning Test

Just for kicks, I wanted to see what happens if the switches are put into learning without all-clearing them first. It was found that the last 10 learnt combinations can be kept, thus a switch could actuate on at most, 20 combinations (i.e. 10 house codes + channel, and 10 house codes + all channel command).


Without having another sender in hand, I can’t say for sure whether the 20 bit house-codes are being well utilized randomly or whether they’re not used at all. Security still remains rather sketchy, as there is no protection against replay attacks, and the “hard coded” all-channels commands still exists.

However, this is where things get interesting. As I’ve built a generic transmitter, I can now code the switches on any house code, ensuring randomness. Better still, I can guard against all-channels commands by allocating each switch to their own house code, thus making all-channels commands no longer command all switches.

The safest option seems to be to learn every switch on its own house code using the all-channels channel 6. This may sound counter-intuitive, but learning the device on Channel 6 means that it will only respond to calls on Channel 6 (every other channel is that channel AND channel 6), and because Channel 6 is not accessible on regular SmartBoxes, meaning that any neighbour collisions due to using the same system are not likely to occur unless they are raw firing codes like I am.

Using this house code technique leaves me a total of just over 1 million independent channels – more than enough when all I wanted was 12.


I suppose this post shows just what a problem incomplete information can be. With only one sender at my disposal, what I thought were fixed bits turned out to be house code bits which contribute security to the system although whether it is properly used is not known. However, by building a generic transmitter, I was able to make use of these bits, and determine other system parameters, such as the meaningless nature of the 25th bit, and the ability for the repetitions, delay between repetitions and bit-times to be shrunk without major adverse effect, which suggests the plugs have high tolerance to timing variations.

Best of all, I now have a system I can use to emulate pulse-trains read-out from analyzing recorded audio from an RTL-SDR and I’ve got enough independent channels on this system to last me a lifetime.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Electronics and tagged , , , , , , , , , , . Bookmark the permalink.

9 Responses to Reverse Eng Pt 2: Watts Clever Easy-Off w/SMART Box (ES-AUS1103)

  1. Ben says:

    That screw almost looks like the “Tampruf” type, seen here: (about halfway down the page)

    • lui_gough says:

      Thanks Ben!

      Looks like you may be right – it looks to be most similar to the rightmost of the line of Tampruf images on that page. Definitely a pain as it’s not a commonly included bit in most security-driver sets (at least, none of which I presently own).

      Thanks for the information and the useful link.

      – Gough

  2. Cameron Barnard says:

    Why is it a pain when you shouldn’t be pulling it apart anyway?

    • lui_gough says:

      Whether one should or should not be doing something is a matter of opinion. Each to their own – but if you buy something, technically it’s yours, and you should be free to do whatever you want with it.

      Customized screws for so-called safety reasons can also be used as a form of rights management (e.g. Apple’s Penatlobe screws) – are you going to side with the manufacturer who says you’re not allowed to repair your own phone because of a trivial issue and who coincidentally might want to force you into buying a new one at full price? Or a car manufacturer that decides not to make any of the spare parts available for replacement or codes available for you to diagnose the problem? The right to repair, modify and interoperate is a big problem we are coming towards and increasingly roadblocks are put into place just for anti-competitive reasons.

      Other competing products often use more common security screws (e.g. regular triangle, Y-shaped) which are readily opened, or none at all – hence why this is a pain.

      – Gough

  3. Gaz says:

    The Jaycar store in Belconnen, ACT still had some of the kits on the shelf at the same price a few days ago.


  4. JR says:

    Great write up and thank you for taking the time to create such a valuable resource!

    I (noob) am having some trouble configuring some Watts Clever ES-AUS1103 Sockets I purchased from eBay (see link below). which unfortunately did not include a remote!

    Firstly, I have done some research online however the documentation is fairly limited (nRF905 the I cannot seem to find any examples which support the nRF905 transmitter or work out a way to program a socket without having access to an original remote.


    Without (easy) access to a Watts Clever remote, what options do I have to interface and control these directly? (Note I have 5 sockets and no base station or remote).


    I have been using an nRF905 transmitter module from Jaycar (see url below) and an Arduino Mega 2560.

    ** Note the RF905 supports the 433.92MHz band, it does operate at a higher baud rate and makes use of the SPI protocol.


    nRF905 DataSheet (Jaycar)

    nRF905 DataSheet (Detailed)


    I have tried resetting the socket configuration by activating the learning mode and sending several codes (provided in your example), modifying house bits (20), channels/groups(3), switches(1), pulse delays to try and establish any communication with the socket without any response. While troubleshooting I did however receive a response triggered by holding down the reset button on the socket however I have not been able to reproduce this and may have been caused by some external interference.

    While power cycling the socket and holding the reset button on the socket itself, the indicator light flashes quickly for a few seconds and then continuously flashes at a slower rate thereafter indicating the socket config has been reset and is ready to pair. The socket does not switch off power as described in the manual and instead appears to remain in ‘learning mode’.


    1. I am considering whether this might be an opportunity to try and obtain the unique code via brute force however given there are 1×10^6 possible combinations, this could take a while and would involve a refactor to support SPI to use the nRF905.

    2. was also thinking the unique code might be stored on the chipset inside the socket (I have 4 others which may have already been programmed).

    3. Does the socket respond to challenge/requests?

    4. Buy a Watts Clever Remote? Are remotes tied to the sockets or do they simply have unique house codes? Would it be possible to reuse another remotes code provided they are not within range or do they require a base unit?

    5. Buy a transmitter/receiver which has good documentation and support for WattsClever sockets

    6. Give up and opt for a better/safer/expensive solution.

    • lui_gough says:

      Let me try to pick apart and diagnose your issue:
      – Firstly, the Nordic nRF transmitters are GFSK. This means it’s a frequency shift keying style transmitter. The Watts Clever sockets I’ve described use ASK (amplitude shift keying) otherwise known as OOK (on-off keying) and expect the transmitted 433.92Mhz signal to be “turned on and off” rather than changed in frequency as per the Nordic transmitter. This is an extremely primitive system – and accordingly, you should use a cheap-as-chips OOK transmitter – e.g. these ones I’ve tried all work just fine There is no way to generate OOK from the nRF from what I can see, in fact, the nRF is a “smart” fully-integrated solution with packet encapsulation and integrated data protection, so it’s really not the right sort of “low level” device you need to talk with the Watts Clever.
      – All sockets are learning sockets. I’ve got 11 sockets right now, none of them have any fixed codes. Buying their remote is not necessary – in fact that 1103 is for the Smart Box IR transmitter, and isn’t compatible with the remote for their other non-Smart Box system as their coding is different. Since you have an 1103, my bet is that your more advanced nRF module is simply the wrong modulation – you need ASK/OOK and to drive that directly with the Arduino (e.g. with the code that I put up)
      – The sockets are dumb. They don’t have any transmission hardware inside, and cannot “reply” their status. To ensure switching, the transmitter needs to send the same command three times in sequence at the least – and if the socket receives at least one, it will perform the function. Repeating the transmission more than three times has no ill effect and improves reliability.

      – Gough

  5. JR says:

    Thank you for the quick response and apologies for not providing more detail earlier.
    Appreciate your time for looking at this and apologies for my persistence and lack of knowledge if this isn’t something worth persuing however for my own personal satisfaction and learning I am still interested to know whether the nRF905 can be used to emulate ASK/OOK and really appreciate the feedback you have provided and your patience with me (noob).

    I agree with your suggestion to try one of the other cheap as chups RF devices instead which would set me back almost $1AU and are readily available on ebay – I will get a couple of these which will allow me to control the sockets.

    One thing however, its not clear to me whether its possible to program the sockets using any unique address id or does the fact that you mentioned the signal below usable suggest that any house code could be used to program the sockets?

    0,938,249,0,406,782,12000,6,1111111111111111111101111 [CH7 A1S] USABLE

    Also regarding the device addressing, the nRF905 (GFSK) requires a TX/RX address to be specified prior to sending the payload. Does ASK/OOK require this too or is this part of the 25 bit payload?

    Regarding the differences between the protocols (GFSK/ASK) as you mentioned, I do recall reading a post regarding this issue however it was not clear from the thread whether the nRF905 is actually capable of supporting (or implementing support for ASK/OOK) for the WattsClever sockets (or any other ASK/OOK remote applications)

    I have been hoping to try and emulate the ASK/OOK protocol by making SPI calls directly to bypass the standard nRF905s nrf905_send() and nrf905_receive() commands provided by the standard nRF905s libraries and as mentioned are designed to facilitate GFSK and the nRF905 specifically and much better suited towards low interference and long range applications than basic IoT devices.

    Assuming the nRF905 modulates the carrier signal, performs encapsulation, CRC and some other automation to transmit data would it theoretically be possible to emulating the much simpler ASK/OOK protocol by setting the transmitter to send a constant carrier which could then be pulsed to emulate ASK/OOK?

    The datasheet suggests TRX_CE must be maintained high instead of being pulsed and Auto Retransmit should be switched off to achieve this with the nRF905. After the initial burst of data is sent the device would continue to send an unmodulated carrier which I am hoping to AM modulate instead preferably without without reconfiguring the device?

    Im not sure whether this could be achieved by toggling the PWR pin or by using an analogue output to achieve AM? This may require an update to the device configuration during transmit mode which would require the device to be put in standby mode and introduce a 650us delay. My understanding is that a persistent connection is required for ASK/OOK to communicate with the sockets and in addition as you mentioned, 3 successful codes to be sent to successfully pair with the deivce.

    Again thank you for your time with this.

    Cheers JR

    • lui_gough says:

      Whether it is possible to emulate ASK/OOK really depends on how fast the device responds to the enable/disable line. If it can’t change over at least ~2400 Hz then it’s not really going to do well with most signals. Toggling power is not likely to work so well because there will be capacitors in the transmitter, so it’s not being “hard” keyed, and instead the signal will “chirp” or fade out slowly which may make detection by the sockets a little less reliable.

      My experience shows that *all 20 bits of house code can be any value* and yet the socket will accept and learn it. In fact, if you don’t want compatibility with the IR SmartBox, you can just choose say channel 6 (all channels, preferable), 7 or 0 (which the boxes can’t emit) and allocate each of them a different house code and that would ensure that none of the sockets would be interfered with by any IR SmartBox users. Each SmartBox has its own house-code fix-programmed into it (and will only emit channels 1, 2, 3, 4 and 5 if I recall correctly), and each socket can “learn” up to 10 distinct house-code and channel combinations (plus the all-channels code #6). The whole idea of keeping your stuff on one house code is only useful if you plan to use channel #6 which is an “all channels” code, meaning “everything with this house code, regardless of channel, power on or power off”. If you don’t want to use this, you have all the freedom in the world to pick any 20-bit house code and any 3-bit channel number and use it. The switches will learn any combination from my experiments.

      Regardless, I still recommend you obtain a cheap ASK/OOK transmitter, verify the code works for you first – this is an important first step to debugging if you then want to get the nRF working, you will know whether the fault is in how the nRF is working or in the switches themselves. It’s cheap, and will save you a heap of time. If you have a spectrum analyzer, I suppose you could use that, but it’s a lot more expensive than an ASK/OOK module.

      – Gough

Error: Comment is Missing!