Go Down

Topic: Kambrook Remote Power Outlet & Arduino - working (Read 22679 times) previous topic - next topic

nevoz

Hello All,

Maurie has told me that his transmitter's codes are different from mine. So based on this, I suspect all transmitters have different codes. The first 4 sets of transitions are the same with our transmitters, but the next 4 sets aren't the same. (Every 4 transitions I have grouped into a "set" .. e.g. "1101 1111 0011" is 12 transitions group into 3 sets).
What this means is that if you are looking to duplicate your Kambrook transmitter's signal, you would need to sniff it first to find out what the code is. However, if you don't care what the Kambrook transmitter's code is, then you can simply use the codes in my arduino sketch and get your Kambrook GPO receivers to learn these signals. It just means you've rendered your Kambrook transmitter useless, which many wouldn't be too fussed about.

craigcurtin


Hello All,

Maurie has told me that his transmitter's codes are different from mine. So based on this, I suspect all transmitters have different codes. The first 4 sets of transitions are the same with our transmitters, but the next 4 sets aren't the same. (Every 4 transitions I have grouped into a "set" .. e.g. "1101 1111 0011" is 12 transitions group into 3 sets).
What this means is that if you are looking to duplicate your Kambrook transmitter's signal, you would need to sniff it first to find out what the code is. However, if you don't care what the Kambrook transmitter's code is, then you can simply use the codes in my arduino sketch and get your Kambrook GPO receivers to learn these signals. It just means you've rendered your Kambrook transmitter useless, which many wouldn't be too fussed about.



Thanks for the update - it would be significant for the WAF i think - as they may still like to reach for the physical remote sometimes !!

Craig

wiseandi

Hi, Thanks for this. Could i please have the codes sent to my email andy.wise91@gmail.com
Thanks once again!

pico

#18
Sep 14, 2013, 07:14 am Last Edit: Sep 14, 2013, 01:54 pm by pico Reason: 1

I initially tried NewRemoteSwitch, RemoteSwitch, and RCswitch. None of these were able to detect this unit. So I used the manual analysis method by sniffing the signals.


Just to say I've had some success implementing a simple sniffer using an Uno and the 4-pin 433MHz recv unit. Sniffer sketch uses the RCSwitch lib http://code.google.com/p/rc-switch/

