Closed Icesory closed 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
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:
rfcontroljs
prepareCompressedPulses
(https://github.com/pimatic/rfcontroljs/blob/f39db799ae1fc86cda74c33a01c27da40eb3c9e8/src/controller.coffee#L68).rfcontroljs
decodePulses
(https://github.com/pimatic/rfcontroljs/blob/f39db799ae1fc86cda74c33a01c27da40eb3c9e8/src/controller.coffee#L118)rfcontroljs
fixPulses
(https://github.com/pimatic/rfcontroljs/blob/f39db799ae1fc86cda74c33a01c27da40eb3c9e8/src/controller.coffee#L89)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.
I would decode the protocol on the arduino. So i cant use the js stuff. but i will look at the functions.
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.
The exdented compressTimings works god. I would create today a rep for the RF-IR-Remote
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.