Tasmota: Support ZAP outlet switch in Sonoff RF Bridge

[dimitrystd]

Bought on amazon cheap RF outlet switch. They have name ZAP.

Unfortunately RF Bridge returns different codes for the same button. This is what i see in console if press the same button

12:30:47 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5670, "Low":180, "High":540, "Data":"107500", "RfKey":"None"}}
12:30:49 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5750, "Low":0, "High":0, "Data":"10750C", "RfKey":"None"}}
12:30:52 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5670, "Low":180, "High":540, "Data":"107500", "RfKey":"None"}}
12:30:53 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5670, "Low":180, "High":540, "Data":"105500", "RfKey":"None"}}
12:30:54 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5750, "Low":150, "High":570, "Data":"10750C", "RfKey":"None"}}
12:30:55 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5710, "Low":180, "High":540, "Data":"107500", "RfKey":"None"}}

Remote control has chip HS2260A-R4. I found another ESP8266 project and as far as i understood from description this chip is similar to PT2260 and has fixed code.

How can i help with debug? Sorry, don't understand what and where to change in code.

P.S. In general RF bridge works, i use it for doorbell and rf pir sensor.

[benzino77]

I have very similar problem. Two remote controllers. One based on Hx2262 chip, and the other based on PT2264. RF Bridge is able to send codes (which I get from remotes using arduino, 433 receiver and RCSwitch library) to my outlet switches without any problem - rf bridge can on and off them:

cmnd/RFCode 4539729 #ON
cmnd/RFCode 4539732 #OFF

The problem is that RF Bridge reports almost always the same codes for different buttons on remote. For example:
RCSwitch/Arduino returns information (for PT2264):

**Button 1**
Decimal: 13980931 (24Bit) Binary: 110101010101010100000011 Tri-State: 1FFFFFFF0001 PulseLength: 505 microseconds Protocol: 1
Raw data: 15668,1564,516,1564,512,184,1528,1560,516,516,1524,1560,516,516,1524,1564,512,516,1524,1564,516,512,1528,1564,512,516,1528,1560,516,512,1528,1564,516,516,1524,516,1528,512,1528,516,1524,516,1524,516,1528,1560,512,1564,516,

**Button 2**
Decimal: 13980940 (24Bit) Binary: 110101010101010100001100 Tri-State: 1FFFFFFF0010 PulseLength: 505 microseconds Protocol: 1
Raw data: 15672,1560,520,1564,516,508,1528,1560,516,516,1524,1564,512,516,1528,1564,512,512,1532,1560,516,512,1528,1560,516,516,1528,1560,520,512,1528,1560,520,508,1532,512,1528,516,1528,512,1528,1564,512,1560,520,516,1528,512,1528,

but
RF Bridge with Tasmota on it returns always:

Nov 21 21:49:53 10.10.30.18 sonoff-rfb01-5278 ESP-MQT: tele/sonoff-rfb01/RESULT = {"RfReceived":{"Sync":15660,"Low":510,"High":1540,"Data":"D55557","RfKey":"None"}}
Nov 21 21:49:56 10.10.30.18 sonoff-rfb01-5278 ESP-MQT: tele/sonoff-rfb01/RESULT = {"RfReceived":{"Sync":15660,"Low":510,"High":1540,"Data":"D55557","RfKey":"None"}}

RCSwitch/Arduino returns information (for HX2262):

**Button 1**
Decimal: 4539729 (24Bit) Binary: 010001010100010101010001 Tri-State: F0FFF0FFFF0F PulseLength: 329 microseconds Protocol: 1
Raw data: 10223,302,1014,962,358,302,1014,303,1016,302,1014,962,360,300,1019,959,358,302,1016,961,365,295,1019,959,362,298,1017,960,363,297,1019,959,361,299,1019,959,363,297,10
19,959,361,959,362,958,366,955,364,957,363,

**Button 2**
Decimal: 4539732 (24Bit) Binary: 010001010100010101010100 Tri-State: F0FFF0FFFFF0 PulseLength: 329 microseconds Protocol: 1
Raw data: 10237,290,1027,949,367,292,1026,292,1028,289,1027,950,369,290,1030,948,371,289,1032,946,370,289,1031,287,1030,288,1030,946,372,288,1035,943,383,276,1036,942,374,286,1
036,942,374,286,1040,937,373,287,1046,272,1037,

but
RF Bridge returns always:

Nov 21 20:23:40 10.10.30.18 sonoff-rfb01-5278 ESP-MQT: tele/sonoff-rfb01/RESULT = {"RfReceived":{"Sync":10260,"Low":340,"High":1000,"Data":"455551","RfKey":"None"}}
Nov 21 20:23:43 10.10.30.18 sonoff-rfb01-5278 ESP-MQT: tele/sonoff-rfb01/RESULT = {"RfReceived":{"Sync":10250,"Low":340,"High":1000,"Data":"455551","RfKey":"None"}}

_I'm aware of that Tasmota reports data in HEX and RCSwitch in DEC_

[arendst]

Sorry guys but tasmota does NOT decode the RF signals as RCSwitch does. The Sonoff bridge contains a seperate microcontroller receiving and transmitting codes to and from Tasmota. I have no influence on the reception of the RF signal.

You'll have to contact iTead if you think the RF microntroller does a bad job in decoding signals.

[benzino77]

Thanks for quick response!
I do understand that Sonoff bridge have separate microcontroller for RF communication, but you perform a lot of _magic_ in bridge code:

sync_time = serial_in_buffer[1] << 8 | serial_in_buffer[2];  // Sync time in uSec
low_time = serial_in_buffer[3] << 8 | serial_in_buffer[4];  // Low time in uSec
high_time = serial_in_buffer[5] << 8 | serial_in_buffer[6];  // High time in uSec
received_id = serial_in_buffer[7] << 16 | serial_in_buffer[8] << 8 | serial_in_buffer[9];

and I wonder maybe this is a problem?

[arendst]

Try to find out what it does...

I can assure you that the data itself is not changed :-)

[benzino77]

I can see that the data itself is not changed :)
Found this on itead forum:
https://itead.freshdesk.com/support/discussions/topics/11000015088

Support Team claims that:

The receiving supports fixed code 433 frequency, like PT2260, PT2262, PT2264, EV1527, etc.

[benzino77]

I have performed more tests yesterday. An this is observation:

• Changing SFB_TIME_AVOID_DUPLICATE to lower value (200,100,50,5 ms) changing returned data.
• (changed SFB_TIME_AVOID_DUPLICATE back to 2000) pressing button "B" and than button "A" causes that returned data is (not always) ... correct!

[benzino77]

I think #1124 is related.

[benzino77]

I'm wondering about this piece of code:

 if (SonoffBridgeSerialInput()) {
      serial_in_byte_counter = 0;
      Serial.flush();
      return;
    }

/*-------------------------------------------------------------------------------------------*/

    if (serial_in_byte > 127) {                // binary data...
      serial_in_byte_counter = 0;
      Serial.flush();
      return;
    }
    if (isprint(serial_in_byte)) {
      if (serial_in_byte_counter < INPUT_BUFFER_SIZE) {  // add char to string if it still fits
        serial_in_buffer[serial_in_byte_counter++] = serial_in_byte;
      } else {
        serial_in_byte_counter = 0;
      }
    }

Function SonoffBridgeSerialInput returns 0 because it is not 0x55 value. Before it returns 0 it is performing: serial_in_buffer[serial_in_byte_counter++] = serial_in_byte
Then if the character is printable and we are not outside the buffer size there is once again serial_in_buffer[serial_in_byte_counter++] = serial_in_byte;
Is this possible that buffer is filled twice with the same character?

[benzino77]

I've found another remote controller based on HS1527 chip ... and this one is working great. Each button generate different Data information on device console/mqtt/syslog.

What is interesting: https://github.com/sui77/rc-switch/wiki/KnowHow_LineCoding

I do believe that for some devices Tasmota or Software on RF Chip does wrong data processing.

[benzino77]

Theo, you are a Rock Star!

[dimitrystd]

Thanks @arendst . Just tested 5.10.0a and it works fine. For some reason i still see different codes in console, but i can learn codes now and they work if i send them.

P.S. This is what i see in console when press the same button

18:30:23 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5670,"Low":160,"High":560,"Data":"105500","RfKey":"None"}}
18:30:24 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5670,"Low":190,"High":530,"Data":"107500","RfKey":"None"}}
18:30:26 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5690,"Low":170,"High":550,"Data":"10750C","RfKey":"None"}}
18:30:27 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5670,"Low":160,"High":560,"Data":"107500","RfKey":"None"}}
18:30:28 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5710,"Low":190,"High":530,"Data":"105500","RfKey":"None"}}
18:30:29 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":2090,"Low":180,"High":540,"Data":"10750C","RfKey":"None"}}
18:30:30 MQT: tele/rf_bridge/RESULT = {"RfReceived":{"Sync":5690,"Low":180,"High":540,"Data":"105500","RfKey":"None"}}

[MACscr]

So has this been solved in the most recent release or is receiving still inconsistent?

[MACscr]

Why is this closed when the issue still exists?