RFsniffer and new auto learn KAKU

[poudenes]

Hi there,

Is there a possibility to grab codes send by wall switches of Kaku ?
Kaku uses a new type where receivers have auto learn coding.

Kind Regards,

[Martin-Laclaustra]

Check this issue out.
Its experimental, but it might work.

[poudenes]

Tried everything... not working. The new switched don't have any wheels for A-P and from 1-16
but the receivers learning the unique code of the sender

[Martin-Laclaustra]

Try to record the signal of the transmitter with ReceiveRF.py.
You might consider showing the image zoomed into one single pulse if you can not interpret yourself.

[poudenes]

Thanks Martin,

Ill try it later. Im running OSMC so will create a new SD-card with Rasbian and follow the instruction. Hope ill figure it out :D

Thanks for pushing me into right direction

[poudenes]

this is the screenhot i got

[Martin-Laclaustra]

You are welcome!
Observing your signal, it seems that it behaves like one of the NEXA protocols. They are described here and here.

This does not work with my protocolless receiver (for receiving), but it might work with the original library (for receiving). Sending should be possible with both.

There has been an attempt to create a protocol for NEXA. You would need different timings, but it might be the next thing to try because you code is very long!

Now, let me tell you about your signal (I did some measurements manually):
The protocol looks like this:
{ ???, { 1, 8 }, { 1, 1 }, { 1, 4 }, false }
The question marks are the width in milliseconds of the thin pulses up in your signal (because you do not have values in the X axis in your image, I can not measure it). You can measure this interactively in the python script.

Then the code in your signal seems to be the following:

0110 0110
0101 0101
0101 0101
0110 1010
1001 1001
1010 0110
1001 0110
1001 0110

wow! 64 bits
In decimal:
7373893881221781142

Please post your pulse length back (the ??? value), and report whether you succeeded to receive and send codes.
Good luck!

[poudenes]

Wow.. what a wonderful explanation :D ill will switch SD card tomorrow and do some more test with same switch and see if the pulse will always the same. Then i will send a image with the X axis :)

Thanks a lot for this already.. I already have fun with idea i can create those pulse images and learn step by step more how it works :)... Finally it will work and my Homebridge is complete haha

[poudenes]

I recorded all my switches. Here 2 from my living room switch. At the end they have a little difference.
Now you also have the pulse length.

[Martin-Laclaustra]

I measured in your picture, but you should revise the measurements and the calculus.
You can go on by yourself from here. Please report your advances, so that other people can benefit from your efforts.

You can decode your other switch yourself also.
These are the figures:
1.33 s - 1.26 s = 70 millisecs = 955 pixels
73.3 microsecs/pixel
32 ones x 5 units wide + 32 zeroes x 2 units wide = 224 units = 930 pixels = 68167.5 microsecs
~ 300 microsecs/unit (You really should revise this value)
So the protocol should look like this:
{ 300, { 1, 8 }, { 1, 1 }, { 1, 4 }, false }
use it in the NEXA branch. Be sure to use that branch.
Where to go next? use that protocol to send your code... record the "synthetic" code with the python script. Then you will be able to compare your recorded signals, original vs synthetic. Look at the differences and tune the timings so that they look more and more similar... when they become "twins", your sockets will be probably triggered when you send the signal. You could test reception of codes then.
If you have trouble... you should look to the inter-signal timings... is there something else? (you only posted single signals)... what is the duration of the "blanks" between signals?
(I suspect that you may be missing another complementary "sync" signal).
You can advance this on your own now. Good luck!

[KierewietNL]

I'm having the same issue like poudenes so I tried to follow your instructions to measure my signal. Since I'm completely new to Linux and didn't get ReceiveRF.py to work I decided to measure my signal with a logic analyzer, because measuring is something I am familiar with :) I measured the following signal:

On the x-axis you see the sample number. I sampled the signal with sample frequency of 300 kHz. So each 3.33 microseconds (not nanosecends like you posted ;-) ) a sample is taken. When analysing the signal I came to the conclusion that the signal can't be divided in units like you do. If I divide the signal in A to F like i did in the picture were CD is 0 and EF is 1 in your analysis, I see there is a difference between the lengths of these signals. When focusing on the C, D, E and F samples I get the following result

