pimatic / rfcontroljs

nodejs modul with protocol support for different 433mhz switches and weather stations for the RFControl Arduino library.
GNU General Public License v3.0
49 stars 54 forks source link

Switch1 protocol in rfcontroljs is different from the output from RFControl #7

Closed Icesory closed 9 years ago

Icesory commented 9 years ago

The Protocol switch1 in rfcontroljs is different from the output from the RFControl compressed output.

Output from RFControl Timing_size: 132 b: 217 2676 314 1317 10124 0 0 0 t: 010203020303020203020303020203020302030302020302030203030203020203030203020203030202030302020303020302020302030203020302030203030204

Values in switch1 Timing_size: 132 b: 268 1282 2632 10168 0 0 0 0 t: 020001000101000001000100010100010001000100000101000001000101000001000100010100000100010100010000010100000100010100000100010001000103

Remote is a ITT-1500 wich use se new KlikAanKlikUit protocol

Sometimes is the order of the buckets different. Most it is so: 217 2676 314 1317 10124 0 0 0 But seen so too : 217 2676 1317 314 10124 0 0 0 this ends in a other compressed string which cant decode from my algorythmus. Is this a bug in RFControl? It was easier, the RFControl.compressTimings will first sort the buckets from the lowest to the highest.

Icesory commented 9 years ago

I tested pilight an remote. Booth ca switch my lamps.

pilight off b: 274 2296 1292 8576 0 0 0 0 t: 010002000202000002000202000002000200020200000200020002020002000002020002000002020000020200000202000200000200020002000200020200000203 Timing_size: 132

remote off b: 211 2680 321 1325 10140 0 0 0 t: 010203020303020203020303020203020302030302020302030203030203020203030203020203030202030302020303020302020302030203020302030302020304 Timing_size: 132

sweetpi commented 9 years ago

Hi Icesory,

thanks for your testing and the report.

RFControl is more sensitive than needed for most protocols. So you get sometimes, depending of the accuracy of your remote, different bucket counts.

This is by design, to catch up further protocols that maybe need a higher sensitivity.

The approach currently is the following:

  1. Record the (maybe to many) buckets and compressed pulses with rfcontrol.
  2. Sort them in rfcontroljs prepareCompressedPulses (https://github.com/pimatic/rfcontroljs/blob/f39db799ae1fc86cda74c33a01c27da40eb3c9e8/src/controller.coffee#L68).
  3. Try to find a matching protocol in rfcontroljs decodePulses (https://github.com/pimatic/rfcontroljs/blob/f39db799ae1fc86cda74c33a01c27da40eb3c9e8/src/controller.coffee#L118)
  4. If we have more than 3 buckets and two of the buckets are similar (b1*2 < b2) we merge them to just one bucket by averaging and adapting the pulses in rfcontroljs fixPulses (https://github.com/pimatic/rfcontroljs/blob/f39db799ae1fc86cda74c33a01c27da40eb3c9e8/src/controller.coffee#L89)
  5. Go to step 3

I added the fixPulses recently, so be sure to use the newest version of rfcontroljs. So your algorithmus should work if we both implemented our stuff right. It could be that there are still some bugs in my code. I have to review it later.

Icesory commented 9 years ago

I would decode the protocol on the arduino. So i cant use the js stuff. but i will look at the functions.

sweetpi commented 9 years ago

I think if you want to decode the protocol on the arduino directly, the best is to adapt the deltas for the specific protocol. I will add your compressTimings function to the arduino version, so you can use this in combination and add a macro for the delta, so that these can be easily adapted if needed for a particular usage scenario.

Icesory commented 9 years ago

The exdented compressTimings works god. I would create today a rep for the RF-IR-Remote