RF bridge 433 not receiving correct code when code contains RF_CODE_STOP value

[xoseperez]

Originally reported by: Albert Weterings (Bitbucket: AlbertWeterings, GitHub: Unknown)

---

Hi my first post over here,

I programmed a SonOff Bridge 433 with Espurna and found it not detecting my remote codes.
After searching for hours what was wrong I finally realized my remote is sending data dat is seen by the firmware as RF_CODE_STOP.

When my remote sends the code hex 455503 it turns up as 450000 as the second byte 55 is seen as RF_CODE_STOP. My remote with a PT2264 chip with 12 buttons is sending always codes that start with two bytes 45 55 so all buttons appeared to have the same code.

I dived into the module espurna - rfbridge.ino and found a solution but I'm not fully sure this is the correct way to solve this issue. At line 255 I found:

if (c == RF_CODE_STOP) {

and changed it into:

if (c == RF_CODE_STOP && _uartpos > 9 ) {

This tells the firmware to ignore any byte similar to the RF_CODE_STOP byte as long as there are not at least 9 bytes received. I doubt if 9 is the correct value? For me it works now.

Please confirm the correct value used instead of 9?

[xoseperez]

Original comment by Albert Weterings (Bitbucket: AlbertWeterings, GitHub: Unknown):

---

The way I solved the problem is not the best and need more work. After applying my change the learn function doesn't work anymore

[xoseperez]

The protocol is

• Start byte (0xAA)
• Action byte (0xA0 to 0xA5 at the moment)
• 9 bytes code (2+2+2+3)
• Stop byte (0x55)

The uartbuf contains the action byte plus the 9 byte code, so actually, uartpos (it holds the next position in uartbuf to write to) should never be more than 10 (when uartpos==10 a 0x55 is expected). Problem is that not all codes are that long, learning code is just 0xAA 0XA1 0x55.

You can try this:

if (c == RF_CODE_STOP && (_uartpos == 1 || _uartpos == 10))

There should also be some code there to prevent a buffer overflow. Let me know if the above code works and I'll modify the method.

[xoseperez]

Original comment by Albert Weterings (Bitbucket: AlbertWeterings, GitHub: Unknown):

---

I did some tests with the if statement changed to " if (c == RF_CODE_STOP && (_uartpos == 1 || _uartpos == 10)) "

It is now correctly receiving and learning these codes when send as 24 bits.

HEX = 00 55 A5 - DEC = 21925 - Send as 24 bit

HEX = 55 A5 55 - DEC = 5612885 - Send as 24 bit

HEX = 00 44 44 - DEC = 17476 - Send as 24 bit

HEX = 55 55 55 - DEC = 5592405 - Send as 24 bit

I'm not able to send in less than 24 bit but it looks like the problem is solved this way.

[xoseperez]

The RFBridge is limited to 24bit codes so that should do. Will modify the method to account for this and check a possible buffer overflow.

[xoseperez]

Released with 1.11.4

[xoseperez]

Removing milestone: 1.11.4 (automated comment)