The length C and E are the same but differ from the length of D. So they can't be described like units like you do. In the length of D and F is some variation the variations are correlated. If the length of D is small, the length of F is long and visa versa:

So there is a lot of variations in the pulse length. So my question is, how critical is this timing? And can this pulse still be reproduced with your script and your proposed protocol?

[Martin-Laclaustra]

It is unlikely that the remote encoder creates the signal with those details of complexity. More probably the irregular pattern is due to big timing tolerances in the signal creation (delays in switching down to up) (or limits in recording the signal in your experiment). For that reason is it also unlikely that the receiver on your switch is very strict on what to expect. Probably it has a nice receiving range of tolerance. This should be tested! It would be nice to know for sure.
You seem to be willing to experiment. Thats very good! It is needed someone that measures this kind of signal completely.
Please measure the timings inter-trains-of-pulses (before A). This info is still missing. Record 2 or 3 trains and measure in-between. I can try to help you with that to receive (trickier) and generate (easier) your signals.
By your info, your protocol should look like this (you don't report B):
{ 95, { 1, B / 95 }, { 1, 1 }, { 1, 4 }, false }
I do not have a NEXA or alike plug, but I could try to guide you, and if you succeed, a patch and pull request can be prepared to improve rc-switch.
I assume that you work with a raspberry pi.
(Thanks, I will be correcting the microsecs.)

[KierewietNL]

Then I expect these are timing tolerances in the signal creation. The device I use to measure the signals is a professional device which I have confidence in that it is measuring accurate enough. The only remaining uncertainty is de RF receiver. I could try to measure multiple signals in the future to compare them and also detemine the sensitivity of the receivers but for now I will work with the signal I posted before just to get everything working :).

The 95 you're mentioning are samples, and each sample has a length of 3.33 microseconds (samplerate of my device was set at 300 kHz) so one unit would be 317 microseconds. But I think 90 samples comes closer to the truth which makes is 300 microseconds for one unit.

B exists out of 751 samples so my protocol should look like this:
{ 300, { 1, 8 }, { 1, 1 }, { 1, 4 }, false }

Converter my signals to a 64 bits code like you showed before and converted it to decials. The result is 7391926142449063574.

So I tried to following code in the terminal:
sudo ./codesend 7391926142449063574 {300, { 1, 35 }, { 1, 1 }, { 1, 4 }, false }
But I get the respond:
sending code[2147483647]
Also when I measure the signal it doesn't look like the original signal at all. Probably I'm using the wrong "branch" like you said before, but I have no idea how to switch to a different branch. Like I said before, I have no experience with Linux at all, so it would be great if you could help me with this (if this is the problem offcourse).

I measured the timings inter-trains-of-pulses before. It was 3160 samples, sow 3160/90 is 35 units, or 10.5 miliseconds.

And you are correct about the Raspberry. I am using a Raspberry Pi Zero W.

[Martin-Laclaustra]

Open a terminal and write:
sudo apt-get update
sudo apt-get install git
cd ~/Downloads
git clone -b nexa https://github.com/xnaveira/rc-switch.git
with the file explorer, replace rc-switch folder (in your compile directory) with the new one that you just downloaded.
Open "RCSwitch.cpp" with leafpad (the text editor). Add your protocol in line 82 or 83.
Compile (type "make" in the RPi_utils directory).
Test.
(I hope that I have not missed any essential step)
PS. I am looking at xnaveira's code and I have the impression that the inter-trains gap is missing in that code. It host 64 bits but I will check if I can find other fork that tried to include the gap. Report back and we can build upon that (if I can not find the branch first)

[Martin-Laclaustra]

This looks like a more complete NEXA patch:
git clone https://github.com/vamanea/rc-switch.git

Read the links describing the protocols at #112 (comment)

Remember that I do not have a NEXA and I can not test the code.
I am confident that you will succeed in sending codes.
Receiving these codes will require further modification of that program.

[Martin-Laclaustra]

Possibly you need to change some "unsigned long" declarations to "uint64_t" to make sure that your code is stored completely and not truncated. For example:
(line 487) void RCSwitch::send(unsigned long code, unsigned int length)