KaKu Extend

My girlfriend has multiple remote controlled AC outlets in her room. In Dutch better known as Klik aan Klik uit (Click on Click off) or KaKu for short. They are not the real Klink aan Klik uit brand but a cheaper version of the Action (Dutch dump store). They all work at 433MHz to send the data to the outlets.

In a junk bin I found another KaKu (and a remote) and it would be nice to use it with the rest. But at first they didn’t seem to work with the original set. But after some testing I found out they could work together but only at address 0. Also on and off where reversed. But hey, it’s a start. Enough to open them up more to check the guts. And because new KaKu would replace a normal switch it was a wish to have a local switch/button to turn on/off the light as well.

The remote

I started with the remote. I opened it en found the LP801 chip as the decoder. After some Googleing I found the following image.
LP801 snap

The image quality is crap but I could see a address select. And because of the switches to Vss and Vcc it appeared to be a tri-state input! Because in both remotes you select the address with a simple dip switch (connected to A0 to A4) witch only connects or disconnects and the fact address 0 (all swiches off) worked the same I started to suspect the new remote pulled the line to the other side as the original remote. I confirmed this with a DMM, the new remote pulls the address lines low as where the original remote pulled the lines high. So I de-soldered the common side of the dip-switch and added a jumper to select between pulling low and pulling it up. And indeed, I was now able to switch the original KaKu’s with the new remote. Only, off was on and vice versa…

After tracing down the PCB it appeared all the buttons where connected via a diode matrix and pulled high with a resistor. The buttons (on the original remote) are connected as follows:
KuKa Remote matrix

This makes sens :D The TE is the Transmit Enable line (active low) to start a transmission when any of the buttons is pressed. And when I checked the new remote it was the same except for D0 en D1, they where swapped. Two solder bridges later and the new remote could control the original KaKu’s without a problem :D

The decoder chip

After opening up the new Kaku and a hole lot of Googling aroundecoder icd I found some datasheets of the chips inside. Inside the new KaKu was a LP802B-L2 chip (and the corresponding LP801 in the remote). It’s hard to find some data about this chip but it appears to be the same as some other chips like the HS2272 or PT2272 (and corresponding HS2260 PT2260). So I had some clearer images of the remote and some English text. It made clear what the suffix L2 meant, it has two latching contacts. And after after plugging in the Kaku I started probing. Care-full because it uses just a capacitor dropper to get the low voltage for the chip so it’s all mains referenced.

The capacitor dropper makes a 5V with a zener to power the IC. As expected the dip switched pulled the address lines low (1 to 5) and the device select lines (6 to 10 with 6 being A and 10 begin E) to low as well. Last makes sens because the buttons on the remote are active low as well. D0 or D1 was latched high according to the buttons pressed. One of those drives a transistor to drive the outlet relay.

The mod

IMG_20150609_210258It would be easy to just convert this KaKu to work with the rest. To match the addresses I disconnected dip switch 1 to 5 and soldered on a wire. I also soldered a wire to Vcc and connected them. And indeed, this made the remote respond to the old and new (converted) remote on all addresses. But, again with on and off interchanged…

Fixing this would have been as easy as swapping the base of the transistor to the right Dx pin. But I wanted more! I wanted to be able to switch the outlet local as well. Before I opened the KaKu I had the hope the latch was separate and I could just use 2 buttons to make it latch local. But the chip itself was latching and it wasn’t possible to just connect a switch. At least not in a way I could just both the local and the remote to turn it on/off. Turn it on local, turn it off with the remote er vice versa.) If I could make it turn on local and I would press the off on the remote I had no way to tell this because the output was already latched low.. But luckily the chip has another output, VT! I guess it stands for Verify Transmission or something because the pin is high as long as a transmission to the set address is going on. Now I had a way to detect a command even without a change in state of the output (D-pin)!

I could have used discreet logic (because it’s just some setting and resetting) but I chose a micro controller because that would give me a one part solution (okay, except for a decoupling cap and a switch). I also gave me some flexibility. I chose a PIC12F629 mainly because they are cheap, have an internal oscillator, are small and I had a bunch of them. And after all the Arduino/AVR projects I could finally use my PicKit 2 again.

The hardware