This isn't for a Kambrook power socket, though, it's appears to be "Efergy" brand (which I hadn't heard of. These units were given to me.) So I thought I'd have a fiddle with these to see if I could get them working with an Arduino, since I already had them at hand.

I've hacked the sniffer sketch so it allows you to plug in the 4-pin recv unit on pins D2-D5, and sources and sinks power using pins D5 and D2. (I'm sure there will be time in purgatory for that. But it beats warming up the soldering iron.) Just make sure your recv unit is rated at < 40mA max power draw (typical appears to be ~10-20mA for these units.) Also, make sure your pins are the same as mine! (or adjust the #defines in the sketch accordingly.)

Here's the sniffer sketch:

Code: [Select]
/*
 RF_Sniffer
 
 Hacked from http://code.google.com/p/rc-switch/
 
 by @justy to provide a handy RF code sniffer

 --

 hacked further by pico to supply power to unit from data pins (lazy!)
 just make sure your recv unit has max draw < 40mA... (typically rated 10-20mA)

 this is set up for a 4 pin recv unit GND DATA DATA VCC
 plug GND into D2, DATA into D3 and D4, and VCC into D5
*/


#include <RCSwitch.h>
RCSwitch mySwitch = RCSwitch();

#define VCC_PIN 5 // source 5V up to 40mA from this pin
#define GND_PIN 2 // sink up to 40mA on this pin
#define DATA_PIN 3 // external int 1 on Uno

void setup() {

 pinMode(DATA_PIN, INPUT);
 // just leave D4 tristated
 
 pinMode(GND_PIN, OUTPUT);
 digitalWrite(GND_PIN, LOW);

 pinMode(VCC_PIN, OUTPUT);
 digitalWrite(VCC_PIN, HIGH);

 Serial.begin(9600);
 mySwitch.enableReceive(1);  // Receiver on interrupt 1 => that is pin D3
 Serial.println("rf_sniffer started");
}

static unsigned long count = 0;

void loop() {
 
 if (mySwitch.available()) {
   
   int value = mySwitch.getReceivedValue();
   
   if (value == 0) {
     Serial.print("Unknown encoding");
   }
   else {
     Serial.print("Received ");
     Serial.print( mySwitch.getReceivedValue() );
     Serial.print(" / ");
     Serial.print( mySwitch.getReceivedBitlength() );
     Serial.print("bit ");
     Serial.print("Protocol: ");
     Serial.println( mySwitch.getReceivedProtocol() );
   }
   
   mySwitch.resetAvailable();    
   count = 0;
 }
 else {
   if (++count == 0) Serial.println("no activity");
 }
}


Here's the output (your sniffed codes will be different, of course!)

Code: [Select]
rf_sniffer started
Received 44262 / 24bit Protocol: 1
Received 44270 / 24bit Protocol: 1
Received 44261 / 24bit Protocol: 1
Received 44269 / 24bit Protocol: 1
Received 44267 / 24bit Protocol: 1
Received 44267 / 24bit Protocol: 1
Received 44259 / 24bit Protocol: 1
Received 44263 / 24bit Protocol: 1
Received 44271 / 24bit Protocol: 1
Received 44264 / 24bit Protocol: 1
Received 44264 / 24bit Protocol: 1
Received 44264 / 24bit Protocol: 1


Only bug I've found is that there seems to be some sort of initialization error regarding synchronization of the recv signal. What this means is that you have to press the buttons on your remote quite a few times before it starts properly receiving the codes. Once it gets the first one OK, they all seem to be read without problem after that, so that's why I'm assuming it's some sort of initalization issue. I haven't bothered to investigate further though... I've got my codes now, and it all works as it should.

I attached an antenna on the transmit unit to give it bit more range... just a 1/4 wavelength monopole affair (aka as a 173mm length of wire  :smiley-mr-green:)

I'll admit it, I did have to heat up the soldering iron for that though.

Anyway, it would be interesting to see if anyone can get the sniffer sketch to work with other remotes.
WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

js898


Hello All,

Thanks to guides on the Internet, I was able to figure out the codes required to control the Kambrook RF3399 remote power outlet.

In Australia, this product is available from Bunnings:
http://www.bunnings.com.au/products_product_kambrook-4-piece-indoor-powerpoint-kit-with-remote-control_P7030054.aspx
http://www.bunnings.com.au/products_product_kambrook-single-indoor-power-point-controller_P4420192.aspx

I initially tried NewRemoteSwitch, RemoteSwitch, and RCswitch. None of these were able to detect this unit. So I used the manual analysis method by sniffing the signals.

I am happy to send these codes to anyone who wants them. I wasn't sure whether I should post it publicly in case it encourages the manufacturer to change the codes.
I am very new to Arduino, and my coding skills aren't great, but it does work.

Something nice I discovered is that I can add extra codes that the Kambrook transmitter doesn't do (but still works with the outlets).. which can be handy in that it would make it difficult for a nearby neighbour to inadvertently control my outlets if he/she were to buy the same kit.



Hi there nevoz. Well done on sniffing the codes and sharing. I have 6 of these units at home and was thinking the same thing, if you could possible forward me the codes please? I will PM you my email address.
I'd like to add feedback control to these units, not sure if at all possible. Could maybe use the existing RF equipment to do that, however I suspect it can only receive signals, and then the remote will also probably onle be able to send signals too. In this case I suspect send and pray protocol will have to suffice.

Principle is you send a command to it, and then expect a reply back indicating command successful or not.
Sending an ON/OFF command:
1) The sender monitor the command return response for ON/OFF confirmation, and timeout.
2) the plug unit return confirmation, relay in ON/OFF position.

Thanks,
J


nevoz

hi js898,

I suspect the transmission is 1-way .. but if you do discover any 2 wy transmission, do share!

You could make it 2-way by placing an RF transmission circuit within the Kambrook unit, but I wonder if it then violates electrical approvals doing so?

pico

#21
Sep 24, 2013, 06:28 am Last Edit: Sep 24, 2013, 07:26 am by pico Reason: 1

I suspect the transmission is 1-way .. but if you do discover any 2 wy transmission, do share!


Definitely no two-way transmission on this style of unit. Maybe something in an X10 style device might offer this capability? I remember (going back a few years ago now) there used to be some X10 units that could be switched by either a RF433 signal or an X10 power line code, and some of these would report their status -- but can't recall if that was just via the X10 power line codes or via RF as well.


