search

mightymos / RF-Bridge-OB38S003

Alternative firmware for the OB38S003 and EFM8BB1 microcontrollers present in Sonoff radio to wifi bridges.
BSD 2-Clause "Simplified" License
37 stars 3 forks source link

Unable to transmit correctly with the passthrough firmware #8

Closed saltech1 closed 1 month ago

saltech1 commented 3 months ago

I was able to properly flash the MCU with the latest passthrough firmware. This is my ESPHome config: https://pastebin.com/p22yFTiz

I can capture the original remote successfully, I think: [13:34:42][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='01110101011111000101110010001' [13:34:42][D][binary_sensor:036]: 'Remote ButtonXXX': Sending state ON [13:34:42][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='11110101011111000101110010001' [13:34:42][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='11110101011111000101110010001' [13:34:42][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='11110101011111000101110010001' [13:34:42][D][binary_sensor:036]: 'Remote ButtonXXX': Sending state OFF [13:34:44][D][binary_sensor:036]: 'Remote ButtonXXX': Sending state ON [13:34:44][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='11110101011111000101110010001' [13:34:44][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='11110101011111000101110010001'

But when I try to output this via the transmitter, the appliance doesn't react and this is what I'm seeing in the logs: [13:36:14][D][button:010]: 'Balcony Fan Light off' Pressed. [13:36:14][D][remote_transmitter:075]: Sending remote code... [13:36:15][W][component:237]: Component api took a long time for an operation (922 ms). [13:36:15][W][component:238]: Components should block for at most 30 ms. [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000' [13:36:15][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='1111010101111100010111001000'

Any idea on what can be wrong? Note that the signal are almost identical, but different.

Would really appreciate the help.

the-mentor commented 3 months ago

From what I'm seeing you are trying to decode the fan on the device itself. The problem is not that the device is not transmitting it's thst it's not transmitting the right thing. You will need to decode the fan with a tool like Universal radio hacker and a USB receiver on your computer A few of us created a discord server to troubleshoot this kind of stuff if you're interested

saltech1 commented 3 months ago

Yes, I am interested in troubleshooting this.

I don't have a USB receiver, any cheap device from AliExpress that would get the job done?

mightymos commented 3 months ago

I think people use the RTL-SDR USB. I think official versions are about $20 US.

You should be able to use the "dump: all" or "dump:raw" decoding to view timing in microseconds, but I admit I have not used this myself to decode unknown protocol. I don't think you would provide a protocol or code in this case so those lines would be deleted, it just tries to dump anything it sees that appears valid. Maybe you can try modifying the YAML first to confirm timing before buying a new hardware?

saltech1 commented 3 months ago

I've changed the yaml to dump:raw.

I pressed a key, and this is what I get: _ [19:09:50][I][remote.raw:041]: Received Raw: [19:09:50][I][remote.raw:041]: Received Raw: [19:09:51][I][remote.raw:041]: Received Raw: [19:09:51][I][remote.raw:041]: Received Raw: [19:10:00][I][remote.raw:041]: Received Raw: [19:10:00][I][remote.raw:028]: Received Raw: 220, -1267, 1096, -382, 1099, -382, 1099, -378, 379, -1096, 1102, -382, 379, -1096, 1105, -385, 379, -1096, 1105, -379, 1101, -380, 1096, -381, 1102, -379, 1096, -385, 375, -1100, 381, -1099, 385, -1096, 1106, -381, 379, -1093, 1107, -387, [19:10:00][I][remote.raw:041]: 1096, -385, 1096, -378, 379, -1096, 385, -1102, 1103, -388, 379, -1096, 385, -1096, 385, -1096, 1102, -382, 1099 [19:10:00][D][binary_sensor:036]: 'Remote ButtonXXX': Sending state ON [19:10:00][I][remote.raw:028]: Received Raw: 1103, -379, 1099, -382, 1096, -382, 1099, -381, 379, -1096, 1103, -385, 375, -1096, 1102, -385, 379, -1096, 1106, -382, 1096, -384, 1097, -382, 1096, -382, 1096, -385, 378, -1093, 385, -1101, 383, -1096, 1103, -385, 375, -1096, 1105, -389, [19:10:00][I][remote.raw:041]: 1096, -382, 1096, -382, 379, -1096, 385, -1102, 1103, -388, 378, -1096, 385, -1093, 388, -1093, 1105, -382, 1096 [19:10:00][I][remote.raw:028]: Received Raw: 1103, -381, 1096, -382, 1099, -382, 1099, -382, 378, -1093, 1106, -381, 379, -1092, 1106, -385, 379, -1096, 1105, -380, 1098, -382, 1096, -382, 1099, -382, 1096, -381, 382, -1093, 385, -1099, 385, -1096, 1102, -385, 379, -1092, 1106, -388, [19:10:01][I][remote.raw:041]: 1096, -382, 1099, -382, 378, -1093, 385, -1102, 1109, -382, 382, -1092, 386, -1095, 386, -1097, 1105, -378, 1099 [19:10:01][I][remote.raw:028]: Received Raw: 1103, -382, 1096, -388, 1093, -382, 1099, -379, 378, -1096, 1103, -382, 382, -1092, 1103, -388, 379, -1096, 1102, -382, 1096, -382, 1099, -382, 1096, -382, 1099, -382, 378, -1093, 385, -1102, 382, -1096, 1105, -379, 382, -1092, 1106, -388, [19:10:01][I][remote.raw:041]: 1097, -381, 1100, -381, 379, -1094, 387, -1099, 1105, -387, 378, -1096, 385, -1093, 385, -1096, 1108, -379, 1096 [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: 175 [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: -1650 [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: -837 [19:10:01][I][remote.raw:041]: Received Raw: -721 [19:10:01][I][remote.raw:041]: Received Raw: -1818 [19:10:01][I][remote.raw:041]: Received Raw: -2120 [19:10:01][I][remote.raw:041]: Received Raw: -663 [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: -1206 [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: -1370 [19:10:01][I][remote.raw:041]: Received Raw: -2437 [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: -1649 [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: 2728, -453 [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][I][remote.raw:041]: Received Raw: [19:10:01][D][binary_sensor:036]: 'Remote ButtonXXX': Sending state OFF_

there were some more lines below with either 0 or 1 number.

I do not have a specific interest in being able to nicely decode to a known protocol. My only desire is to "replay" the signal so my fan turns on :)

Any directions on how to proceed? Should I just try to transmit the raw signal back remote_transmitter.transmit_raw?

saltech1 commented 3 months ago

I have tried to replay the raw signal back with:

button:

No success :(

mightymos commented 3 months ago

It looks similar to "protocol 1" but sometimes not at the beginning. So you should see things like about 1050 microseconds followed by 350 microseconds or the opposite to represent different bits (i.e., 0 or 1). There would be 24 bits for protocol 1, so 48 numbers total.

I do not think the raw dump is showing sync pulses either (should be about 10850 microseconds) between repeats, so that could also cause decoding problems if we do not known if sync timing is correct or not.

Also the log is showing Sending state ON or Sending state OFF. During decoding we do not want any transmissions from the bridge itself so I do not think it is good that these are appearing in the log.

I think my fan that uses radio is at other than 433 MHz. I have some outdoor lights that use a radio remote also that I think is at 433 MHz.

Let me try to play around with decoding and see if I can learn something that will help in the next few days. You might just be able to replay a captured signal timing and have it work but it's just difficult to understand what's going on if the timing does not at least roughly match a known format. You could try it however.

saltech1 commented 3 months ago

Also the log is showing Sending state ON or Sending state OFF. During decoding we do not want any transmissions from the bridge itself so I do not think it is good that these are appearing in the log.

These are the result of the following sensor that tries to pick up this signal. I would guess it doesn't interfere with anything, but I can remove it if it helps.

binary_sensor:

I think my fan that uses radio is at other than 433 MHz. I have some outdoor lights that use a radio remote also that I think is at 433 MHz.

Let me try to play around with decoding and see if I can learn something that will help in the next few days. You might just be able to replay a captured signal timing and have it work but it's just difficult to understand what's going on if the timing does not at least roughly match a known format. You could try it however.

Thanks! Would really appreciate help as I'm stuck at this point.

mightymos commented 3 months ago

Ok, just one clarification for now. Is the "Sending" in the log referring to radio transmission or sending decoding up to the smart home software (in other words it's really radio receiving)?

saltech1 commented 3 months ago

Ok, just one clarification for now. Is the "Sending" in the log referring to radio transmission or sending decoding up to the smart home software (in other words it's really radio receiving)?

Yes it is really radio receiving. I can remove it for clarity, but I don't think it matters.

saltech1 commented 3 months ago

One last question - if I'm repeating back the raw signal and it doesn't work - what could be the reasons? Are the receiving or transmitting functions on the rf bridge not good enough?

Really appreciate the support!

saltech1 commented 3 months ago

I got it figured out with help of ChatGPT :)

It averaged out the signals and gave me this raw signal:

    _- remote_transmitter.transmit_raw:
        code: 
          [907, -603, 1096, -384, 1096, -382, 1099, -380, 378, -1095, 1103, -382, 378, -1094, 1104, -386, 379, -1096, 1104, -381, 1097, -382, 1096, -381, 1099, -381, 1096, -383, 378, -1095, 384, -1100, 383, -1096, 1104, -382, 378, -1093, 1106, -388, 1096, -382, 1096, -380, 379, -1094, 385, -1101, 1105, -386, 379, -1096, 385, -1094, 387, -1095, 1104, -381, 1097]
        repeat: 
          times: 10
          wait_time: 20ms_

This one works with my appliance :) I still wonder what seems to be wrong. It is interesting to see that the first 2 numbers are very different, but the following ones look pretty close.

the-mentor commented 3 months ago

hi @saltech1 github is not the best way to troubleshoot this issues if you want feel free to jump on discord and we'll be happy to help out https://discord.gg/5sbyrDdN

mightymos commented 3 months ago

Good that it's working...probably getting on Discord would be a helpful offer still. What Sonoff HARDWARE VERSION do you have by the way?

I tried checking out the dumps you posted and they seem odd in various ways. One last thing that could be a waste of time.

You could follow these instructions for the passthrough mode with Tasmota: https://github.com/mightymos/RF-Bridge-OB38S003/pull/7/commits/a444c04c229659c9f08b09f8b9148052cfbf04d2

Install using a web browser: https://tasmota.github.io/install/

Then see if the rc-switch implementation built into Tasmota can decode the protocol if it is known. You can then always switch back to ESPHome.

Again this is to hopefully avoid the need to buy another product if possible.

mightymos commented 3 months ago

An example raw format is shown here but I do not understand the starting numbers. I'm sure it is explained somewhere: https://esphome.io/components/remote_transmitter#remote-setting-up-rf

I was able to decode remote commands from a remote that controls my outdoor lights. However I think the lights are out of range for replaying so I'll have to try another setup.

Finally, I am able to transmit between my white Sonoff and EFM8BB1 development kit.

One last thing for now. You could always carefully take apart a remote and look up chip datasheets to try to know with certainty which protocol they are using.