I soldered the IC to a spare piece of prototype PCB. The IC is socketed because I did not add a ICSP-header. Not because it doesn’t fit but it was more work and I wasn’t planning on changing the code soon. Because I glued the switch in the other halve of the housing I soldered on a header for the switch.  This way I could detach the housing when opening the KaKu. The switch pin (GPIO0) is pulled high by the PIC. The 5V is just connected to the 5v from the capacitor dropper, I figured it has enough power to drive a small PIC. I removed the connection between the decoder and the relay and routed it via the micro controller. VT was also connected. And instead of attaching the dip switches to GND or 5V I connected them to a IO pin. This way the micro can change the address range of the KaKu on the fly.

Okay, now I was ready to make some code. I just put a PIC12F629 in a breadboard, connected the programmer and a LED to the relay output and started coding.


The code

But my PIC skills where a bit rusty… I had to check the datasheet quite a few times to check the pins and some registers. In the pasted I used quite some PIC’s but I always used a bit of a crude debounce methode. Mostly because I could in those applications. But this time I wanted to do it right. On the Arduino I’m a fan of the Bounce2 libray. But I write my PIC code in CCS I can only use C, no classes this time. So I started by porting the Bounce2 library to PIC.

I did this by using the build in ticks timer. When set to 1ms it’s the same thing as millis() on an Arduino. In stead of a object for each button I made a typedef for a struct to hold all the info for one button. This can be passed to all the buttons functions: buttonAttach(), buttonRead(), buttonUpdate(), buttonFell() and buttonRose().

typedef struct{
int   pin;
long  lastMillis;
int1  debouncedState;
int1  unstableState;
int1  changed;
} _button;

In this case I only used one instance because VT and data did not need debouncing. But now I have a nice library to use in other projects as well.

The rest of the code was kind of simple. Toggle the output when the button fell and check VT to see is a remote is sending. But I added a program mode. If you press the button when you plug the KaKu in and keep it pressed for 5 seconds it goes into program mode. The output is switched on for 1 second to let you know. The micro starts to alternate the address line to check for pulled high and pulled low remotes (this way you can switch). After a detection of VT going high it saves the state of the address line to EEPROM. Now you have three options:

  1. On/off mode (like it used to be) => Press the On and the Off button after each other (or the other way around)
  2. Toggle with On button (press on, output turns on, press on again, output turns off) => Press On twice.
  3. Toggle with Off button (press off, output turns on, press off again, output turns off) => Press Off twice.

Between the button presses the KaKu acks by turning on the output once. After the second button press the output is blinked twice, the settings are saved to EEPROM and the micro returns to it’s normal program. It does not effect the channel of the KaKu. If the dip switches are set for channel B only the on and off buttons of channel B can trigger the modes. If you want another channel, just change the dip switches. With mode 2 and 3 you can have two KaKu’s with the same address but control the first with the on button and the second with the off button. Instead of 5 KaKu’s you can control 10 with one remote.


I hot glued the small PCB on top op the decoder IC. I then drilled a hole in the front for a button and hot glued it in place. This is connected to the header.


Once closed it looks like this (still on my workbench). Yes, it was a water proof KaKu but I’m only going to use it indoors. It works flawless so my girlfriend is going to be happy. :D


Info and download

KaKu Extend (with debounce lib) v1

Datasheet LP801B/LP802B
Datasheet PT2272
Datasheet HS2272C
PT2262/PT2272 Info page

9 thoughts on “KaKu Extend

  1. I’m surprised you were able to use the built-in power supply/converter to power the PIC. I have a similar old device by Stabo which uses two zener diodes inside a bridge rectifier followed by a few caps to generate around 8V as a first voltage to drive the relay, followed by an 7805 linear regulator to power the RF and PT2272.
    As a first step to modding I added another linear regulator to the the 8V line to power the micro controller separately from the RF. But even before adding the micro controller just the current drawn by my extra linear regulator was enough to lead to a voltage drop at the 8V line to the point that the whole device wasn’t working any more (The 5V became 3V). I’m surprised that the device would work with such narrow specs on the power supply. It’s a cheap device but still they left no room for a few milliamps.

    1. Sorry for the late reaction! Notification mail was send to spam :/

      Mm, that’s weird. Then you were really unlucky. A regulator should draw barely power, same for a PIC/micro. Btw, no need for a separate regulator. Just be sure to add a 100nF cap and you’re all set. The PT2271, my PIC and the RF all work fine on the same supply. And my unit didn’t even used a linear regulator, just a 5V zener (and a regular diode).

      What might happened, if the device wasn’t brand new, that the X2 cap degraded and lost some value. That’s a common failure more of capacitive droppers.

Leave a Comment

Your email address will not be published. Required fields are marked *