KakuNew not recognized

[gerardwr]

Hi,

Let me start with telling you have done an excellent job in creating a reliable recognition of 433Mhz signals. I created my own, but yours is much more reliable.

Just a few remarks: - The "simple" example fails to compile due to a missing declaration of "timings_size". - The "compressed" example fails to compile due to a missing declaration of "pulse_length_divider". EDIT: Fixed by PR #13

Greetings, Gerard.

[SunboX]

ping

[Icesory]

pong?

Next time i work on RFControl i will fix the compilation failures. What is the problem with KakuNew? Any references?

[gerardwr]

Ref : The "simple" example fails to compile due to a missing declaration of "timings_size". I solved this by adding in Setup:

unsigned int timings_size;

Ref : The "compressed" example fails to compile due to a missing declaration of "pulse_length_divider". I solved this by adding in Setup:

    unsigned int pulse_length_divider = RFControl::getPulseLengthDivider();

Re the KakuNew issue: I re-tested the recognition of newer Kaku remotes using 132 bits code again, since it was some time ago that I did.

An original Kaku Remote AYCT-102 is recognized reliably every time(132 bits code).

A Home Easy Remote HE844A that sends multiple RF datagrams at every button-push (a.o. KakuNew 132bits) is not recognized reliably. The remote sends the following datagrams:

• a 58 bits code
• 2 repeats of a 50 bits code
• a 132 bits code (KakuNew compatible)

The Sketch reliably shows the 58 and 50 bits code every time, but the 132 bits code is often not shown.

Possibly it's not caused by your code, but by the Home Easy!?

[Icesory]

@gerardwr On which target did you build the library? For the kaku protocol you need at least a buffer size of 270 words. https://github.com/pimatic/RFControl/blob/master/arduino_functions.h#L10

[gerardwr]

I'm building on a Mac for Arduino Nano Atmega328 with Arduino 1.6.7.

I added the following to my Arduino sketch now, and re-tested. #define MAX_RECORDINGS 300 // fallback for undefined Processor.

This did not change the behavior. Again, the 132 bits Kanunew datagram of the Home Easy remote is listed only in appr. 50% of the time :-( The other 50/58 bits datagrams are listed every time.

The 132 bits Kanunew datagram of the Kaku AYCT remote is listed every time.

Possibly the repeat-number of 132bits datagrams sent bij my Home Easy switch is not sufficient. I think you're checking for 2 sequences of the same diagram before listing it, right?

[Icesory]

yes, RFControl needs two identical transmissions to verify the data. You can use the raw method to see if something is received.

  if(in_raw_mode){
    if(RFControl::existNewDuration()){
      Serial.print(RFControl::getLastDuration() * RFControl::getPulseLengthDivider());
      Serial.print(", ");
      static byte line=0;
      line++;
      if(line>=16){
        line=0;
        Serial.write('\n');
      }
    }
  }

Eventually produced this a lot of messages in your console.

Did you use the Pimatic or Homeduino projects?

[gerardwr]

Hi Ronny,

Thanks for your comment.

Reading Raw data as you suggested DOES deliver a constant stream of output in the Arduino Serial Monitor. So much, that spotting a valid datagram is not possible :-(

I imagine I'll have to accept that the Home Easy RF data and your library are incompatible, considering the fact that an original Kaku remote is recognized just fine.

BTW, I'm not using Pimatic/Homeduino.

I've been decoding the datagrams of many RF devices in the past years, using my own software. Not nearly as sophisticated as yours. In an interrupt routine I measure the #usecs between interrupt flanks of the RF signal, and store this value in a circular buffer. In "loop" I scan the circular buffer for an assumed end-of-datagram (a looooonger pulse). The length of 2 subsequent end-of-datagram pointers is for me an indication of the datagram type. 50 bits for PT2262 device, 132 bits for Kaku device, 74 for an RF temperature sensor, etc.

For reverse engineering of new RF devices I had no "fancy" RF sniffer, so I use your RFcontrol for that.

Funny thing : I ran the RFcontrol_simple sketch on my Wemos D1 ESP8266 board, and the Home Easy 50/58/116 bits are recognized fine, but NO 132 bits datagrams are recognized at all! The real Kaku AYCT is recognized at all. I'm confused.

Thanks for your support.

[Icesory]

The ESP8266 Bug is solved with my last commit. The Buffer was to small. Alternatively you should look at RFLink and rc-switch both are arduino based 433MHz decoding softwares.

[gerardwr]

Thanks for solving the ESP822 bug! For me the result is still:

• Kaku AYCT remote 132 bits datagram recognised OK
• Home Easy remote 132 bits datagram recognised some of the time (app. 50%)

Appreciate the hint for alternatives, have tried rc-switch and RFLink before, but have best results (on Arduino and ESP) with RemoteReceiver/NewRemoteReceiver from here: https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home The example sketch NewRemoteReceiver/ShowReceivedCode receives the 132bits datagram from both Kaku and HomeEasy reliably on Arduin and ESP. This code also awaits 2 repeated datagrams. Not sure what causes the RFControl issues I have :-(

Thanks.

[Icesory]

Can you please a capture of the raw data stream. I mean start the raw function. Send multiple times your Home easy commands. Finally post the big data file in pastebin or Dropbox. I will look what the failure is.

[gerardwr]

http://pastebin.com/z6KcXwSK

Pastebin contains:

• Arduino Sketch I used (just to make sure I got it right)
• copy of Arduino Serial Monitor output, 4-5 pushes on the remote button

Good luck hunting, thanks!

[mwittig]

I am re-opening this as the "KakuNew not recognized" issue has not yet been fixed as far as I can see,

@gerardwr Can you please clarify on the current status. Thanks!

[mwittig]

No feedback. Closing this now