You could make it 2-way by placing an RF transmission circuit within the Kambrook unit, but I wonder if it then violates electrical approvals doing so?


Well, yeah, it would definitely violate electrical approvals -- even the manufacturers have to reapply for a new approval if they change their design at all. But unless you are planning to resell the modified units, you are not going to get into any trouble with regulators -- just ensure they are safe for your own use.

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

nevoz


Well, yeah, it would definitely violate electrical approvals -- even the manufacturers have to reapply for a new approval if the change their design at all. But unless you are planning to resell the modified units, you are not going to get into any trouble with regulators -- just ensure they are safe for your own use.


I take it though if there was a fire, an insurance company could use that as a reason to not pay out though (even if it wasn't the direct cause..)

pico



Well, yeah, it would definitely violate electrical approvals -- even the manufacturers have to reapply for a new approval if the change their design at all. But unless you are planning to resell the modified units, you are not going to get into any trouble with regulators -- just ensure they are safe for your own use.


I take it though if there was a fire, an insurance company could use that as a reason to not pay out though (even if it wasn't the direct cause..)


If it was (demonstrably) the direct cause, perhaps. If it wasn't a direct cause, no chance. The courts wouldn't wear it.

The onus of proof would be on the insurance company, however, and after a fire, a lot of evidence is destroyed, naturally.

If you are competent to ensure your modifications really are safe, I don't believe there is a problem, at least not in real terms.

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

js898




Well, yeah, it would definitely violate electrical approvals -- even the manufacturers have to reapply for a new approval if the change their design at all. But unless you are planning to resell the modified units, you are not going to get into any trouble with regulators -- just ensure they are safe for your own use.


I take it though if there was a fire, an insurance company could use that as a reason to not pay out though (even if it wasn't the direct cause..)


If it was (demonstrably) the direct cause, perhaps. If it wasn't a direct cause, no chance. The courts wouldn't wear it.

The onus of proof would be on the insurance company, however, and after a fire, a lot of evidence is destroyed, naturally.

If you are competent to ensure your modifications really are safe, I don't believe there is a problem, at least not in real terms.




Oh my, I never thought of that, I won't use a modded unit then. Having said that, should I discover anything interesting in the RF unit, I will still share it. Thanks for the reality check!

nevoz

Another possible idea..

Not as neat as mucking around with the insides .. but you could place a light dependent resistor on the blue on/off light indicator on the kambrook unit. One annoying downside is that you would need to power this circuit .. whereas if it was something on the inside of the kambrook you could tap into power in that.

js898

I had to test to make sure before posting this, but I can confirm that the remotes and plug units are coded to each other. The reason I am saying this is because I have 2 remotes and 6 plugs units. I have programmed 4 plug units, p1, p2, p3 and p4 to remote r1, and another 2 plug units p5 and p6 to remote r2. I use this configuration just because of convenience of use.

Remote: r1
Program A: p1, p2, p3
Program D: p4

Remote: r2
Program B: p4, p5

r2 will not operate p1 to p4, neither will r1 operate p4 and p5. I suspect each remote has a unique identifier and that the plug unit learns this code when set to learn mode, along with the remote unit's program (A,B,C,D) and corresponding button (1,2,3,4,5).

I thought I'd test my theory and programmed r1 program B to p4 as well. Result is, r1 will control P4 as expected, however r2 does not operate the plug unit anymore. Pretty cool. Very slim chance of someone else having the same remote codes...

What do you think?

nevoz


I suspect each remote has a unique identifier and that the plug unit learns this code when set to learn mode, along with the remote unit's program (A,B,C,D) and corresponding button (1,2,3,4,5).


Yes this is correct, you'll see I mentioned this in the first post on the second page of this thread. It is easy to miss this if you don't read the thread though, so I'll see if I can update my original post with this info.

@nevoz I wonder if you could explain in more detail how you net about sniffing the signal from the Kambrook remotes? All I have been able to do is to use a PC based Oscilloscope to try and catch the signal.

This is what I got from one of my remote buttons.



I would like to be able to sniff and decode all the buttons on my two remotes. Any help appreciated.

pico


I would like to be able to sniff and decode all the buttons on my two remotes. Any help appreciated.


You can try this:

http://forum.arduino.cc/index.php?topic=187951.0
WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

Go Up